More likely is that Ogg Vorbis would get the extenstion.oga, for Ogg Audio. Then you'd get.ogm for Ogg M(ovie|edia) or perhaps.ogv... Since Og can be pronounced much the same as Ogg, this preserves the name while giving aditional type information, which is a good thing.
.ogg would be a generic extension for any of the above, and probably should be discouraged.
As it stands now, LSB has done absolutely nothing to improve consistancy between distribtuions, and only allowed them to diverge even moreso, and saying that divergance is OK for compatibility. This is a wrong assumption, and should be looked at by the LSB group.
Hey-a. I seem to recall hearing that this is one of the big things wrong with X-related 'standards'--they got in late, and bent over backwards to accomodate every different way things were done already, thus making them less than useful. This is heresay, of course.
In contrast to this, "Don't fragment Linux any more than it is". A desktop/server split would be bad. My desktop linux skills are totally transferable, and my desktop is my server. Why obscure things more by making two different filesyetm layouts? Yeah, I know the why people say, but I don't agree that the tradeoff is worth it.
Anyway, that's the jist. Needless to say there is a very good reason that the Unix filesystem has its current layout. A nice change might be to install programs under/usr/local into seperate directories (e.g./usr/local/perl-5.8.0 and/usr/local/perl-5.7.0) and provide symlinks where appropriate into/usr/local/bin and so on. I believe such a scheme as this is used under solaris.
I think/usr/local/perl/5.8.0/ and similar would be better.
I wish some scheme could be arrived at which performs all of the functions of the traditional layout but which makes it more obvious what each bit is for, and why each bit is necessary. Much trouble could be avoided if such a scheme could be devised, but I am continually stumped when I try to invent one.
I think that most of the resistance to gobolinux has to do with the fact that it's different, not on any merits or faults of these differences. There are a whole bunch of UNIX geeks out there, especially in the university environment, who would lose their jobs if UNIX were easier to use and more intuitive. Just because you're semi-autistic and can manage to hack out UNIX commands and use the CLI doesn't mean that you're smart, or elite or anything else other than that you have a memory for arcane trivia.
I think most of the people cheering gobolinux on are doing it out of ignorance. A few probably are well aware of what it all means, and I am eager to hear their reasoned opinions.
It's got little to do with it just being different. Okay, some (ie "It's different but not better so why change it at all?"), but not much.
Gobolinux proposes changing/home to/Users. This is not less confusing, only confusing in a different way. Why would a user be looking for his files under a directory called Users (even supposing he was browsing from / to begin with?)? To the kind of nonsavvy person this is supposed to cater to, Users is not going sound like a place for users personal files, it just sounds like it from the perspective of engineers who are used to thinking in such terms. An average joe is much more likely to descend into a directory called home to see if it's his home or not.
And notice the difference here... why/Users and not/users? The capital letter wont really matter to your desktop users, but it sure as hell matters to a command line junkie. Tab completion is case sensetive (even on OS X where the filesystem is not) and over time it's a LOT more effort to hit SHIFT+U than it is to hit u.
I could continue like this, but I'm sure you get the idea. There are good reasons for the way things are, it's not simply a matter of intertia (although, admittedly, a lot of it is) and it is most certainly not simply a desire of the elite to keep themselves in power.
I once advocated radical changes such as gobolinux proposes, but then I investigated why things were. And once you know why, it becomes very hard to argue to change. You become aware of what kinds of problems must be taken into account. I am sure most Linux distro's have had someone do what I did, and they seem to mostly reach my conclusion: It's hard to change, there are too many technical reasons why it might be a disaster, too many personal feelings are involved, and the system as it is Works Now. If it aint broke (or at least if it aint real broke) don't fix it.
My proposal for a revised Linux directory structure:
Since all names are arbitrary, I see no reason not to have an easy transition./bin/programname/ # Executables for programname /lib/programname/ # Libraries for programname /etc/programname/ # System configuration for programname /share/programname/ # Data files for programname /share/programname/etc/ # Default system and user configuration for programname /home/username/ # Useranme's directory /home/username/.etc/ # Username's configuration files. Note the hidden-ness /home/username/.local/ # Programs the user installed himself /tmp/ # Any and all temporary files /root/ # The administer is NOT a user!
No more/usr/ directory! I know exactly why eliminating it is a bad idea, and I do it anyway.
Let the admin worry aout what is local and what is not.
Under this scheme libraries and only libraries would be under/lib, executables and only executables would be under/bin (this is pretty much done already) and no libraries or executables would ever be under/share
Only when some manner of directory joins are possible can we truly have the flexibility needed to replace the old structure compeltely. The parent post alluded to this and is completely correct. Regardless of how it is implimented, we simply MUST be able to say "all files matching this shell pattern are to be considered a new directory HERE". Rules for name clashes would have to exist... such as either the first encountered takes precedence, or the last encountered , or whatever. Doesn't matter, so long as it is standardized. This would be mind-bogglingly useful and fairly simple to impliment at the shell level (filesystem level would be better, but I don't know what that would entail).
The important thing to note is: The UNIX directory structure is like it is for very good reasons. Any attempt at replacing it must satisfy at least most if not all of those reasons. You can't just treat root like a user and put his home directory under/home. This is because the administer is NOT a user. You cannot have/root under/home if you expect/home to be a remote filesystem (likely in server configurations). Call the directory/administrator if you like and always refer to it as/`id -nu`/ but leave it where it is. You can't move/bin and/usr/bin to the same directory, because one is basic utilities needed for operation (like booting and fixing things in an emergency situation) while the other is all of the applications and utilities that are necessary for more general operation. For this I have no solution, so I choose to ignore the problem.
I firmly believe that UNIX can be all things to all people at the same time. Desktop efforts like gobo seem to think otherwise; they are attempting to cater to the desktop by totally ignoring the server (and the advancd user).
Totally? Yes, I mean it. They capitalize the first letter of directory names. This is fine if you're a GUI user who does little, but the moment you pull up a command prompt it becomes a horrible pain. There is nothing wrong with lower case words, and it is frankly necessary so long as tab completion is case sensetive... which I also believe it should be.
Let me reiterate: One filesystem for all uses. This is a must. The only thing that makes the current scheme better than gobo's is that it's mostly the same everywhere. 98% of the time any standard (however awful) is better than no standard. A revised directory structure is a good idea and a positive step, but it must not alienate one section of users. Any revised layout must be accepted and become widely used or it
Debian for all the reasons other have mention--light, customizable, works well on older hardware, easy to do mass installs, etc.
IceWM is very light and fast, simple to configure, and looks a bit like Windows.
On this note, perhaps an old version of Libranet? They use IceWM by default, and the older versions are free. Something in the 1.x range with a desktop install would work.
btw, does anyone know a good personal delta-backup software to automatise this?
No, but I could write you a shell script in about nine seconds.
Oh, do you mean with a GUI? Then no.
But seriously, I have have cron job tar, gzip and store in a safe location my entire home directory once per day under a date-stamped filename. HD space is cheap, so I delete old stuff infrequently.
To make this more secure, make the script run as a user whose files normal users are not allowed to read (much less write), make the backup location a seperate disk or a network drive, and boom. Safety. One can rvrn impliment the "Roll back to a working configuration" thing by a similar method of autobacking up/etc.
but I'm not convinced web server is good enough for GUI of such device.
Agreed. I'd prefer a simple FTP NFS or Samba server, or something along those lines. Maybe just SSH + a SFTP client with a pretty file-manager-like GUI whenever I want to access it. The device-side interface should merely be a protocal.
The only real advantage of the web server idea is that you wont be limited to what platforms have a client as all platforms pretty much have a client already.
IE for Mac renders pages differently. Not just a little, REALLY differently. Until Mozilla came out IE5Mac was the most standards compliant browser around. If you were a web developer and tested your pages on many OSs/browsers you'd be familiar with this.
Actually, to me, 1 bin directory isn't what I want. I want 100 directories, (one for each program) all as subdirectories to bin and automatically searched as part of the path.
I've seen this argument before, and I do not necessarily dissagree. I'm still undecided as to which would be the best solution. Many directories seems visually cleaner, but as you say there could be performance problems.
I've scrolled halfway through the posts and haven't seen anyone say it, so I will: He's describing Debian.
Okay, not now Debian, but a friendly Debian. His/system/commands "idea" is a clunkly thought out version of/etc/alternatives. His "One bog site where you can download packages that are guaranteed to work with your distro" describes the official apt repository nicely. His description of dependancy hell sounds like the experience of a RPM user--I wont say that Debian never has pckage problems, but I will say that I've only ever seen them in Unstable--on my Debian system dependancies are never an issue.
I don't mean to sound like a Debian-loving zealot (though I probably am...) but 50% of what he wants Debian already does. Of the rest:
The revamped directory structure is a must. I've looked at it every way I can, but as far as I can see the old unix layout (while close to my heart) is not going to make desktop users happy. I've heard all tha counter arguments (and made most of them myself) so don't bother. I dissagree with his names, and I don't like the way MacOSX does it either, but something has to be done. Even if it isn't renaming (people can learn any names, after all) it should be depreciating certain practices and/or not allowing them. I know there are good reasons for/bin and/usr/bin and/usr/local/bin (and on Debian at least their uses are clearly defined) but one bin directory for users and one for root should be enough. (The argument is (of course) partitioning. Mount/usr ro!/bin is on / so that the system always boots and everything else can be remote! I don't have an answer; maybe the HURD and its fancy merging directory thing will be the solution.) Debian can dictate such a change, if it could be agreed upon.
Limiting choice. This is a Very Bad Idea. limited choice is never, ever good--this is my firm conviction. But that doesn't mean there can't be sensible defaults. Make everything work automatically and TOGETHER automatically, and have all of the choices there for those who go looking. Maybe limiting packages on the install CD is worthwhile... but the choice should always be there. Debian limits nothing, and its default setup does not work perfectly... but it has potential. I can see it pulling itself up by its bootstraps and becoming a system that works together with itself.
Graphical installers. I'll say it one more time, I've said it before: screen one of the installer should be DOS/curses style and say "Easy install or Advanced install?" This is not to say everything he said about having the graphical install have advanced buttons isn't true; that's necessary as well. What this means is that the idiots can pick "Easy" while I pick "Advanced" and I get my sure-to-work-on-this-VGA-piece-of-shit installer complete with cfdisk partitioning and all of the gory details. There should never be a total reliance on a fully GUI install. Debian's installer is awful and could use some kind of option like this.
Liscense. BSD-style is nice, but GPL is Free. Non-GPL is not an option.
Kernel. This is another point in favor of Debian. It's (at least potentially) kernel agnostic. Linux today, NetBSD tomorrow, the HURD on Friday. A truly Complete Debian would allow you to pick any (supported) kernel you wanted at install time... be it Linux, or *BSD, or whatever. Doesn't matter.
As far as source goes... the debian way seems good. apt-get source. You can't do it by mistake, and it's not like archive material so few would get it "because it's free". Bandwidth problem largely solved (or at least not seriously aggravated) and you don't piss off zealots like me.
I will close by saying it again: Don't reinvent what Debian already does. Build a debian-based distro (a script could repackage many applications to use any new dir layout you choose). What this guy wants is a Friendly Debian and a little bit of proprietary code.
Linus has strong opinions, yes, but he also will go to great lengths to deny that. Some people take him at his word when he says stuff like that.
It's a great political move. Deny everthing so the majority are fooled into thinking you don't have any relevance while at the same time shaping the nature of the discussion everyone else has. He does this over and over. Truly impressive.
Torvalds' political apathy, on the other hand is irritating, in the same way that Canada's wishy-washy stance on the war in Iraq is irritating: trying to please all by doing nothing.
Guess what: driven people have strong opinions, and are willing to risk unpopularity (and often, much worse things), to stand by them.
Ah, but Linus does have strong opinions and is very much risking unpopularity (with his own crowd, even) by standing by them.
Even the GPL itself states that one cannot descriminate aganst users for who they are or what they do with the software, as long as the source remains Free. Linus is standing very, stubbornly close to this philosophy, even though it would be easier to go with the crowd that demands changing things to be more restrictive
If you ban DRM on the kernel, where does it end? Currently nothing is banned, as long as you provide the sources. That's a high ideal to hold to: upholding the right of others to use your code in a way you find immoral, because of the principle that says the code's usage must remain unrestricted.
It's flamebait because he starts off calling most people "lusers," declares the scroll wheel to be an "abomination," slants the MS Natural Keyboard by calling it "unnatural," and declares that since people buy them, they must be idiots.
Um... not to be rude, but I don't see your point. That most people are lusers is somewhat debatable, but the scroll wheel IS an abomination (I'd kill for an optical 3-button no-scrollwheel mouse!) the so-called "natural" keyboard IS unnatural, and people who buy them may not be idiots, but those who LIKE them certainly are. So far nothing he's said has been particularly harsh or uncalled for.
Then he starts to make a rational post, but goes awry again when he complains about "'Windows enhanced' pieces of shit."...which they are...
He then declares that he doesn't want to pay more for a higher quality product.
It's not "higher quality:" it's "more useless 'features' which hinder productivity"
And as if the initial insults weren't enough, he uses the phrase "Masses are Asses." He then agrees with someone else, and then finishes up with an ever-so-slightly insightful comment.
Listen closely... the 'needs' of the general masses are shaping what computer products get produced. These people are (largely) not computer-obsessed enough to appreciate how detrimental some of their preferences would be to the rest of us. This would be fine (to each his own) except that hardware manufacturers, seeing the massive market, DROP THEIR OTHER PRODUCTS. This forces the computer-obsessed to use consumer-grade crap, or pay lots extra for specially-made standard hardware.
A certain bitterness at the masses of computer-adjacent morons that changed the world from a "Mice I use are cheap and easy to find" place to a "I must pay lots of money for a mouse even close to ideal" kind of place is understandable.
That's for commercial software, where "first release" is 1.0 and any decent enhancement causes a major version number jump. With open source stuff, a number is just a number. Mozilla has tried to keep some meaning foir the 1.0 release, but in reality Mozilla hit 1.0-comercial quality at version 0.9 or so. Further, while commercial apps tend to add performance enhancements and bug fixes for minor version numbers, open source stuff adds whatever needs adding.
I've thought about this
on
Eleventy What?
·
· Score: 2, Funny
and you're right, there is no current answer.
What needs to be done is to invent words that mean each of these symbols. When you say A in hex it is not the alphabet A, it's a totally different concept and needs a different word to express it.
The best way would be to invent and standardize a set of words for speaking numbers/about numbers in base 16. Because, really, 10 would be pronounced "sixteen" which makes no sense. Base16(16) should be pronounced "16" and mean base10(22).
It's a culture/language thing, you see. In order to have it make sane sense you need to think of numbers in base 16, not 10.
I have, of course, come up with my own words for each of these A-F numbers, with simple rules for how to pronounce combinations like 1CF anf D7B and so on. I'd post them, but I've mislaid the paper I wrote them on. And I think that illustrates my point: In order to remember/use these things properly, we'd have to think in another base. And that's just too impractical to be likely to happen.
Slashdot Mirror
Ah, so true...
More likely is that Ogg Vorbis would get the extenstion .oga, for Ogg Audio. Then you'd get .ogm for Ogg M(ovie|edia) or perhaps .ogv... Since Og can be pronounced much the same as Ogg, this preserves the name while giving aditional type information, which is a good thing.
.ogg would be a generic extension for any of the above, and probably should be discouraged.
As it stands now, LSB has done absolutely nothing to improve consistancy between distribtuions, and only allowed them to diverge even moreso, and saying that divergance is OK for compatibility. This is a wrong assumption, and should be looked at by the LSB group.
Hey-a. I seem to recall hearing that this is one of the big things wrong with X-related 'standards'--they got in late, and bent over backwards to accomodate every different way things were done already, thus making them less than useful. This is heresay, of course.
In contrast to this, "Don't fragment Linux any more than it is". A desktop/server split would be bad. My desktop linux skills are totally transferable, and my desktop is my server. Why obscure things more by making two different filesyetm layouts? Yeah, I know the why people say, but I don't agree that the tradeoff is worth it.
I believe the intention with gobo is for one to be able to say something like
/$dir/Packagename/Version/
for dir in Programs Libraries Whatever do
rm -r
done
and have it remove all associated files.
The key thing is consistency. All files in one dir is very consistent, but so is all files in one pattern (as long as the pattern is simple).
You can tell bash to list directories first no matter what.
But I agree, case sensitivity is a must.
Gobolinux torrent taken from the gobolinux site, which now appears to be accessible.
Anyway, that's the jist. Needless to say there is a very good reason that the Unix filesystem has its current layout. A nice change might be to install programs under /usr/local into seperate directories (e.g. /usr/local/perl-5.8.0 and /usr/local/perl-5.7.0) and provide symlinks where appropriate into /usr/local/bin and so on. I believe such a scheme as this is used under solaris.
/usr/local/perl/5.8.0/ and similar would be better.
I think
I wish some scheme could be arrived at which performs all of the functions of the traditional layout but which makes it more obvious what each bit is for, and why each bit is necessary. Much trouble could be avoided if such a scheme could be devised, but I am continually stumped when I try to invent one.
I think that most of the resistance to gobolinux has to do with the fact that it's different, not on any merits or faults of these differences. There are a whole bunch of UNIX geeks out there, especially in the university environment, who would lose their jobs if UNIX were easier to use and more intuitive. Just because you're semi-autistic and can manage to hack out UNIX commands and use the CLI doesn't mean that you're smart, or elite or anything else other than that you have a memory for arcane trivia.
/home to /Users. This is not less confusing, only confusing in a different way. Why would a user be looking for his files under a directory called Users (even supposing he was browsing from / to begin with?)? To the kind of nonsavvy person this is supposed to cater to, Users is not going sound like a place for users personal files, it just sounds like it from the perspective of engineers who are used to thinking in such terms. An average joe is much more likely to descend into a directory called home to see if it's his home or not.
/Users and not /users? The capital letter wont really matter to your desktop users, but it sure as hell matters to a command line junkie. Tab completion is case sensetive (even on OS X where the filesystem is not) and over time it's a LOT more effort to hit SHIFT+U than it is to hit u.
I think most of the people cheering gobolinux on are doing it out of ignorance. A few probably are well aware of what it all means, and I am eager to hear their reasoned opinions.
It's got little to do with it just being different. Okay, some (ie "It's different but not better so why change it at all?"), but not much.
Gobolinux proposes changing
And notice the difference here... why
I could continue like this, but I'm sure you get the idea. There are good reasons for the way things are, it's not simply a matter of intertia (although, admittedly, a lot of it is) and it is most certainly not simply a desire of the elite to keep themselves in power.
I once advocated radical changes such as gobolinux proposes, but then I investigated why things were. And once you know why, it becomes very hard to argue to change. You become aware of what kinds of problems must be taken into account. I am sure most Linux distro's have had someone do what I did, and they seem to mostly reach my conclusion: It's hard to change, there are too many technical reasons why it might be a disaster, too many personal feelings are involved, and the system as it is Works Now. If it aint broke (or at least if it aint real broke) don't fix it.
My proposal for a revised Linux directory structure:
/bin/programname/ # Executables for programname
/lib/programname/ # Libraries for programname
/etc/programname/ # System configuration for programname
/share/programname/ # Data files for programname
/share/programname/etc/ # Default system and user configuration for programname
/home/username/ # Useranme's directory
/home/username/.etc/ # Username's configuration files. Note the hidden-ness
/home/username/.local/ # Programs the user installed himself
/tmp/ # Any and all temporary files
/root/ # The administer is NOT a user!
/usr/ directory! I know exactly why eliminating it is a bad idea, and I do it anyway.
/lib, executables and only executables would be under /bin (this is pretty much done already) and no libraries or executables would ever be under /share
/home. This is because the administer is NOT a user. You cannot have /root under /home if you expect /home to be a remote filesystem (likely in server configurations). Call the directory /administrator if you like and always refer to it as /`id -nu`/ but leave it where it is. You can't move /bin and /usr/bin to the same directory, because one is basic utilities needed for operation (like booting and fixing things in an emergency situation) while the other is all of the applications and utilities that are necessary for more general operation. For this I have no solution, so I choose to ignore the problem.
Since all names are arbitrary, I see no reason not to have an easy transition.
No more
Let the admin worry aout what is local and what is not.
Under this scheme libraries and only libraries would be under
Only when some manner of directory joins are possible can we truly have the flexibility needed to replace the old structure compeltely. The parent post alluded to this and is completely correct. Regardless of how it is implimented, we simply MUST be able to say "all files matching this shell pattern are to be considered a new directory HERE". Rules for name clashes would have to exist... such as either the first encountered takes precedence, or the last encountered , or whatever. Doesn't matter, so long as it is standardized. This would be mind-bogglingly useful and fairly simple to impliment at the shell level (filesystem level would be better, but I don't know what that would entail).
The important thing to note is: The UNIX directory structure is like it is for very good reasons. Any attempt at replacing it must satisfy at least most if not all of those reasons. You can't just treat root like a user and put his home directory under
I firmly believe that UNIX can be all things to all people at the same time. Desktop efforts like gobo seem to think otherwise; they are attempting to cater to the desktop by totally ignoring the server (and the advancd user).
Totally? Yes, I mean it. They capitalize the first letter of directory names. This is fine if you're a GUI user who does little, but the moment you pull up a command prompt it becomes a horrible pain. There is nothing wrong with lower case words, and it is frankly necessary so long as tab completion is case sensetive... which I also believe it should be.
Let me reiterate: One filesystem for all uses. This is a must. The only thing that makes the current scheme better than gobo's is that it's mostly the same everywhere. 98% of the time any standard (however awful) is better than no standard. A revised directory structure is a good idea and a positive step, but it must not alienate one section of users. Any revised layout must be accepted and become widely used or it
You went to an Ask Slashdot in hopes of getting FEWER choices? :::shakes head:::
Debian for all the reasons other have mention--light, customizable, works well on older hardware, easy to do mass installs, etc.
IceWM is very light and fast, simple to configure, and looks a bit like Windows.
On this note, perhaps an old version of Libranet? They use IceWM by default, and the older versions are free. Something in the 1.x range with a desktop install would work.
btw, does anyone know a good personal delta-backup software to automatise this?
/etc.
No, but I could write you a shell script in about nine seconds.
Oh, do you mean with a GUI? Then no.
But seriously, I have have cron job tar, gzip and store in a safe location my entire home directory once per day under a date-stamped filename. HD space is cheap, so I delete old stuff infrequently.
To make this more secure, make the script run as a user whose files normal users are not allowed to read (much less write), make the backup location a seperate disk or a network drive, and boom. Safety. One can rvrn impliment the "Roll back to a working configuration" thing by a similar method of autobacking up
but I'm not convinced web server is good enough for GUI of such device.
Agreed. I'd prefer a simple FTP NFS or Samba server, or something along those lines. Maybe just SSH + a SFTP client with a pretty file-manager-like GUI whenever I want to access it. The device-side interface should merely be a protocal.
The only real advantage of the web server idea is that you wont be limited to what platforms have a client as all platforms pretty much have a client already.
IE for Mac renders pages differently. Not just a little, REALLY differently. Until Mozilla came out IE5Mac was the most standards compliant browser around. If you were a web developer and tested your pages on many OSs/browsers you'd be familiar with this.
You know that Mozilla "bugs" are pretty meaningless, right?
Actually, to me, 1 bin directory isn't what I want. I want 100 directories, (one for each program) all as subdirectories to bin and automatically searched as part of the path.
I've seen this argument before, and I do not necessarily dissagree. I'm still undecided as to which would be the best solution. Many directories seems visually cleaner, but as you say there could be performance problems.
I've scrolled halfway through the posts and haven't seen anyone say it, so I will: He's describing Debian.
/system/commands "idea" is a clunkly thought out version of /etc/alternatives. His "One bog site where you can download packages that are guaranteed to work with your distro" describes the official apt repository nicely. His description of dependancy hell sounds like the experience of a RPM user--I wont say that Debian never has pckage problems, but I will say that I've only ever seen them in Unstable--on my Debian system dependancies are never an issue.
/bin and /usr/bin and /usr/local/bin (and on Debian at least their uses are clearly defined) but one bin directory for users and one for root should be enough. (The argument is (of course) partitioning. Mount /usr ro! /bin is on / so that the system always boots and everything else can be remote! I don't have an answer; maybe the HURD and its fancy merging directory thing will be the solution.) Debian can dictate such a change, if it could be agreed upon.
Okay, not now Debian, but a friendly Debian. His
I don't mean to sound like a Debian-loving zealot (though I probably am...) but 50% of what he wants Debian already does. Of the rest:
The revamped directory structure is a must. I've looked at it every way I can, but as far as I can see the old unix layout (while close to my heart) is not going to make desktop users happy. I've heard all tha counter arguments (and made most of them myself) so don't bother. I dissagree with his names, and I don't like the way MacOSX does it either, but something has to be done. Even if it isn't renaming (people can learn any names, after all) it should be depreciating certain practices and/or not allowing them. I know there are good reasons for
Limiting choice. This is a Very Bad Idea. limited choice is never, ever good--this is my firm conviction. But that doesn't mean there can't be sensible defaults. Make everything work automatically and TOGETHER automatically, and have all of the choices there for those who go looking. Maybe limiting packages on the install CD is worthwhile... but the choice should always be there. Debian limits nothing, and its default setup does not work perfectly... but it has potential. I can see it pulling itself up by its bootstraps and becoming a system that works together with itself.
Graphical installers. I'll say it one more time, I've said it before: screen one of the installer should be DOS/curses style and say "Easy install or Advanced install?" This is not to say everything he said about having the graphical install have advanced buttons isn't true; that's necessary as well. What this means is that the idiots can pick "Easy" while I pick "Advanced" and I get my sure-to-work-on-this-VGA-piece-of-shit installer complete with cfdisk partitioning and all of the gory details. There should never be a total reliance on a fully GUI install. Debian's installer is awful and could use some kind of option like this.
Liscense. BSD-style is nice, but GPL is Free. Non-GPL is not an option.
Kernel. This is another point in favor of Debian. It's (at least potentially) kernel agnostic. Linux today, NetBSD tomorrow, the HURD on Friday. A truly Complete Debian would allow you to pick any (supported) kernel you wanted at install time... be it Linux, or *BSD, or whatever. Doesn't matter.
As far as source goes... the debian way seems good. apt-get source. You can't do it by mistake, and it's not like archive material so few would get it "because it's free". Bandwidth problem largely solved (or at least not seriously aggravated) and you don't piss off zealots like me.
I will close by saying it again: Don't reinvent what Debian already does. Build a debian-based distro (a script could repackage many applications to use any new dir layout you choose). What this guy wants is a Friendly Debian and a little bit of proprietary code.
Linus has strong opinions, yes, but he also will go to great lengths to deny that. Some people take him at his word when he says stuff like that.
It's a great political move. Deny everthing so the majority are fooled into thinking you don't have any relevance while at the same time shaping the nature of the discussion everyone else has. He does this over and over. Truly impressive.
And nice sig, by the way.
Torvalds' political apathy, on the other hand is irritating, in the same way that Canada's wishy-washy stance on the war in Iraq is irritating: trying to please all by doing nothing.
Guess what: driven people have strong opinions, and are willing to risk unpopularity (and often, much worse things), to stand by them.
Ah, but Linus does have strong opinions and is very much risking unpopularity (with his own crowd, even) by standing by them.
Even the GPL itself states that one cannot descriminate aganst users for who they are or what they do with the software, as long as the source remains Free. Linus is standing very, stubbornly close to this philosophy, even though it would be easier to go with the crowd that demands changing things to be more restrictive
If you ban DRM on the kernel, where does it end? Currently nothing is banned, as long as you provide the sources. That's a high ideal to hold to: upholding the right of others to use your code in a way you find immoral, because of the principle that says the code's usage must remain unrestricted.
It's flamebait because he starts off calling most people "lusers," declares the scroll wheel to be an "abomination," slants the MS Natural Keyboard by calling it "unnatural," and declares that since people buy them, they must be idiots.
...which they are...
Um... not to be rude, but I don't see your point. That most people are lusers is somewhat debatable, but the scroll wheel IS an abomination (I'd kill for an optical 3-button no-scrollwheel mouse!) the so-called "natural" keyboard IS unnatural, and people who buy them may not be idiots, but those who LIKE them certainly are. So far nothing he's said has been particularly harsh or uncalled for.
Then he starts to make a rational post, but goes awry again when he complains about "'Windows enhanced' pieces of shit."
He then declares that he doesn't want to pay more for a higher quality product.
It's not "higher quality:" it's "more useless 'features' which hinder productivity"
And as if the initial insults weren't enough, he uses the phrase "Masses are Asses." He then agrees with someone else, and then finishes up with an ever-so-slightly insightful comment.
Listen closely... the 'needs' of the general masses are shaping what computer products get produced. These people are (largely) not computer-obsessed enough to appreciate how detrimental some of their preferences would be to the rest of us. This would be fine (to each his own) except that hardware manufacturers, seeing the massive market, DROP THEIR OTHER PRODUCTS. This forces the computer-obsessed to use consumer-grade crap, or pay lots extra for specially-made standard hardware.
A certain bitterness at the masses of computer-adjacent morons that changed the world from a "Mice I use are cheap and easy to find" place to a "I must pay lots of money for a mouse even close to ideal" kind of place is understandable.
"13. Re-assemble the mouse and you now have a 3 button no wheel mouse!" ...with a really, really small middle button. No thanks.
Probably best to just make the storage back end plugable. The added advantage is that this doesn't piss off the postgres people.
That's for commercial software, where "first release" is 1.0 and any decent enhancement causes a major version number jump. With open source stuff, a number is just a number. Mozilla has tried to keep some meaning foir the 1.0 release, but in reality Mozilla hit 1.0-comercial quality at version 0.9 or so. Further, while commercial apps tend to add performance enhancements and bug fixes for minor version numbers, open source stuff adds whatever needs adding.
This table might explain it best:
Mozilla version --- commercial equivalent
M17 --- Alpha
0.8 --- Beta
0.9 --- 1.0
0.9.1 --- 1.1
...
0.9.6 --- 1.9
0.9.7 --- 2.0
0.9.8 --- 2.1
0.9.9 --- 2.2
1.0 --- 2.3
1.1 --- 2.5
1.2 --- 2.6
1.3 --- 3.0
1.4alpha --- 3.1beta
Get the idea?
and you're right, there is no current answer.
What needs to be done is to invent words that mean each of these symbols. When you say A in hex it is not the alphabet A, it's a totally different concept and needs a different word to express it.
The best way would be to invent and standardize a set of words for speaking numbers/about numbers in base 16. Because, really, 10 would be pronounced "sixteen" which makes no sense. Base16(16) should be pronounced "16" and mean base10(22).
It's a culture/language thing, you see. In order to have it make sane sense you need to think of numbers in base 16, not 10.
I have, of course, come up with my own words for each of these A-F numbers, with simple rules for how to pronounce combinations like 1CF anf D7B and so on. I'd post them, but I've mislaid the paper I wrote them on. And I think that illustrates my point: In order to remember/use these things properly, we'd have to think in another base. And that's just too impractical to be likely to happen.