A. "From a software perspective, we don't think the patent system is perfect... But when I look at the software industry today, we've been getting a lot of innovation from Microsoft, IBM, Oracle, Adobe, the list goes on..."
A few weeks ago we had an interview from Steve Ballmer saying that Oracle didn't innovate. Seems that MS needs to coordinate their FUD better.
In Brazil, we call DST "Summer Time" (Horário de Verão). Sometimes we jokingly refer to the Standard Time as "Winter Time" (especially during the weeks before/after the switch).
Since in this proposal the non-DST time would last only three months (Dec-Feb), you might as well call that "Winter Time".:)
In stories like this you can see how much the Slashdot userbase has changed over the years.
Here's a new UI concept, that is very promising and hasn't been implemented anywhere yet. A true opportunity for Linux to score a "first" in UI design -- this could be the next generation of window shading/rollup, the possibilities are endless.
And the comments are "in Mac OSX you do such-and-such instead", "in Windows you do such-and-such instead". Things like "this problem is solved" -- as if there was One True Solution in UI design! -- and "before doing your research you should stop at the Apple store" -- as if PhD research didn't do related work assessment! --, enumerations of Windows key sequences, and so on. And those are ranked "5, Insightful".
A few years ago the comments would range from the usual "GUI? Give me a CLI any day" to discussions on how to implement this on Linux and which wm would get it first, which would (d?)evolve to a healthy wm flamefest.
That "imperfection", the tiny variations humans add to music, is in fact a very important element in music and can be measured by quantization.
Quantization takes a recording of a performance (typically, in MIDI format) and does the musical equivalent of "snap to grid" in graphics programs: it moves the slightly off-time notes so that they match the rhythm count precisely.
For most types of music, quantization makes the sound too mechanical, without "life". Actually, there are also programs that do the opposite -- take a music score (where all notes are written "perfectly") and add micro variations to the time, so that it feels "more human". That doesn't fully work, however, because humans tend to do their variations in very subtle -- and very personal! -- patterns.
To add to the complexity, those variations take place in a number of different "degrees of freedom" which a computer has a hard time reproducing (for a guitarist, for example, beyond time variation, you have the angle of the guitar pick, the strength of plucking, left-hand vibrato, right-hand muffling of the strings, etc, etc). The sum of all these little things is what makes a musician's particular style of playing, which is reflected even when he/she's reading a song note by note from a book.
Come on, that's not the kind of attitude we should be having around here.
I'm not particularly a fan of Google (though I use and enjoy their services every day), but this kind of behavior towards a company that's releasing a Linux product is not very nice.
There are reasons for some programs to be in/bin, and others in/usr/bin,/usr/local/bin,/usr/sbin,/home/$USER/bin, and/opt. Well, okay, maybe not/opt. They're the same reasons some Windows executables are in C:\Program Files, while others are in C:\WINNT, or C:\WINNT\system32, etc. Now, I'm fine with slopping an abstraction layer over the top of it, but you can't just dump all the binaries in one folder without finding another way to make the distinction between administrator applications, local vs. remote applications, etc. Too much flexibility would be lost.
In GoboLinux we don't dump all binaries in one folder, but we separate the files by application, rather than "by category" as is done in Linux and (to some extent) in Windows.
With regards to administrator applications, the Unix filesystem already offers a good abstraction for that: the permissions system. If only root is supposed to run it, "chown root" and "chmod 500".
With regards to "local versus remote" and other circumstantial distinctions (ie, not related to the logic of the app), you can separate the files "physically" and them present them in a consistent way using a union-filesystem. This is what Knoppix does, for example, to present the read-only files of the CD and the read-write area of the RAM-disk as a single, transparent, unit. No reason why the same can't be done to unite local and remote apps. The user shouldn't care where (in the network) an app is, that's the beauty of the abstraction.
The technology is here to provide us more elegant solutions than the ones used in the early days of Unix. Let's use it!
What if we took this idea a step further and added a form of authentication, namely, signing of messages?
Here's what I have in mind, please point out any flaws in my logic:
I log into livejournal.com using my id, "hisham".
I post a message at foo.com using my OpenID, hisham@livejournal.com.
foo.com sets a cookie in my browser, and issues a request to livejournal.com, with the cookie and the message.
livejournal.com receives the request, verifies the cookie (confirming that the request from foo.com was posted by a browser who's actually currently logged as hisham in livejournal).
livejournal.com then signs the message and sends the signature back to foo.com.
foo.com posts the message saying that hisham@livejournal.com posted it, with the signature in the end (or most likely, accessible through a link).
If anybody wants to verify if the message is legit, they can copy-paste the message and the signature and check it in a verification form in livejournal.com.
The system is still fully decentralized (anyone can host their own "OpenAuth" servers) and you only need to trust one of the sites (the signer), not both as in OpenID (though "trust" in the sense of OpenID means just identification, not authentication -- and I'm fine with it since that's its purpose).
Off the top of my head, the only two potential issues I see are:
the signer server would see everything you posted anywhere -- but anyway, Google see all my emails... if this is a concern, host your own server;
the load on the servers -- would this be a big problem? most sites could use lighter, less CPU-intensive cryptography... again, if this is a concern, host your own server with 1024-bit crypto.
What do you people think? Could something like this work??
It does not open a hole in the protocol per se. I understand your relevant concern, but people are bashing OpenID so much that I don't think it's advisable to talk about "holes" at this point.
But yes, I agree that popularizing popping up a login to your server is a bad idea, as if people get used to this, that could be prone to phishing -- but not actual man-in-the-middle attacks to the actual OpenID protocol.
Anyway, the way I understand it, OpenID assumes that the user trusts both sites:
I have an OpenID at foo.com, hisham@foo.com. I want to post at randomsite.com, using my OpenID.
If foo.com couldn't be trusted, then foo.com might certify that other people than me are hisham@foo.com.
If randomsite.com can't be trusted, then randomsite.com could just post random crap saying that "hisham@foo.com" posted there.
Still, there are a lot of scenarios where OpenID makes sense: for example "blogger.com says that hisham@livejournal.com wrote xyz". This is the kind of thing that OpenID allows, and I think it's great. The question is if people will "get" this.
From Gobolinux: "GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy. In GoboLinux you don't need a package manager because the filesystem is the package manager: each program resides in its own directory, such as/Programs/Xorg/6.7.0/ and/Programs/KDE/3.2.2. Like it?"
No. Sure it'll help windows users feel more at home, but for the rest of us, it'd be just plain wrong and confusing. Don't try to make linux to be like windows. Linux is different and for very good reasons. Linux users coming from windows, should learn why it's different and adjust their way of thinking. Don't try to convert linux to the totally wrong model of windows.
Thanks for your input, but I think you may be missing the point: GoboLinux is not replicating the Windows structure. We don't like the Windows dir structure either.
Under each program directory, what we have in GoboLinux is a Unix tree:/Programs/Bash/3.0/bin,/Programs/Bash/3.0/lib, etc. We compile programs with their own --prefix, for organizational purposes. It's the same reason why a user compiles "his/her stuff" in/usr/local rather than/usr -- so it doesn't get mixed up with system stuff... but then their various programs get mixed up in/usr/local. We're just taking this idea one step further, applying it to the whole system (and throwing versioning into it, while we're at it). Think/opt on steroids.
The goal of GoboLinux is not to make the fs tree "look prettier" or "more like Windows". It's a matter of organization. About the 'pretty' names (/Users,/System), we took the clue from NeXT, Mac OS X, RISC OS and many others before, and in fact it's a way very good way to avoid clashing with the ever-changing "standard" Linux tree (think/sys).
I for one don't like the windows dir structure. Binaries, libraries, and config files are scattered all over the place.
Exactly! Neither do we! And the thing is, the usual Linux structure also has binaries, libraries and config files scattered "all over the place" --/bin,/sbin,/usr/bin,/usr/sbin,/usr/X11R6/bin,/usr/X11R6/sbin,/usr/local/bin,/opt/bin,/opt/sbin... -- with no clear distinction of what should go where. Sure there are some vague rules, but given a program you can't tell a priori where it is [I know about the 'which' program, duh; I'm arguing about the principle of the layout]. Sure, in GoboLinux you'll have a hundred different ".../bin" directories, but there's a logic and deterministic way to determine what is where, and that is the file path:/Programs/Bash/3.1/bin/bash. (And no, the $PATH is not a hundred entries long, because we use symlink directories to index the system -- and you can use that to do 'reverse lookup' easily).
So, in GoboLinux we don't have the mess that is/windows/system (or whatever it's called these days) or the mess that is/usr/lib. Sure, the package managers try to, err, manage that mess in Linux. But isn't a better idea to have things layout properly instead?
Don't let the name "Programs" fool you into thinking of "Program Files". It works very differently. Well, I guess we should have picked a different name, if only to avoid this kind of confusions.
I hope I clarified some points, and thanks for checking out the project!:)
Those English-written articles are of course giving you the standard English pronunciation. I dont see a problem with that -- you're entitled to pronounce foreign names according to the rules of your language, just like you don't call Paris "Pah-hee" like the French do, or Munich "Mewn-shen" like the Germans (man, were those crappy approximations or what).
However, if you are interested in the proper pronunciation of Zeus: the "e" sounds like the "a" in "bay", the "u" sounds like the "oo" in "food".
Incidentally, the Ancient Greek pronunciation is exactly the same as we pronounce "Zeus" in my native language (Portuguese), and I assume that's how it is pronounced in German as well (because following strict German rules, Zeus would be pronounced "Tzoyce", as in "Joyce" with a "Tz").
Microsoft are big on XML. Their new office format will be completely open and XML compliant.
Do you call releasing a file format in a GPL-incompatible way "completely open"??
(Notice I didn't refer to GPL-incompatible code. There's a lot of GPL-incompatible free software out there, and they are still free software. File formats, however, are a different story. To be open, they need to be implementation-independent. Not only in their specification but also on their licensing.)
Or is it a "good, fast, cheap, pick two, tough shit" situation?
Yes, but it's more like a "open, popular -- pick one" situation. A friend of mine is a GP32 developer. The architecture is completely open, he bought it to hack on it more than to play with it. In fact, he's now maintaining the Linux kernel port for the specific ARM architecture of the GP32 port.
And yes, nobody else had a GP32 in his town when he bought it (or in his state, maybe even country(!), for that matter). But he found a very exciting user and developer community on the internet. So the installer base in [whatever specific place you are] is not that relevant.
Still, after seeing the GP32, I was almost tempted to buy one for myself (but I was broke at the time). Chances are, if you buy one, your friends might follow suit.
And emulators work like a charm, so there's no shortage of games, especially if you're into the classics.;)
The Z Shell features some heuristics for that. If a command line performs a completion on "*" and the command is "rm", it asks for confirmation, even with -f:
hisham@brick/Depot/test]rm a* hisham@brick/Depot/test]rm * zsh: sure you want to delete all the files in/Depot/test [yn]?n hisham@brick/Depot/test]rm -f * zsh: sure you want to delete all the files in/Depot/test [yn]?
Obviously, as everything in zsh, this is configurable (setopt -u rm_star_silent to disable it).
/usr for installed programs /etc for all systemwide configuration files /home for different user's files /boot for stuff related to booting the system /tmp for temporary files
Those are what you are likely to occur, every thing is nice and systematic.
Except that everything is not nice and systematic. First, all programs get dumped together under/usr, making it nearly impossible to cleanly uninstall if it was compiled from source or the package manager database got corrupted ("--force", anyone?), ocasionally with bits and pieces spread under/bin,/sbin, etc (look at all the different places the files from CoreUtils is usually installed). The fact that "ping" and "traceroute" are stored in different place is not systematic.
I also noticed you didn't describe/var -- now that's something quite hard to do (its de facto usage in distros, not the dream world described by the FHS).
"random placement if configuration files"
System configuration files will all be in/etc, programs generally check the following areas -
True, but under/etc they are placed almost randomly. If you don't know the exact name of the configuration file you need (which may or may not be under a subdirectory...), you're out of luck.
Yes, the usual Linux directory structure is arcane.
Everytime I hear someone say "compiling packages by hand" I think of some guy looking up assembly equivalents of the code in question, then optimizing the assembly in his head, and finally doing an opcode translation.:-)
As someone who has already done exactly what you described, in a distant Apple II past (6502 asm... large chunks of code any time you needed a 16-bit operation, what a pain) -- except for the "optimization in his head" bit of course; I resorted to plain-old paper, much easier to fix the jump offsets -- I can say the Gentoo experiment would take something in the order of centuries.:)
But seriously, while "compiling by hand" sounds funny is not that much of a misnomer. With so many tools to automate compilation out there (emerge, SRPMs and of course our own Compile) , there is definitely a distinction nowadays to be made. In the mailing lists we often ask "was that compiled 'by hand' or with Compile?"
I'll join my voice to the ones praising Linux From Scratch. It's an amazing resource for learning how a Linux system is built.
We used it as a reference when we built the first full version of GoboLinux -- essentially following the steps of the book and adding our modifications (configure and makefile flags) to build the new directory structure, to make our "/usr"-less distro.:)
To this day, I refer to their build instructions every now and then. They also contain a good collection of security patches, so if you're into compiling your packages by hand, drop by at their site and see if they suggest any additional patches. LFS covers the basic system and Beyond LFS covers the additional stuff (KDE, GNOME, etc.).
As in "Yay, content should be free, but if somebody subscribes to Slashdot and starts posting the subscriber-sees-early material on some website before Slashdot opens it up, then they should burn in jail"?
Oh well. That would probably be some kind of "violation of terms of service" anyway. Or wouldn't it?...
Slashdot Mirror
A. "From a software perspective, we don't think the patent system is perfect... But when I look at the software industry today, we've been getting a lot of innovation from Microsoft, IBM, Oracle, Adobe, the list goes on..."
A few weeks ago we had an interview from Steve Ballmer saying that Oracle didn't innovate. Seems that MS needs to coordinate their FUD better.
In Brazil, we call DST "Summer Time" (Horário de Verão). Sometimes we jokingly refer to the Standard Time as "Winter Time" (especially during the weeks before/after the switch).
:)
Since in this proposal the non-DST time would last only three months (Dec-Feb), you might as well call that "Winter Time".
Smart way to link to your own website with the UPS link.
Not that there's anything wrong with that!
In stories like this you can see how much the Slashdot userbase has changed over the years.
Here's a new UI concept, that is very promising and hasn't been implemented anywhere yet. A true opportunity for Linux to score a "first" in UI design -- this could be the next generation of window shading/rollup, the possibilities are endless.
And the comments are "in Mac OSX you do such-and-such instead", "in Windows you do such-and-such instead". Things like "this problem is solved" -- as if there was One True Solution in UI design! -- and "before doing your research you should stop at the Apple store" -- as if PhD research didn't do related work assessment! --, enumerations of Windows key sequences, and so on. And those are ranked "5, Insightful".
A few years ago the comments would range from the usual "GUI? Give me a CLI any day" to discussions on how to implement this on Linux and which wm would get it first, which would (d?)evolve to a healthy wm flamefest.
The Slashdot audience truly has changed. *sigh*
That "imperfection", the tiny variations humans add to music, is in fact a very important element in music and can be measured by quantization.
Quantization takes a recording of a performance (typically, in MIDI format) and does the musical equivalent of "snap to grid" in graphics programs: it moves the slightly off-time notes so that they match the rhythm count precisely.
For most types of music, quantization makes the sound too mechanical, without "life". Actually, there are also programs that do the opposite -- take a music score (where all notes are written "perfectly") and add micro variations to the time, so that it feels "more human". That doesn't fully work, however, because humans tend to do their variations in very subtle -- and very personal! -- patterns.
To add to the complexity, those variations take place in a number of different "degrees of freedom" which a computer has a hard time reproducing (for a guitarist, for example, beyond time variation, you have the angle of the guitar pick, the strength of plucking, left-hand vibrato, right-hand muffling of the strings, etc, etc). The sum of all these little things is what makes a musician's particular style of playing, which is reflected even when he/she's reading a song note by note from a book.
Come on, that's not the kind of attitude we should be having around here.
I'm not particularly a fan of Google (though I use and enjoy their services every day), but this kind of behavior towards a company that's releasing a Linux product is not very nice.
With regards to administrator applications, the Unix filesystem already offers a good abstraction for that: the permissions system. If only root is supposed to run it, "chown root" and "chmod 500".
With regards to "local versus remote" and other circumstantial distinctions (ie, not related to the logic of the app), you can separate the files "physically" and them present them in a consistent way using a union-filesystem. This is what Knoppix does, for example, to present the read-only files of the CD and the read-write area of the RAM-disk as a single, transparent, unit. No reason why the same can't be done to unite local and remote apps. The user shouldn't care where (in the network) an app is, that's the beauty of the abstraction.
The technology is here to provide us more elegant solutions than the ones used in the early days of Unix. Let's use it!
What if we took this idea a step further and added a form of authentication, namely, signing of messages?
Here's what I have in mind, please point out any flaws in my logic:
- I log into livejournal.com using my id, "hisham".
- I post a message at foo.com using my OpenID, hisham@livejournal.com.
- foo.com sets a cookie in my browser, and issues a request to livejournal.com, with the cookie and the message.
- livejournal.com receives the request, verifies the cookie (confirming that the request from foo.com was posted by a browser who's actually currently logged as hisham in livejournal).
- livejournal.com then signs the message and sends the signature back to foo.com.
- foo.com posts the message saying that hisham@livejournal.com posted it, with the signature in the end (or most likely, accessible through a link).
- If anybody wants to verify if the message is legit, they can copy-paste the message and the signature and check it in a verification form in livejournal.com.
The system is still fully decentralized (anyone can host their own "OpenAuth" servers) and you only need to trust one of the sites (the signer), not both as in OpenID (though "trust" in the sense of OpenID means just identification, not authentication -- and I'm fine with it since that's its purpose).Off the top of my head, the only two potential issues I see are:
- the signer server would see everything you posted anywhere -- but anyway, Google see all my emails... if this is a concern, host your own server;
- the load on the servers -- would this be a big problem? most sites could use lighter, less CPU-intensive cryptography... again, if this is a concern, host your own server with 1024-bit crypto.
What do you people think? Could something like this work??It does not open a hole in the protocol per se. I understand your relevant concern, but people are bashing OpenID so much that I don't think it's advisable to talk about "holes" at this point.
But yes, I agree that popularizing popping up a login to your server is a bad idea, as if people get used to this, that could be prone to phishing -- but not actual man-in-the-middle attacks to the actual OpenID protocol.
Anyway, the way I understand it, OpenID assumes that the user trusts both sites:
I have an OpenID at foo.com, hisham@foo.com. I want to post at randomsite.com, using my OpenID.
If foo.com couldn't be trusted, then foo.com might certify that other people than me are hisham@foo.com.
If randomsite.com can't be trusted, then randomsite.com could just post random crap saying that "hisham@foo.com" posted there.
Still, there are a lot of scenarios where OpenID makes sense: for example "blogger.com says that hisham@livejournal.com wrote xyz". This is the kind of thing that OpenID allows, and I think it's great. The question is if people will "get" this.
Thanks for your input, but I think you may be missing the point: GoboLinux is not replicating the Windows structure. We don't like the Windows dir structure either.
Under each program directory, what we have in GoboLinux is a Unix tree: /Programs/Bash/3.0/bin, /Programs/Bash/3.0/lib, etc. We compile programs with their own --prefix, for organizational purposes. It's the same reason why a user compiles "his/her stuff" in /usr/local rather than /usr -- so it doesn't get mixed up with system stuff... but then their various programs get mixed up in /usr/local. We're just taking this idea one step further, applying it to the whole system (and throwing versioning into it, while we're at it). Think /opt on steroids.
The goal of GoboLinux is not to make the fs tree "look prettier" or "more like Windows". It's a matter of organization. About the 'pretty' names (/Users, /System), we took the clue from NeXT, Mac OS X, RISC OS and many others before, and in fact it's a way very good way to avoid clashing with the ever-changing "standard" Linux tree (think /sys).
Exactly! Neither do we! And the thing is, the usual Linux structure also has binaries, libraries and config files scattered "all over the place" -- /bin, /sbin, /usr/bin, /usr/sbin, /usr/X11R6/bin, /usr/X11R6/sbin, /usr/local/bin, /opt/bin, /opt/sbin... -- with no clear distinction of what should go where. Sure there are some vague rules, but given a program you can't tell a priori where it is [I know about the 'which' program, duh; I'm arguing about the principle of the layout]. Sure, in GoboLinux you'll have a hundred different ".../bin" directories, but there's a logic and deterministic way to determine what is where, and that is the file path: /Programs/Bash/3.1/bin/bash. (And no, the $PATH is not a hundred entries long, because we use symlink directories to index the system -- and you can use that to do 'reverse lookup' easily).
So, in GoboLinux we don't have the mess that is /windows/system (or whatever it's called these days) or the mess that is /usr/lib. Sure, the package managers try to, err, manage that mess in Linux. But isn't a better idea to have things layout properly instead?
Don't let the name "Programs" fool you into thinking of "Program Files". It works very differently. Well, I guess we should have picked a different name, if only to avoid this kind of confusions.
I hope I clarified some points, and thanks for checking out the project! :)
BSD or other GPL-incompatible Free Software developers.
The BSD license (at least the one used nowadays) is GPL-compatible.
In fact, there are parts of KDE licensed under BSD-style licenses.
Here's FSF's list of licenses and their relation to the GPL.
It's a reminder, just like attaching a picture of a fat person to the door of your fridge.
Welcome to life, where people will always try to find something you did in the past to put you in a bad situation. And this will happen every day...
I can totally picture Marvin from Hitchhiker's Guide saying this.
Those English-written articles are of course giving you the standard English pronunciation. I dont see a problem with that -- you're entitled to pronounce foreign names according to the rules of your language, just like you don't call Paris "Pah-hee" like the French do, or Munich "Mewn-shen" like the Germans (man, were those crappy approximations or what).
However, if you are interested in the proper pronunciation of Zeus: the "e" sounds like the "a" in "bay", the "u" sounds like the "oo" in "food".
How to assess this? Look up the Greek spelling in Wikipedia: Zeus article and then this Ancient Greek pronunciation table.
Incidentally, the Ancient Greek pronunciation is exactly the same as we pronounce "Zeus" in my native language (Portuguese), and I assume that's how it is pronounced in German as well (because following strict German rules, Zeus would be pronounced "Tzoyce", as in "Joyce" with a "Tz").
Wine (which Cedega is based on) runs of hundreds of other Linux distributions.
"-1, buy an ad" -- oops, wrong site.
Microsoft are big on XML. Their new office format will be completely open and XML compliant. Do you call releasing a file format in a GPL-incompatible way "completely open"?? (Notice I didn't refer to GPL-incompatible code. There's a lot of GPL-incompatible free software out there, and they are still free software. File formats, however, are a different story. To be open, they need to be implementation-independent. Not only in their specification but also on their licensing.)
Or is it a "good, fast, cheap, pick two, tough shit" situation?
;)
Yes, but it's more like a "open, popular -- pick one" situation. A friend of mine is a GP32 developer. The architecture is completely open, he bought it to hack on it more than to play with it. In fact, he's now maintaining the Linux kernel port for the specific ARM architecture of the GP32 port.
And yes, nobody else had a GP32 in his town when he bought it (or in his state, maybe even country(!), for that matter). But he found a very exciting user and developer community on the internet. So the installer base in [whatever specific place you are] is not that relevant.
Still, after seeing the GP32, I was almost tempted to buy one for myself (but I was broke at the time). Chances are, if you buy one, your friends might follow suit.
And emulators work like a charm, so there's no shortage of games, especially if you're into the classics.
The Z Shell features some heuristics for that. If a command line performs a completion on "*" and the command is "rm", it asks for confirmation, even with -f:
/Depot/test]rm a* /Depot/test]rm * /Depot/test [yn]? n /Depot/test]rm -f * /Depot/test [yn]?
hisham@brick
hisham@brick
zsh: sure you want to delete all the files in
hisham@brick
zsh: sure you want to delete all the files in
Obviously, as everything in zsh, this is configurable (setopt -u rm_star_silent to disable it).
"archane directory structure"
/usr for installed programs
/etc for all systemwide configuration files
/home for different user's files
/boot for stuff related to booting the system
/tmp for temporary files
/usr, making it nearly impossible to cleanly uninstall if it was compiled from source or the package manager database got corrupted ("--force", anyone?), ocasionally with bits and pieces spread under /bin, /sbin, etc (look at all the different places the files from CoreUtils is usually installed). The fact that "ping" and "traceroute" are stored in different place is not systematic.
/var -- now that's something quite hard to do (its de facto usage in distros, not the dream world described by the FHS).
/etc,
/etc they are placed almost randomly. If you don't know the exact name of the configuration file you need (which may or may not be under a subdirectory...), you're out of luck.
Those are what you are likely to occur, every thing is nice and systematic.
Except that everything is not nice and systematic. First, all programs get dumped together under
I also noticed you didn't describe
"random placement if configuration files"
System configuration files will all be in
programs generally check the following areas -
True, but under
Yes, the usual Linux directory structure is arcane.
Now, as to why they decided to use front slashes for command line parameters, I have no idea.
.COM and .BAT file extensions.
IIRC, Forward slashes for options comes from VMS. And so do the
Everytime I hear someone say "compiling packages by hand" I think of some guy looking up assembly equivalents of the code in question, then optimizing the assembly in his head, and finally doing an opcode translation. :-)
:)
As someone who has already done exactly what you described, in a distant Apple II past (6502 asm... large chunks of code any time you needed a 16-bit operation, what a pain) -- except for the "optimization in his head" bit of course; I resorted to plain-old paper, much easier to fix the jump offsets -- I can say the Gentoo experiment would take something in the order of centuries.
But seriously, while "compiling by hand" sounds funny is not that much of a misnomer. With so many tools to automate compilation out there (emerge, SRPMs and of course our own Compile) , there is definitely a distinction nowadays to be made. In the mailing lists we often ask "was that compiled 'by hand' or with Compile?"
I'll join my voice to the ones praising Linux From Scratch. It's an amazing resource for learning how a Linux system is built.
:)
We used it as a reference when we built the first full version of GoboLinux -- essentially following the steps of the book and adding our modifications (configure and makefile flags) to build the new directory structure, to make our "/usr"-less distro.
To this day, I refer to their build instructions every now and then. They also contain a good collection of security patches, so if you're into compiling your packages by hand, drop by at their site and see if they suggest any additional patches. LFS covers the basic system and Beyond LFS covers the additional stuff (KDE, GNOME, etc.).
IIRC, Windows 98 came with IE4.
As in "Yay, content should be free, but if somebody subscribes to Slashdot and starts posting the subscriber-sees-early material on some website before Slashdot opens it up, then they should burn in jail"?
Oh well. That would probably be some kind of "violation of terms of service" anyway. Or wouldn't it?...