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.
>>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:
> Why must Unix be user-friendly?
Because it isn't opposed to being powerful or performant, in the same way that being user-hostile isn't always powerful and performant
What we are is:
5. OS X users who think "lol, don't they notice how backwards their system is? Good thing I managed to limit my interactions with UNIX to that little web server which I never log into"
>>198
That was number 3.
How about that we would like to use Unix, but it's doing its best to make our lives miserable, for reasons that make very little sense?
> You are responding to the Linux zealots who think everyone ought to use Unix, typically coated with layers of tape and makeup. Very well, I think these people are being dumb too, nor am I satisfied with KDE/Qt/GNOME/GTK/etc. I think trying to build this kind of thing out of Unix is dumb. So if you're arguing this, you can stop because we agree.
This is part of it. However, OS X has pretty much achived making a user-friendly system out of Unix. It can be done, with great results. Apple haven't done everything mentioned in here, because they've mostly focused on the interface, but the point is: There's no reason Unix has to be unfriendly.
> You feel that you and others are forced to use Unix (e.g. to run a server), and so it should be made easier for you. But why not hire a sysadmin or call for more diversity in general?
There is also this, but come on, your suggestion there is incredibly silly. Are you really suggesting hobbyists "hire a sysadmin"? Hell, I do some admin work for 4-ch. Do you really think "hire a sysadmin" is a reasonable option here? "More diversity in general" makes no sense, when no other OS comes close to Unix for running a server.
>>1
funniest thing i've read all week
i would like to point out that xfce, rox, graveman, and xpad put their configs in ~/.config/. probably more, too
> OS X has pretty much achived making a user-friendly system out of Unix. It can be done, with great results. Apple haven't done everything mentioned in here, because they've mostly focused on the interface, but the point is: There's no reason Unix has to be unfriendly.
I like how Apple's propaganda calls UNIX in OS X: "BSD Subsystem". Although OS X technically works on top of UNIX, unless you work with very, very low level stuff, then for all intents and purposes, you can pretend that UNIX is just another useful app/lib thing in the system. For non-programmers, UNIX is just that weird user-hostile Terminal.app
> no other OS comes close to Unix for running a server.
If you are an hobbyist, OS X can be enough in some cases.
> This is part of it. However, OS X has pretty much achived making a user-friendly system out of Unix.
That's rather subjective, but nonetheless, not a conversation I'm interested in, nor do I see why it belongs on /code/. Programming has little in common with interface design.
> "More diversity in general" makes no sense, when no other OS comes close to Unix for running a server.
Well, that was kind of the point. Unix is the only choice on servers => there's no diversity.
> This is part of it. However, OS X has pretty much achived making a user-friendly system out of Unix.
That's rather subjective, but nonetheless, not a conversation I'm interested in, nor do I see why it belongs on /code/. Programming has little in common with interface design.
> "More diversity in general" makes no sense, when no other OS comes close to Unix for running a server.
Well, that was kind of the point. Only one choice on servers => no diversity.
>>203
if you are a hobbyist, windows 98 can be enough. i used it for years.
.config/ is a silly idea. It doesn't help organize anything because there's no reason for dotfiles in your home directory to be anything but configuration and other program-generated files. It's not an accurate name because dotfiles are used for other purposes: .w3m has cached pages and my bookmarks file in it, .bsflite has IRC logs.. It'd just be more typing for no reason.
> It doesn't help organize anything because there's no reason for dotfiles in your home directory to be anything but configuration and other program-generated files.
I've reread that several times, and I'm still uncertain what you're trying to say. Could you please rephrase?
> Programming has little in common with interface design.
is now the funniest line in all thread, and a good insight into the UNIX mentality
> .config/ is a silly idea. It doesn't help organize anything because there's no reason for dotfiles in your home directory to be anything but configuration and other program-generated files.
No. Dotfiles can also be backups and temporary files for your own use (faster than /tmp). And it helps organizing stuff. But what about using Config/ instead of .config/ ? After all, it is something important and useful, exposing it would be a nice idea, then it'd contain one subfolder for every app, maybe in reverse-dns notation to do it really clean.
Oh, wait, it's already been fixed, as usual, by OS X.
>>208
What dotfiles in your home directory would not go in .config?
> If you are an hobbyist, OS X can be enough in some cases.
If you use OS X for a server (remotely, at least), you're really just using plain old Unix. There's no significant difference.
> Well, that was kind of the point. Unix is the only choice on servers => there's no diversity.
Right. But then what does "promote diversity" mean? Going around saying, "boy, I wish there were more server OSes"? Writing my own OS?
>>212
Sure. You're already going around saying "Boy, I wish Unix was more to my liking", aren't you? Why would going around wishing for something else be less effective?
> There's no significant difference.
Push butan. Receive server up.
> But then what does "promote diversity" mean?
Plan9 and GNU/Hurd, of course!!
Because cleaning up Unix is marginally less of a pipe dream than someone suddenly creating a whole new OS with widespread support?
Or, I guess, Windows stopping sucking as a server OS. I really can't even imagine what the odds of that are.
> Plan9 and GNU/Hurd, of course!!
"GNU/Hurd" was a good joke to throw in, but unfortunately it doesn't quite work since that's just more Unix anyway.
>>216
That's a hacker joke that really means "GNU is a clone of Unix", but good try.
>>216,217 GJ at ruining the joke by explaining it!
I knew someone would take that bait... I just didn't think they would be that retarded. I like this 56ker ID. I should get another modem and shotgun them for the AMAZING SPEED.
KAMI!
>>219
It was so unfunny I figured you were just confused. Next time you want to make a joke, try being funny.
I always thought Hurd was a good idea. Particularly when you think of its clustering potential. Keep your kernel small and its dependancies minimal. Everything else can live in user space.
>>222
It IS funny though. GNU means GNU's not UNIX. Thus the proper response to calling GNU just like UNIX is to say that GNU's not UNIX.
>>223
Why wait? Use QNX instead!
Talking about which, I just discovered that QNX was bought out in 2004. Ouch.
UNIX is not user-friendly. But windows or macos X aren't either. Computers aren't for mouth-breathers regardless of what billy h. gates farts out of his upper orifice.
Today's catch:
_It doesn't have to be this way. Lisp programmers, for example, rarely write command line parsers because they can simply use S-expressions and use the Lisp reader to parse them. Moreover, Lisp programmers rarely have to learn new command line syntaxes for the same reason. S-expressions are a universal command-line syntax. Everything can be expressed as an S-expression.
Contrast this state of affairs with the unix command line syntax (or lack thereof). Because there is no universal syntax, the unix world is a Babel of dozens of different syntactic conventions. For example, sometimes the '-' sign is an operator (subtraction), sometimes it is a keyword indicator (the conventional command syntax), sometimes it indicates a function call (in conditionals in some shells), sometimes it denotes a range (e.g. in some regular expression syntaxes), etc. etc. etc. In lisp '-' has no special syntactic meaning. It is merely a constituent character like the letters of the alphabet._
your *board still* **sucks,** __*NIGGER*__ your *board still* **sucks,** __*NIGGER*__ your board still sucks, __*NIGGER*__ your board still sucks, __ NIGGER __ your board still sucks, __ NIGGER __ your board still sucks, __ NIGGER __your board stillyour board stillyour board stillyour board stillyour board stillfuckingyour board stillfucking_your board still*fucking**`multline
code`
`multline \
code`
multline
codeugh make a new thread if you want to continue >>1's topic