It's used by a load of educational and research institutions (notably CERN), as well as Wall Street firms.
No kidding. I had an account where I could "cd/afs" and get into at least twenty universities. (I was trying to use some software that a student put on the web, and I needed to recompile it but he refused to put up the source. So I cd'ed into his home directory at his school and copied it. For my personal use only, not to distribute.)
One nasty glitch is that (at least in some installations) AFS file permissions are maintained separately from standard *nix file permissions. In other words, "chmod o-r *" does nothing to stop other people from reading your files (as I found out when my entire home directory was made available over the web).
* Matrix operations
* Polynomials (represented by array of coefficients, [1,1]*[1,1] gives [1,2,1])
* Other string operations, like 3*"a" gives "aaa"
Kind of strange to realize that the mathematical operations are one programming language (demanding a parse tree and so on) embedded in another language.
Besides, if you're using X over the net WITHOUT ssh..., what are you thinking?!!!
X forwarding with SSH is fundamentally broken. It is a kluge.
Here is the problem. If I am sitting at localmachine and running an X app through ssh on foreignmachine, the X resources used are those stored on foreignmachine. The purpose of.Xdefaults is so I can set the parameters of programs to fit the local display, and these files are going to be different on a laptop with a small screen, a desktop at 1600x1200, and a crappy old X terminal, because things like the size of the window the app opens, whether to limit color usage, what colors are usable as background behind black text, and so on are going to be different for these displays.
In some circumstances, using.Xauthority is better and easier. If you often do work using a set of servers that share home directories, all you need to do is copy.Xauthority from your local machine to the server if you restart X. It is also possible to use xhost with relative safety. A machine only needs to be xhosted to start the X connection, so you "xhost +foreignmachine", start app, "xhost -foreignmachine", use app for as long as you like. In both cases, the programs use the correct X resources.
This avoids another annoyance with ssh's X forwarding. If you ssh to a machine and start an X app, the logout hangs until all the apps using the X forwarding are exited. (This can be avoided somewhat by using "ssh foreignmachine command&", but requires full pathname for command and any files. Or the "~&" command will allow you to logout leaving X apps behind, but you have to remember to do it before hitting ^d.)
I use ssh with X forwarding often, but it is not a replacement for all the other security methods X has evolved. Obviously there are times when encryption is important, but usually it isn't. It hardly matters if someone can spy on me while I am editing my public web page as long as they don't have direct access to my X server.
He is goal is to get people to use his distro rather than Microsoft, and so he gives it a name identical to the name of Microsoft's operating system except for one letter. No sane person can doubt that he was attempting to tie his product to Microsoft Windows by allusion and confusion, which violates Microsoft's trademark. Note that he is selling a direct replacement for Microsoft Windows under this name, which is different from using a form of the word "windows" somewhere in the name of your product.
He'd be welcome in my house for a beer.
He'd still be welcome in my house for a beer, too. I could give him the address and he could walk over after work some day:-) Or someone could organize a/. party at Crazy Mels down the street.
have been for a long time trying to convince the technology department to move to a Linux server...This could be the perfect time for Lindows to enter the market for the average user.
Yikes. Lindows (I cringe typing the name) is apparently designed not to be a server. The answers show that it is being pushed for a desktop for a single user. Many things that make Linux useful on a server are exactly the things that have been hacked out to make the Lindows distribution. If you need a server that can be run by someone who finds the filesystem too confusing and remembering two different passwords too difficult, I really don't know what you should do.
You need some sort of approval from the "technology department"? Scrounge an old Pentium or P2 computer nobody wants, have someone download a distro and burn cd's for you, and go set the thing up. If you can't do it in school, do it at your house or a friend's house. Start now! Time's a-wasting!
You have explicitly decided to ignore "whatever reason", whereas that is how a user would group things.
I think I gave some reasons when/opt is especially useful. I gave some examples of situations where trying to split things by app just doesn't work. And this is not how a "user" would group these (because I am one, and I wouldn't), though it may be how a novice user would.
Since Galeon is tied to a specific version of Mozilla, let me instead use ghostview and ghostscript as an example. ghostview needs ghostscript to run, but doesn't care much about which version. Make hardlinks from/app/ghostview to all the fonts, libraries, executables, and scripts in/app/ghostscript, so that ghostview will still run if/app/ghostscript is deleted. Now the next time a new version of ghostscript comes out, say because of a security bug, updating/app/ghostscript leaves the old, buggy version in/app/ghostview. This is bad.
Current system is not designed to guide such users to understand what is going on. It is not robust to poking around.
I agree, but mucking with the filesystem layout won't do much to help this. There is nothing you can do to stop someone with the root password from wrecking their installation. The system can be made relatively robust to mucking about with a package manager and decent configuration utilities. Heck, you could write a package manager shell, where you use 'cd' and 'ls' to move around in a hierarchy of package names and use 'rm' to remove them. Then 'rm/Apps/Ghostscript' will tell me 'ghostscript is needed by your postscript viewer (ghostview) and your printing system (lprng): use rm -f to force deletion (do not do this unless you are sure you know what you are doing)'. And we can let rm, ls and so on work perfectly normally for the user inside/home.
I am getting convinced that the rift between users and power users/sys admin is so large as to be impassable, and is primarily in the way people think, the way they structure things.
I would say the opposite. Redhat is working like crazy to make configuration and maintenance simple and gui driven. Lots of stuff that I used to do by editing scripts and config files is now either automatic or click-click. These gui's just read and write the ascii config files and run the standard system commands, so I can use them or not. There also is documentation that is grouped by tasks rather than by commands, mostly in the How-To's.
One of the great problems is how to make things more accessible and usable without sacrificing utility and power. If you spend 3 months as a newbie and 10 years as an experienced user, do you want your tools geared toward the 3 months or the 10 years? Every single thing to be gained by playing with the filesystem can be gained more easily, more transparently, and more robustly using other means.
You have talked about how users want things gathered together in app directories. I don't think this is true. I think you meant that users want a good way to delete software completely. This is true, and a package manager does this much better than having/app directories. Adding undelete for files and packages isn't hard (if you don't mind wasting a lot of disk space), but the place to implement this is not the core filesystem. Think of MacOS 10, there are two completely different views of the filesystem, the Mac view and the BSD view, which use different tools to manipulate things. There is no reason a similar Mac-ish layer can't be written for Linux that will make things easier for a newbie and not cripple a more experienced user.
So for instance when they uninstall a program they want every trace of that program gone. Leaving chunks lying about makes the whole thing feel somehow unclean.
I agree completely. That is what a package manager is for. Wouldn't you say then that what the casual user needs is a good GUI package manager?
For another example, look at ghostscript. I never run it, but if I delete it, my printer will stop working. But then there is ps2pdf, which converts postscript to pdf; this I do run as a user. This doesn't sound like part of the operating system, but all ps2pdf does is call ghostscript with a certain set of options. You'd have to consider ghostscript part of the operating system, but it doesn't make sense to create a whole new "app" directory for a few scripts that call gs.
The dividing line between system stuff and user stuff seems clear in the abstract, but whenever I look at the real programs that are on my machine, they are impossible to categorize.
Also, putting things is separate/Apps (or whatever) directories gives the impression that these programs are all independent, when that might not be true (like in the mozilla and galeon example I gave). It is bad interface design for the representation (in this case, separate directories) to not match the reality (dependencies between programs). The real answer is to have a good package manager. You have convinced me that a novice should be able to run the system without ever leaving/home. It is bad for such a person to go poking around deleting directories when he doesn't understand the consequences. The beauty of it is that we can have multiple interfaces for different people, building one, the package manager, on the other, the filesystem. The fact that some people need a decent gui package manager does not in any way mean that the filesystem needs to be changed around.
And last but not least, what's up with 3 letter names? "/opt"? How about "/System/apps/tryout"? Or "/System/apps/temporary programs"?
I believe that disks were so small that using cp for copy and so on made a significant difference./opt is not for temporary things;/opt is where you install stuff if you want all the libraries, executables, docs, and so on kept together for whatever reason. The reason may be that it is not packaged in a format that makes it easy to delete if you want to get rid of it. One thing I keep in/opt is a directory full of utilities written by a friend of mine; I don't want them in/usr/local/bin because his names sometimes clash with names of other programs. They aren't temporary, but they belong together in/opt.
Re:"Keeping files together" all over the place :-)
on
If I Had My Own Distro...
·
· Score: 2, Insightful
Those files started out all in one place, together with their owner package, and it's you that says that the right thing to do is to spread them out all over the system.:-)
What you said doesn't even pass as meaningful English. You are claiming that I want config files spread "all over the system" by putting them all together in/etc.
I will explain, since the point of this escapes you. A system may have hundreds or thousands of configuration files. If every config file is off hiding with its associated app, then the only way to back up my personal configuration is by essentially copying the entire hard drive. If everything is in/etc, then I just make one tarball.
This is not dogma. I am explaining what happens in real life, and how I have determined through experience what features are valuable and why.
If anything is hilarious, it is that, no matter how many specific examples I discuss, most the replies are hand-waving based on vague ideas and a distinct lack of concrete examples.
There is a danger here. While Windoze is still primitive compared to even a 15-year old Unix except in surface aesthetics, it will mature eventually, and if attempts to make even small and fairly reasonable improvements to Unix continue to be thwarted by barely-substantiated resistance to change then the future will not be rosey.
From everything I have read, windows is now a very stable platform (as stable as Linux was eight or more years ago). I don't know in what way you mean it is "primitive", or in what way it needs to "mature". There are (at least) two main differences: 1) Linux is free and windows isn't 2) the Unix design philosophy of modularity, power, and the CLI (not a great description, but you know what I mean). I don't see either one of these changing. I would not use windows unless somebody put a gun to my head, but this is based on design philosophy.
I don't know why people think that the fs layout is set in stone. I still had an installation of Redhat 4 on a triple boot machine until recently, and you know what? There have been significant changes to the filesystem since then. Things have been made a great deal more coherent and less complicated. The changes were made, I suspect, because people were able to rationally explain why a given change resulted in an improvement.
So you think that just because Linux uses outdated security concepts it should stick to outdated hierarchy layout.
I never ever said such a thing. I said that the specific proposal in the original post is not an improvement, and I said why it is not an improvement.
The other way would be to have users
learn to think in machine terms to see the logic
of what's going on. The users like to have things
related to an app all in one directory/folder.
You are conflating two unrelated things, how the fs is laid out and how users access programs. The user wants to click the little picture of the red dinosaur or type mozilla at the command line and have a web browser start up. This has nothing to do with where the executables and libraries live in the filesystem. This level of user shouldn't ever have to see anything other than their home directory, so the layout of the rest of the file system is irrelevent.
Why should the users care where the libraries and so on are? What good does it do to separate packages into different directories, especially when package managers know what belongs to what and where it all is? In particular, spreading configuration files all around with their owners is a great mistake. This also doesn't work well with the modularity of much of Linux distributions, because components are shared. Does all of KDE go in one directory? Galeon uses the mozilla libraries, so are galeon and mozilla separate or together? If they are separate, then you have to depend on the package manager to not let you get rid of mozilla libraries while galeon is installed, but if you are using the package manager for this, what is the purpose of putting things in all these different directories in the first place?
Computer has an OS. I expect OS to be in its own folder/partition, whatever. I never look in there. It should take care of itself.
OK, the kernels are in/boot. Does that satisfy your requirement? Or is the window manager part of the operating system, or the compiler, the shells, ps, ls, gs, lpr? How about the web browser? IE is apparently a part of the windows OS. My point is that unless you are talking strictly about the kernel, there is no line between what is in the operating system and what is an application. Trying to create this division on an arbitrary basis does not make things more clear, it makes them more confusing
There are cases where stuff should be kept strictly separated out. Say I want to try an experimental compiler for a few days and it doesn't come as an rpm. This is what/opt is for.
Just because something has a reason for being there doesn't make it a good reason. Every one of those confusing directories may have a purpose, but the fact remains that it could be simple and logical. But it won't because of legacy elitists.
Maybe it could be "simple and logical". The system proposed here is not simple and it is not logical. It is at best merely different. Can you give me a single way in which the proposed system is an improvement? I explained how it would create more confusion and lose valuable features of the current system, all for zero gain.
In the Linux world, people have been putting a lot of work into making the directory hierarchy more coherent; see the Linux Standards Base. This shows that changes will be made if they serve a purpose.
Sigh. Whoever wrote this apparently has never read or thought about why the *nix filesystem is arranged as it is, or at least what the strengths are of the current setup.
Example: "/var => mostly placed under/System" The/var directory exists to collect the stuff that programs have to have write access to, like logs, spools, locks. There is some advantage to mounting e.g./usr/bin read-only on production systems while mounting/var read-write.
Example: "/bin =>/System/Commands.../usr/bin =>/System/Executables" The stuff in/bin (and/sbin) consists of programs you need to rescue a system that has gone nuts, e.g. ps belongs in/bin and pstree goes in/usr/bin. It makes no sense to call one of these a "Command" and one an "Executable".
Example: "/opt =>/Apps" What is the difference between a "Command", an "Executable", and an "App"? Is mozilla an executable or an application? This is very like metaphor shear. These three different names seem to mean three different things, but really they are essentially synonymous, so all this will do is create confusion as people try to understand the difference when the categorization is in fact utterly arbitrary.
The goals: "100% Application Directory Oriented" which means what? "Internationalization of Directory Names" has nothing to do with moving around/bin etc. "More Intuitive Directory Names" Demonstrably false--see above. "Fewer Root Directories" so what? What value is there in have fewer root directories, when all you are doing is creating more subdirectories? "Increased System Flexibility" how is flexibility increased? "Applications would no longer need to hard code directory names." Any hardcoded directory compiled into an app is probably a bug (unless it is easily over-ridden with an environment variable). "Set of environmental variables pointing the location of major system directories." What is the difference between hardcoding a directory name like/tmp and hardcoding an environment variable like $TEMP? NOTHING. (As I said, a decent program will do something like use $TEMP if it exists and fall back on/tmp.)
This is the best: "The standard will not be finalized until a Linux distribution ships based upon it." I have a good idea when that will happen.
I (and many others like me) write code 'cause it's fun, because we can fill a niche, or because we just need to scratch some itch we have.
Why are open source coders always talking about their itches? Do they not bathe often enough? Could M$ destroy the open source movement by sending out sample bottles of calomine lotion to programmers?
Re:Torvalds muddying discussion with PERSONAL stuf
on
Linus on DRM
·
· Score: 1
Nice one Linus, drag in the hated figure of RMS to rally the troops around to support your position and make sure that this becomes a personality grudge-fest instead of a discussion about the principles involved.
It is shocking to see how people who live at the center of open source like to denigrate RMS for his ideals, when RMS and his ideals are largely what made the current environment possible. It is almost enough to make me sympathize with RMS's rantings about why it should be called Gnu/Linux. You don't have to agree with everything the man says, but that doesn't make it acceptable to ridicule and insult him.
Sure he's an extremist. Extremists are vitally important, as they set the boundaries. Anyone who is slightly less dogmatic than RMS appears reasonable and respectable. If it weren't for RMS, people like Bruce Perens would be viewed as wild-eyed extremists to be shunned rather than responsible moderates.
Re:So don't use that Linux
on
Linus on DRM
·
· Score: 1
At this point Linux, *BSD and the other open sources are a sufficiently large base that we can now safely expect there to always be linux-friendly hardware.
That is not an assumption I would want to rely on.
There is a lot that could be done to limit the availability of hardware for running Linux and *BSD. If the big media companies lean on the major distributors, say Dell, Gateway, Fry's, CompUSA and so on, they can make the hardware hard to get. This will not stop people who are willing to build their own box from parts from having a Linux/*BSD box, but the number of casual and institutional/business users will go way down. (If I need a new desktop at work, it has to come from Dell, and I don't think I am alone in this situation.)
The danger is that the number of users could fall below a critical mass. There must be enough users that hardware drivers are complete and maintained. I personally do not want to go back to the days of Redhat 4 where getting any sound support meant recompiling the kernel and I had to search the web for patches to the ghostscript source to handle my printer.
Dual boot machines with windoze, for those who need them, would be impossible, b/c the M$ stuff would require hardware DRM.
I just bought a new modem, and only a small number of them are not winmodems (and the non-winmodems advertize "for use with Linux" which I thought was pretty cool). It is hard to buy a box from a large supplier that has a real modem. This means most people cannot take their machines and install Linux and expect all their hardware to work. Think how much worse it will be if soundcards and disk drives start getting proprietary hardware DRM. I don't care whether "Linux is ready for the masses", but I do care that there is a large enough userbase that hardware will be supported.
Re:What this is about
on
Linus on DRM
·
· Score: 1
If the signature is NOT part of the kernel binary, is it not an academic exercise to simply create your own kernel with accompanying, seperate signature? Am I missing something here?
Yes. You are assuming you have access to the keys necessary to produce a valid signature. The whole point of the sort of DRM that media companies want is that you the consumer don't have access to the keys. That's what I don't understand about Linus' post: He makes the point that some forms of DRM are innocuous or beneficial, but fails to acknowledge that some forms are odious and dangerous to the future of open sourse operating systems.
he's unconscious and his eyes are turning purple, what the fuck does that mean?
Sometimes I think that I only read/. to find quotes to put in my fortunes file:-)
Something good about using these contacts that I don't see mentioned here is that it would allow almost continuous monitoring. You could see how fast the blood sugar level rises and decays after you eat something. You could also see throughout the day whether the level is behaving like you think it should or if you need to have a little more food or less. I believe that better regulation of the sugar level alleviates some of the complications of diabetes, so this could in theory be a big help.
Theo is a Canadian living and working in Canada. He doesn't have any 1st Amendment rights.
Interesting that the US Constitution says that congress (and by extension any agency that is funded by a vote in congress) cannot abridge freedom of speech. It does not say "but only for US citizens". According to the Constitution, the speech itself is protected no matter who says it.
I once worked for a boss who was a religious conservative. I disagree with his views on most everything to do with religion, philosophy, and government. However, I did not choose to decorate my office with signs and images to that effect.
There are varying levels of protection of speech recognized by the US courts. Expression in the workplace is not necessarily strongly protected and may be restricted various ways. Public political speech however is the most highly protected form of speech, and this is the category that Theo's statements are in.
The classic example of unprotected speech is yelling "Fire!" in a crowded theater. The courts rightly view that the purpose of free speech is to combat government opression, and therefore the single most important kind of free speech is the freedom to complain about the government. There is no comparison between not arguing religion in the workplace and being punished by the government for speaking critically of it in public. They are in utterly different categories.
As long as Theo thinks that his freedom to make statements on touchy subjects is more important than the health of the OpenBSD project, this kind of thing will continue, and knowing that, he shouldn't complain.
How do feel about this famous quote: "Those who would give up essential liberties for a measure of security, deserve neither liberty nor security."
Maybe I'm just not up to date on the Bill of Rights, but I don't see anything that says the government is requied to foot the bill for all research projects....All they're saying is they're not going to foot the bill.
(This thread is operating under the assumption that the cancellation had something to do with Theo's statements, which is possible but not proven.)
The gov't can choose not to fund research projects. But if the gov't decides to fund them, they can't choose which to fund based on the political viewpoints and statements of the project leader.
Your argument seems to say that the gov't is allowed to punish people for their political speech, as long as it doesn't stop them completely. In other words, it is acceptable to put someone in prison for disagreeing with the president as long as you leave him a little window he can use to shout out his opinions to the world.
The government can only stop you from saying something by killing you. Freedom of speech implies, I hope, a lot more than simply that the gov't won't put you in front of a firing squad for what you say. A man in jail is alive but he isn't free; speech is free only if it is not just permitted but also unencumbered.
Now where does it say in that "open source is bad"? Could it be that the government has decided other threats are more immediate to address with DARPA's limited budget?
This opinion is not consistent with what occurred. Most of the conference accommodations, 80%, were paid for as a cancellation fee. The monetary savings was minimal. If the BSD folks had been allowed to put up the other 20%, the conference could have gone on as planned without costing UPenn/DARPA any more than what they had to pay anyway.
If you bought 1 tape of StarWars in the 90s, Lucas Films & Fox have a right to sue you into oblivion if you set up a business that did nothing but make copies of that tape or transfer it to other media for the next decade and resold the results.
Agreed, but an important distinction is that George Lucas did not write the copyright laws. For good or for ill, a sufficient number of our legally selected legislators approved them and they became law.
I also agree with whoever posted it that warranties and support are a separate issue. For example, if I call up Sony and complain about the Linux kernel on my laptop, they'll laugh in my face because it was sold to me with Windows on it. But this is a far cry from them not allowing me to install Linux in the first place. (By the logic of the parent-parent post, Sony would be right to forbid me to run Linux on my laptop, because they don't support it and poor performance could hurt the reputation of their machines. That's a scary thought.)
A colleague once told me that the world was full of bad security systems designed by people who read Applied Cryptography" - Bruce Schneier (author of Applied Cryptography). Quote from Secrets & Lies.
I am regularly asked what the average Internet user can do to ensure his security. My first answer is usually "Nothing; you're screwed." - Bruce Schneier
I'm sorry, but it is attitudes (and books) like these that give rise to the woeful state of affairs that have existed in "practical cryptography" over the years. Schneier's book, while certainly well-meaning, has promoted the idea that you don't need to understand formal notions of security to be a serious cryptographer. It is hard to overestimate the damage that this idea (and this) book have caused.
I find it astonishing that a book that has only been out a few weeks has caused much damage.
Unless you are thinking of Schneier's first book on cryptography. If you knew what you were talking about, you would know that he wrote Secrets and Lies mainly to explain that crytpographic protocols by themselves don't solve the whole problem. He thought his first book might leave that impression, and he wanted to correct it.
It sounds like you are arguing that this information must be locked up because it is dangerous, and the "serious cryptographer[s]" will then decide who gets access to it and who doesn't. This is disgusting elitism.
Sure, lots of people pass themselves off as experts based on reading a book. The problem is these people and the people who believe them, not the book. Some programmers write buggy code in operating systems. Does this mean that no one should write a book about operating systems to protect us from people who read the book and then write buggy code? Any competent person with training or education knows where the limits to his knowledge are. Anyone who doesn't know this is incompetent, and that can't be blaimed on a book.
Maybe in future EULAs, Microsoft will prevent the use of the install CD case to hold open doors in offices with BSD servers.
What is happening here is that companies are using EULAs to essentially write their own laws. If these agreements are considered legally valid, then governments are in effect having their courts co-opted to help in the enforcement of the laws (EULAs) written by the corporations.
In theory, we are protected from this by the freedom to avoid the product if we don't like the EULA, or by anti-monopoly laws if no choice is available. If the anti-monopoly laws were being enforced.
Control, however, is extremely important when it comes to brand reputation, and is perfectly justifiable in many cases. Consider a software vendor who has released a product specifically for a certain class of operating systems. It would be entirely reasonable for them to restrict the use of that application (via the EULA) to avoid deployment on other OS's, due to the unpredictable issues that will pop up.
I see the propaganda has succeeded and mind control is now complete.
It is not the slightest bit reasonable ever for a company to be able to control how you use their product after you have given them money in return for the right of such use.
To give a concrete example of why this is wrong, for those who don't find it obvious, imagine a company wants to distribute these executables to a restricted set of identical Linux boxes with the configuration carefully tested. There is no danger of damaging the reputation of the original framework; in fact this could only improve its reputation.
Your argument is the same one that would make all mp3 files illegal, because they may be related to illegal copying, or the outlawing of the DeCSS code because it might be used to make a forbidden copy.
Maintaining a remotely free society demands extreme scrutiny of such examples of prior restraint, restrictions based on a hypothetical damage with no proof that it ever had or would actually occur.
Adobe and Microsoft together will submit a proposal for Web page font embedding using OpenType to the W3C's working group on style sheets.
This sounds like a really, really bad idea at first. It violates a fundamental principle of the web that presentation is to be controlled by the client. And web pages will become even more bloated with code and unusable over a slow connection.
But there is something that is good about it. When people want fruity fonts in their web pages today, they do it by puttin the text in images. This is unsearchable, both for search engines and the browser's search in page, and totally breaks text-only browsers. If there is a way to embed the font in the page, then the titles, links, whatever that the designer feels just have to be in new gothic outline copperplate will still be text in the html code. This is good.
Slashdot Mirror
One nasty glitch is that (at least in some installations) AFS file permissions are maintained separately from standard *nix file permissions. In other words, "chmod o-r *" does nothing to stop other people from reading your files (as I found out when my entire home directory was made available over the web).
* Matrix operations
* Polynomials (represented by array of coefficients, [1,1]*[1,1] gives [1,2,1])
* Other string operations, like 3*"a" gives "aaa"
Kind of strange to realize that the mathematical operations are one programming language (demanding a parse tree and so on) embedded in another language.
Here is the problem. If I am sitting at localmachine and running an X app through ssh on foreignmachine, the X resources used are those stored on foreignmachine. The purpose of .Xdefaults is so I can set the parameters of programs to fit the local display, and these files are going to be different on a laptop with a small screen, a desktop at 1600x1200, and a crappy old X terminal, because things like the size of the window the app opens, whether to limit color usage, what colors are usable as background behind black text, and so on are going to be different for these displays.
In some circumstances, using .Xauthority is better and easier. If you often do work using a set of servers that share home directories, all you need to do is copy .Xauthority from your local machine to the server if you restart X. It is also possible to use xhost with relative safety. A machine only needs to be xhosted to start the X connection, so you "xhost +foreignmachine", start app, "xhost -foreignmachine", use app for as long as you like. In both cases, the programs use the correct X resources.
This avoids another annoyance with ssh's X forwarding. If you ssh to a machine and start an X app, the logout hangs until all the apps using the X forwarding are exited. (This can be avoided somewhat by using "ssh foreignmachine command&", but requires full pathname for command and any files. Or the "~&" command will allow you to logout leaving X apps behind, but you have to remember to do it before hitting ^d.)
I use ssh with X forwarding often, but it is not a replacement for all the other security methods X has evolved. Obviously there are times when encryption is important, but usually it isn't. It hardly matters if someone can spy on me while I am editing my public web page as long as they don't have direct access to my X server.
You need some sort of approval from the "technology department"? Scrounge an old Pentium or P2 computer nobody wants, have someone download a distro and burn cd's for you, and go set the thing up. If you can't do it in school, do it at your house or a friend's house. Start now! Time's a-wasting!
Since Galeon is tied to a specific version of Mozilla, let me instead use ghostview and ghostscript as an example. ghostview needs ghostscript to run, but doesn't care much about which version. Make hardlinks from /app/ghostview to all the fonts, libraries, executables, and scripts in /app/ghostscript, so that ghostview will still run if /app/ghostscript is deleted. Now the next time a new version of ghostscript comes out, say because of a security bug, updating /app/ghostscript leaves the old, buggy version in /app/ghostview. This is bad.
I agree, but mucking with the filesystem layout won't do much to help this. There is nothing you can do to stop someone with the root password from wrecking their installation. The system can be made relatively robust to mucking about with a package manager and decent configuration utilities. Heck, you could write a package manager shell, where you use 'cd' and 'ls' to move around in a hierarchy of package names and use 'rm' to remove them. Then 'rmOne of the great problems is how to make things more accessible and usable without sacrificing utility and power. If you spend 3 months as a newbie and 10 years as an experienced user, do you want your tools geared toward the 3 months or the 10 years? Every single thing to be gained by playing with the filesystem can be gained more easily, more transparently, and more robustly using other means.
You have talked about how users want things gathered together in app directories. I don't think this is true. I think you meant that users want a good way to delete software completely. This is true, and a package manager does this much better than having /app directories. Adding undelete for files and packages isn't hard (if you don't mind wasting a lot of disk space), but the place to implement this is not the core filesystem. Think of MacOS 10, there are two completely different views of the filesystem, the Mac view and the BSD view, which use different tools to manipulate things. There is no reason a similar Mac-ish layer can't be written for Linux that will make things easier for a newbie and not cripple a more experienced user.
For another example, look at ghostscript. I never run it, but if I delete it, my printer will stop working. But then there is ps2pdf, which converts postscript to pdf; this I do run as a user. This doesn't sound like part of the operating system, but all ps2pdf does is call ghostscript with a certain set of options. You'd have to consider ghostscript part of the operating system, but it doesn't make sense to create a whole new "app" directory for a few scripts that call gs.
The dividing line between system stuff and user stuff seems clear in the abstract, but whenever I look at the real programs that are on my machine, they are impossible to categorize.
Also, putting things is separate /Apps (or whatever) directories gives the impression that these programs are all independent, when that might not be true (like in the mozilla and galeon example I gave). It is bad interface design for the representation (in this case, separate directories) to not match the reality (dependencies between programs). The real answer is to have a good package manager. You have convinced me that a novice should be able to run the system without ever leaving /home. It is bad for such a person to go poking around deleting directories when he doesn't understand the consequences. The beauty of it is that we can have multiple interfaces for different people, building one, the package manager, on the other, the filesystem. The fact that some people need a decent gui package manager does not in any way mean that the filesystem needs to be changed around.
I believe that disks were so small that using cp for copy and so on made a significant difference.I will explain, since the point of this escapes you. A system may have hundreds or thousands of configuration files. If every config file is off hiding with its associated app, then the only way to back up my personal configuration is by essentially copying the entire hard drive. If everything is in /etc, then I just make one tarball.
This is not dogma. I am explaining what happens in real life, and how I have determined through experience what features are valuable and why.
If anything is hilarious, it is that, no matter how many specific examples I discuss, most the replies are hand-waving based on vague ideas and a distinct lack of concrete examples.
From everything I have read, windows is now a very stable platform (as stable as Linux was eight or more years ago). I don't know in what way you mean it is "primitive", or in what way it needs to "mature". There are (at least) two main differences: 1) Linux is free and windows isn't 2) the Unix design philosophy of modularity, power, and the CLI (not a great description, but you know what I mean). I don't see either one of these changing. I would not use windows unless somebody put a gun to my head, but this is based on design philosophy.I don't know why people think that the fs layout is set in stone. I still had an installation of Redhat 4 on a triple boot machine until recently, and you know what? There have been significant changes to the filesystem since then. Things have been made a great deal more coherent and less complicated. The changes were made, I suspect, because people were able to rationally explain why a given change resulted in an improvement.
Why should the users care where the libraries and so on are? What good does it do to separate packages into different directories, especially when package managers know what belongs to what and where it all is? In particular, spreading configuration files all around with their owners is a great mistake. This also doesn't work well with the modularity of much of Linux distributions, because components are shared. Does all of KDE go in one directory? Galeon uses the mozilla libraries, so are galeon and mozilla separate or together? If they are separate, then you have to depend on the package manager to not let you get rid of mozilla libraries while galeon is installed, but if you are using the package manager for this, what is the purpose of putting things in all these different directories in the first place?
OK, the kernels are inThere are cases where stuff should be kept strictly separated out. Say I want to try an experimental compiler for a few days and it doesn't come as an rpm. This is what /opt is for.
In the Linux world, people have been putting a lot of work into making the directory hierarchy more coherent; see the Linux Standards Base. This shows that changes will be made if they serve a purpose.
What was that small-gods directory for, anyway?
Example: "/var => mostly placed under /System" The /var directory exists to collect the stuff that programs have to have write access to, like logs, spools, locks. There is some advantage to mounting e.g. /usr/bin read-only on production systems while mounting /var read-write.
Example: "/bin => /System/Commands.../usr/bin => /System/Executables" The stuff in /bin (and /sbin) consists of programs you need to rescue a system that has gone nuts, e.g. ps belongs in /bin and pstree goes in /usr/bin. It makes no sense to call one of these a "Command" and one an "Executable".
Example: "/opt => /Apps" What is the difference between a "Command", an "Executable", and an "App"? Is mozilla an executable or an application? This is very like metaphor shear. These three different names seem to mean three different things, but really they are essentially synonymous, so all this will do is create confusion as people try to understand the difference when the categorization is in fact utterly arbitrary.
The goals: "100% Application Directory Oriented" which means what? "Internationalization of Directory Names" has nothing to do with moving around /bin etc. "More Intuitive Directory Names" Demonstrably false--see above. "Fewer Root Directories" so what? What value is there in have fewer root directories, when all you are doing is creating more subdirectories? "Increased System Flexibility" how is flexibility increased? "Applications would no longer need to hard code directory names." Any hardcoded directory compiled into an app is probably a bug (unless it is easily over-ridden with an environment variable). "Set of environmental variables pointing the location of major system directories." What is the difference between hardcoding a directory name like /tmp and hardcoding an environment variable like $TEMP? NOTHING. (As I said, a decent program will do something like use $TEMP if it exists and fall back on /tmp.)
This is the best: "The standard will not be finalized until a Linux distribution ships based upon it." I have a good idea when that will happen.
Sure he's an extremist. Extremists are vitally important, as they set the boundaries. Anyone who is slightly less dogmatic than RMS appears reasonable and respectable. If it weren't for RMS, people like Bruce Perens would be viewed as wild-eyed extremists to be shunned rather than responsible moderates.
There is a lot that could be done to limit the availability of hardware for running Linux and *BSD. If the big media companies lean on the major distributors, say Dell, Gateway, Fry's, CompUSA and so on, they can make the hardware hard to get. This will not stop people who are willing to build their own box from parts from having a Linux/*BSD box, but the number of casual and institutional/business users will go way down. (If I need a new desktop at work, it has to come from Dell, and I don't think I am alone in this situation.)
The danger is that the number of users could fall below a critical mass. There must be enough users that hardware drivers are complete and maintained. I personally do not want to go back to the days of Redhat 4 where getting any sound support meant recompiling the kernel and I had to search the web for patches to the ghostscript source to handle my printer.
Dual boot machines with windoze, for those who need them, would be impossible, b/c the M$ stuff would require hardware DRM.
I just bought a new modem, and only a small number of them are not winmodems (and the non-winmodems advertize "for use with Linux" which I thought was pretty cool). It is hard to buy a box from a large supplier that has a real modem. This means most people cannot take their machines and install Linux and expect all their hardware to work. Think how much worse it will be if soundcards and disk drives start getting proprietary hardware DRM. I don't care whether "Linux is ready for the masses", but I do care that there is a large enough userbase that hardware will be supported.
Something good about using these contacts that I don't see mentioned here is that it would allow almost continuous monitoring. You could see how fast the blood sugar level rises and decays after you eat something. You could also see throughout the day whether the level is behaving like you think it should or if you need to have a little more food or less. I believe that better regulation of the sugar level alleviates some of the complications of diabetes, so this could in theory be a big help.
The classic example of unprotected speech is yelling "Fire!" in a crowded theater. The courts rightly view that the purpose of free speech is to combat government opression, and therefore the single most important kind of free speech is the freedom to complain about the government. There is no comparison between not arguing religion in the workplace and being punished by the government for speaking critically of it in public. They are in utterly different categories.
How do feel about this famous quote: "Those who would give up essential liberties for a measure of security, deserve neither liberty nor security."The gov't can choose not to fund research projects. But if the gov't decides to fund them, they can't choose which to fund based on the political viewpoints and statements of the project leader.
Your argument seems to say that the gov't is allowed to punish people for their political speech, as long as it doesn't stop them completely. In other words, it is acceptable to put someone in prison for disagreeing with the president as long as you leave him a little window he can use to shout out his opinions to the world.
The government can only stop you from saying something by killing you. Freedom of speech implies, I hope, a lot more than simply that the gov't won't put you in front of a firing squad for what you say. A man in jail is alive but he isn't free; speech is free only if it is not just permitted but also unencumbered.
I also agree with whoever posted it that warranties and support are a separate issue. For example, if I call up Sony and complain about the Linux kernel on my laptop, they'll laugh in my face because it was sold to me with Windows on it. But this is a far cry from them not allowing me to install Linux in the first place. (By the logic of the parent-parent post, Sony would be right to forbid me to run Linux on my laptop, because they don't support it and poor performance could hurt the reputation of their machines. That's a scary thought.)
Unless you are thinking of Schneier's first book on cryptography. If you knew what you were talking about, you would know that he wrote Secrets and Lies mainly to explain that crytpographic protocols by themselves don't solve the whole problem. He thought his first book might leave that impression, and he wanted to correct it.
It sounds like you are arguing that this information must be locked up because it is dangerous, and the "serious cryptographer[s]" will then decide who gets access to it and who doesn't. This is disgusting elitism.
Sure, lots of people pass themselves off as experts based on reading a book. The problem is these people and the people who believe them, not the book. Some programmers write buggy code in operating systems. Does this mean that no one should write a book about operating systems to protect us from people who read the book and then write buggy code? Any competent person with training or education knows where the limits to his knowledge are. Anyone who doesn't know this is incompetent, and that can't be blaimed on a book.
What is happening here is that companies are using EULAs to essentially write their own laws. If these agreements are considered legally valid, then governments are in effect having their courts co-opted to help in the enforcement of the laws (EULAs) written by the corporations.
In theory, we are protected from this by the freedom to avoid the product if we don't like the EULA, or by anti-monopoly laws if no choice is available. If the anti-monopoly laws were being enforced.
It is not the slightest bit reasonable ever for a company to be able to control how you use their product after you have given them money in return for the right of such use.
To give a concrete example of why this is wrong, for those who don't find it obvious, imagine a company wants to distribute these executables to a restricted set of identical Linux boxes with the configuration carefully tested. There is no danger of damaging the reputation of the original framework; in fact this could only improve its reputation.
Your argument is the same one that would make all mp3 files illegal, because they may be related to illegal copying, or the outlawing of the DeCSS code because it might be used to make a forbidden copy.
Maintaining a remotely free society demands extreme scrutiny of such examples of prior restraint, restrictions based on a hypothetical damage with no proof that it ever had or would actually occur.
But there is something that is good about it. When people want fruity fonts in their web pages today, they do it by puttin the text in images. This is unsearchable, both for search engines and the browser's search in page, and totally breaks text-only browsers. If there is a way to embed the font in the page, then the titles, links, whatever that the designer feels just have to be in new gothic outline copperplate will still be text in the html code. This is good.