Skip to Content.
Sympa Menu

sm-users - Re: [SM-Users] menuconfig for casts

sm-users AT lists.ibiblio.org

Subject: Sourcemage Users List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: Arthur Nascimento <tureba AT gmail.com>
  • Cc: sm-users AT lists.ibiblio.org
  • Subject: Re: [SM-Users] menuconfig for casts
  • Date: Fri, 16 Dec 2005 20:04:15 -0800

On Fri, Dec 16, 2005 at 05:58:54PM -0200, Arthur Nascimento wrote:
> Hi!
> May I join this conversation? Since nobody else is joining I thought I
> could make myself an example and bring other lurkers into the chat.
>
> 2005/12/16, Thomas Orgis <thomas-forum AT orgis.org>:
> > But still I have to watch out for the question I want to answer
> > differently (pressed enter one time too much: redo it again)... and
> > there are these answers that are remembered in a way that I cannot
> > change them (question and answer appearing in []brackets without a
> > prompt) - The rule behind them is not so clear to me. Of course, I
> > could look at the code to find it...
>
> I agree with Thomas on every aspect so far: answering to the very same
> question a second time (or more) is definately a pain. I remember the
> last time I tried to install SMGL, on the initial rebuild, I had to
> answer 3 or 4 times if I wanted to cast gettext.

Check out the syntax for sorcery default add.

> Seems simple enough, since it stops there, but it is a real pain to
> reconfigure xorg over and over again because of so many programs
> depending on it.

Then don't, it should only ask you once, but it will ask you many times
if things might want to use xorg, but it will default to what you
answered before or set in sorcery defaults.

Sorcery leans to ask, to give back power. Sorcery is not Portage, let's
please not try to go away from the philosophy just for some switchers
who want it more like Gentoo.

> Also, there are those questions that just go by automatically answered
> and all I can do is restart the cast asking it to force reconfigure.

The whole point is that during upgrades it remembers what you wanted
before unless you tell it to reconfigure them.

> This could be so easy with a menuconfig-like thingy to help.
>
> >
> > > I'll point out that backing up after you answer a question isnt really
> > > a trivial thing to do in a robust and efficient way. Theres a lot more
> >
> > I didn't say that it is trivial... just that it seems desirable for
> > error-prone humans;-)
>
> Very much desirable for me. Yet, not trivial, that's for sure.
>
> >
> > > going on then whats just presented to the end user. All relavent spell
> > > files are shell scripts in a turing complete language, theres not really
> >
> > Wait. Yes, I already noted that spells consist of shell scripts...
> > but are they really allowed to do everything? Could a spell config
> > script do `rm -f /boot/*` ? I'd think that spell scripts (apart from
> > install) should only (be able to) access system information in a
> > read-only way and store their config/do their compilation in a
> > confined place. And besides what is allowed for them to do, what is
> > possible in reality? Can one guarantee a certain set of commands to
> > be available to the scripts (sed, perl, ...) even on a very, very
> > minimal system? How far does the turing completeness go in reality?
>
> If I may be so bold, I am quite sure Andrew doesn't really mean
> turing-complete.

Yes he does.

> We all know very well what turing completeness means
> and what a universal turing machine is. I know we all are or have been
> computer science or mathematics students, but I will remind us what
> those things mean. A system is turing-complete if it can behave as an
> UTM. UTM is a machine that can do anything/everything (a computer, for
> instance).

That's actually one of Turing's Hypotheses (Church-Turing Thesis), which
has never been proven.

> That said, I am sure sorcery isn't turing-complete

Oh yes it is.

> , and it shouldn't be.

Why not?

> Can it make complex graphics calculations, comet crash simulations,
> play emulated console games

Yes, it can.

> , surf the web, work as a server etc?

Actually, communication systems aren't strictly computational, they are
communicational. While there may be computational assistance in
communication, and communication may be assisted by computation, a
universal turing machine, by itself, cannot perform the task of sending
information to another machine.

> We are not talking about SMGL, but about sorcery (cast+scribe+...);
> SMGL is certantly turing-complete. On a smaller scale, can rmdir make
> a dir? Can mkdir remove a dir? No, therefore neither is
> turing-complete.

Neither invoke a turing-complete scripting language, either.

> But can a GNU system create or remove a dir? Yes!
> Can it do those things that I asked about sorcery? Yes! The important
> question: can it behave as any other turing machine? Yes, therefore,
> it is a universal turing machine and is turing-complete.

