it's when a new version of something comes out every year and LOTS OF STUFF is just moved around or different
Every small change adds up, though. If you look at two different versions of Red Hat, they will be quite different. I don't think *ix changes more than any other system. Windows now is still very much like Windows95 (as Linux 2.4 is relatively like Linux 2.0). There are large (major) versions and then there are smaller versions.
When the old things they want to do just no longer work.
erm. I think *ix users _don't_ upgrade for this precise reason. Their system is finely tuned to their liking. You might be able to say "Unix users don't upgrade as much as XYZ users." And you might be right. They don't upgrade so they won't have to suffer having things broken again. This is why I hate installing new Linux distros. They never come how I want and I end up spending days tuning it to my liking. *ix users as a whole might not have this "version fatigue" problem, but the cause IMO is not the same. One type of user might upgrade all the time to play the latest games, use latest word processor, etc. If you want the newest gadget, you have to expect it to be new! I just don't understand why people expect to "upgrade" to the same software...
If you look at _software_ for *ix you will notice the same problems. The GIMP is notorious for changing its UI. GNOME and KDE have the exact same problems. Mozilla too.
I don't buy this stuff about how unix is hard and other stuff is easy
Then..
The problem is when things change rapidly. Totally.
This is part of the problem w/ determining ease-of-use. If you went from Windows to Unix in one day, you would be completely lost. More so, if you had never touched DOS before. You would have no concept of command lines or executing programs. Metaphorically, things can be different. Folders don't exist in (traditional) *ix, but directories do. If you took a long time vi user who had never used another text editor, and moved him to a Windows text editor, he would struggle to do anything. The classic vi vs. emacs is the same thing. I wouldn't say either one is more easy to use than the other. There are simply people attached to their tools.
Perhaps the ultimate answer is: ease-of-use doesn't exist. I do believe good documentation and teachers do, though (and overly-complex software, which is only slightly different from powerful software, in that one provides a use per complexity, the other does not).
well.. UI has changed somewhat. Let's look at Linux: when I started using it in ~1996, much was different. Default keybindings were different (I believe they have become more PC-friendly over the years.. with actual working backspace, tab, etc. in most distros). Besides that, color was becoming a big part of the shell. Today many Linux (and I know at least FreeBSD) users would never dream of using the shell without "ls" color highlighting. "ncurses" was becoming a bigger part of the shell, with many installation/config programs and even the kernel configuration based on it.
The nature of X makes it anti-change, in a way. They are about mechanism, not policy. You can see some changes in window manager features. If you looked at Linux in 1996, all you would have is twm, fvwm, and a few others. The biggest UI "eye-opener" was probably Enlightenment. But, before E a major change happened rather inadvertently. If you remember, someone made a fake X screenshot which had a transparent xterm. This is what, IIRC, led to a more eye-candy X UI, starting with E which eventually implemented a transparent terminal. Before E, no one really thought X could be "pretty." It always had that dull Motif/tk feel about it.
Later came KDE, followed by GNOME. They have the goal of transforming what is basically a high-graphics shell into a "desktop" with higher program interaction than what was available in the normal shell and X interfaces. X allows small things like copy-and-paste, but has no desire to handle program integration. IMO, neither KDE or GNOME have come very far and I'm not quite sure either are very much more than a glorified window manager + X at this point.
does the causation run the other way round - because all the obscure Emacs keybindings are so well known by its users (and developers), they can't be changed?
I think this is a large part of what is, to some people, "holding Linux back." It doesn't just happen with keybindings, either. The file system layout is a good example. A number of people have wished to change configuration from traditional/etc to something more "sane." There is always a huge argument when that idea comes up--simply because it is tradition.
Commercial *ix might not evolve as much as an open system, but I'm sure the open systems put great pressure on the commercial ones. I don't think you can purchase a commercial *ix today that does not have at least a few GNU-isms, such as gcc for example. Because of the open nature of software, it will evolve. And it will also remain the same. It will grow in every direction that people push it. If Red Hat came along today and said "there will be no bash shell in the next release," many people would have to adapt.
Is this an explanation for why Unix users typically learn more of the intricate features of their software?
I don't think this is the case at all. For me, I have never felt compelled to learn the intricate features of the majority of Linux software. I know a little about most, but usually not everything. I tend to pick it up on an as-needed basis. I'd also say that Linux demands the user to know more. To use pipes, you must first know a little about the shell. To use X, you must know a little about window managers. To use vi, well you need plenty of time and aspirin and a very open mind (coming from traditional text-editors). I would say that every UI that has ever been introduced into Linux is still there. What _is_ changing, is more UI's are constantly being added.
I disagree. My first unix-style OS was FreeBSD, which I used for a week. Then I decided to try Linux (to see what the fuss was about) and installed Slackware (IIRC, 3.2). Both Slack and FBSD worked similar, and both had a "clean" feel about them. I would recommend either to a person new to unix-flavor OSes. Back then I would _not_ have recommended Debian (I had issues w/ dselect back then, IIRC). I also tried Red Hat (IIRC I tried 4.x and then 5.2). Out of all the above, Slackware was the easiest (along w/ FreeBSD, from what I can remember). I'd probably give Debian another shot though. I will definately _not_ use Red Hat again. I'm avoiding it like the plague. There is a certain "fake" quality about Red Hat and the way it hides its unix nature. Seems as if it doesn't want to be a *ix anymore (I think the turning point was seeing fvwm95.. ewwww).
Software is also relatively young. Not just in the sense that it has only been around for 40/50 years, but in the sense that the tools evolve so quickly
It is very ironic, the tools and methods in use today and the data formats in use. There is a saying that goes something like this: "Those who do not know Lisp are doomed to reimplement it." What have we learned lately in new programming tools and languages? From Java and C# we learn that garbage collection is a Good Thing(tm). From Perl we learned that quick throwaway programs (prototypes) can be extremely useful. From SGML to HTML and finally XML we learned that having a simple representation is the best way to represent malleable data (away from documents, back to symbolic expressions, or S-expressions).
Now if only we could pursuade people that parans aren't as evil as they first look...
One thing many programmers haven't gotten which quite a few Lisp'ers have is this: data is data. How the data is contained is irrelevant. What is done or can be done with the data is the most important. What tools you use to move data to other forms of data doesn't matter. There is also a very fluid nature to Lisp (i.e. code is data), which is very eye-opening (especially for those asm/C/C++ coders out there).
Heh. I tried Debian pre-apt, and I remember dselect. I had Debian about 2 days before Slackware went back on. Even Red Hat lasted about a month (a terrible month, at that).
I think the reason people (or at least I) use Slackware is they realize the futility of managing packages and dependencies. They understand that once a package is installed, it is more-or-less a permanent fixture in their system. No promises or false guarantees. Want something removed? You gotta get your hands dirty.
Of course, package management has become someone nicer today..
There are tons of problems with Linux file systems (and general *ix).
all SHARED libraries are in the same place. That way the dynamic linbker does not need to do a ridiculous path search to find a library
This is a convenience for the linker, though. Not one for the user or developer. We should not have to sacrifice simplicity to make the linker simple. And if we have the hierarchy and system that I have in mind this won't be a problem at all, since the linker today uses a cache and doesn't scan the directories at all (for the most part, unless you ldconfig).
all binaries are in 3 -4 places -- that way you don't need a massive PATH variable like 'the good old DOS days'
But there is where you are wrong. /bin /sbin /usr/bin /usr/local/bin /usr/sbin /usr/local/sbin /usr/X11/bin /var/lib/apache (only god knows how it got there..) /opt/kde/bin (NOTE this) /opt/gnome/bin (and this)
Then IBM Java needs added to the $PATH. I also remember Qt having issues with this and needing added to the path. And typically I add a/home/*user*/bin which I place personal scripts that I use. The PATH issue is still there. I'm willing to bet that there is a much cleaner and better way to find executable files than what we use today. Perhaps a caching method would do well.
I don't see your point about NFS, other than/etc is for the most part system-independent. Perhaps package+configuration directory would be good enough? But, ideally configuration data would remain with the package. That way you can simply move a directory and the package will become persistent. With my method you could share one program across multiple machines. Say you have this:
/package/my-application-1.0/
You can use NFS and the entire package will be available remotely. You are really taking my usage of DOS way too literal (and in a different context). The simplicity of one program to one directory is what I meant by "good old DOS days." Not that DOS could be used via NFS in the way you mentioned.
'the good old DOS' system was good for what it was used for -- a small system for one user with a few programs and didn't need any optimization. The heierarchal system is a lot better here used as a multi-user, muti-tasking shared-library networked OS with hundreds of programs.
And I would say to that, that much of the complexity of Linux (general *ix) is invented and not actual complexity with a purpose. The multi-user and multitasking issues are simple to tackle w/ the system I described. The shared-library issue would need work, but it is very doable.
Now if you hate the heierarchal system that much, you can do what SCO OpenServer does -- install all the files into each 'program directory' and then make symbolic links
Erm.. but then we are all still dependent upon the Linux hierarchy, now aren't we? It might be useful for me (after tons of work making every package fit my system), but it doesn't do a thing for anyone else. Which I think was the purpose of the article..
[...] expecially since you have package databases to help tell you where all the files are
It could very well be the other way around (databases telling where packages are).
The bulk of this article and thread seem to be once again people bitching about RPM dependency hell.
No, not RPM dependency hell. Dependency hell in general. Which is easier to depend on: one package, or a library in/usr/local/lib, 50 header files in/usr/include/*lib-name*, a config script that brings it all together in/usr/local/bin? Dependency is not just a shared-library issue, either (as I mentioned with header files). It is much bigger and in the future will be much, much more nasty.
If we don't clean the crap up now we are in for a very very nasty environment later. Call it pollution of the OS, if you want. The Linux I use today is much less organized than even the one I used 4 years ago. And it is getting worse.. such as the/opt/kde and/opt/gnome directories which some distributions are now doing. This tells me there is something seriously wrong when you must recreate the file system hierarchy in/opt just to allow simple removal of packages (or in this case, a complete desktop system).
Libraries are shared code, intended to be used by multiple programs/apps/packages.
Erm. People are hung up on this library thing. The reason we have */lib today is not a user or developer convenience. It is a linker convenience. All the linker has to do is scan a few directories in it's path. Perhaps another idea behind the */lib structure is all application libraries go into this directory and a developer can simply find and choose a library to use. In practice it is never like that. A developer uses a library which is pseudo-standard, such as GTK+, Qt, ncurses, Xlib, etc. Sometimes a package may create libraries which it uses itself, such as The Gimp. The Gimp uses libgimp for plug-ins. The thing is this: The Gimp and libgimp go hand-in-hand and it would be very difficult seperating the two. It makes no sense to seperate the library from the binary and have people confused as to which version is on their system. If you simply had a directory called "gimp-1.2.3" then you would know exactly which version. You could also depend on that package and be guaranteed that it would never change.
Another issue that goes along with libraries is where do applications place their header files? I have had major issues with this. Typically, what happens is old header files get mixed with new header files and when you go to compile an application it will many times get confused (include wrong files, etc.). If libraries had their own seperate directory, then you could place all header files there too. Imagine how much developer time this would save. I don't know if you use GTK+ or GNOME style libs much, but they have scripts written just so developers can link to the library easier (gtk-config, *-config). Type "gtk-config" at the command line to see what I'm talking about.. I'm sure you have it. Imagine how simplified linking to an application could become. Instead of needless -I and -L we could just do something like: --usepackage gtk+-1.2 and the linker/compiler would know exactly what needs done.
This is a serious problem. Think about why KDE and other medium to large applications are using/opt today. IIRC, Slackware installed GNOME and KDE both in/opt. Look in there and you will find exactly the same structure as your file system. Now you end up adding another path to $PATH anyways. What about X? It has been doing basically whatever it feels like with its libraries and includes. Typically they fall into/usr/X11/*. IMO, the only possible solution is a major overhaul. Package management that we use today doesn't work at all because any modification to the file system could wreck dependency havoc. For example: if I removed gtk-config, I just killed the library. Yes, the library file is there and works for existing libraries. If I ever need to compile something with it though, I'm out of luck.
I'd really like to get my hands on a Mac w/ OS X. It sounds really cool and I've heard many good things about it...
I think you missed the point.. I said _arbitrary_. libc is a central library. The idea behind shoving all libraries into a directory is because of the possibility someone may use a library. This is a theory and in practice you rarely use libraries which are not well defined or even their own seperate package entity.
Re:RPM not the problem..
on
Is RPM Doomed?
·
· Score: 4, Interesting
I don't know if you've noticed lately, but libraries _are_ packages today. GTK+ for example. Qt, ncurses, etc. And if a package creates a _new_ library, then not many people are going to depend on it. And if they _do_ depend on it, they might as well depend on the entire package being there--since the library is a _part_ of the package.
The idea of sharing arbitrary library code is a failed experiment. If I create MyProgram and then I create MyProgramLib.. not many people will ever use the library. The only case they _will_ use that library is if I _package_ it seperately, and make it a coherent entity itself--with documentation. This is why, IMO, going package-only and dropping the various */lib directories can only be a Good Thing. And this is how Red Hat, etc. do it today. They create dependencies between _packages_. If I create an app in RPM format that needs, say libgimp, then my package will depend on the _entire_ gimp package being installed. Not just libgimp. Why not just handle packages naturally?
I'd also like to point out the benefits of doing this:
- Package corruption will be detected immediately. When something depends on a package and a file is missing or corrupt then the package can be determined corrupt.
- Dependencies handled naturally. When a program complains that a file doesn't exist, I can pinpoint _exactly_ which package the file is in and can simply reinstall the package. No need to hunt down which file belongs to which package.
RPM not the problem..
on
Is RPM Doomed?
·
· Score: 3, Insightful
in itself. The problem is not using the hierarchal file system in a coherent way. In addition to that problem we have way too many files nowadays. When package contents mix with one another.. well I'm sure you've had Chem. 101.
This article wants solutions, so here is mine: Make packages a seperate directory. Just like good old DOS days--where every program lived by itself in a directory. _All_ package contents go in this special directory. Then you have the problem of per-user configuration. This is incredibly simple. Have a directory in each user's directory which _mirrors_ the package directory. Each package directory should be unique (i.e. MyProgram v1.0 lives in a different directory than MyProgram v1.1). Dependencies would be much easier this way since you would only depend on a _directory_ existing. Moving packages would simply be a matter of packing up the directory and taking it wherever.
In any case, software is _package_ based. Why do we still throw library files from different packages together in the same directory?! When you want to remove a package you have to rely on broken package managers, or hunt down every file which goes with a package. We should be able to completely remove software by simply removing a directory. I've heard MacOS does this, why can't Linux?
People think PHP is something special. The reality is it is more like perl than not. It's truly funny watching people say perl is old and outdated for CGI use and then turn around and claim PHP is somehow better. PHP is simply an ad-hoc language just like perl. Each uses various syntax and semantics from C, Java, even BASIC (probably much closer to BASIC semantics than anything). Having two or more syntactic ways of doing a semantic process is _not_ really a good idea (code maintenance becomes more difficult).
CGI is CGI. Perl has mod_perl, so it is on par with PHP. I'd really love to see mod_scheme. Scheme is perfect, IMO, because the ease of use and the base language, R5RS, has very useful functions which are perfect for web use. All that would be needed is an addon library to make the language a little more complete. Of course there is always mod_python, which I've heard is Lisp/Scheme-like.
Unfortunately, we have a little thing called "competition," and when two or more businesses have a bottom line, on the line, then you get inconsistencies. They may all state that they support LSB, and they all probably do. But then every distro will add their features which make them different from every other distro and then you have the same problem over again! Developers will become dependent upon distro-specific features and the LSB will fall very very behind. One person claimed that the LSB would simply be updated. I say this is horseshit. You can't have a moving standard because then it is no standard at all! There would become many many LSB versions in a short time and you would have LSB-version incompatibilities.
In the end, it will be Red Hat that sets the standards for Linux. Infact, they already do with RPM. Even Slackware comes with RPM integration (strong *ix philosophy meets desktop user-friendly philosophy).
There are problems with LSB itself. It has to define way too much to be useful (which it can't and doesn't) and LSB-compliant applications are way too restricted to be useful. GNOME/KDE applications are not LSB-compliant, for example. And never will because then LSB would require all implmentations to have KDE/GNOME installed (and would have to define the precise version of every library which consists of a "GNOME system" and a "KDE system".. a near impossible task at that).
The LSB is a pseudo-standard. It defines many interfaces, but it leaves it wide open for interpretation. For example (context: LSB application compliance):
5. It does not use any interface or data format that is not required to be provided by a conforming implementation, unless:
[...]
* The use of that interface or data format, as well as its source, is identified in the documentation of the application.
As you can see, this is pointless standardization and, IMO, will never get anywhere. The problem with defining Linux is that Linux can be anything to anyone and programmers tend to not conform to standards unless there is a _technical_ barrier that conforming to the standard is the only way to get around that barrier. For example, not too many people conform to UI guidelines, but everyone who wishes to use an internet RFC follows it precisely.
Negativity is still negativity. I know very well Windows' faults. I know the nature of Microsoft (and corporate business in general).
Don't you ever get tired of people bashing Windows and MS? If Linux is so good, then it should stand on its own. You shouldn't need to bring Windows, MS, or their user base down to make Linux look good. There seems to be more talk about MS in the Linux community than Linux itself.
Sure, it could. But the fact remains that a LOT of us don't want users using Linux unless they have a clue. Put simply -- stupid people will make Linux look bad. They'll do dumb things like logging in as root, for example, deleting everything, and then blame the O/S for not having a "recycle bin".
Instead of making people new to Linux uncomfortable and unwelcome, I would instead _teach_ them how Linux works and how it differs from other systems. For the most part, people using Windows take for granted that an OS even exists. Many assume that the OS is a part of the computer and don't realize that many abstractions are placed over the hardware that can differ between OSs.
Users use an OS for the applications. To tell someone they must find alternatives, or *gasp* develop entire applications is actually working around faults and limitations with the OS itself.
Ever consider that perhaps Windows users are using Windows because it _works for them_? And they don't need Linux. Yet the technical elitists of the Linux community always feel the need to take a stab at Windows, MS, and Windows users and pressure people into trying Linux. Just because someone puts up with Windows technical problems does not make them stupid.
Bugs? Just like stealing/etc/passwd and cracking passwords and then logging in through the front door is a bug? We forget that things like password shadowing, etc. have been added over time to make *ix secure. Security comes from a need for that security. Unix had that need early on, since they were going multi-user. Just because Windows has security needs _now_ rather than decades ago does not mean they can't bring it up to par with *ix security mechanisms. Learning from mistakes and mistrusted users is a big part of security. Windows design has and will evolve to meet security needs, I'm sure.
Now, compare it with Windows where the security is NOT builtin; moreover, the security is made a victim to ease-of use: Click attachment to start a worm.
I'm not saying Windows is better at *ix in terms of security.. I'm saying *ix users have become "fat dumb and happy"--complacent. Everything they know about security comes from the *ix way. I recommend joining a cracking group and watch which targets they choose. They will 99% of the time choose *ix based because they are that much easier to get into (and the fact that there are hundreds of ignorant admins who don't have the first clue). I've seen *ix box after *ix box broken into. IRIX, SunOS, Digital UNIX, Solaris, etc. You name it, I've seen it broken into. Countless Linux boxes. *BSD? Yep.
*ix admins assume that because they have a secure _design_ they are free from exploit. The fact is you could just as easily exploit sendmail in 1988 as you could in 1998. You don't need to figure out design flaws when there are easier ways to gain access to a system. It's not just sendmail, either. Or bind. It's CGIs which allow you to run any command, etc. I think it could be argued that there is a design flaw in *ix because it allows any program running access to the outside world. Most people won't see it that way, though. They will continually believe that they have achieved some security nirvana and will foolishly believe that the only security issues present just need "ironing out." What they fail to see is there will _always_ be bugs present and there will _always_ be exploits.
Okay, but this article is mocking Windows users while at the same time wanting Linux for the masses:
[...] it looks like the old dream of Linux eventually overtaking Windows and becoming the world's most popular operating system will never come to pass
Perhaps it will remain an "old dream" and become even older if Linux advocates continue to stereotype the userbase needed to achieve their dream. You don't hope for mass Linux acceptance and at the same time bash the future users. It just doesn't work that way. Users do not come from a magic hole in the sky. They will come from Windows, Mac, etc.
Elitism is only wrong when its done maliciously against attributes people cannot, or should not change
So in some magical way this is different from people who have to use Windows for specific applications? If they depend on MS Office, what you are saying is they should remain stereotyped as stupid Windows users?
An OS is something you can change, and if one has such a thin skin they can't take a jibe or two from someone on the opposite side of the fence on such a light issue perhaps they have some personal issues to deal with first?
This isn't a "jibe or two." This is a constant onslaught of negativity towards Microsoft and their userbase. It was funny the first time someone used "Micro$oft" or "M$." It is completely immature and redundant now.
Well, I would humbly suggest you're just looking in the wrong places. If you want to use windows and Linux equally
I dunno.. I look at those sites and see either bias because of corporate interests (microsoft.com) which really has no reason to be objectionable, or sites which attempt to be objectionable like cnet.com. I read an OS faceoff type article about Mac vs. Linux and the article had a person from each side arguing what made their OS better at certain things. And then I attempted to look at user comments at cnet.com and found this little bit:
[...] and while you're at it everyone should at least TRY Mandrake 8.2. Even simpleminded Windows Bots can manage this distro. Dual boot for awhile and you'll end up a convert eventually. I did and I was a Windidiot for years.
and then..
Yes, but not all of us Windidiot's want to convert to being arrogant Penguin-Thumpers...
I don't see many people on Slashdot seriously pushing Windows, Mac, etc. I also read linuxisforbitches.com:
I don't have an issue with Linux so much as the user base it
attracts.
Still, there was a philosophy going on of openness--the stuff that RMS speaks of. Everyone generally trusted each other and security was not a serious issue at the time. Take a look here.
In November 1988, Robert Tappan Morris released the infamous "Internet worm" that corrupted thousands of net-connected machines overnight.
[...]
The worm exposed a Pandora's Box of vulnerabilities in UNIX, including bugs in the venerable sendmail and finger programs. It also exploited the concept of "trusted hosts" in UNIX
[...]
Beyond it's immediate impact on infected systems, the worm called into question the "open lab" approach to UNIX security, which maximizes resource-sharing and trusting cooperation at the expense of formal security controls.
The result of this was the formation of the CERT organization. What I'm getting at is that *ix security methods have evolved very much, just like Windows security methods will. Overall, there is no silver bullet. Just as no one saw the internet worm coming, or the first wave of DoS attacks, no one will see the next serious security issue. Until it's too late.
Every security measure taken is always the result of a security breach. Or the _perceived_ security breach, which usually fits a pattern. For example, the advice you gave about not trusting the client is fairly new security "common sense" and is the result of many security breaches via client spoofing and manipulation. Back in '88 I doubt such security axioms existed, as they do today. I myself am a little worried that one day someone will come along and turn everything everyone knows about security upside-down.. and many people will be sitting idly by with their "secure" *ix box thinking they are perfectly safe, but maybe I'm just a tad paranoid.
I really haven't noticed Windows/Mac users stereotyping Linux users, but maybe I'm reading the wrong sites. The linuxsucks seems to be written by Linux users themselves.. not Windows, etc. users.
The article has a serious tone:
As Windows apologists are fond of pointing out, Linux can't possibly compete with Windows until it can match it feature for feature, and then some. I hold out little hope of Linux ever matching Windows on the virus vulnerability front, so it looks like the old dream of Linux eventually overtaking Windows and becoming the world's most popular operating system will never come to pass.
Note the author uses "Windows _apologists_" and then turns around and trys to claim (with humor) that Windows is superior. It's not entirely satire.
I know beyond a shadow of a doubt that Windows users love viruses, because they spread so many of them.
"I know beyond a shadow of a doubt that [insert country, favorite baseball team, etc.] people love viruses, because they spread so many of them." This just isn't funny at all. The nature of viruses is they travel undetected. You don't knowingly pass viruses (willingly or not). Would you willingly pass viruses, if you could? No, because that would be _stupid_. There is an implied stupidity on the Windows' users going on here. It is not the literal words, but the tone of the author that makes it most elitist.
There's not "elitism" involved, just regular old inter-group competition. It's natural and normal.
Perhaps that is part of the problem. You and others think it is normal behavior.. and it is because you believe it to be. That doesn't mean it _should_ be that way, or that it is normal to other people. I don't find this article amusing in the least bit.
If I moved to the Windows/Mac communities, would I constantly be reminded of Linux stereotypes? I seriously doubt it. The impression I get from other OS communities is they are concerned with themselves and aren't worried about what others are doing.
Erm. You have posters mixed up I think. I never said the bit about users not wanting to learn their computer or Linux users are more knowledgable. Anyhow...
This article was not funny at all to me. I've been a Linux user for years and this is plain boring and trite. It might have been funny 5 years ago, but today it sounds like a broken record.
And it also ignores one small detail: the most needed stuff is usually kept in the _user's_ directory. If someone killed my/etc,/lib, or/usr directories I would be mad. If someone destroyed my/home/login I would cry. Almost everything of any importance is stored in my $HOME directory. Typically, viruses aren't created to take over machines. They are created to _do damage_. Sure, root would cause much greater damage (possible hardware too), but destroying a user's home directory is Bad Enough. I really can see people creating viruses which live in a user's home directory and have no expectation of gaining root.
You would be correct, but only if security was an absolute. It is not.
What does it mean to "be secure?" It is easy to spew common *ix security logic when that is all you know and think about when security is the topic. You have to take a step back to understand the nature of security.
I'm rusty on *ix history, but I'm fairly certain security was never a top priority of the original Unix, until later. If you check up I'm sure you will find that security actually _was_ added to *ix on a as-needed basis.
As an example consider this: until fairly recently (mid to late '90s) denial-of-service was not a threat. *ix admins everywhere had to rush to turn off common "safe" services such as ping, finger, etc. as a result of what they believed was security.
The _biggest_ threat will always come unannounced and from a never suspected "location." What *ix has for security is simply barriers for the patterned attacks. Security has been a buzzword of sorts long before Microsoft--and will continue to be a "buzzword" as long as people foolishly believe that security is an absolute.
I bet that every group of people who are "in the know" about anything have their own bodies of humor. Ever insulted Britney Spears or her fans because you have much better taste in music than that? Yeah, I though so.
That's called elitism, and it actually alienates people. If you want to make a joke about something then you don't talk down at others. There are plenty of other ways to joke about Linux and viruses than to stereotype a group (Windows' users) as having a low IQ. Perhaps the reason people claim Linux is a religion or for fanatics is because they are alienated by crap like this. I've been in whatever this "Linux community" is for a number of years now and I'm feeling increasingly alienated. There is too much negativity towards Microsoft and too much seriousness about Linux for the masses. The fun has been lost between '96 and now, at least for me anyways.
Slashdot Mirror
Every small change adds up, though. If you look at two different versions of Red Hat, they will be quite different. I don't think *ix changes more than any other system. Windows now is still very much like Windows95 (as Linux 2.4 is relatively like Linux 2.0). There are large (major) versions and then there are smaller versions.
erm. I think *ix users _don't_ upgrade for this precise reason. Their system is finely tuned to their liking. You might be able to say "Unix users don't upgrade as much as XYZ users." And you might be right. They don't upgrade so they won't have to suffer having things broken again. This is why I hate installing new Linux distros. They never come how I want and I end up spending days tuning it to my liking. *ix users as a whole might not have this "version fatigue" problem, but the cause IMO is not the same. One type of user might upgrade all the time to play the latest games, use latest word processor, etc. If you want the newest gadget, you have to expect it to be new! I just don't understand why people expect to "upgrade" to the same software...
If you look at _software_ for *ix you will notice the same problems. The GIMP is notorious for changing its UI. GNOME and KDE have the exact same problems. Mozilla too.
This is part of the problem w/ determining ease-of-use. If you went from Windows to Unix in one day, you would be completely lost. More so, if you had never touched DOS before. You would have no concept of command lines or executing programs. Metaphorically, things can be different. Folders don't exist in (traditional) *ix, but directories do. If you took a long time vi user who had never used another text editor, and moved him to a Windows text editor, he would struggle to do anything. The classic vi vs. emacs is the same thing. I wouldn't say either one is more easy to use than the other. There are simply people attached to their tools.
Perhaps the ultimate answer is: ease-of-use doesn't exist. I do believe good documentation and teachers do, though (and overly-complex software, which is only slightly different from powerful software, in that one provides a use per complexity, the other does not).
The nature of X makes it anti-change, in a way. They are about mechanism, not policy. You can see some changes in window manager features. If you looked at Linux in 1996, all you would have is twm, fvwm, and a few others. The biggest UI "eye-opener" was probably Enlightenment. But, before E a major change happened rather inadvertently. If you remember, someone made a fake X screenshot which had a transparent xterm. This is what, IIRC, led to a more eye-candy X UI, starting with E which eventually implemented a transparent terminal. Before E, no one really thought X could be "pretty." It always had that dull Motif/tk feel about it.
Later came KDE, followed by GNOME. They have the goal of transforming what is basically a high-graphics shell into a "desktop" with higher program interaction than what was available in the normal shell and X interfaces. X allows small things like copy-and-paste, but has no desire to handle program integration. IMO, neither KDE or GNOME have come very far and I'm not quite sure either are very much more than a glorified window manager + X at this point.
I think this is a large part of what is, to some people, "holding Linux back." It doesn't just happen with keybindings, either. The file system layout is a good example. A number of people have wished to change configuration from traditional
Commercial *ix might not evolve as much as an open system, but I'm sure the open systems put great pressure on the commercial ones. I don't think you can purchase a commercial *ix today that does not have at least a few GNU-isms, such as gcc for example. Because of the open nature of software, it will evolve. And it will also remain the same. It will grow in every direction that people push it. If Red Hat came along today and said "there will be no bash shell in the next release," many people would have to adapt.
I don't think this is the case at all. For me, I have never felt compelled to learn the intricate features of the majority of Linux software. I know a little about most, but usually not everything. I tend to pick it up on an as-needed basis. I'd also say that Linux demands the user to know more. To use pipes, you must first know a little about the shell. To use X, you must know a little about window managers. To use vi, well you need plenty of time and aspirin and a very open mind (coming from traditional text-editors). I would say that every UI that has ever been introduced into Linux is still there. What _is_ changing, is more UI's are constantly being added.
I disagree. My first unix-style OS was FreeBSD, which I used for a week. Then I decided to try Linux (to see what the fuss was about) and installed Slackware (IIRC, 3.2). Both Slack and FBSD worked similar, and both had a "clean" feel about them. I would recommend either to a person new to unix-flavor OSes. Back then I would _not_ have recommended Debian (I had issues w/ dselect back then, IIRC). I also tried Red Hat (IIRC I tried 4.x and then 5.2). Out of all the above, Slackware was the easiest (along w/ FreeBSD, from what I can remember). I'd probably give Debian another shot though. I will definately _not_ use Red Hat again. I'm avoiding it like the plague. There is a certain "fake" quality about Red Hat and the way it hides its unix nature. Seems as if it doesn't want to be a *ix anymore (I think the turning point was seeing fvwm95.. ewwww).
Example Common Lisp code:
Now if only we could pursuade people that parans aren't as evil as they first look...
One thing many programmers haven't gotten which quite a few Lisp'ers have is this: data is data. How the data is contained is irrelevant. What is done or can be done with the data is the most important. What tools you use to move data to other forms of data doesn't matter. There is also a very fluid nature to Lisp (i.e. code is data), which is very eye-opening (especially for those asm/C/C++ coders out there).
yes..
At first the article made perfect sense, but then he went into Netscape and browser wars and went into iffy territory.
I love the info about IBM using open source though. For awhile I was really confused about their push.. but it makes it perfectly clear now.
Heh. I tried Debian pre-apt, and I remember dselect. I had Debian about 2 days before Slackware went back on. Even Red Hat lasted about a month (a terrible month, at that).
I think the reason people (or at least I) use Slackware is they realize the futility of managing packages and dependencies. They understand that once a package is installed, it is more-or-less a permanent fixture in their system. No promises or false guarantees. Want something removed? You gotta get your hands dirty.
Of course, package management has become someone nicer today..
But there is where you are wrong.
Then IBM Java needs added to the $PATH. I also remember Qt having issues with this and needing added to the path. And typically I add a
I don't see your point about NFS, other than
You can use NFS and the entire package will be available remotely. You are really taking my usage of DOS way too literal (and in a different context). The simplicity of one program to one directory is what I meant by "good old DOS days." Not that DOS could be used via NFS in the way you mentioned.
And I would say to that, that much of the complexity of Linux (general *ix) is invented and not actual complexity with a purpose. The multi-user and multitasking issues are simple to tackle w/ the system I described. The shared-library issue would need work, but it is very doable.
Erm.. but then we are all still dependent upon the Linux hierarchy, now aren't we? It might be useful for me (after tons of work making every package fit my system), but it doesn't do a thing for anyone else. Which I think was the purpose of the article..
It could very well be the other way around (databases telling where packages are).
No, not RPM dependency hell. Dependency hell in general. Which is easier to depend on: one package, or a library in
If we don't clean the crap up now we are in for a very very nasty environment later. Call it pollution of the OS, if you want. The Linux I use today is much less organized than even the one I used 4 years ago. And it is getting worse.. such as the
Another issue that goes along with libraries is where do applications place their header files? I have had major issues with this. Typically, what happens is old header files get mixed with new header files and when you go to compile an application it will many times get confused (include wrong files, etc.). If libraries had their own seperate directory, then you could place all header files there too. Imagine how much developer time this would save. I don't know if you use GTK+ or GNOME style libs much, but they have scripts written just so developers can link to the library easier (gtk-config, *-config). Type "gtk-config" at the command line to see what I'm talking about.. I'm sure you have it. Imagine how simplified linking to an application could become. Instead of needless -I and -L we could just do something like: --usepackage gtk+-1.2 and the linker/compiler would know exactly what needs done.
This is a serious problem. Think about why KDE and other medium to large applications are using
I'd really like to get my hands on a Mac w/ OS X. It sounds really cool and I've heard many good things about it...
I think you missed the point.. I said _arbitrary_. libc is a central library. The idea behind shoving all libraries into a directory is because of the possibility someone may use a library. This is a theory and in practice you rarely use libraries which are not well defined or even their own seperate package entity.
I don't know if you've noticed lately, but libraries _are_ packages today. GTK+ for example. Qt, ncurses, etc. And if a package creates a _new_ library, then not many people are going to depend on it. And if they _do_ depend on it, they might as well depend on the entire package being there--since the library is a _part_ of the package.
The idea of sharing arbitrary library code is a failed experiment. If I create MyProgram and then I create MyProgramLib.. not many people will ever use the library. The only case they _will_ use that library is if I _package_ it seperately, and make it a coherent entity itself--with documentation. This is why, IMO, going package-only and dropping the various */lib directories can only be a Good Thing. And this is how Red Hat, etc. do it today. They create dependencies between _packages_. If I create an app in RPM format that needs, say libgimp, then my package will depend on the _entire_ gimp package being installed. Not just libgimp. Why not just handle packages naturally?
I'd also like to point out the benefits of doing this:
- Package corruption will be detected immediately. When something depends on a package and a file is missing or corrupt then the package can be determined corrupt.
- Dependencies handled naturally. When a program complains that a file doesn't exist, I can pinpoint _exactly_ which package the file is in and can simply reinstall the package. No need to hunt down which file belongs to which package.
in itself. The problem is not using the hierarchal file system in a coherent way. In addition to that problem we have way too many files nowadays. When package contents mix with one another.. well I'm sure you've had Chem. 101.
This article wants solutions, so here is mine:
Make packages a seperate directory. Just like good old DOS days--where every program lived by itself in a directory. _All_ package contents go in this special directory. Then you have the problem of per-user configuration. This is incredibly simple. Have a directory in each user's directory which _mirrors_ the package directory. Each package directory should be unique (i.e. MyProgram v1.0 lives in a different directory than MyProgram v1.1). Dependencies would be much easier this way since you would only depend on a _directory_ existing. Moving packages would simply be a matter of packing up the directory and taking it wherever.
In any case, software is _package_ based. Why do we still throw library files from different packages together in the same directory?! When you want to remove a package you have to rely on broken package managers, or hunt down every file which goes with a package. We should be able to completely remove software by simply removing a directory. I've heard MacOS does this, why can't Linux?
People think PHP is something special. The reality is it is more like perl than not. It's truly funny watching people say perl is old and outdated for CGI use and then turn around and claim PHP is somehow better. PHP is simply an ad-hoc language just like perl. Each uses various syntax and semantics from C, Java, even BASIC (probably much closer to BASIC semantics than anything). Having two or more syntactic ways of doing a semantic process is _not_ really a good idea (code maintenance becomes more difficult).
CGI is CGI. Perl has mod_perl, so it is on par with PHP. I'd really love to see mod_scheme. Scheme is perfect, IMO, because the ease of use and the base language, R5RS, has very useful functions which are perfect for web use. All that would be needed is an addon library to make the language a little more complete. Of course there is always mod_python, which I've heard is Lisp/Scheme-like.
In the end, it will be Red Hat that sets the standards for Linux. Infact, they already do with RPM. Even Slackware comes with RPM integration (strong *ix philosophy meets desktop user-friendly philosophy).
There are problems with LSB itself. It has to define way too much to be useful (which it can't and doesn't) and LSB-compliant applications are way too restricted to be useful. GNOME/KDE applications are not LSB-compliant, for example. And never will because then LSB would require all implmentations to have KDE/GNOME installed (and would have to define the precise version of every library which consists of a "GNOME system" and a "KDE system".. a near impossible task at that).
The LSB is a pseudo-standard. It defines many interfaces, but it leaves it wide open for interpretation. For example (context: LSB application compliance): As you can see, this is pointless standardization and, IMO, will never get anywhere. The problem with defining Linux is that Linux can be anything to anyone and programmers tend to not conform to standards unless there is a _technical_ barrier that conforming to the standard is the only way to get around that barrier. For example, not too many people conform to UI guidelines, but everyone who wishes to use an internet RFC follows it precisely.
Users use an OS for the applications. To tell someone they must find alternatives, or *gasp* develop entire applications is actually working around faults and limitations with the OS itself. Ever consider that perhaps Windows users are using Windows because it _works for them_? And they don't need Linux. Yet the technical elitists of the Linux community always feel the need to take a stab at Windows, MS, and Windows users and pressure people into trying Linux. Just because someone puts up with Windows technical problems does not make them stupid.
*ix admins assume that because they have a secure _design_ they are free from exploit. The fact is you could just as easily exploit sendmail in 1988 as you could in 1998. You don't need to figure out design flaws when there are easier ways to gain access to a system. It's not just sendmail, either. Or bind. It's CGIs which allow you to run any command, etc. I think it could be argued that there is a design flaw in *ix because it allows any program running access to the outside world. Most people won't see it that way, though. They will continually believe that they have achieved some security nirvana and will foolishly believe that the only security issues present just need "ironing out." What they fail to see is there will _always_ be bugs present and there will _always_ be exploits.
The article has a serious tone: Note the author uses "Windows _apologists_" and then turns around and trys to claim (with humor) that Windows is superior. It's not entirely satire. "I know beyond a shadow of a doubt that [insert country, favorite baseball team, etc.] people love viruses, because they spread so many of them." This just isn't funny at all. The nature of viruses is they travel undetected. You don't knowingly pass viruses (willingly or not). Would you willingly pass viruses, if you could? No, because that would be _stupid_. There is an implied stupidity on the Windows' users going on here. It is not the literal words, but the tone of the author that makes it most elitist. Perhaps that is part of the problem. You and others think it is normal behavior.. and it is because you believe it to be. That doesn't mean it _should_ be that way, or that it is normal to other people. I don't find this article amusing in the least bit. If I moved to the Windows/Mac communities, would I constantly be reminded of Linux stereotypes? I seriously doubt it. The impression I get from other OS communities is they are concerned with themselves and aren't worried about what others are doing.
Erm. You have posters mixed up I think. I never said the bit about users not wanting to learn their computer or Linux users are more knowledgable. Anyhow...
This article was not funny at all to me. I've been a Linux user for years and this is plain boring and trite. It might have been funny 5 years ago, but today it sounds like a broken record.
And it also ignores one small detail: the most needed stuff is usually kept in the _user's_ directory. If someone killed my /etc, /lib, or /usr directories I would be mad. If someone destroyed my /home/login I would cry. Almost everything of any importance is stored in my $HOME directory. Typically, viruses aren't created to take over machines. They are created to _do damage_. Sure, root would cause much greater damage (possible hardware too), but destroying a user's home directory is Bad Enough. I really can see people creating viruses which live in a user's home directory and have no expectation of gaining root.
You would be correct, but only if security was an absolute. It is not.
What does it mean to "be secure?" It is easy to spew common *ix security logic when that is all you know and think about when security is the topic. You have to take a step back to understand the nature of security.
I'm rusty on *ix history, but I'm fairly certain security was never a top priority of the original Unix, until later. If you check up I'm sure you will find that security actually _was_ added to *ix on a as-needed basis.
As an example consider this: until fairly recently (mid to late '90s) denial-of-service was not a threat. *ix admins everywhere had to rush to turn off common "safe" services such as ping, finger, etc. as a result of what they believed was security.
The _biggest_ threat will always come unannounced and from a never suspected "location." What *ix has for security is simply barriers for the patterned attacks. Security has been a buzzword of sorts long before Microsoft--and will continue to be a "buzzword" as long as people foolishly believe that security is an absolute.