Re: clisp -- Flávio Cruz, GSoC 2008 (was: Writing translators in lisp - cl-hurd code recovered)
Hi, On Thu, Oct 08, 2009 at 11:40:08PM +0100, Flávio Cruz wrote: > Yes, the CVS branch only contains the aggregation of the original > commits and I agree on keeping the original version (non-CVS-branch). Just to be sure: is this true also for the changes you did after first merging stuff into the CVS branch? -antrik-
Re: subhurds etc.
Hi, On Wed, Sep 23, 2009 at 03:38:08PM +0300, Sergiu Ivanov wrote: > On Tue, Sep 22, 2009 at 01:58:52AM +0200, olafbuddenha...@gmx.net > wrote: > > On Tue, Aug 18, 2009 at 09:46:23AM +0300, Sergiu Ivanov wrote: > > > On Mon, Aug 17, 2009 at 01:59:49AM +0200, olafbuddenha...@gmx.net > > > wrote: > > > > It's much more interesting to have a partially customized > > > > environment *without* booting a complete extra system instance; > > > > but rather accessing the main system for most stuff. That's what > > > > I'm calling "light-weight subhurd-like environments" -- but it's > > > > all very vague, as many of my ideas :-( > > > > > > Are you talking about reusing other base system services besides > > > terminal and root store? > > > > Yes. Reusing most of the original system environment, and only > > replacing specific bits you are interested in. > > I see. I've always thought that sub-hurds worked in this way right > now :-( Is it very hard to make things work like this, or is it the > lack of developer time that hinders sub-hurds from being this > flexible? It's mostly lack of a concrete vision... I have some vague ideas how such partial subhurds could be used; but not really much of an idea how such a setup would look like exactly... Probably needs some very concrete use case(s) to work from. And as we are doing very badly at creating tools and applications that make use of Hurd's possibilities, there are simply no specific use cases yet. > I'd like to have a snapshotting filesystem at my box, because having > experienced the possibility to roll anything back in git, I'd be happy > to be able to do so with the non-git-managed files :-) Well, btrfs is not quite ready yet for production use AFAIK; but it won't take too long I think. However, you don't really need a snapshotting filesystem for that. While technically less elegant and efficient, other methods for doing regular snapshots (AKA backups) existed for ages... -antrik-
Re: [PATCH] Implement the sync libnetfs stubs.
Hi,
On Mon, Aug 17, 2009 at 11:44:59PM +0300, Sergiu Ivanov wrote:
> I think that file_syncfs is equivalent to fsys_syncfs, the difference
> being in the target of invocation (file_syncfs is invoked on a port to
> a file, while fsys_syncfs is invoked on the control port).
Yeah, that's my understanding as well.
> It looks as though the existence of both RPCs were indeed motivated by
> the necessity of solving the problem Fredrik pointed out (syncing
> filesystems of which you are not an owner).
Probably.
> diff --git a/netfs.c b/netfs.c
> index 89d1bf6..0180b1a 100644
> --- a/netfs.c
> +++ b/netfs.c
> @@ -1,5 +1,6 @@
> /* Hurd unionfs
> - Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
> + Copyright (C) 2001, 2002, 2003, 2005, 2009 Free Software Foundation, Inc.
> +
> Written by Moritz Schulte .
>
> This program is free software; you can redistribute it and/or
> @@ -282,7 +283,45 @@ error_t
> netfs_attempt_sync (struct iouser *cred, struct node *np,
> int wait)
> {
> - return EOPNOTSUPP;
> + /* The error we are going to report back (last failure wins). */
> + error_t final_err = 0;
> +
> + /* The index of the currently analyzed filesystem. */
> + int i = 0;
I think the initialization of "i" should be as close to the loop as
possible -- after all, it's a loop counter...
> +
> + /* The information about the currently analyzed filesystem. */
> + ulfs_t * ulfs;
> +
> + mutex_lock (&ulfs_lock);
> +
> + /* Sync every writable directory associated with `np`.
> +
> + TODO: Rewrite this after having modified ulfs.c and node.c to
> + store the paths and ports to the underlying directories in one
> + place, because now iterating over both lists looks ugly. */
> + node_ulfs_iterate_unlocked (np)
> + {
> +error_t err;
> +
> +/* Get the information about the current filesystem. */
> +err = ulfs_get_num (i, &ulfs);
> +assert (err == 0);
Minor nitpick: it's more common to do such checks with "!err".
> +
> +/* Since `np` may not necessarily be present in every underlying
> + directory, having a null port is perfectly valid. */
> +if ((node_ulfs->port != MACH_PORT_NULL)
> + && (ulfs->flags & FLAG_ULFS_WRITABLE))
Not sure whether I asked this before: is there actually any reason not
to attempt syncing filesystems without FLAG_ULFS_WRITABLE as well?...
(I don't know how file_sync() or file_syncfs() bahave on filesystems or
nodes that really are not writable -- but IIRC that's not what
FLAG_ULFS_WRITABLE conveys anyways?...)
> + {
> + err = file_sync (node_ulfs->port, wait, 0);
> + if (err)
> + final_err = err;
> + }
> +
> +++i;
> + }
> +
> + mutex_unlock (&ulfs_lock);
> + return final_err;
> }
>
> /* This should sync the entire remote filesystem. If WAIT is set,
> @@ -290,7 +329,44 @@ netfs_attempt_sync (struct iouser *cred, struct node *np,
> error_t
> netfs_attempt_syncfs (struct iouser *cred, int wait)
> {
> - return 0;
> + /* The error we are going to report back (last failure wins). */
> + error_t final_err = 0;
> +
> + /* The index of the currently analyzed filesystem. */
> + int i = 0;
> +
> + /* The information about the currently analyzed filesystem. */
> + ulfs_t * ulfs;
> +
> + mutex_lock (&ulfs_lock);
> +
> + /* Sync every writable filesystem maintained by unionfs.
> +
> + TODO: Rewrite this after having modified ulfs.c and node.c to
> + store the paths and ports to the underlying directories in one
> + place, because now iterating over both lists looks ugly. */
> + node_ulfs_iterate_unlocked (netfs_root_node)
> + {
> +error_t err;
> +
> +/* Get the information about the current filesystem. */
> +err = ulfs_get_num (i, &ulfs);
> +assert (err == 0);
> +
> +/* Note that, unlike the situation in netfs_attempt_sync, having a
> + null port here is abnormal. */
Perhaps it would be helpful to state more explicitely that having a NULL
port *on the unionfs root node* is abnormal -- I didn't realize this
point at first.
(Maybe you should actually assert() this.)
> +if (ulfs->flags & FLAG_ULFS_WRITABLE)
> + {
> + err = file_syncfs (node_ulfs->port, wait, 0);
> + if (err)
> + final_err = err;
> + }
> +
> +++i;
> + }
> +
> + mutex_unlock (&ulfs_lock);
> + return final_err;
> }
>
> /* lookup */
> --
> 1.6.3.3
-antrik-
Re: Mercurial vs. git
Hi, On Sat, Oct 24, 2009 at 01:57:22PM +0200, Arne Babenhauserheide wrote: > Am Samstag, 24. Oktober 2009 06:08:49 schrieb olafbuddenha...@gmx.net: > Yay, reviving the thread! ;) Sorry, couldn't resist... :-) > If you use the system for tracking your coding and occassionally > merging with changes from others, then you don't have to fully > understand it, since the tracking of changes can be done quite well > without full understanding. > > If you don't have to integrate hundreds of branches, then there's no > merit in learning how to do that efficiently - so it isn't efficient > to have to learn background for that before being able to use the > system efficiently for other stuff. The point is that there is hardly anything you need to learn for specific tasks like integrating many branches -- once you understand the basics, most specific tasks become trivial! And programming is not systematic enough that you can avoid doing all kinds of specific stuff now and then. I claim that *every* regular programmer can profit considerably from being really proficient with the VCS. It's different for a wiki of course -- here indeed the requirements for non-trivial operations are so rare, that learning efficient VCS usage is not likely to pay off... > For me the measure of efficiency is: * Time for initial learning until > I can use it, plus * Time I spend relearning stuff I forget (a major > factor with git for me), plus * Time to learn the new stuff I need and > for optimizing, plus * Time I actually spend using it. > > That calculated for different systems to be able to compare them. > > With git the first and second are quite high (for me) for basic > features like branching and merging (that's why I wrote a guide on > merging the news - I use that guide myself when I prepare the next > news). > > The optimizing part only makes sense, when it saves netto time -> when > I use the system so much that the time I save per usage ??? the number > of times I use it is higher than the time spent on optimizing it. > Since most developers firstly write code and only secondly manage > history, optimizing a git workflow often doesn't make that much sense > (simlarly it doesn't make must sense for most people to write a > Mercurial extension for their individual workflow). You can't measure the efficiency of VCS usage by "the time spent using it". That just doesn't reflect reality. "Managing history", and other VCS usage, is not a separate task -- using the VCS is part of the programming workflow. Efficient VCS usage is about being able to perform my *programming* work in the most efficient manner. > With Mercurial on the other hand, the first is very short and the > third also stays short for the stuff most people need. For example I > never had to work with Mercurial Queues (doing patch reworking), so I > never had to learn how to use them. It's not about what you *have* to do, but about what you *can* do. As I already said at the setout, it is perfectly possible to perform all tasks with only a handful of fixed workflows, and with VCS knowlegde limited only to these few workflows. (In fact, even most git users seem to work that way -- which is a very sad situation indeed :-( ) But that's not efficient. Programming is not a linear or systematic task. When programming, I write a bit of code; while at it, I discover something else I can improve or need to fix; or I realize that I have to change something else first in order to do the change I intended; or I realize that the changes are more complex, and I have to split them up; or I realize that I have to go back and change the approach; or I realize that something I changed in the past didn't make sense after all; or I decide to work on an entirely different thing for now; or I realize that the change I am working on makes more sense in a different branch; or I realize that I forgot to commit something, or commited too much; or I want to try things out, later abandoning them again, or include them in some branch; and so on. These things happen *all the time*; they are part of the normal programming process. All of them require using the VCS in some particular way -- and only with a VCS that allows me to do exactly what I want without ceremony, I can work efficiently. If I have to work around, because the thing I want to do doesn't fit the model of the system; or if I have to learn new functionality to be able to do the thing I want: that's not efficient. (This is where Git scores: the model is so flexible that very few things do not fit in it; and the fundamental concepts so universal, that once I internalized those concepts, I can do almost anything I want -- no matter how unusual -- without needing to learn new things.) Let's take changing history as an example, as this seems to be a major point of contention. You can muse about the meaning of history etc. as much as you like -- but I simply don't buy the (implicit) claim that there are many people
Re: [PATCH] Apply pattern-matching immediately beneath the stow directory.
Hi, On Wed, Sep 23, 2009 at 03:06:21PM +0300, Sergiu Ivanov wrote: > On Tue, Sep 22, 2009 at 03:25:39AM +0200, olafbuddenha...@gmx.net > wrote: > > I still don't understand why you think that the current hardcoded > > "descend into all directories, then match all subdirectories against > > foo" is more efficient than "descend into all directories matching * > > (i.e. all directories), then match all subdirectories against > > foo"?... [...] > The misunderstanding, IMHO, appeared mainly due to the fact that I > didn't universally take into account the fact that you don't need to > go deeper than the number of components in the pattern :-( Well, now that the misunderstanding seems resolved -- what's the status on this?... -antrik-
Re: Mercurial vs. git
Hi, On Sat, Oct 24, 2009 at 01:57:17PM +0200, Arne Babenhauserheide wrote: > Am Samstag, 24. Oktober 2009 06:10:38 schrieb olafbuddenha...@gmx.net: > > Complexity? I still think that Git is actually very simple in its > > fundamental concepts. It only seems complex to people who haven't > > yet fully mastered these concepts... > > That's true with any system, no matter how complex :) No, it's not. Complexity is a rather objective measure. It is certainly true that many (not all) concepts don't look so hard anymore once you understand them -- but that doesn't change the fact that some concepts are inherently complex, while others are really quite simple, even if they appear more complex to people not familiar with them yet. > I tried learning git, though, but gave up when it took too much time > (much more than "just a few hours" - it costed me several nights). Yes, it takes more then a few hours: reading enough of the Git documentation in order to truly understand the concepts, probably requires a couple of days. But for people programming 200 days a year, this investment will soon be made up for by increased productivity. -antrik-
Re: OT: automation
Hi, On Sat, Oct 24, 2009 at 02:14:08PM +0200, Arne Babenhauserheide wrote: > Am Samstag, 24. Oktober 2009 09:03:10 schrieb olafbuddenha...@gmx.net: > > I only write scripts for stuff that requires a lot of commands, or > > that I do *very* often -- precisely so I *have* to remember the > > commands, > > I think the approach depends on what you want to archieve. > > I don't need perfect commandline skills Again, it's not about what you *need*, but about being able to work more efficiently. > (these are very opaque to others), but I like improving my Python > skills, so I wrote the script :) Also I can easily teach not so tech > savvy people to use that script. That's a very bad thing to do. I hate all these mmv and other bullshit scripts -- it's really not so hard to learn some basic shell; and it's *much* more valuable knowledge than usage of any specific scripts. This generic knowledge, once obtained, can be reused in all kinds of situations. This is what UNIX -- and for me at least, also the Hurd -- is really all about. -antrik-
Re: subhurds etc.
Hello, On Mon, Oct 26, 2009 at 07:22:28AM +0100, olafbuddenha...@gmx.net wrote: > On Wed, Sep 23, 2009 at 03:38:08PM +0300, Sergiu Ivanov wrote: > > > I'd like to have a snapshotting filesystem at my box, because having > > experienced the possibility to roll anything back in git, I'd be happy > > to be able to do so with the non-git-managed files :-) > > Well, btrfs is not quite ready yet for production use AFAIK; but it > won't take too long I think. Yeah, I'm keeping an eye on it and I guess I'll be trying it out soon. > However, you don't really need a snapshotting filesystem for that. While > technically less elegant and efficient, other methods for doing regular > snapshots (AKA backups) existed for ages... That's, of course, true :-) I do backups of sensitive information, but the reason I want a snapshotting filesystem for is automated decision when to do the backup. I often think about doing a backup after having screwed things up. OTOH, a snapshotting filesystem is not exactly about backups IMHO. When I do a backup, I aim at keeping two copies of information so that I can always restore it on failure. When I do a filesystem snapshot, I do it to be able to revert things from some future state. Although technically these are almost the same, I can see significant conceptual difference. Regards, scolobb
Re: [PATCH] Apply pattern-matching immediately beneath the stow directory.
Hello, On Tue, Oct 27, 2009 at 12:44:20AM +0100, olafbuddenha...@gmx.net wrote: > On Wed, Sep 23, 2009 at 03:06:21PM +0300, Sergiu Ivanov wrote: > > On Tue, Sep 22, 2009 at 03:25:39AM +0200, olafbuddenha...@gmx.net > > wrote: > > > > I still don't understand why you think that the current hardcoded > > > "descend into all directories, then match all subdirectories against > > > foo" is more efficient than "descend into all directories matching * > > > (i.e. all directories), then match all subdirectories against > > > foo"?... > [...] > > The misunderstanding, IMHO, appeared mainly due to the fact that I > > didn't universally take into account the fact that you don't need to > > go deeper than the number of components in the pattern :-( > > Well, now that the misunderstanding seems resolved -- what's the status > on this?... This has been discussed on the IRC (Oct 29, 2009) and I will answer for the record. I haven't worked on this problem for a long time already due to the fact that I only have the possibility to work on a single Hurd task at a time. I will look into this problem soon and will decide whether it can be implemented without much effort. If it proves to possible, I'll do this more or less soon; otherwise I'll leave it for the better times. Regards, scolobb
Re: Mercurial vs. git
Am Sonntag, 25. Oktober 2009 10:54:44 schrieb olafbuddenha...@gmx.net: > > If you don't have to integrate hundreds of branches, then there's no > > merit in learning how to do that efficiently - so it isn't efficient > > to have to learn background for that before being able to use the > > system efficiently for other stuff. > > The point is that there is hardly anything you need to learn for > specific tasks like integrating many branches -- once you understand the > basics, most specific tasks become trivial! That's not really a specific task to me, but basic operation... In mercurial it's "hg merge " for named branches or "hg merge " for unnamed ones - maybe with "hg pull " or "hg import " to get them into your local clone. > You can't measure the efficiency of VCS usage by "the time spent using > it". That just doesn't reflect reality. "Managing history", and other > VCS usage, is not a separate task -- using the VCS is part of the > programming workflow. Efficient VCS usage is about being able to perform > my *programming* work in the most efficient manner. Then lets state it more precisely: "The time spent using it" has to be changed to "the time overhead created by the time spent in the version tracking part of the work". "Jumping back in history" is a version tracking action, as is merging, branching, etc, so it adds to the version tracking overhead. To be really fair, you have to substract the programming time you save because you can move more freely in history. That way you get a ±time which is the part of your programming spent with version tracking. You can even go to defining VCS actions. Having a certain VCS action at your disposal can save you programming time. That time reduces the overall VCS overhead. Everytime you do a VCS action, you need a certain amount of time. That time adds to the VCS overhead. Then you add all the factors I mentioned earlier (learning time, ...) and add everything over the time span you're likely to use the tool (10-30 years?). The VCS overhead can easily become negative this way, but heck, that's what good tools are about :) It should be true for Git and Mercurial - I don't know how much teh degrees vary. > It's not about what you *have* to do, but about what you *can* do. As I > already said at the setout, it is perfectly possible to perform all > tasks with only a handful of fixed workflows, and with VCS knowlegde > limited only to these few workflows. Did you read my guide? That's pretty much what say in the middle of the guide "now you can do about everything. All that follows is about convenience - and that's good". > (In fact, even most git users seem > to work that way -- which is a very sad situation indeed :-( ) But that really defeats everything you write later about efficient workflows. In Mercurial people routinely jump back and forth, use feature clones and much more, because it is really easy and fast - you'll notice, that it's in the basic workflows for which you don't need any extensions (the ones in the guide). A powerful tool is only useful to a group, if most people use its power - and being easy to learn increases the number of people who can access the power. (most people are lazy and generally don't dive deep, and the required startup learning time reduces the number of people who learn the deeper flow; I wonder if it's an exponential function like the one in statistical physics: number_in_a_state = N_0 * exp(-Energy_to_reach_the_next_step*num_steps) For VCS: people with number of tricks mastered = = exp(-Energy per trick * number of tricks) Since the energy per trick isn't linear, these will somehow group. If there are many easy to learn tricks, most people will know many tricks. If most tricks require a startup time investment, most people won't know any tricks and some will know almost all. Only speculation and possibly disallowed analogies, though ;) Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part.
Re: OT: automation
Am Sonntag, 25. Oktober 2009 11:23:59 schrieb olafbuddenha...@gmx.net:
> That's a very bad thing to do. I hate all these mmv and other bullshit
mmv?
> *much* more valuable knowledge than usage of any specific scripts. This
> generic knowledge, once obtained, can be reused in all kinds of
> situations.
What I use of my shell is for loops, some globbing, pipes with sed, grep, find,
and such.
The reason I prefer python scripting is mainly shell escaping, which can
really hurt :(
Sometimes I haggle for minutes with a sed script, before I get it right. I
think I should write me a python script which just takes stdin and some python
commands as input, executes the commands on the file and pipes the result to
stdout...
Something like ... damn ... del 10 lines of unnecessary script ...
find -print0 | python -c "from sys import stdin;from os.path import isfile
files = stdin.read()
for f in files.split('\0'):
if isfile(f):
data = open(f).read()
d = data.split('orig')
print 'new'.join(d)
"
(replace "print..." with "open(f, 'w').write('new'.join(d))" to replace in
files)
This is more verbose than a "find (only files) | sed -i s/orig/new/", but it
saves me from having to escape all kind of weird stuff in sed...
Note: Until today I haggled with sed instead, because I didn't think this
would be that easy with python...
> This is what UNIX -- and for me at least, also the Hurd -- is really all
> about.
But it's only useful to people who often have to do these kinds of tasks.
Just look at the viewpoint of a writer instead. He needs to be able to write
text and sometimes replace some words in a list of files.
Learning the intricacies of cat and sed won't help him - he will lose far more
time than he wins, since he can just use a script which does what he needs to
do - or get someone to write it for him.
It's far less versatile than the shell, but it does what he needs and he
doesn't have to spend as much time learning things he won't really need
(improving ones writing skills takes enough learning time). And he doesn't
have to keep all the different programs and options in mind.
In short: A specialized script helps him to stay focussed on his work.
Best wishes,
Arne
--- --- --- --- --- --- --- --- ---
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
- Arne (http://draketo.de)
--- --- --- --- --- --- --- --- ---
signature.asc
Description: This is a digitally signed message part.
Re: Mercurial vs. git
Am Sonntag, 25. Oktober 2009 11:08:47 schrieb olafbuddenha...@gmx.net: > Yes, it takes more then a few hours: reading enough of the Git > documentation in order to truly understand the concepts, probably > requires a couple of days. > > But for people programming 200 days a year, this investment will soon be > made up for by increased productivity. If it offers increased productivity over an easier to learn system like Mercurial, that is. To truly understand Mercurials concepts you don't need long - and you can also quickly understand how to map these concepts to commands. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Ein Mann wird auf der Straße mit einem Messer bedroht. Zwei Polizisten sind sofort da und halten ein Transparent davor. "Illegale Szene. Niemand darf das sehen." Der Mann wird ausgeraubt, erstochen und verblutet, denn die Polizisten haben beide Hände voll zu tun. Willkommen in Deutschland. Zensur ist schön. (http://draketo.de) --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- signature.asc Description: This is a digitally signed message part.
Re: subhurds etc.
Am Montag, 26. Oktober 2009 07:22:28 schrieb olafbuddenha...@gmx.net: > I have some vague ideas how such partial subhurds could be used; but not > really much of an idea how such a setup would look like exactly... > Probably needs some very concrete use case(s) to work from. Can you think of some? What can be done in a subhurd which we can't easily do in a unionfs changeroot? How would I go for starting a virus which only gets a bogus environment? Something like the xkcd virus aquarium, but without real virtual machines: -> http://xkcd.com/350/ Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part.
Re: OT: automation
Hello,
On Wed, Oct 28, 2009 at 05:23:13PM +0100, Arne Babenhauserheide wrote:
> Am Sonntag, 25. Oktober 2009 11:23:59 schrieb olafbuddenha...@gmx.net:
> > That's a very bad thing to do. I hate all these mmv and other bullshit
>
> mmv?
I've heard of this for the first time, too :-)
google (``man mmv'') told me that mmv is something than can copy,
move, append, or link bunches of files. Also, it is apparently
possible to ask mmv to perform several operations at once. The man
page also states that mmv will check for name collisions etc., i.e.
the kind of problems into which one would sometimes unexpectedly run.
I'd rather agree with antrik here, because stuffing all these
operations in a single command seems a little bit useless, IMHO.
> > *much* more valuable knowledge than usage of any specific scripts. This
> > generic knowledge, once obtained, can be reused in all kinds of
> > situations.
>
> Sometimes I haggle for minutes with a sed script, before I get it
> right. I think I should write me a python script which just takes
> stdin and some python commands as input, executes the commands on
> the file and pipes the result to stdout...
>
> Something like ... damn ... del 10 lines of unnecessary script ...
>
> find -print0 | python -c "from sys import stdin;from os.path import isfile
> files = stdin.read()
> for f in files.split('\0'):
>if isfile(f):
> data = open(f).read()
> d = data.split('orig')
> print 'new'.join(d)
> "
> (replace "print..." with "open(f, 'w').write('new'.join(d))" to replace in
> files)
>
> This is more verbose than a "find (only files) | sed -i s/orig/new/", but it
> saves me from having to escape all kind of weird stuff in sed...
>
> Note: Until today I haggled with sed instead, because I didn't think this
> would be that easy with python...
Hm, this may be case-specific :-) For me the sed command is much
easier :-)
The problem might be that I'm often a fan of fast solutions, no matter
how intricate the syntax might be, that's why I'd often invest a lot
of time in learning shell intricacies to be able to code complex
problems in a dozen characters afterward. But, again, this is
case-specific.
> > This is what UNIX -- and for me at least, also the Hurd -- is really all
> > about.
>
> But it's only useful to people who often have to do these kinds of tasks.
I do agree with you :-)
Actually, I believe antrik referred to professional programmers, too.
But I may be wrong, of course.
Regards,
scolobb