Any cast can, and even any dependency can be specified in a
turing-complete language, which was the point.

> On some small details sorcery is turing-complete, but not on all
> points. For instance, it is necessary that the system has some sort of
> construction that allows it to loop to be t-c (the requirement is that
> it must be able to never halt, ie, reach an end).

try this:

echo 'while true; do :; done' > DEPENDS; chmod a+x DEPENDS

cast it, see if it ever halts. Get back to me when it does.

> On that point almost everything seems t-c, but it alone cannot be the
> decisive point to say what is or is not turing-complete.

Of course not, but anything you can do in bash can be done in a spell
and in dependency resolution.

> So to sum up, Thomas, everything has at least a little bit of turing
> completeness

This seems kind of an odd statement to say, either it's complete or it
isn't, by the definition of complete. If you're going to allow partial
completeness, anything passes that except something that has zero
completeness.

> but only complete systems able to work as a universal turing machine
> are fully turing-complete.

Like bash and DEPENDS, which is merely bash. I'm not sure how much I
can repeat this, but hopefully as often as you can repeat "but it must
work as a UTM!", which would lead me to prevail!

> Besides, we all know that theory and practice are very different. Real
> machines are never turing machines

Because they don't have infinite storage, of course.

> and vice-versa so don't worry about any of this. I may have deviated
> myself from the original goal, so returning to it: I agree that some
> things are dangerous for sorcery to do. The most dangerous is actually
> 'rm -rf /home/' since the user's data is usually the most precious
> information. However, if the system is to be updated, them the program
> needs full rwx permissions to all files. It is only important to keep
> user files safe and have the option of whether to update config files
> or not, which by the way, SMGL does very well, I must add.
>
> [...]
> > OK, you have quite some points there... I still think that in
> > principle the configuration could be done in a menuconfig-like way
> > (on the look-and-feel side, not internally) for a whole cast
> > together, but I see that the spell design would have to take care of
> > being able to go back and forth, support enabling and disabling of
> > things. So even if this could be done, it won't be done in the near
> > future.
>
> Some menuconfig-like way of doing thing seems very good, but I think
> it goes against the flow of SMGL right now. As Andrew noted, SMGL is
> proud of its dynamicity, while the way you are suggesting (and that I
> support) would need lots of things to be static, such as it is with
> the actual kernel configs. The work will be huge to make the switch,
> although I think it will be worth the while.

There wouldn't be a switch. Sorcery is becoming more and more
transaction-oriented, when that's "good enough", we might add in some
more options for reverting changes or going backwards, but then we'd
need to make DEPENDS not turing complete at least in policy/principle.
With a tradeoff in power, we gain in control. I can see a reason to
change a policy to make things more strict, but only after we understand
how the most complex dependencies work within a distribution.

>
> You must be thinking 'who is this?' I have to say that I know little
> of how SMGL works internally (I only know c, c++, python and a few
> others, but I suck at bash scripting) but I can try to contribute with
> theory and algorythms (which is possibly to become the thesis of my
> major). So maybe some day I can send some idea to help.
> Moreover, I have tried to install SMGL 4 or 5 times in the past and I
> never get it finished because of some compile errors in various places
> (every time in a different place, even though I use only the stable
> grimoire), so I end up always going back to my FC to be able to do my
> work.

http://bugs.sourcemage.org/

> So I know a lot about the frustration Thomas feels.
> I lurk in this mailing list just waiting for some change that will
> make SMGL work for me, and maybe this is it, maybe not. At every new
> release I go ahead and test it, but I just don't have the time to try
> and figure out the problems of the spells or to reconfigure things 2
> or 3 times on the same cast. I wish I did. (That is my excuse for
> never helping you guys: time.) I just need a system that works well
> and possibly that is optimized for my machine, but LFS&DIY are way too
> simple and crude, Gentoo is overly difficult to install and SMGL
> simply hasn't worked for me yet - so I give up the optimization and
> stay with FC.

Thanks for continuing to try. If we at least know about the problems we
can fix them.

>
> Thanks for your time. Maybe next time I might be of more help.
> Arthur

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Key id 63C1E02F = E07A FB0E 5925 CE4A 6526 2AD5 1782 FEC2 63C1 E02F

Attachment: pgp3PKUe3ectP.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page