We’ve all used UNIX or one of its derivatives. A lot of us use it for development and server applications. Quite a few of us love it. And I’m sure we’ve all got things we hate about it too. Is it time for a new Unix-Hater’s Handbook?
I have a few bones to pick:
a) Inconsistent command-line options:
Most programs use -- in front of their options. For example, mc --version. Some don’t, like dd, find, and other utilities from the Stone Age.
(backward compatibility, blah, blah, blah, it’s been several decades, blah, blah, blah)
b) Directory structure:
Yes, we’ve all heard the reasons why there’s a /bin, /usr/bin, /usr/local/bin, and /usr/local/*/bin, or why there are multiple library locations, or why there’s a /usr and /usr/local, etc. So what?
And then there’s the programs that think they’re somehow special so their default installation location is something like /usr/local/mysql (cough). Or libraries that think they’re special (hello, Qt, I hate you with a passion).
The directory tree is a mess, no matter what the reasons given.
c) Libraries and binaries:
Related to the above, all the binaries and libraries are thrown into a huge pile. Take a look in /usr/lib. Do you know what every library in there does? What its dependencies are? And what about /usr/bin? Don’t forget /usr/local/lib and bin too! And what happens if you have different versions of a library in /usr/lib and /usr/local/lib? Fun!
Yes, in this era of shared libraries and commands accessible from everywhere (ie, ye olde PATH), that’s one solution. Yet, while DOS didn't have shared libraries, its layout was a whole lot simpler. Want to install a program? Put it in its own directory. Want to remove it? Delete directory.
It's not that hard to devise a solution that combines simplicity and consistency with shared libraries and programs. Where is it?
d) The shell:
Zsh/BASH/tcsh, etc, are all a lot better than the windows world. On the other hand, shell scripting is amazingly ugly. Why isn't the shell more extensible? Perl may not be an ideal language, but the perl shells I've seen were a lot saner when it came to making shell scripts. Oh, sh and friends also have a convoluted configuration system.
e) Configuration:
I love doing a ls -la of my homedir. ~90% of the crap I see there are dot files. It’s like every program thinks it has a god-given right to throw a file in there.
And then there are the ones that don’t put a dot file. Nor a dot dir. Nope, they put a _normal_directory there (hello GNUstep, zinf). So now not only is my –la listing full of junk, normal listings are too. Thanks guys.
Why can't they standardize on something like ~/.config/* ? At least then there'd be only one uninteresting entry clogging up the file listing. It’s not that hard to cd .config to get at my settings.
f) Init system:
So how do you like your poison? BSD or SysV? Do they treat you well at night too? Or are you one of the crack-heads who made your own custom init system that uses a makefile so you can parallelize you boot? That makefile’s pretty brittle, huh?
People are having flamewars and religious arguments over BSD and SysV, but they simply both suck (although SysV sucks more, hah!). Maybe Apple is right? I don’t know much about initd, but Apple has a point.
g) Editors:
The major editors are all terrible. Emacs is a monstrosity that required bizarre key-combinations. Vi has that horrible dual-mode (and also has byzantine sequences of keys). I prefer vi myself, and I know vim can remove the dual-mode, but why aren’t there any sane and powerful default editors out there?
h) Library, library, on the wall...:
Since I’m one of the strange people in this world who still downloads source tarball and compiles, I’ve noticed an odd trend: more and more programs are making useless libraries. The developers think it’d be brilliant to put all functionality in the library, and leave some tiny stub program in the binaries.
Of course, nobody ever uses that library other than the original proggie. So why did they make a library in the first place? You’re writing a program, not a library.
Linux-land, at least, has gone library mad. They make and use libraries like it’s air. Then there are the fools who make major pieces of software that require either KDE or Gnome to be installed. And eventually we end up with several pieces of software that use either.
Nah, we’re not using GTK or QT, we’re going all the way, baby!
Wait, I’m running two desktop environments now? At the same time? WHY?!
i) ZOMG FREEDOM!
Does h) sound familiar? Do you often hear the refrain, “but it’s freedom to do and use whatever you want! Evolution! Yayayayay lololol!”
Guess what? As a user I don’t give two hoots about your freedom. I want a system that works, and isn’t held together by cruft and duct-tape.
Guess what? As a developer I don’t care about your fucking freedom either. I want a single API to target (and isn’t held together by cruft and duct-tape)!
Why do I have to use an additional abstraction layer so I’ll be able to use either QT or GTK depending on what’s available?! And what’s the whole deal with autoconf?
If you had a free hand, what would you wish was changed? Do you disagree with me? Flame away and show me where I’m wrong.
>>95-97 are DQN
"The first step to fixing is recognizing there's a problem."
But you don't do anything about it. You just complain about the people who actually do stuff. If you think UNIX is so bad, show me a system you've made that works better. But you won't because whiners just remain whiners.
I'll expand a bit on this. UNIX is the best and most productive system I've used, and yes, coherent. It all fits together. It's sure not perfect, but the alternatives aren't forthcoming. The critics ITT haven't produced any.
This thread has left a bitter taste in my mouth because many of the criticisms are based on a lack of understanding, or a lack of willingness to understand. >>1 for instance complains about inconsistent command-line options, but nearly all UNIX utilities do use options consistently: they are one character and can be combined, so "-9qo -" is equivalent to "-9 -q -o -". The --long-option style was invented by GNU and has been copied by some applications. It is not at all the standard.
The directory structure >>1 complains about serves a good purpose and is not at all a mess. /bin is for utilities that are needed when the system is booted in single-user mode and the files under /usr may not be available. /usr/bin is for other system programs, and /usr/lib is for system libraries. /usr/local is where applications and application libraries go. These distinctions are important for maintaining servers and timesharing systems. If >>1 only wants a single-user desktop computer, then maybe this is overkill for >>1. I, however, find the /usr vs. /usr/local distinction helpful and the /bin vs. /usr/bin distinction quite livable, if a little superfluous. MySQL and Qt are not part of UNIX and are therefore moot, although if >>1 thinks they suck so much, he's welcome to fix them or make something better.
I can recognize more than half of the files in /usr/lib and have at least a vague idea what the others do. The same goes for /usr/local/lib. I do not know what everything in /usr/bin and /usr/local/bin is, but I can easily find out by typing "man commandname". I do not need to know about library dependencies, because anything in /usr/bin or /usr/lib is part of the operating system and I have no reason to change it, and my operating system supplies a package manager that tracks dependencies in /usr/local/bin and /usr/local/lib (although this is not a standardized part of UNIX).
If "it's not that hard to devise a solution that combines simplicity and consistency with shared libraries and programs," then indeed, >>1, where is it? Anything is easy if you're not the person who has to do it. I find the directory hierarchy simple and consistent enough already. That's not to say it couldn't possibly be improved upon, but you haven't suggested any improvements, and there are more important things to worry about. There is no real problem with the current layout.
The complaints about shell scripting are pointless. If >>1 prefers to write Perl scripts, then why doesn't he just do so? There is nothing different about the process, only that the line at the top has to say "#!/usr/bin/perl" rather than "#!/bin/sh".
The configuration complaint is similarly without merit. The entire reason ls hides dotfiles by default is not to show configuration files. If you don't want to see them, don't give ls the -a option. Then >>1 complains about GNUstep and Zinf saving configuration files visibly, not as dotfiles. This is a valid complaint against those programs, but like the MySQL and Qt examples, the problem lies with poor-quality applications, not UNIX.
It is easier to dismiss a system as worthless and badly designed than to learn to use it properly. But if you must do the former, at least don't make stupid threads, please. If you have something better, just release it, and stop complaining about what exists, okay?
>>102's very valid point aside, how about I show you a shell I made for AmigaOS once back in the day that was much more of a joy to work with than pretty much any Unix shell out there? Will that count?
(Excepting the theoretical possibility that I might one day figure out how to make zsh behave the way I want it to)
Also:
> This thread has left a bitter taste in my mouth because many of the criticisms are based on a lack of understanding, or a lack of willingness to understand.
I think you misspelled "unwillingness to agree with me" at the end there. Trust me, we've had the supposed justification explained to us many, many time, and we are not ignoring them out of some sort of pigheaded denial of the world around us, we actually disagree with them. You can not simply dismiss those who do not agree with you as uninformed or unwilling to learn. As it happens, both me and dmpk2k are, if I may make so bold a claim, highly skilled computer users and programmers. We have many, many years of experience using both Unix and non-Unix systems. It is from exactly this experience that we formulate our criticisms of Unix as it now stands.
I really don't have the time to refute all your points, especially as many of them are refuted here, or even in >>1. If you try to read the thread, you will also notice a criticism of the mindset of many Unix users and developers that there is nothing wrong with Unix, and any problems experienced is due to the person complaining. This is not only incredibly arrogant and irritating, it also not a good attitude for a developer to have, if he wants people to use his product.
> It's sure not perfect, but the alternatives aren't forthcoming.
a) It's not perfect.
b) There aren't any alternatives.
therefore
c) We shouldn't note the shortcomings?
Ignoring that b) is false, I'd really like to know what the hidden premise here is, because c) certainly doesn't follow from a) and b).
>>102, many individuals can write software by themselves. Few can overturn governments and/or start their own countries.
>>103, please do.
>>104, the original post contains many complaints that suggest the writer does not understand the mechanisms involved (see >>101 re: command-line options, directory layout, etc.). Argument from authority will not change this.
>>105. Alternatives. Present some then. VMS? DOS? AmigaOS? Those are all dead. Unix has some deficiencies, but not what you've "noted" -- your notes are the same old whiny rants about how "I don't understand it, therefore it sucks."
> many individuals can write software by themselves. Few can overturn governments and/or start their own countries.
How many write operating systems by themselves? You're just parroting the number one fallacy of the Internet: "If you can't do better, you're not allowed to critize!" Do you never complain about food if you can't make something better? Do you never critize art, music or architecture?
> the original post contains many complaints that suggest the writer does not understand the mechanisms involved
Look, I am trying to tell you: Both him and me do understand. We just do not agree. Try to accept that there is a difference. If you would read >>1 again:
> Yes, we’ve all heard the reasons why there’s a /bin, /usr/bin, /usr/local/bin, and /usr/local/*/bin, or why there are multiple library locations, or why there’s a /usr and /usr/local, etc. So what?
And again: "Yes, we’ve all heard the reasons..." - why then are you repeating them, as if being told them one more time would suddenly make them valid?
For instance: The reason you give for the split between /bin/ and /usr/bin/ is completely invalid on just about every modern Unix system. Modern Unixes, especially those running as a home desktop, are never booted into single-user mode, and if they are, /usr/ is pretty much always available. There is no longer any need for this, yet it is still vehemently defended as a good design decision. That is the attitude we're annoyed by.
>>107 It sure is difficult to drag logic into a debate where so much is at stake for the status quo camp, they don't want to realize that their extensive knowledge of trivia about legacy UNIX quirks would become useless with some clean-up.
I hate all the mystique the UNIX hackers like to have around their OS.
A lot of valuable time is wasted all the time by people who try to learn their way around issues that should have been solved before half of us were born.
Let's all just move to Plan 9. :-)
> Present some then.
Off the top of my head, used commercially: OSX, Windows, QNX, OpenVMS, TRON.
> "I don't understand it, therefore it sucks."
I understand it all too well, mate. Just because you say I don't doesn't make it true. But, if it protects you emotional investment, you'll believe that regardless.
By the way, you still haven't told me what the hidden premise in >>105 is.
>>107, you could at least suggest an alternative design, e.g. instead of doing this, the system should work this way. Write a detailed specification for how the entire system should work and justify why each part of it is best off working the way it does. If you don't want to do that, or are not willing, then maybe you'd best not be commenting on the shortcomings of existing systems. The number one fallacy here is "My ideas are great, and I can just leave the easy part of actually doing something with them to other people." Nobody's going to come along and fix Unix for you because you whined and ranted about it.
>>110: OSX is Unix. Windows -- glad your sense of humor is still there. QNX is a real-time operating system, so it's not suited to the same purposes as Unix. Besides, a quick visit to Wikipedia informs me that it is "POSIX compliant" and "Unix-like." Not familiar enough with your last two examples to comment -- but if they're so good, why aren't you using them, instead of griping about Unix? This is a serious question.
>>111
I thought that this thread was already the spec. You take UNIX and you correct what has been stated to be wrong.
And people may actually take steps to fix UNIX if enough people are pissed off at its current state. Somebody comes up with the idea, somebody with the work. I have seen my share of interesting projets started that way from discussion.
But you know, you really shouldn't expect people to design or develop a complete operating system to make a point in an Internet discussion.
And you cannot say that OS X is UNIX because it is not perceived as such by normal users (by normal users, I mean people who only use terminal.app when coding). It is not a pretty GUI on the top of a standard UNIX, it is UNIX reworked until you could integrate it into Mac OS.
> OSX is Unix.
So... if I mention the mess of libraries that plague *nix, then I'm misguided because that isn't UNIX, but if I mention OSX, all of a sudden it is? You defend against many of my criticisms, yet when OSX attempts to fix those same problems you want to take credit for that?
> Windows -- glad your sense of humor is still there.
I favour pragmatism. I try to use the best tool for the job, and for some things Windows is that tool. Are you saying that there's nothing Windows is better at?
> QNX is a real-time operating system, so it's not suited to the same purposes as Unix.
Why no, it isn't, although the embedded folks would be interested to hear that. Mind you, QNX isn't too bad as a general *nix replacement either. Ever used it for desktop?
But we weren't discussing specific domains. We were discussing flaws with *nix. Just because *nix makes a good server doesn't mean that it has no problems. So the directory hierarchy is ugly, what does that have to do with it serving webpages?
Nobody's going to use my own personal spec either, and neither should they, because it wouldn't be very good. I'm not an operating system designer, nor does everyone have the same requirements as me. That's why we have discussion first to get people interested in the idea, to indentify problems, and to suggest improvements. Such as this very thread.
Are you seriously suggesting that every single person who has problems with Unix should make up their own design before they are allowed to even talk about it?
>>112
Unfortunately, nobody seems to be correcting anything ITT, just complaining.
I don't expect anyone to design an operating system to make a point, but surely in order for a better operating system to exist.
>>113 is DQN. The "mess of libraries" is an application issue -- third time I've had to say this. I'm not defending KDE or GNOME. And operating systems that serve a different purpose are not alternatives -- should be obvious, right?
>>114
Certainly anyone should have given serious thought to a better design before they begin to talk about it with your sort of attitude: "It's not me, it's Unix." If you believe the root of the problem is Unix being flawed, you should be ready to suggest a system design that isn't.
If what you people are trying to say is that Unix is not ideal for desktop systems with GUIs, I agree. Moreover, for that application, I think it should be replaced, not fixed.
> The "mess of libraries" is an application issue -- third time I've had to say this.
And M$ Windows has DLL-hell, amirite?
It looks like I have to spell this out for you:
> And operating systems that serve a different purpose are not alternatives
Why not? Why isn't Windows an alternative? Why not QNX? Why not all the others? It's only an alternative if it's in an problem domain where UNIX is superior, right? The fact that people are trying to push linux embedded (where QNX and TRON make their daily bread) have nothing to do with this, right?
And again, what does this have to do with anything? Even if *nix was the only solution, and no others existed, does that mean the ugliness vanishes? That somehow the directory hierarchy improves itself, there are fewer inconsistencies everywhere, the commonly installed shells magically suck less, and the library mess fixes itself? *nix is somehow suddenly perfect?
> If you believe the root of the problem is Unix being flawed, you should be ready to suggest a system design that isn't.
One of my professors at uni is an old-skool OS developer (now retired) who happens to like Solaris. When I ask him about the problems with initd, all I get is a bunch of handwaving. He is unable to give me a single reason why initd is better than launchd, other than something along the lines of, "it's missing the magic".
The problem is that the *nix of today evolved that way. Normally I'd applaud that, but now there's cruft in there that's several decades old. Even parts that were there in the initial design could use replacement, but they're still there because of inertia (the same reason the linux fanatics always gripe that Windows is still here).
When better solutions comes along, what happens? They're ignored due to dogma and familiarity.
You're right to some degree about good ideas being ignored. Fortunately, though, there are enough Unices out there that at least one of them generally implements any particular good idea.
I'm thinking of strlcpy and strlcat, for instance, which are now available pretty much everywhere except on Linux.
Another way of looking at it: Steve McConnell, in his book "Code Complete", introduces the idea of a "technology wave": if you're on the early end of the wave, you're working with new technologies that are exciting but still developing, and you may not have very mature tools. On the late end of the wave, your tools are hardened, battle-tested, but consist mostly of thoroughly crusty technology.
Unix is very late-wave now. For me this is a good thing, because having a solid, carefully put together operating system is important to me. It does mean some aspects look a bit quaint (e.g. /bin vs. /usr/bin is rarely a useful distinction anymore), but not so much that I can't be productive.
Now, Microsoft's "monad shell" is an interesting idea. I haven't used it, but examples I've heard give me the flavor; for instance when you type "ls", instead of having text thrown at you, you see objects, which have properties and can be manipulated. I'll be the first to admit that seems quite a bit more powerful than cut, paste, find, and xargs. But this is real early-wave stuff, so for the moment, it's only interesting to experiment with, not to use on a daily basis.
I don't think any major improvements will be made to Unix. All you'd end up with would be an incompatible Unix, and who wants to use that? I think the next big system architecture will have to start from scratch. It also won't be written in C. When C is your systems language, Unix is probably about the best you can do. The next kind of system will use, and popularize, a more higher-level language, like Lisp, Haskell, or who knows what.
> The next kind of system will use, and popularize, a more higher-level language, like Lisp, Haskell, or who knows what.
and will probably require 2GB of RAM to run well (Windows Vista, anyone?)
There used to be computers that ran everything with lisp (see: lisp machines).
Some commercial lisp compilers can come close to C, as can certain dialects of ML. Given the additional leverage you're getting from higher level languages, it would almost certainly be a worthwhile tradeoff.
>>120
Actually, I swear Microsoft wrote most of Vista in Haskell. Not only would it totally explain the astronomical memory requirements, it also might explain the rumors that they've finally built a secure OS this time. (There are no buffer overflows in Haskell programs.)
>> (There are no buffer overflows in Haskell programs.)
I bet MS could find a way
No, they really couldn't! Haskell is referentially transparent and purely functional. There's no such thing as a pointer in it.
I suppose they could mess up and have a buffer overflow inside part of the Haskell run-time system, though.
after finally looking at plan 9, i have to say it looks like it could be a very nice system if it had better graphics capabilities and more apps ported to it...
I think it's pretty safe to assume that if your language can't have a buffer overflow, you can't code an OS in it either. Part of an OS, sure, but not the whole thing.
>>126
I meant the vast majority of it. You can at least code all of userland in such a language, and probably parts of the kernel.
Also, 0x80GET!
>>117
That's typical behaviour from Solaris fans. Deride everything until it appears in Solaris, then claim ground-breaking and revolutionary. I have to constantly put up with them; they spend years bashing features in other OSes not in Solaris, then magically when Solaris gets a piss poor copy of them (under a different name, naturally), the bitches won't stop extolling the virtues of it and claiming how it's the first of its kind. e.g. DTrace, just a weak copy of perf counters.
> DTrace, just a weak copy of perf counters.
Hahaha, what?
>>130
Sounds like the cdrecord guy; apparently, Solaris is the gold standard of SCSI device handling, and other OSes require so much ostensibly horrible hackery to get working that he'd rather not deal with them unless they're "reasonably close" to what Solaris does. The comments bashing Linux in the libscg source are particularly telling (and they only got worse after his little hissy fit on linux-kernel).
Not only that, but "libscg" insists on viewing things through the guise of a Unix workstation circa 1992 (e.g. a SPARCstation IPX or SS1); it demands a SCSI bus:target:LUN address and will freak out at you if you hand it a device node. (It may still work, but it still bitches you out.) This, of course, makes ittle sense if you're trying to burn to a non-SCSI device (you could argue that anything that speaks SCSI is subject to the SCSI Parallel Interface rules, but not even SCSI-2 or CAM says that, and Windows certainly doesn't do it that way), and I haven't seen a new SCSI CD writer in years (only the very first DVD recorders were SCSI, not that cdrecord will support them without getting "ProDVD"...).
Someone at SuSE patched the warning about this out of their version of cdrecord, and he screamed and yelled about it on linux-kernel until they told him to go away. (He does the same thing on the Debian bug tracking system whenever someone does something "inofficial" with cdrtools...god damn annoying, that). I find that behavior childish and unprofessional, and would like to see cdrecord replaced because of it. I've considered doing it myself, using some patches I made up to FreeBSD's burncd program for another project, but I just haven't given myself the time to write SCSI support layers for other OSes and clean it up.
The directory structure can be fixed, take a look at heretix(http://www.h-e-r-e-t-i-x.org/, a new linux distrobation, everything is written in ruby(the init system too). The package manager installs everything into /pkg with a name system based on the package name and version. For example GCC 3.4 is installed as /pkg/gcc/3.4/. Then it's symlinked into /bin, /lib and so forth.
At the moment it uses WhiteWater(a bittorrent like protocol) for distrobation. But a change to a new protocol is expected with the next stable release.
Sure there are som problems with their implentation but it is a change for the better and imho the road that alot of distros will take.
>>133
That sounds like a half-done version of GoboLinux.
http://www.gobolinux.org/
"Distrobation" is my new favourite nonsense word.
Why the emphasis on it being written in Ruby? That's hardly noteworthy.
>>137
I looked up FHS on Wikipedia. It seems to be a fairly new standard that everyone ignores in the first place, based on the article. I suspect you meant to trash on the de-facto standards that preceded FHS (/etc, /bin, /sbin, /usr/bin and so on).
>>134
GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.
>>136
Easily extended init system.
>>135
Embrace it.
>>137
FHS is just de facto heir with ugly /opt added to it.
>>138
It is better then the windows way of doing things, it was created before the thought of dependency handling :).
>GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.
So if different FS layout and init system don't qualify as "new", what exactly is remarkable about heretix? The portage clone in Ruby?
> Easily extended init system.
i don't know ruby.
learning ruby is a decidedly nontrivial task.
therefore i suggest you refrain from using the word "Easily" next time.
> GoboLinux is doing stupid things, like adding capital letters to the begining of names. It doesn't do anything new excecpt change the names of stuff.
This statement makes no sense.
Problem: File system is badly structured.
Attempted solution: Changing the names of stuff to arrange it better.
Complaint: Changing names does nothing new.
what
>>141 is right on. If it's supposed to be easy, it should be possible to do it in my choice of language.
If it's supposed to be easy, it shouldn't be using a "language" at all.
"It's possible to program a computer in English. It's also possible to make an airplane controlled by reins and spurs." -- John McCarthy
>>138
Yes, I meant the guys who came up with that shit. Didn't know FHS was new, I thought I just had found a name for the source of all evil.
> GoboLinux is doing stupid things, like adding capital letters to the begining of names.
Capital letters aren't stupid. They look better. For example, see the menu on the left here in 4-ch. If it were all lowercase, it'd look like a GNU hippie's job.
> It is better then the windows way of doing things
Ha ha, no.>>139
Capital letters aren't stupid. They look better. For example, see the menu on the left here in 4-ch. If it were all lowercase, it'd look like a GNU hippie's job.
Capital letters are stupid for path names because you have to mash the shift key all the time.
Capital letters are good... if you have a case-insensitive filesystem (sup NTFS)
Capital letters and spaces in filenames are good. It is much more conveninent for users. Who cares about developers? Those guys are clever enough to use the space, backslash, and tab key when they have no other choice than to use the CLI.
>>149 but it's much less convenient for users who prefer the CLI.
>>150
And your point is? Why should we cater to the needs of the minority? That's because of this attitude that we still have impossible to understand folders like /bin, /usr, /dev, /etc. Compare for example with Applications, Library, System.
Is it because some people can get some sense of superiority by pretending that the CLI is much better suited to normal file management (as opposed to complex operations that require a scripting language)?
>>148 has another good point: Dump the goddamn case sensitivity from the Unix filesystem. That's a horrible, horrible idea.
...that is, case sensitivity is a horrible idea. I was being somewhat unclear there. Case sensitivity is really just boneheaded programmer mentality.
>>147
That's because you have a filesystem that's case sensitive even though we treat lowercase and uppercase letters conceptually the same.
>>149-150
We can also use a case-insensitive command line subsystem, like Win32's.
>>152-153
I wholeheartedly agree with you, and I'm a programmer.
However, for some reason, case-sensitivty seems to be a quite religious issue for some Linux people. Even when they need to support case-insensitive anything, they make sure that case-sensitivty is default and to enable insensitivity you need to use some ugly, long, or half hidden switch the like of --really-i-want-case-insensitivity-please-ok-i-suck-i-know-sorry . Even the CRT pseudostandard functions are longer (strcasecmp as opposed to stricmp in most other CRTs). It's as if they wanted to punish people for wanting case-insensitivity.
I mean they rename /bin and so forth into /Programs and what not, no additions nor changes.
sure if you don't know ruby there is a problem but make your own distro then :P.
>>151 is the reason democracy doesn't work.
>>151
Seriously, how do you come up with this garbage? "Sense of superiority"? "Pretending"? I:
Is it so hard to believe that someone has these characteristics, and therefore prefers a different method of interacting with computers than you?
But yeah, obviously I inconvenience myself in order to get a "sense of superiority", and gays make a conscious choice to be perverts, and the minority doesn't matter. And 2 plus 2 is five. And ignorance is strength.
Seriously, "sense of superiority"? What the fuck, man?
>>154
You can't blame Linux for strcasecmp(): it was introduced in 4.4BSD. Personally, I think that the added obviousness of what the function does outweighs the need to type 3 more characters when using it. What runtimes besides MSVC's call it "stricmp", by the way?
>>157
A lot of people force themselves to use the CLI to be "cool". Go to any web-based Linux forum to see for yourself. Your case doesn't refute >>151.
However, it's true that visual file managers should be more suited to keyboard command and that the current ones lack some of the advantages of the CLI. (I think GUI FMs are better since I work mostly with media and scripting languages, but let's not go off-topic).
So, anyway, can't we at least all agree that UNIX folders suck? Their meaning is hard to guess and every program and library chooses where to install its stuff seemingly at random.
I fucking hate coding. This thread has convinced me to quit my job writing code, move to brazil and start killing people for a living.
And no, unix folders don't suck. If you follow standard conventions for building your application it's real fucking easy. It's been the same way for how many years now? Figure it out. And why the hell do you have to instantly be able to tell what each folder does. Do you know how much more complicated an application would be if you wrote everything out in plain english?
>So, anyway, can't we at least all agree that UNIX folders suck? Their meaning is hard to guess and every program and library chooses where to install its stuff seemingly at random.
man 7 hieranyone who doesn't obey that deserves to be beaten, stabbed, tarred and feathered, shot, boiled in oil, and burned at the stake.
>>163
how is it "seemingly random"? it makes sense to me...
unless the linux hier(7) manpage is significantly different from the freebsd one i'm looking at right now...
EXPLANATION ABOUT "EASILY GUESSABLE"
If you need to learn about it, it is not easily guessable.
Examples: /bin, /etc, /usr (= user?), /opt, `/dev (= development?), ....
Counterexamples: /home, /binaries, /Applications, /libraries, /devices, ....
It's been there for 30 years? Big fucking deal. If the folders were named /fo, /pk, /cnf, /wut, or /lol, you'd cope the same way, by learning. It means that hundreds of valuable hours are wasted every time an UNIX newbie must learn about it.
Thank you for your attention.
> Do you know how much more complicated an application would be if you wrote everything out in plain english?
Yeah, let's just do everything in ASM!
>>165
Off the top of my head:
/bin - system binaries for single-user mode
/dev - devices
/etc - system configuration files
/usr/bin - system binaries
/usr/lib - system libraries
/usr/share - read-only system program data
/usr/local/bin - application binaries
/usr/local/lib - application libraries
/usr/local/share - read-only application data
/home - user directories
If it takes you "hundreds of valuable hours" to remember the above, you have issues.
>>167
You fail at reading comprehension.
People should deal with as little learning as possible, and it is possible to do so without making the system less performant for developers and professional users. UNIX directory structure is a decent example of making other people deal with your problems because you didn't take the time to engineer your way around it.
If your are a coder, laziness is not just a virtue, it is a moral imperative. Computers are supposed to allow you to do stuff fast. Having to learn things gets in the way. One clever person is generally enough to solve a problem for millions of people.
I think the subtle mix of maximal computer performance orientation, legacy, elitism and coder mentality will never allow any improvement in UNIX, there's too much inertia.
I like how the original UNIX scheme doesn't try to hide the fact that it is an arbitrary set of directories, which is dependent on application developers to use properly.
>>169
Is this supposed to be a sarcasm? Given the UNIX fanboyism found ITT, it's difficult to say.
>>168 Unix is for people who don't mind learning. If you are not one of these people, don't use it. It's that simple.
>>171 You say that like it's a good thing instead of a problem that needs to be corrected.
> Counterexamples: /home, /binaries, /Applications, /libraries, /devices, ....
what's the difference between /binaries and /Applications?
no matter what, you're going to have to learn a few arbitrary things. i think it's obvious what /bin, /etc, /lib, etc. are for, and /lib is a lot shorter to type than /libraries...
also, no matter what the "correct" filesystem hierarchy is, it's still up to application developers to use it.
>>173 Then what about making them /b, /d, /h, /e, /r, /p, /t, /u, /v ? It'd save much typing.
OS X doesn't have /Binaries, even though I wish it would. But if it had, the difference would be that /Applications contains application bundles, which are essentially directories that contain all the files an application need, but are treated as single objects by the GUI - you click on it, and your app runs. You move it somewhere else, and all the files move along with it, and it still works no matter where you put it. /Applications is just for convenience. /Binaries would contain single executables that are run from the command line. (Right now, OS X has /bin and /usr/bin, but not /usr/local/bin unless you go and specifically create it, or some installer still stuck in Unix land creates it for you.)
PS: How often do you actually type "/bin"? And does your command line not have filename completion?
> How often do you actually type "/bin"?
about 5-6 times a day.
> And does your command line not have filename completion?
it does, but my text editor doesn't.
>>177 Mine does. Get another if it is useful for you.
And when you code, you generally don't have to type paths often anyway, since you don't hardcode them.
>>178
what text editor do you use?
>you generally don't have to type paths often anyway, since you don't hardcode them.
#!/bin/shYeah, "#!/bin/sh" is another really stupid Unixism that should be changed. Why on earth won't it search the path? Why do I have to worry about whether Perl lives at /usr/bin/perl or /usr/local/bin/perl?
#! /usr/bin/env perl
>>179
TextMate, a great OS X only editor, but forget that, I realized afterwards that the feature is not built-in, it just completes words it already knows without caring about their semantics. Since it has a great shell integration, you can make a shell script to do it for you then map it to a shortcut.
I'm sure the filename completion should be possible in a lot of Unix editors though, maybe built-in in the feature-packed ones like emacs.
>>180
Not really knowledgeable about it, but shouldn't /usr/bin/env perl work everywhere ?
>>181
Damn, you were faster
> emacs
is full of AIDS.
turns out elvis (what i've recently started using) does have filename completion, it just isn't enabled by default...
apparently pico also has filename completion, but all i've been able to find about that is that "-e" (what!) enables it.
Most GTK apps have filename completion.
Well, that was before GTK went gay and started removing text fields wherever possible. What's up with that?
Hooray for Unix feature shyness!
>>186
Don't you realize that they'll just go all "compatibility with the original 1975 freeware" then all RTFM, and the whole argument will start again in a slighlty different version?
>>187
Fork your own version then, damn. Or use nano. Or fork your own version of nano, if they're the same way.
Seriously -- you're a programmer. Maintaining a text editor for your own use is not that hard.
Ok, now I've lost track of who's trolling, who's sarcastic, and who's serious in this thread. Whichever it is, I'm nominating this for funniest line of the thread:
> Seriously -- you're a programmer. Maintaining a text editor for your own use is not that hard.
Looks like the argument for pretty much always follows this template:
Cue quote from TAOUP, that one about UNIX being the sum of its errors, or one from K&R or Don Knuth if you really need to win the argument.
>>189
Seriously. It is not that hard. Download the source, grep it for "getopt", find the flag that gets set when 'e' is found as an argument, set that flag by default, and compile, and you're done.
Do you really think these guys who maintain text editors are doing something magical? How much dumber than them can you possibly be that you can't maintain a text editor?
>>189
Seriously. It is not that hard. Download the source, grep it for "getopt", find the flag that gets set when 'e' is found as an argument, set that flag by default, and compile, and you're done.
Do you really think these guys who maintain text editors are doing something magical? How much dumber than them can you possibly be that you can't maintain a text editor?
>>190 More like:
Unix is not user-friendly. Get over it. Use something else if you can't accept the fact that power requires learning.
> Seriously. It is not that hard. Download the source, grep it for "getopt", find the flag that gets set when 'e' is found as an argument, set that flag by default, and compile, and you're done.
is now the funniest line of the thread.
> Use something else if you can't accept the fact that power requires learning.
That argument is used to justify requiring from users to take care of developer's problems.
also, MOAR LIEK:
- UNIX is perfect. If you disagree you are dumb, lazy, and mistaken.
> Unix is not user-friendly. Get over it. Use something else if you can't accept the fact that power requires learning.
I can't see this as anything but an admission that the complaints in this thread are all pretty much justified.
> I can't see this as anything but an admission that the complaints in this thread are all pretty much justified.
Next logical step is the good old "then fix it yourself instead of whining"
>>195 We're going in circles here. Why must Unix be user-friendly? You want something user-friendly, so why do you not use something that is? I don't get it.
I can see four possibilities here: