Linked by Thom Holwerda on Fri 25th May 2012 14:55 UTC
General Unix James Hague: "But all the little bits of complexity, all those cases where indecision caused one option that probably wasn't even needed in the first place to be replaced by two options, all those bad choices that were never remedied for fear of someone somewhere having to change a line of code... They slowly accreted until it all got out of control, and we got comfortable with systems that were impossible to understand." Counterpoint by John Cook: "Some of the growth in complexity is understandable. It's a lot easier to maintain an orthogonal design when your software isn't being used. Software that gets used becomes less orthogonal and develops diagonal shortcuts." If there's ever been a system in dire need of a complete redesign, it's UNIX and its derivatives. A mess doesn't even begin to describe it (for those already frantically reaching for the comment button, note that this applies to other systems as well).
Thread beginning with comment 519423
To read all comments associated with this story, please click here.
Levels of design
by jessesmith on Fri 25th May 2012 15:16 UTC
jessesmith
Member since:
2010-03-11

I don't think it's the underlying design of UNIX that needs to change so much as the applications layered on top of it. The userspace stuff. In contrast with other operating systems it's often the other way around, where the userspace apps and controls are well designed and mesh together, but the underlying system is often a mess.

Reply Score: 10

RE: Levels of design
by piotr.dobrogost on Fri 25th May 2012 15:57 in reply to "Levels of design"
piotr.dobrogost Member since:
2011-10-04

Totally agree. Just see TermKit (http://acko.net/blog/on-termkit/) to see how terminal should look like.

Reply Parent Score: 2

RE[2]: Levels of design
by kwan_e on Fri 25th May 2012 16:11 in reply to "RE: Levels of design"
kwan_e Member since:
2007-02-18

Totally agree. Just see TermKit (http://acko.net/blog/on-termkit/) to see how terminal should look like.


All I see is yet another GUI/DE replacement that runs in its own window.

A new broom sweeps clean, but new brooms becomes old brooms in short time.

Reply Parent Score: 3

RE[2]: Levels of design
by AlephZero on Mon 28th May 2012 07:48 in reply to "RE: Levels of design"
AlephZero Member since:
2011-07-12

That's the heaviest site I've ever visited.
I hope that the whole "HTML5 + JS + CSS3 (+ webGL + ...)" stuff will not be worse than Flash in terms of CPU usage

Reply Parent Score: 1

RE: Levels of design
by zima on Fri 25th May 2012 16:46 in reply to "Levels of design"
zima Member since:
2005-07-06

In contrast with other operating systems it's often the other way around, where the userspace apps and controls are well designed and mesh together, but the underlying system is often a mess.

What? "Other operating systems" (at least where the userspace apps and controls are distinct enough to warrant talking about them like that; embedded OS are really outside of it, as are hobby OS) basically means... Windows - not much of anything other non-*nix around.

And the underlying system in that case, NT kernel and its immediate surroundings, is hardly a mess... seems to be less of a mess than typical *nix, actually.
(plus OTOH, I wouldn't really call win apps "well designed and mesh together" - they, and the compromises forced by them, are the real reason for poor reputation of Windows)

Reply Parent Score: 7

RE: Levels of design
by whartung on Fri 25th May 2012 16:52 in reply to "Levels of design"
whartung Member since:
2005-07-06

It's easy to complain that Cygwin doesn't follow the Windows philosophy, but that's not a commentary on the benefits or shortfalls of windows. Nor is it representative.

Its not representative to say that a Java Application Server is "not Unix". I mean, of course it's not Unix - It's Java. Java brings along it's own virtual machine world that's different from Unix (or Windows, or anything else).

The JVM is less "in your face" about it's differences than, perhaps, cygwin is on Windows, or some other virtual machine environment running on top of Unix (such as an MV emulator to run legacy IBM applications). But it's certainly different.

The fundamentals of Unix came to life before the interconnected world of network computing became dominant. Even still, systems such as inetd and HTTP CGI made publishing pipelines trivial.

The fundamental issue today with the Unix model is simply its inefficiency. Chaining heavyweight processes has costs, high enough costs that it's worth going to a different dedicated model, a model that foregoes the simplicity and safety of the classic Unix system.

Combine that reality with the stark difference of the GUI event/window model to the command line process pipelining model, and it seems as if there is "less Unix in Unix". Where Unix becomes simply a process loader rather than a component toolkit.

Java and database servers are the worst offenders here. A good app server deployment is one that dedicates the vast majority of system resource to a singular JVM instance. A dedicated DB deployment is the same kind of thing. Why leave free memory for generic file buffers when they can be better used for dedicated internal database pages, since it's doing all of the I/O anyway.

But contrast those to a classic php_mod server on top of the legacy Apache forking model. That's almost a pure Unix design. Process safety, effectively a stdin -> stdout processing chain. Embedding PHP in to the Apache server saves the process pipeline an extra fork and exec, along with the associated startup and resource costs. But process protection means that one connection can't kill Apache, can't kill the machine, can hardly kill anything.

While started by Apache, the OS still has a say and can control that process. Too much memory? Kill it. Too much disk? Kill it. Too much time? Kill it. Kill it now, kill it safely. Recover cleanly. Services the OS can provide, wheels I as a designer and developer don't have to reinvent.

Today, folks are not stacking processes in pipeline as much any more as they are stacking entire machines and sticking them together via the network. VMs are the unit of work today, which makes much of the Unix philosophy unnecessary. Back in the day, Processes were cheap and ubiquitous enough to create and kill on demand for the most trivial of tasks. VMs aren't quite that cheap, but designers are to the point where they're considering them that way. While not as cheap as processes, they're getting cheaper on their own every day.

Now the Unix philosophy is transcending the operating system itself.

Reply Parent Score: 4