Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unix Philosophy

catb.org

Post reply on HN
Print view View original

211–220 of 269 posts

Re: The Unix Philosophy

#211

Post by coldtea »

c22 wrote: post #205
coldtea wrote: post #180

Earlier quoted context omitted.

> You are conflating a property of the claim itself (violating the laws of physics) with a straw-man property of the person making the claim. They aren't the same thing - one enables a simple proof by contradiction, the other is ad-hominem. I don't see why you think I haven't considered that. My whole argument is based on the idea that ad-hominens are pefectly fine in some cases. When? For people with a bogus claims…

I'm going to dismiss everything you have to say because it doesn't look like you know how to properly respond to threads when there's a comment cooldown timer.

>I'm going to dismiss everything you have to say

Feel free!

>because it doesn't look like you know how to properly respond to threads when there's a comment cooldown timer.

I actually do, but am too lazy to click on the message to open alone...

Re: The Unix Philosophy

#212

Post by munificent »

ajross wrote: post #96
fauigerzigerk wrote: post #32

I keep wondering about what seems to be the most important component of Unix philosophy: write many small programs that do one thing well and interface using text streams! Yes, modularity is important. However, in some cases, this philosophy has resulted in the "tangled mess held together by duct tape" kind of systems architecture that no one dares to touch for fear of breaking things. I think Unix philosophy is stru…

> in some cases, this philosophy has resulted in the "tangled mess held together by duct tape" kind of systems architecture that no one dares to touch for fear of breaking things. Pretty much, just as Booch's philosophy has given us tangled messes of class hierarchies with cross references pointed every which way. And just as The Gang of Four gave us AbstractedTangleMessFactorySingleton. The distinction with the Unix…

> And just as The Gang of Four gave us AbstractedTangleMessFactorySingleton.

The Gang of Four didn't give us that. An army of OOP novices who were overwhelmed by all of the new choices and only skimmed Design Patterns gave us that.

If you actually read the book (which surprisingly few people have, given the number of people who have strong opinions about it), you'll see the Gang of Four are actually quite clear on the limitations or and ways to abuse the patterns.

Re: The Unix Philosophy

#213

Post by alkonaut »

pdkl95 wrote: post #97
alkonaut wrote: post #75

Earlier quoted context omitted.

Exactly. That's one of the biggest problems with text-only interfaces.

Maintaining IPC/RPC as text has the significant advantage of keeping the programs involved honest, approachable, and easier to debug. Just being able to see the interface by running the program (or reading the config file) makes it a lot easier to learn[1], and bugs in text formats can often be seen visually (or marked in an editor). The alternative - binary structures - require complex data definitions where you hav…

"Text" in a computer is bytes + metadata about those bytes. Without that metadata, it's just bytes. Exactly that is what unix pipes are: a streams of bytes, not streams of text.

Ironically, the tools that are happiest about these streams are of course those tools that don't care about text but just stream bytes. The pain occurs when the tools actually need to parse the text.

I would agree much more with the unix design, and think it was a much better implementation of the unix philosophy, if the glue layers were strictly specified or demanded that programs could negotiate things like encodings.

Somewhere between "just bytes" and "binary structures" there has to be a reasonable simple format for program communication. Structured text, or text with a small metadata header (like BOM, but done right) for example.

Re: The Unix Philosophy

#214

Post by deckiedan »

sanderjd wrote: post #167
deckiedan wrote: post #120

Earlier quoted context omitted.

Surely a lot of that could be done with a commandline switch? tape_robot start -tapeid=1 as the quick hacky version, and: tape_robot --protobuf 'msg:start;tapeid:1' (replace the 'single:quote;string:thing' with your protobuf message.), or tape_robot --protobuf_file filename The filename could be a fifo or socket, of course. Then use a general purpose server which runs the programs: proto_serve tape_robot 127.0.0.1:80…

Interesting. This seems very non-unix-y to me. The `tape_robot` doesn't "do one thing", it does many things, including parsing protobuf from shell strings and files, which seems error prone and way outside its core competency.

Maybe I misunderstood @jalfresi's idea - as I understood it, it was that each command would do not only parse protobuf and unix style flags, but also contain a RPC server of some sort.

