10 Things I Hate About UNIX

http://www.informit.com/articles/printerfriendly.aspx?p=424451

Everything he said, I agree wholeheartedly.

What's better than Unix and addresses all of his 10 points, /prog/?

plan 9

Losethos

>>3
I am an agreement.

I've always wondered why we don't use an executable file format that you can also link to (statically and dynamically). This way, you could make a tool called png, which can encode and decode png data. Then you have a section of the code labeled "bootstrap" or something, which is the CLI using the library. This is left out when statically linking and not loaded when loading as a library.

That way when you link with png you get their API like you would with libpng, without needing to have the png executable load the libpng library somewhere else, creating 2 files that are clearly related, with the bootstrapping bits being tiny.

>>5
exec

His Small Tools, Not Small Libraries example is awful; if every program had to do its own wildcard expansion, globbing just wouldn't have happened in any but a very few programs.
Programs that don't want wildcard expansion can use a separate syntax or insist on explicit escaping, like find. The fact that so few do shows why this should be the shell's business.

>>7
Yeah, what he's essentially saying is that each program should define its own DSL and that we should then all hope that everyone fortuitously agrees on the exact same semantics (or that users will be willing to remember the subtle differences between all of them).

It looks like this guy skimmed the UNIX-HATERS' Handbook, but hasn't given Unix nearly as much thought as he thinks he has. It has real problems, and he sort of hints at some of them (sockets, X11), but he doesn't nail a single one.

>>8
What's wrong with sockets? The POSIX API might be shit but sockets as a concept?

>>9
http://plan9.bell-labs.com/magic/man2html/3/ip

Plan 9 fixes all these problems.

>>9
You can't divorce the POSIX API from Unix. Sockets should just be files, the way Plan 9 does it.

>>11
Plan 9 addresses none of the specific complaints in the article. The thing is that the article is shit.

>>5

I want an object format that carries dependency information, so if I want to link my program to liba that requires libb I can just run LDFLAGS += -la rather than having to manually resolve the dependency on libb or use some pkg-config or autoconf or whatever.

>>8
X11 is not a Unix problem. OS X, unlike Linux, is a certified Linux and has no sign of X11.

I consider the UNIX shell to be one of the worst possible implementations of the ideal.
As opposed to what? Windows? DOS? Commodore 64? LoseThos AKA SparrowOS?

>>14
U MENA CERTIFIED UNIX, ``faggot?''

>>16
YAEH THATS WAT I MENAT

Plan 9.

>>5
What, you mean a bastardized version of 'have each tool do one thing and do it well'? You would have been on the right track if it weren't for the 'dynamic linking' and 'API' parts.

To everyone here suggesting Plan9:

http://news.ycombinator.com/item?id=447435

I suspect that none of you have actually used Plan9. Faggots.

>>19
>Plan 9 sucks
>emacs and vi and nano are not ported so it sucks
>command completion is 'an idea of Linux'
>Plan 9's text editors and plethora of tools don't 'allow you to get working on stuff'
>implying I don't use Plan 9, or Inferno, or at least one of the Plan 9 text editors every single day
Compelling argument, ``faggot''.

>>1
10 Things I Hate About UNIX
http://www.informit.com/articles/printerfriendly.aspx?p=424451
Yeah

>>7
That and he also has never used Zsh.  It would be hell to implement Zsh-style globbing in any program.  How about this:

# From the Zsh Lovers.  Removes spaces from filenames recursively.
for a in ./**/*\ *(Dod); do mv $a ${a:h}/${a:t:gs/ /_}; done
And this is one of the simpler things from that document.

>>21
Strawman much?

>>19
I suspect you should go back to le /g/

>>10,12
I don't understand why they should be files. What do you gain? What if I have an application managing a ton of connections from a lot of different peers? I quite like the file descriptor concept. Like I said the API might be bad but that doesn't really mean the concept is bad.

>>18
I mean why not make tools able to export their API like a library, so when it comes time to make a program that also needs to read png files it doesn't have to spawn a whole fucking process and redirect IO and all sorts of crap, but instead just link to the png tool (statically or dynamically), then have the linker or OS load everything except the CLI argument parsing junk.

>>13
http://en.wikipedia.org/wiki/Elf_format

>>20
I KNOW, RIGHT /
                °
When evidence shows otherwise.

>>24
What do you gain?
Oh I dunno, maybe being able to casually peek and poke at it with cat and echo? At least, this is exactly what you can do to everything in plan 9 and inferno.

>>21
Yep, the guy wants us all to waste a lot of time and effort implementing over and over what the shell should be implementing. He's either fresh from Windows, or not a programmer at all, or has simple gone through the Unix-Haters Handbook, as has been said above.

>>22
I don't think you know what the word means.

>>24
I don't understand why they should be files. What do you gain?
What you gain is a great deal of simplicity. You can write to anything with any program without making any modifications at all, and likewise read from them. You could bring a remote computer's filesystem or sound card or network connection (etc.) into your local namespace and then write to it and/or read from it. No knowledge of single-purpose, ENTERPRISE QUALITY, byzantine APIs required, and not a sockets API in sight. Just standard read/write calls.

What if I have an application managing a ton of connections from a lot of different peers?
What of it?

I mean why not make tools able to export their API like a library, so when it comes time to make a program that also needs to read png files it doesn't have to spawn a whole fucking process and redirect IO and all sorts of crap, but instead just link to the png tool (statically or dynamically), then have the linker or OS load everything except the CLI argument parsing junk.
If you're going to all that effort (there's a lot you need to know about that binary, and a billion things can go wrong) then you might as well just transplant that png reading code into your own program.

>>27
What if I have an application managing a ton of connections from a lot of different peers?
What of it?
I'm not the guy, but I think he means if there's one file handling all those connections, they can't all write to it simultaneously.
But he should know that if file <=> socket, there should be one socket per connection, and therefore one file per connection.

>>28
POSIX sockets can't do that either.

>>27
Just standard read/write calls
Yeah, you can use sockets that way too. Damn you suck.

Yeah, like Microshit is so much better

Unix has not evolved in decades, it stuck itself in a dead end with its shoddy "design".

And it's not about 10 things to hate or the number of WTF's joted down in the UGH, before the authors lost interest. Because everything in Unix is idiotic and there are no exceptions.

>>32
This man speaks an unencumbered truth free from the Stockholm Syndrome. He is truly a free man among indentured slaves of the old.

>>31 microshit is closer to UNIX than you think.
>>32 Then what would be better design, faggot?

The only real issue on the list that causes me the slightest concern is the in-band signaling. The way it applies to hidden files is a non-issue, but C's reliance on sentinel values is less than perfect.

>>35
Out-of-band signalling is no less common in Unix than in other operating systems. His examples are nonsense.

ITT: denials.

>>30
Yes, I know that sockets are seen as file descriptors in Berkeley sockets. That is flexible within your program, but not in the system as a whole.

Let me word the previous post better: you can send the stdout/stderr of a program to a file, and that file can be anything you want it to be, so long as that abstraction has been implemented as a fileserver; a socket, another computer's filesystem, a DVD burner, a WORM cache, another computer's network card, all of these things already have user-space fileservers written for them. Everything is a file. The ability to pipe programs together _as well as_ the ability to send and receive remote things straight through the standard input and output of those constituent programs is flexible indeed.

>>36
In-band signaling is still bad, and C has that same problem on all systems of course. But don't forget that C is a Unix thing and Unix is a C thing.

>>27
>>28
I can make a socket file (under linux at least), or I can choose not to. I don't however want sockets that are private between two processes to exist in a pseudo-filesystem. Especially if I have 100's of them.