The Unix Philosophy

http://www.catb.org/esr/writings/taoup/html/ch01s06.html

by dorsatum • 11 years ago

353 256 11 years ago

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/

jumblesale• 11 years ago

It's a really great read and did a lot to inform my approach to writing all kinds of software. It's a shame that I cringe to recommend in now due to the politics of its author.

yarou• 11 years ago

That's really bizarre. A person's political views have no bearing on the validity or usefulness of what they write.

spiralpolitik5• 11 years ago

Personally I found it disappointing as it seemed to take the view that the only UNIX in existence since 1992 has been Linux.

A better title would have been the Art of Linux Programming or the Art of Open Source Programming.

davidgerard9• 11 years ago

This book is ESR's masterwork, and that's taking into account everything else he's done.

tobik• 11 years ago

Thanks. PDF version is here: http://www.catb.org/esr/writings/taoup/html/graphics/taoup.p...

bcg12• 11 years ago

Chapters 1 and 2 (Philosophy and History) are required reading for all junior devs and aspiring hackers.

larrys• 11 years ago

"People will hang shit on ESR"

An example "Reading it, it looks like a total hack job by a poor programmer."

https://news.ycombinator.com/item?id=923660

yummyfajitas3• 11 years ago

That's not hanging shit on ESR, that's just a valid critique of poor code.

A better example might be this post, where ESR is implied to be racist when his actual post is a reflective one about correcting irrational racist reactions: https://news.ycombinator.com/item?id=6884767

nickpsecurity3• 11 years ago

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.

hitlin37• 11 years ago

in case of mankind extinction, we should preserve the above text and pass it on to the next race.

digi_owl2• 11 years ago

the rule of separation makes me wonder if the long term legacy of Wayland will be as a hardware accelerated backend for X.

jkot2• 11 years ago

X as a protocol is long gone. Direct memory access, kernel drivers etc are not really compatible with network protocol. Wayland is just streamlining and formalizing current situation.

umanwizard• 11 years ago

At my old job (which I left about ten days ago) I ran X servers and clients on different machines daily. Typical example was running my IDE on my desktop, connected to an X server running on my laptop.

pdkl954• 11 years ago

