| |||||||||||||
|
| |||||||||||||
How to write a Linux virus in 5 easy stepsHow to write a Linux virus in 5 easy stepsPosted Feb 11, 2009 17:29 UTC (Wed) by rvfh (subscriber, #31018)Parent article: How to write a Linux virus in 5 easy steps
Is it that these files still (since 2006) need not be executable to be 'run'? I mean, isn't that basic UNIX stuff?
I am confused. What happened in more than two years?
(Log in to post comments)
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 18:25 UTC (Wed) by drag (subscriber, #31333) [Link]
Well they are not executed, per say, but they are interpreted by your nautilus browser.
Sort of like how when you setup a python or php website you have the initial file executable, but all the stuff that it reads and uses in the program does not have to be executable.
It's still a problem, of course.
The _Linux_system_ is relative secure, but as far as user accounts on the desktop there isn't much protections.
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 18:43 UTC (Wed) by drag (subscriber, #31333) [Link]
Probably the solution here is to use SeLinux/Smack or perhaps a simpler LSM to provide two security contexts for the Linux desktop. Or maybe just something built into nautilus or whatever.
So that files that are downloaded to the desktop are automatically given a 'untrusted' or 'internet' security context and it would require a extra step to make them trusted. This is how Vista and Windows XP SP2+ works.
Or use a LSM to make it normally impossible for people to save files from processes that connect to the internet in any directory but the designated "$HOME/Downloads" directory. And then nautilus and whatever will treat those files in a different manner.
That way if Firefox or Adobe Flash gets hacked then a attacker can't modify or otherwise screw around with any other files on the user's desktop.
Sort of like how files stored in the ~/.Trash directory are treated differently then files that are stored in other directories.
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 19:42 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
One could also the permissions of user applications to do anything dangerous (including accessing the net or file I/O) in a PolicyKit-like way. Then one application could be kept from accessing another applications files (or generally, files with a mime type that it is not supposed to handle), and it could be kept from overwriting any files except the one it had opened. If the applications were hardened à la Chrome so that one process handled one document, they could even be prevented from reading documents other than the one they were currently editing. Basic tools like ls or whatever could still work as expected, but the limited applications would not be allowed to run them.
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 20:35 UTC (Wed) by nix (subscriber, #2304) [Link]
Well, that's just stupid. We *have* a way to implement things that must be
interpreted in order to be run. Why don't desktop files start
#!/usr/bin/desktop-interpreter
That would fix all these problems. Executable permission is now required,
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 21:25 UTC (Wed) by drag (subscriber, #31333) [Link]
Well the .desktop thing can probably be fixed in that manner, but the fundamental problem is that there is no divisions or security within a user's environment.
When you have code running and connecting to the internet and then acting/interpreting on that data, much of which is coming from anonymous sources that is essentially running with full 'root' rights to anything and everything in a user's home directory then your going to have problems.
There remains a need to have a way to divide a user account between programs that are dealing with untrusted data and then stuff that has full privileges.
As it stands right now one security flaw in Firefox or your Jabber client or anything else (like Evince reading in PDF files you just downloaded) that is going out and fetching data from the internet and your entire account is compromised. There is no need to get root as the most important stuff is running with user privileges and is in your home directory.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 10:51 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
Interesting idea, but I have to wonder what such a thing would even look like. How would such a system work, and how would the user interact with it?
And how would it interact with the standard permissions?
I mean, right now we have the ability to add and remove permissions from a file, but in the "interpreter" case, if the user has permission to read a script file, and permission to run the interpreter...well, how would we mark such a file to say "this is not yet trusted"? Extended attributes of some kind?
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 12:55 UTC (Thu) by nix (subscriber, #2304) [Link]
If it's not trusted, turn the executable bit off, and have the interpreter refuse to run something if the executable bit is off (so that "/usr/bin/desktop-launcher /tmp/bad-not-executable.desktop" would fail).
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 14:08 UTC (Thu) by hppnq (subscriber, #14462) [Link] When the launcher is invoked as an executable through the hash-bang mechanism with the executable bits off, it will refuse to run anyway, and when run by the interpreter you have the current situation.So the problem remains the same: do you trust your desktop launcher or not? The traditional Unix security model can never be trusted in this respect. I would think that it may even be more safe to have an external interpreter run the desktop launcher, because at least you then cannot accidentally run any Joe Random Hacker's setuid binary instead of an easy to parse script.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 20:47 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, yes, the .desktop-launching interpreter would of course be a
specialized program that knew how to run .desktop files; and it checks the executable bit on .desktop files that are passed to it as parameters *itself* before launching programs named in them: it doesn't leave this up to the kernel or anything like that.
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 9:57 UTC (Fri) by hppnq (subscriber, #14462) [Link] What I meant is that you cannot be sure that there actually is trusted content in that launcher file, so the DE would still have to verify that it would actually run the launcher interpreter, to start with. The executable bit would tell the DE to trust the content, because presumably the user has seen the content, and that is not such a great idea.It might even add a risk if the launcher can also be seen from another environment, such as a shell, instead of being a file that can only be meaningfully interpreted by the DE proper. All this has little or nothing to do with the ability to run files in a certain way, but with the level of trust given to a class of files.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 14:24 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
Right, but that requires modifying the interpreter program. What can we do that would accomodate current software?
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 20:49 UTC (Thu) by nix (subscriber, #2304) [Link]
DEs need changing for this (as do the .desktop files). I can't see a way
of sticking with current DEs and .desktop files (without a hashbang) while simultaneously securing against this attack.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 21:11 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
What do you mean by "DEs"?
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 22:11 UTC (Thu) by nix (subscriber, #2304) [Link]
DE = desktop environment.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 22:16 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
Alright, that makes sense.
So you would propose that the desktop environments include a ".desktop interpreter" whose job it would be to check for executable privilege on the .desktop files? That could work.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 23:29 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, its job is to exec() the programs specified in .desktop files: it's
just that the first stage of that is to check that the user can execute them. :)
I don't see any reason why anything else in the DE needs to know how to
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 1:02 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
That does make sense. It could even be a desktop environment-agnostic tool, such that it would work with GNOME, KDE, XFCE, or what have you, without any changes. Make it depend on minimal libraries (I think you'd only need libc, actually), and make it universally available. For maximal adoption, I'd think you'd want it to be permissively licensed, ala the X.org license.
Y'know, this could work! Gonna write it yourself?
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 9:04 UTC (Fri) by nix (subscriber, #2304) [Link]
I'd like to, but to be useful it has to come out of one of the desktop
environment development groups, really, because it's useless unless they adopt it.
(... actually, not all that useless: it could be useful from the command
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 16:29 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
Well, all it really has to do is examine a .desktop file's permissions and ownership, and return success if they're good, or failure if they're bad. That could be used from any environment.
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 17:03 UTC (Fri) by nix (subscriber, #2304) [Link]
I was expecting it to handle the Exec line itself: i.e., with this in place, running an executable-marked .desktop file from bash would exec() the command stated in its Exec line, by way of the interpreter.
Just having the interpreter return a return code without actually running anything seems profoundly counterintuitive. (Imagine if Perl scripts just returned 1 or 0 when you ran them, indicating whether 'perl $SCRIPTNAME' should be allowed to work!)
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 17:06 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
Oh, right, I knew that. Just forgot.
Either way, though, I can see something like that being useful in any number of contexts. I can't help but think "If you write it, they will come."
Write the program, audit it carefully, release it under a permissive license, and push for the major desktop environments to start using it. I think they have an interest in better security.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 14:50 UTC (Thu) by cate (subscriber, #1359) [Link]
The "executable bit" is only an hits (for program in path). Every program,
which is readable is also executable! Classical examples: execute the program as argument of the dynamic linker, executing scripts using the interpreter. Eventually a copy of the program and then changing permission bits. In short time the exploiters could use such work-arounds. So execution bit should not be used for security reasons
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 20:46 UTC (Thu) by nix (subscriber, #2304) [Link]
You don't get it. The interpreter is a specialized interpreter
for .desktop files, which does all the parse-and-launch stuff. *It* checks the state of the executable bit on the .desktop files that it is invoked with, and *nothing else runs programs named in .desktop files at all*.
A possible solution might look like this Posted Feb 17, 2009 18:50 UTC (Tue) by lyeoh (guest, #56701) [Link]
A lot of people claim it's a PEBKAC problem, but I disagree.
If you expect people to figure out whether a file is safe before "launching/opening" it, then you are expecting people to solve something similar to the "halting problem" (which I heard is very hard).
Thus I propose that:
Do note there's also:
I have proposed this concept before to Ubuntu and Suse, see:
It'll be hard to implement, but I suspect it's easier than getting people to reliably solve the "halting problem", and in typical cases solve the halting problem without even being able to look at the actual source code.
A possible solution might look like this Posted Feb 17, 2009 20:19 UTC (Tue) by flewellyn (subscriber, #5047) [Link] The halting problem is not hard to solve. It's IMPOSSIBLE to solve. See Wikipedia for info. As for your proposal, I don't know how wise it is to resort to the "bug the user" idea, when that's been shown to induce users to just click through things in annoyance.
sh-bang line for desktop entry files Posted Feb 12, 2009 16:58 UTC (Thu) by nedu (guest, #50951) [Link]
The FDO Desktop Entry spec provides that comments may begin with a hash. So beginning with a sh-bang line shouldn't be a problem for existing Gnome or KDE environments.
Of course, just 'cause the FDO “standard” sez something, doesn't mean that implementations actually do that. But, at least, my version of Nautilus doesn't choke on hash-marked comments.
sh-bang line for desktop entry files Posted Feb 12, 2009 20:55 UTC (Thu) by nix (subscriber, #2304) [Link]
True. However, IMNSHO starting with a hashbang should be *mandatory* :)
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 22:54 UTC (Wed) by jengelh (subscriber, #33263) [Link]
>The _Linux_system_ is relative secure, but as far as user accounts on the desktop there isn't much protections.
And don't forget the PEBKAC. Telling users to rm -Rf still yields an occassionall hit.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 2:36 UTC (Thu) by drag (subscriber, #31333) [Link]
Well ya.
but you don't want to hang the users out to dry.
My biggest pet peeve, for example, is when people tell other people that they are stupid for double clicking on a attachment in a email that ran a program that installed a virus.
It's very irritating because double clicking is about the only way to interact with the system. And _no_shit_ attachments in email can be dangerous, but why does the system react to double click in the most dangerous manner possible?
Users are trained by the UI to double click on everything and see what happens. So it's like it's a trap... extremely bad UI design.
So probably the policy for the UI is not to do anything automatically unless it's safe.
The unfortunate problem is that programs react the same if it's safe data vs having untrusted data.
------------------
Of course you shouldn't go out of your way to protect stupid users. If they insist on doing something potentially stupid then you should let them. Just don't do it automatically for them.
Something like that.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 12:43 UTC (Thu) by epa (subscriber, #39769) [Link] It's very irritating because double clicking is about the only way to interact with the system. And _no_shit_ attachments in email can be dangerous, but why does the system react to double click in the most dangerous manner possible?Absolutely right. Double-clicking on an icon should and must be a safe operation. It should *open* the file, not execute it. The only things that can be safely executed are programs specifically installed as executable, either through the system package manager or by the user (or desktop environment) marking them as such.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 17:08 UTC (Thu) by drag (subscriber, #31333) [Link]
Well don't forget that opening malicious documents in applications can have the same effect as executing a binary.
For example a common attack vector is to use HTML email to exploit flaws in Microsoft's HTML rendering technology. Using javascript or other things like that to exploit weaknesses that were discovered and 'patched' in Internet Explorer.
Another one is using built in languages for applications to execute virus-like things. For example Word Macro viruses were very very popular.
-------------------------
So... say in Linux there is a flaw in Envice's PDF rendering method some were. So you could send a legal PDF over email that when executed by Evince it would exploit that flaw and run some shell code.
Since there is no security internal to a user account or desktop any program, even the most trivial and unimportant, with a exploitable flaw can be used to gain full access to anything and everything on that user's desktop..
This example is just targeting Nautilus or Konquerer to do a oversight in the .desktop standard... but any program that is commonly used to handle files downloaded from the internet has the same potential problems.
------------------------------
With Linux having a generic attack like with Word Macros or Win32 HTML rendering flaws probably won't work.
So worms and viruses won't spread. The environments are to diverse and are patched too quickly for a generic attack to work in that manner.
This is, in fact, what makes Linux resistant to viruses even though the Linux binary formats makes it very easy to write viruses.
HOWEVER this does not make Linux resistant against focused attacks. If a attacker knows what desktop your using and knows that there are flaws in some of the software your using on your desktop then they could create a focused attack that, if they are targeting a corporate desktop install (for example) with hundreds of users, then they can have a very high probability of success.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 9:03 UTC (Thu) by renox (guest, #23785) [Link]
Not only a PEBKAC.. 'rm -Rf' works because the command name is obscure, telling users to type 'delete -recurse -noconfirm' would be far less successful..
I'd argue that a sensible designer should choose meaningful name for dangerous actions.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 15:43 UTC (Thu) by jhardin (guest, #3297) [Link]
> telling users to type 'delete -recurse -noconfirm' would be far less successful.
You're assuming that they know what "recurse" means. :)
delete --subfolders --noconfirm
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 16:13 UTC (Thu) by jengelh (subscriber, #33263) [Link]
Directories, directories. Shitty Windows "folder" terminology, even Microsoft once knew better during DOS times.
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 8:04 UTC (Fri) by muwlgr (guest, #35359) [Link]
What about that thing called "Active" Directory ? :>
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 9:49 UTC (Fri) by jengelh (subscriber, #33263) [Link]
That's probably a circumscription for a reiser-backed data storage, because normal directories are pretty much static and inactive by themselves.
(SCNR-reiser-joke-after-everybody-else-had-theirs-already.)
Special desktop files and untrusted media Posted Feb 12, 2009 14:18 UTC (Thu) by pboddie (guest, #50784) [Link] Well they are not executed, per say, but they are interpreted by your nautilus browser. It's like RISC OS's !Boot file mechanism where the desktop environment would scan application directories and run !Boot files to set up icons and file types (and potentially do other stuff): supposedly great for convenience, but a great way of spreading malware in a way not dissimilar to the "autorun" behaviour of media under Windows (where the malware may well be some media company's latest rootkit). A quick review of prior art would surely have paid dividends here, but I guess (or would hope) that the ROX Desktop people guard against such attacks, at least, given the RISC OS inspiration of that project. Everyone else should do less posturing and more homework.
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 20:35 UTC (Wed) by jmorris42 (subscriber, #2203) [Link]
Ok, I probably shouldn't but I gotta go on a rant here.
> What happened in more than two years?
Exactly nothing. Because the leading lights in both the GNOME and KDE camps do not see themselves as UNIX users, do not intend to 'inflict' UNIX design decisions on their users and just generally have the attitude that they are supplanting UNIX, not extending it. The relationship between OS X and Darwin is their guidestar. Or more bluntly, that they draw their inspiration from Windows and the Mac and despise *NIX. They consent to be hosted on *NIX/X because it is the only game in town and doing so lets them get on with the GUI stuff they like and forget about the operating system details.
Make all .desktop files executable and the problem doesn't exist. That this IS a problem waiting to happen has been obvious for years and the downside to the change is pretty close to zero. This is a failure in design philosophy. Push a devel in a corner and make em explain and I'd bet money it would involve a more weasel worded version of "Windows doesn't have an executable flag, thus it would confuse new users. Getting new users is the be all end all arguments priority."
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 21:13 UTC (Wed) by aleXXX (subscriber, #2742) [Link]
> Because the leading lights in both the GNOME and KDE camps do not see
> themselves as UNIX users,
Being a KDE developer myself, I can assure you that this is simply not
Alex
How to write a Linux virus in 5 easy steps Posted Feb 11, 2009 21:47 UTC (Wed) by dskoll (subscriber, #1630) [Link] aleXXX wrote: Being a KDE developer myself, I can assure you that this is simply not true. I'm willing to give KDE some grudging benefit of the doubt, but some of the top GNOME people (eg, Miguel de Icaza) are anti-UNIX. And although .desktop files are a "standard", they are a terrible idea. They are a clear security danger. I have e-mailed the security contacts at both kde.org and gnome.org. I fully expect them to ignore the issue, at which point I will have to write an article retracting my original opinion (from 2001) that Linux is more resistant to e-mail trojans than Windows. What a sad state of affairs.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 7:58 UTC (Thu) by bkor (guest, #27950) [Link] some of the top GNOME people (eg, Miguel de Icaza) are anti-UNIX Ignoring your statement about Miguel, could you give another example? I'm involved in GNOME and I think your statement is not true. Further, Miguel isn't involved with GNOME anymore (only relation is that he started it, etc). From what he said himself, he only attends e.g. GUADEC as an interested user (plus it is fun). I have e-mailed the security contacts at both kde.org and gnome.org We don't have a security contact (unless it changed over the last few months).
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 14:20 UTC (Thu) by dskoll (subscriber, #1630) [Link] bkor wrote: We don't have a security contact (unless it changed over the last few months). Well, I sent an e-mail to security@gnome.org, and the mail did not bounce. So either that address exists or your mail server is blackholing mail. Ignoring your statement about Miguel, could you give another example? I cannot give names, because I don't know any. But I'll give an example of anti-UNIX behaviour: I've asked for various GNOME tools such as evolution to support an external editor; shelling out to an external editor is time-honoured UNIX behaviour. This request has been met with reactions of various degrees of hostility, from "go away, we're too busy" to downright derision. I don't mean to go on an anti-GNOME rant. But you did ask! (For the record, I don't use KDE either.)
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 18:26 UTC (Thu) by bkor (guest, #27950) [Link] Well, I sent an e-mail to security@gnome.org, and the mail did not bounce. So either that address exists or your mail server is blackholing mail. Or that is the wrong address. Just mailing some random thing is not a promise that it is the right method. But I'll give an example of anti-UNIX behaviour Ah, so you're feature request wasn't implemented. Oh well, I wouldn't call it anti. I do want to know in which bugreport you interpreted someones remark as derision. Feature requests can be rejected, but people have to be respectful. Btw, Evolution has a plugin to use an external editor.
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 2:21 UTC (Fri) by k8to (subscriber, #15413) [Link] Well, I sent an e-mail to security@gnome.org, and the mail did not bounce. So either that address exists or your mail server is blackholing mail.Or that is the wrong address. Just mailing some random thing is not a promise that it is the right method. No, one of two things he or she said is true regardless of your postulation. Your comment may be pretty relevant to the right way of going about things, of course. However, gnome does all kinds of things totally wrong in a manner that shows a failure to understand UNIX. Gnome libraries don't even understand what standard error is for. They think it's standard debug or something. A typical gnome program has so much library spew that you couldn't ever possibly notice a real problem that the application you're using is trying to tell you about.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 11:32 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
"I'm willing to give KDE some grudging benefit of the doubt, but some of the top GNOME people (eg, Miguel de Icaza) are anti-UNIX."
Let me point out that the desktop file standard is heavily based on kdelnk format from KDE. A anti-GNOME rant is going to fix any potential security issues with a cross-desktop standard format at this point.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 8:57 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
Other people also like to distance themselves from Unix. Remember what GNU stands for? That is not just a joke name. Linux is also not Unix for that matter. Obviously Unix design decisions which are still appropriate today are worth keeping up, but is every legacy decision sacred? For instance, for many purposes I would rather user python than the old Unix standard tool collection. And surely names longer than three (or four) characters would be acceptable for standard directories now, in an age when modern systems have both PATH variables and tab completion at the command line :)
How to write a Linux virus in 5 easy steps Posted Feb 13, 2009 16:35 UTC (Fri) by geohump (guest, #27792) [Link]
>Other people also like to distance themselves from Unix. Remember what GNU
>stands for? That is not just a joke name. Linux is also >not Unix for that matter.
Dear Mike, I'm sorry but you seem to have misunderstood both why GNU is called GNU and why Linux is Linux. RMS was not "distancing" GNU from UNIX. RMS was making a free CLONE of UNIX. RMS intended GNU to be an exact functional replacement for UNIX. You might want google up the original postings to usenet from RMS about the project.
RMS named GNU "GNU" as part of his way of making clear that GNU was to be completely free of any the original UNIX intellectual property despite being a clone of UNIX. Do you suppose that its just an accident that every tool the GNU folks built had exactly the same name and function as their UNIX counterparts? (And tweaks as well. I never met a programmer yet who could resist the chance to "flavor the pot" to their own personal taste when they could get away with it. :-) )
Both the GNU and Linux efforts were created in order to give the people who loved the power and elegance of UNIX, a free version of UNIX, complete with source code to work on themselves, without having to purchase an AT&T/Bell Labs source code license.
Your idea that GNU and LINUX are not UNIX show that you missed the conversation that happened at the time of their creation. The GNU tools and Linux were made to be as much like the original UNIX as they could be in every way that matters to programmers, while maintaining total separation from any of the source code from ATT/Bell so that they would be free from licensing costs and restrictions. If all you care about is the name "UNIX" being licensed, then you were never a UNIX or Linux person anyway.
For those who say Linux is not a "UNIX" because its not perfectly identical to UNIX, I say: "Hey thanks for the belly laugh!" Linux is just as identical to UNIX as ULTRIX, HP-UX, Domain-IX, SUNOS, BSD, AIX, SCO, and all the other "legal UNIX licensees" are to each other and to the original ATT/BELL UNIX (assuming you can resolve the differences between the teeming masses of UNIX versions Bell put out itself! How many were there? 20? 30? )
Your claims that names should be longer 3 or 4 chars and that "Modern systems" have both PATH and "tab complete" are amazingly lacking. UNIX and its clones/variants have had those for more than 25 years. In fact PATH was there in the 1970's. Probably longer than you've been alive. (Personally I approve of keeping comamnd names somewhat short as long as there is a mnemonic relationship in the name. Why make people type more than they have to? (Excuse me, I meant "cat" not "type" :-) Well, OK, cat isn't the best example of a mnemonic. :-) ) ) (Note these are parenthetical side notes, not Lisp code. ( Hey, these ARE the jokes folks! ) )
As for liking Python. Thats great. New languages come out of the UNIX/Linux environments all the time. UNIX/Linux even has tools for generating new languages. You are, of course, totally familiar with Lex and yacc. :-) What I especially like about python is how well it integrates with the "standard" UNIX/Linux environment. :-) That liking python might imply anything is wrong with the UNIX/Linux tools is an interesting notion.
The GNOME desktop vulnerability is a clear example of why the UNIX design legacy is a good one, well thought through and still applicable today. That vulnerability exists because the GNOME folks are trying to make LINUX just like Windows and sadly, within the confines of their project, they are suceeding. They are even introducing the typical Windows security issues!. Happily no one has to use GNOME and therefore Linux users can remain free of this Ballmer-esque disease of corruption. (Hey guys - try throwing a chair at your design, maybe that will improve it. ) The Gnome project is an excellent example of people ignoring the UNIX design philosophy and paying the price.
"Those who do not understand UNIX will re-invent it. Poorly." Has never been more true than today.
The quality of the UNIX design philosophy is becoming more and more clear as time goes forward. Even MS is busy today adding more and more UNIX-Like features to their OS. :)
Does this mean that Linux has to stay the same? Absolutely not. New features can and are being added all the time. Lets just make sure those new features are really new, not copies of MS mistakes and that those features actually work the way they need to, including security.
[N.B.]
By creating a clean room style clones of UNIX, GNU and Linux gave a version of UNIX to the worlds programmers that they could use in a totally unrestricted fashion. The key point being that the GNU tools and Linux system WERE UNIX CLONES. Thats WHY they are and were so popular. Legally, NOT licensed from ATT/Bell, Functionally and design-wise - as darned near identical as they could be made to be by the best efforts of their creators. (subject to the perfidies of ego, of course. :-) )
The naming of GNU was done to emphasize the free licensed nature of GNU. Otherwise it was a functional clone (plus more) of UNIX tools.
Final postscript: To those who will try to play "geek gotcha" with this comment by finding obscure techno arcana or tortured interpetations of the above statements repurposed to support things other than what was said in the context above, you fail. The above posting is about the philosophical spirit of UNIX which GNU and LINUX completely engender and not about the legal-word-smithing typical of the "We-add-no-value-but-we-have-lawyers" approach typical of some people and companies. By trying the latter approach you actually support the statements made above. The spirit, not the letter rules here.
|
|
||||||||||||