My reinterpretation was to say how about factoring out the server part, and leave the command only understanding either flags or protobuf commands - which could be delivered to the command either as an arg, or as a file given to it by an arg.

You could go a stage further by having all commands only accept protobuf (or similar), and distribute a spec/human-mapping to go with it. Then your shell would parse the args that you give to the command using the spec, and actually call the command using protobuf.

This would allow very awesome shell completion / highlighting / etc. It should also allow much simpler end-point/commands, as they'd not have to do hardly any type checking / re-parsing, as it would arrive in protobuf.

I actually kind of like that idea. Hmm...

Re: The Unix Philosophy

#215

Post by adrusi »

el33th4xx0r wrote: post #29

I wonder how relevant is it nowadays. Many good things we can't have, like systemd, if we have to follow strictly to the unix philosophy.

No. Systemd isn't ununixy because it has to be, it's ununixy because that's the way it was written. It's superior to System V style init IMO, but it got that way in spite of its poor monolithic design, not because of it.

Re: The Unix Philosophy

#216

Post by nickpsecurity »

alfiedotwtf wrote: post #2

People will hang shit on ESR, but The Art of Unix Programming is one of my all time favourite books. If you haven't read it, even if you're not a *nix developer, do yourself a favour and just skim the table of contents... something may pique your interest and you may learn a thing or two. It's also free online: http://www.catb.org/esr/writings/taoup/html/

Thanks for the book. Unlike most UNIX fans, he's unusually honest in his critiques of it and even references material from UNIX Hater's Handbook haha. His comparisons to other OS's are fair except for the robustness of VMS: main reason many companies kept using it despite its uncertainty. Downloading it to re-read and see if I find some more enlightenment as a system designer.

Re: The Unix Philosophy

#217

Post by [deleted] »

anewhnaccount wrote: post #156
spiralpolitik wrote: post #119

Earlier quoted context omitted.

The Gang of Four book recommends "composition over extension" which fits neatly into the UNIX philosophy of building things by composed of smaller independent programs. The main issue that most of the common programming languages in use notably Java and C++ have very poor support for composition thus forcing developers to have to extend things.

Can you explain how exactly Java and C++ have poor support for composition? Classes can have member variables in both languages. What else is there?

[deleted]

Re: The Unix Philosophy

#218

Post by nickpsecurity »

marcosdumay wrote: post #192
thinkmoore wrote: post #175

The Unix Hater's Handbook ( https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook ) has a few sections on of some of the ills of the Unix philosophy.

The UNIX Haters Handbook shows its age, it's criticizing a system that has only a passing similarity with modern unixes. But yes, it's funny.

Nonetheless, the specific examples show the UNIX system contradicted many of the supposedly "UNIX" principles. The article seems a bit revisionist in a pro-UNIX way in that sense. Unsurprising.

Saying that these are modern UNIX principles might be more fair. Yet, Kemp's article inspires doubt in even that:

http://queue.acm.org/detail.cfm?id=2349257

Re: The Unix Philosophy

#219

Post by [deleted] »

jebblue wrote: post #200
fauigerzigerk wrote: post #145

Earlier quoted context omitted.

Absolutely, but that doesn't mean we shouldn't try to make some progress. I think we have actually made progress with HTTP and all the REST. But I feel that the great failure of distributed object systems in the 1990s and 2000s has left a great void when it comes to new thinking about more fine grained sort of interfaces between programs. Functional programming has influenced so many things but hasn't really arrived…

REST is a kludge but it's easy. SOAP as much as I dislike giving Microsoft credit was brilliant, but it was hard.

[deleted]

Re: The Unix Philosophy

#220

Post by juliangregorian »

jebblue wrote: post #200
fauigerzigerk wrote: post #145

Earlier quoted context omitted.

Absolutely, but that doesn't mean we shouldn't try to make some progress. I think we have actually made progress with HTTP and all the REST. But I feel that the great failure of distributed object systems in the 1990s and 2000s has left a great void when it comes to new thinking about more fine grained sort of interfaces between programs. Functional programming has influenced so many things but hasn't really arrived…

REST is a kludge but it's easy. SOAP as much as I dislike giving Microsoft credit was brilliant, but it was hard.

How is REST a kludge and SOAP not?
Post reply on HN