Nonsense - I use it all the time, as do many other people I know. It is mostly GTK+ and Qt that badly misuse the protocol by rending everything client side. (OpenGL is it's own world, and works with X just fine, even remotely)

jokoon3• 11 years ago

This should be taught in any programming class.

Rule of Diversity: Distrust all claims for “one true way”.

Although, does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ?

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

I wonder what rob pike has to say about OOP or java, I wish I could listen to it.

Also it says that text is a good representation of data, but I think he meant it as intermediary. I don't think xml or html are really good choices when you see all the CPU cycles spent parsing those.

Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

I prefer this rules versus the "no premature optimization" rule.

mtrn• 11 years ago

I wonder what rob pike has to say about OOP or java, I wish I could listen to it.

12 minutes where Pike talks about a few things, that seem to be wrong in our software world: https://www.youtube.com/watch?v=5kj5ApnhPAE

olavk• 11 years ago

Perl is arguable much closer to the Unix philosophy than Python, for better or worse. That said, the "One obvious way" in Python is not exactly the same as "Only one true way".

vmsisbetter2• 11 years ago

Rob Pike doesn't know Smalltalk, Self, or Common Lisp/CLOS--why should you care what his opinions are concerning OO as a paradigm?

fao_• 11 years ago

Most developers touting OOP don't know those languages; so why should we care what their opinions are concerning OOP as a paradigm.

If you exclude one person because they disagree with X and don't know Y, then you must equally disregard all who agree with and disagree with X, because they don't know Y. Otherwise you're just cherrypicking :)

mseepgood2• 11 years ago

He definitely knows Smalltalk and Lisp

pjmlp4• 11 years ago

Funny how HNers have such a high regard for his opinion on a domain he is well known for being sceptical and yet disregard his opinion, as UNIX co-author, that UNIX is well past its due date and is time to move on.

AdieuToLogic• 11 years ago

<voice type="Lucky Charms Leprechaun"> That's magically elitist! </voice>

bad_user2• 11 years ago

does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ?

The irony is that Python has more ways of doing things in general and often the choice is very much non-obvious, compared to a language like Ruby which is supposedly embracing TIMTOWTDI. In other words, that Python rule doesn't match reality and I've always found it funny.

tonyedgecombe• 11 years ago

I thought the opposite for Ruby, for instance all those aliased methods on classes.

paddyoloughlin• 11 years ago

Is it the Python language or the Python ecosystem you are referring to?

The statement in question is from The Zen of Python and is more of a guiding principle for the design of Python than a rule.

The usual observation with Python is that it can have many libraries and frameworks which are quite similar and choosing one can be hard (e.g. web frameworks). This is a function of popularity and not something which can fairly be subject to that principle.

On a different note: missing is the Zen of Python's following line:

  Although that way may not be obvious at first unless you're Dutch.

coldnebo• 11 years ago

The rule of composition is an important counterpoint to the rule of diversity. Unix's most important feature is treating everything as a file. That interface allows a lot of freedom in composition, but every process has to conform to exactly the same interface. Perhaps not surprisingly, TCP's stream-based interface has also allowed a great deal of freedom in composition in networks.

logicchains• 11 years ago

I wonder what rob pike has to say about OOP or java, I wish I could listen to it.

“object-oriented design is the roman numerals of computing.” - Rob Pike (http://harmful.cat-v.org/software/OO_programming/)

Some other gems from that page:

“Object-oriented programming is an exceptionally bad idea which could only have originated in California.” – Edsger Dijkstra

“The phrase "object-oriented” means a lot of things. Half are obvious, and the other half are mistakes.“ – Paul Graham

“I used to be enamored of object-oriented programming. I’m now finding myself leaning toward believing that it is a plot designed to destroy joy.” – Eric Allman

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” – Joe Armstrong

jokoon3• 11 years ago

I would love to throw those quote at any programming class that promotes OOP.

amyjess• 11 years ago

“object-oriented design is the roman numerals of computing.” - Rob Pike

Which is weird because Pike's Rule 4 is one of the fundamental principles of OO design.

wvenable• 11 years ago

When I see the never end complaints about object-oriented programming, I'm reminded of Bjarne Stroustrup's quote "There are only two kinds of languages: the ones people complain about and the ones nobody uses." I think that applies equally well to software design concepts.

marcosdumay3• 11 years ago

Although, does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ?

Nope, that's a design guideline, it's not taking choice away. A rule like "Python is the only language you'd ever need" would contradict it.

spiralpolitik5• 11 years ago

I think you'll find your answer to the Rob Pike question by using The 'Go' Programming Language

nkassis2• 11 years ago

"Although, does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ?"

I don't think so. To me Python's design rule implies there should be one way clear path to solve a specific problem and generally you'd also want to stay as consistent as possible with other similar solutions.

The "one true way" argument is to force everything to fall into a pattern even when it's a less than ideal way to solve a problem. An example would be trying to force everyone to use the same language/database/framework combination in a company for everything. Sometimes you want to be flexible and use the right tools for the job (while also accounting for the cost of deviating from the general accepted standard in making that decision).

mseepgood2• 11 years ago

I wonder what rob pike has to say about OOP

https://talks.golang.org/2012/splash.slide#55

https://talks.golang.org/2012/splash.slide#56

https://talks.golang.org/2012/splash.slide#57

From this talk: http://www.infoq.com/presentations/Go-Google

jkot2• 11 years ago

How debacles such as micro-kernels and XServer fits into Unix Philosophy?

grymoire1• 11 years ago

Sun had the NeWS windowing system before XWindows. Be glad that did not become the standard. Be very glad.

arethuza3• 11 years ago

I rather liked NeWS - certainly it was a lot more fun to develop for at that time than X and had some wonderful UI toolkits (particularly HyperNeWS).

For example, being able to draw a shape in a a graphical editor and then paste the shape directly to a window as the shape that window should take was rather cool - and this was in the early 90s!

nickpsecurity3• 11 years ago

Easy: a number of microkernel-based systems today actually have the properties UNIX pretends to. And to the core.

el33th4xx0r• 11 years ago

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.

userbinator• 11 years ago

For a lot of people, the set of "good things" does not include systemd.

vezzy-fnord3• 11 years ago

Not to mention you can certainly get feature parity with systemd while still being Unix philosophy-robust. See the nosh service manager.

TickleSteve• 11 years ago

The principle stands just as it always has.

The Single responsibility Principle (SRP), interfaces, cohesion and coupling are all relevant patterns and techniques that also describe the same design ideas.

The UNIX philosophy is simply one example of the above principles implemented at a user interface level, but they apply equally well in low-level embedded code, and device drivers just as well as in desktop and server land.

Software complexity grows exponentially with the number of internal interactions. by reducing the scope of any given module, you greatly simplify it. Thinking about, designing and implementing fixed interfaces between small cohesive modules helps this process and you get much more simple (as in the Rich Hickey sense) software as a result.

These same principles pop up all over the place in software, the Unix Philosophy, SRP, Microservices... they're all manifestations of the same thing.

spiralpolitik5• 11 years ago

Sure you can. See 'launchd' on OSX.

The reason that 'systemd' is the ball of mud it is that Linux being just a kernel does not provide the basics for systemd to build on so it has to provide them itself.

vezzy-fnord3• 11 years ago

The main service management-related components of systemd very much exploit the Linux kernel's facilities, so your claim is completely incorrect.

The broader tools that systemd also provides (stub DNS/LLMNR resolution, network management [DHCP, PPP...], container registration, message bus introspection and library, event loop library, EFI stub loader, device and mount management, hardware database, TTYs, NSS plugins, session and seat management, SNTP client, time/date control, dynamic configuration population, etc.) exist mostly for philosophical reasons of being a one true toolkit/middleware that sits between GNU and Linux.

launchd isn't Unix-y at all, anyway.

adrusi• 11 years ago

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.

zvrba3• 11 years ago

The ‘Unix philosophy’ originated with Ken Thompson's early meditations on how to design a small but capable operating system with a clean service interface.

Except that a program-to-program interface based on formatting and parsing text is anything but clean.

mbrock• 11 years ago

What do you mean by "text"?

alkonaut2• 11 years ago

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

zvrba3• 11 years ago

Semi-rigid, informally specified output meant for easy inspection by humans. The output of `ifconfig -a` for example. (That's the worst offender, most other commands have a better-formatted output.)

As a general rule of thumb: if you have a command pipeline that would break because programs in it handle locale differently, it's most definitely text-based program.

I like the idea of Power shell: programs pipe formatted (binary) objects between them, and there exist commands to print them out in a nicely formatted way to the terminal. But it's objects. I can extract information through named fields instead of through magic indexes and regexpes in awk/sed/perl oneliners.

IOW, proper object (meta)model, not sucky text streams. Text is great for long-term storage, but awful for data in flight. UNIX ignored this distinction and decided to use text for everything.

nwmcsween• 11 years ago

I thought the same but what are the alternatives? Use a format like json? What happens when the format can't express what I want? The other issue is the output is now deeply intertwined with the program because it's now an API, although the same could be said about text output.

ben11kehoe• 11 years ago

PowerShell gives a good alternative: the things passed between the programs should be objects. It requires, of course, that everything is communicating with a common runtime, but for a shell that is not the biggest burden.

fauigerzigerk3• 11 years ago

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 struggling with a fundamental dilemma:

On one hand, creating systems from programs written by different people requires stronger formal guarantees in order to make interfaces more reliable, stronger guarantees than interfaces within one large program written by one person or a small team would require.

On the other hand, creating systems from programms written by different people requires more flexibile interfaces that can deal with versioning, backward and forward compatibility, etc, something that is extremely difficult to do across programming languages without heaping on massive complexity (CORBA, WS-deathstar, ...)

I think HTTP has shown that it can be done. But HTTP is also quite heavy weight. It doesn't exactly favor very small programs. Handling HTTP error codes is not something you'd want to do on every other function call.

In any event, I think Unix philosophy is a good place to start but needs a refresh in light of a couple of decades worth of experience.

lmm• 11 years ago

The big problem I've found is serialization of sum types. thrift (or protobuf or any number of similar systems) is very good at serializing most of the data one tends to work with, with declarations that are suitably strict but easy to write. But it doesn't have a good way to represent "this field is an A or a B".

nly• 11 years ago

Thrift has unions, so does Apache Avro. Afaik Protocol Buffers is the only one where you have to string together one yourself with a required tag and a bunch of optionals.

coderjames• 11 years ago

Protobuf has somewhat recently added the 'oneof' feature which tries to deal with these union types.

The one downside I found when trying to use it was that the 3rd-party C# Protobuf libraries didn't yet support it.

See: https://developers.google.com/protocol-buffers/docs/proto#on...

justwannasing2• 11 years ago

Are you saying you disagree with the use of subroutines, functions and interfaces? After all, they are essentially small programs that do one thing and do it well.

cousin_it3• 11 years ago

Note the part about text streams in fauigerzigerk's comment. If all functions were limited to accepting a text stream and returning a text stream, the overall program would quickly become a ball of mud.

fauigerzigerk3• 11 years ago

No, I don't disagree with the use of functions or interfaces at all, but functions in particular are a programming language construct and as such not easily extended across programming languages, processes and networks, mostly due to different type systems and error states.

I think it's not an accident or historical vestige that Unix philosophy uses the word "program". It has technical as well as social implications that have barely changed in the past 50 years.

Functions and programs are certainly not an either-or kind of thing but making them one and the same would require a very different kind of operating system than we have ever seen. Say, emacs OS :)

jalfresi4• 11 years ago

Recently I've been exploring the idea that small programs should consist of two parts; a "backend" that you can communicate with via a strict message protocol like protobuf. It can handle multiple requests because it is a mini server, the message format is locked to a "type" and you communicate with it via RPC.

The second part is a "frontend", a command-line client that does all the unixy stuff with text streams etc; but is just another RPC client to the backend.

This provides flexibility; for quick duct-tape situations you use the front end and pipe anf ilter to your hearts content. Then when stuff needs to get serious, you can bypass the command-line front end and connect directly over RPC using a strict message format which has the ability to handle a couple (doesn't have to many) of concurrent requests.

Of course this is early doors yet, but I think it might have legs in the flexibility in the text streams/hard message format debate, for very little additional work.

fmoralesc2• 11 years ago

Incidentally, this is what neovim does.[1]

[1] http://neovim.io/doc/user/msgpack_rpc.html#msgpack-rpc

deckiedan2• 11 years ago

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:8080

or whatever.

This (to me) is closer to the unix idea - one server program, one actual processing app. Why should my tape_robot program actually have a server embedded in it?

If in the future, I want to add authentication, I only have to add it (once) to the proto_serve program, rather than to every single application that is a 'server', for instance.

It would also allow a version which 'pre-forked' the processes, and left them waiting for the data on the socket/filehandle, or whatever.

You could do a bunch of this already using nc or similar, I suspect.

forgottenpass2• 11 years ago

You're sort of describing the design idea common in unix-y areas to build libfoo that does all the work, then a foo frontend that makes tasks useable from the command line. I don't know how widely used this model is, but it's certainly out there.

The difference is that in what I've described, the ABI is the common interface and an RPC server would be just another consumer of the library.

JadeNB• 11 years ago

I like this idea! It seems very Unix-philosophy-y (sorry) itself; break up the programme even further, from "do one thing" to "figure out what to do" + "do it".

batou• 11 years ago

A lot of people don't know this but that's pretty much how Windows actually works underneath everything (DCOM, RPC, pipes etc)

blakeyrat• 11 years ago

That's how a lot of well-designed software works, including Windows (in general) and old-school Mac Classic with AppleEvents (not sure if OS X still does that.)

kanzure• 11 years ago

Recently I've been exploring the idea that small programs should consist of two parts; a "backend" that you can communicate with via a strict message protocol like protobuf. It can handle multiple requests because it is a mini server, the message format is locked to a "type" and you communicate with it via RPC.

Well there was an implementation of something like that, see https://en.wikipedia.org/wiki/DCE/RPC

or DCOM, https://en.wikipedia.org/wiki/Distributed_Component_Object_M...

then there was dcop, dbus, and a bunch of others and now nobody remembers what the goal was

ajross2• 11 years ago

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-style pipe mess is that it exists and works an order of magnitude faster than other examples of bad code.

jbooth• 11 years ago

Additionally, it's not a religion. Every programmer should be exposed to Unix style programming just like every programmer should be exposed to functional programming. 100% purity in either case is just creating unnecessary problems.

ak39• 11 years ago

And just as The Gang of Four gave us AbstractedTangleMessFactorySingleton.

Hey, not funny. I actually googled that pattern just to make sure it was a joke.

spiralpolitik5• 11 years ago

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.

fauigerzigerk3• 11 years ago

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 in the systems corner of the world yet. Also, looking at the sort of query capabilities of online streaming databases and complex event processing systems I get the feeling that there may be a lot of potential in combining that with Unix pipes and text streams.

Publish-subscribe ala zeromq is also something that could be a core part of modern Unix.

Sorry about the half-baked mess I'm dumping on you here :)

munificent2• 11 years ago

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.

marcosdumay3• 11 years ago

For a while, Linux mostly had the philosophy that your software should come with a text interface, optionally a GUI, and a C library. That library part is for solving the messes created by tangled text interfaces.

But nowadays lots of things only come for the GUI.

mjevans• 11 years ago

A lot of those are actually just task specific business logic style applications in scripting languages (often python, sometimes perl, etc).

In this case the 'library' is often the base programming language it's self, as the shipped parts are entirely glue and configuration.

eli_gottlieb3• 11 years ago

On the other hand, creating systems from programms written by different people requires more flexibile interfaces that can deal with versioning, backward and forward compatibility, etc, something that is extremely difficult to do across programming languages without heaping on massive complexity (CORBA, WS-deathstar, ...)

Personally, I think the LLVM project shows what the Right Thing is here: package most of the real functionality into libraries while putting the user interfaces into runnable programs. Everyone who wants to communicate with the functionality can just link the library.

And if we want to do it statefully, well, handling global state across a large system is basically the unsolved problem of programming.

JustSomeNobody• 11 years ago

Anyone can make a mess of anything if they are not sufficiently careful. This is not unique to nix.

Personally, I enjoy the nix philosophy of using small programs that do one thing well. Also, I prefer text to proprietary binary formats that _I_ can't do anything with.

As a *nix and Windows developer, I've never understood the mentality of wanting to build huge monolithic applications. But, I do think the tide is turning. I think more and more developers are allowing themselves to be influenced by ideas outside of what they are used to and that's a great thing.

0xdeadbeefbabe• 11 years ago

It's your viewpoint that makes you think it becomes a mess of duct tape and not some failing of the philosophy. To improve the philosophy you look outside the box not inside it i.e. not at http. Something like, "everything is a file" is an improved philosophy (but I'm cheating of course because I know this is a plan9 philosophy to improve upon unix).

webkike• 11 years ago

I think maybe the Unix philosophy applies to programs that users (read: programmers) use in their own time, and to make other programs.

contingencies2• 11 years ago

Unix philosophy is a good place to start but needs a refresh in light of a couple of decades worth of experience.

It's always going to be a good place to start because it embodies a realistic, documented, proven and actionable compromise between engineering purity (the "formal guarantees" you describe) and just shipping something.

For a collection of related thoughts, not limited to traditional unix philosophy but still unix philosophy-centric, check out my ansified fortune clone @ https://github.com/globalcitizen/taoup

sytse2• 11 years ago

When making a microservice application you have to choose between a text (JSON) or binary (Thrift) interface. You cloud argue that the unix way is to make it JSON until it becomes a performance problem.

ajtulloch• 11 years ago

This is a false choice - you can serialize/deserialize Thrift objects to/from JSON. I think the choice here is between having a clearly-defined /schema/ or not.

sytse2• 11 years ago

Thanks for the insight.

coldtea6• 11 years ago

You could argue that the unix way is to make it JSON until it becomes a performance problem.

I'd argue that the unix way is to make it JSON until it becomes a performance problem by which time the format is so entrenched in so many programs and since there's no real central coordination, you just get to live with it.

coldtea6• 11 years ago

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

Which means that no program is more un-UNIX-y than Emacs...

rekado• 11 years ago

Emacs is a collection of separate Elisp programmes that all cooperate and share data structures. You would not call Unix tools un-UNIX-y only because they all share procedures from the C library.

Emacs also interfaces with external processes (e.g. using comint mode). It's the ultimate bottle of glue.

agumonkey• 11 years ago

Because Emacs is a system of its own, the Lisp Machine legacy leaked too much. Inside of emacs many things are tiny components, after all it's a lisp, which had a stronger unixy feel than so many things since. I mean lambda, compose, map... hard to separate concerns more than that.

brudgers• 11 years ago

Emacs is an example of a complex application written consistent [more or less] with the Unix philosophy. One might argue [anything, it's the internet after all] that Emacs four decade shelf life demonstrates the robustness of its embedded Unix philosophy [at the risk of being a bit circular].

Where it butts against contemporary practice is in places like threads where it is still not proven that YAGNI doesn't apply.

oldpond• 11 years ago

Can't upvote this enough. My takeaway from this gem is that we need to keep thinking about our craft even as we evolve our technologies, and we need to have the courage to stand up for it. The hardest thing in the world to see is your own point of view because you have to step outside of it to see it.

McElroy• 11 years ago

At my place of work, we have a client relationship to a company like ours in a neighbouring country. They develop a software that is of much use to us so we pay a license to them for it. They are nice people but god damnit, there is one thing they just never got right. They only support one platform, one that is certified UNIX, yet no matter how severe an error, their cli tools and scripts exit with 0 no matter what. I'm the guy who writes some smaller tools and scripts on our side integrating with their software so you probably understand why I get a bit upset about this at times. Still, I enjoy my work and as I said they are nice people and also they are a quite small team so I don't want to burden them with these concerns when there are other things that our company need from them more.

Anyway, I've been with my company for a few years and soon my contract expires and I'm going to study the field our company is in and get a degree in that, then I'm going to apply for a position doing our core business. I would still like to be involved with the software my current position is touching on, though, if possible. (Our company has 1000+ employees and several different sub-sections, so even though I might get back into the company, it's not a given that I'll be working with the group of people I am now even though I'd like to.)

I also sometimes think that if possible, perhaps I'd like to work for that other company in our neighbouring country for a few years and be on the dev team of the software. After all, I have experience from the user side which the dev team has not and the dev team has seen some of the tools I've made and a couple of the guys seemed to think that some of that stuff was pretty decent.

JoeAltmaier3• 11 years ago

This can be a very good fit. Smart companies hire their customers' best engineers with the most familiarity with their product. The best, smartest feedback comes with that package.

thinkmoore2• 11 years ago

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.

marcosdumay3• 11 years ago

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.

thinkmoore2• 11 years ago

Agreed, I posted mostly for the humor, though there are some grains of truth there still.

nickpsecurity3• 11 years ago

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

Fenume• 11 years ago

Agreed. Modern unixes are a lot worse.

The Unix Philosophy

Related Stories