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

The Collapse of the Unix Philosophy

kukuruku.co

Post reply on HN
Print view View original

561–570 of 616 posts

Re: The Collapse of the Unix Philosophy

#561

Post by vram22 »

fstephany wrote: post #400
vram22 wrote: post #170

Earlier quoted context omitted.

Interesting comment. Got to say I agree with the direction of it, to some extent - stable and powerful over newfangled and weak / unstable / buggy / done for glory rather than substance. Do you know about the Royal Enfield Bullet [1] from India? It is not at all as technologically sophisticated as the bikes you mention and others, but it is a fantastic bike to ride. They are selling it in the West, too, from some yea…

My cousin and two of his friends recently did New Delhi - Brussels[0] on 1971, 1973 and 1974 Royal Enfields.They made it but they got a lot of mechanical problems. I guess that was part of the fun ;) I almost bought a Bullet Classic 500 (sold with injection in Europe). It is probably much more reliable but it is probably a bit too limited for a 100km daily commute. I went with a modern Triumph Street Twin instead. Th…

Ha, plug bike to computer to start it ...

If AI matches up to its hype, after some time newborn babies will have to be plugged in to "start" them too :)

Re: The Collapse of the Unix Philosophy

#563

Post by vram22 »

eikenberry wrote: post #142
mastax wrote: post #100

Earlier quoted context omitted.

What OS would be analogous to the Honda in your example? OpenBSD? Plan9? Not Linux, surely. That would be more like the Suzuki, but it used to be an older bike so they left the carburetor in there and next year someone will add an electric motor too.

Any free software OS can meet his requirements as they all are transparent to anyone with the time to learn, just like the older bikes. The problem with modern bikes is that all the advanced tech is proprietary and you have no way of understanding it or tinkering with it. IMO you can take any modern distro and strip it down to something understandable. It just takes some time to learn how to strip it down and how wha…

>IMO you can take any modern distro and strip it down to something understandable.

Or strip it up, so to speak, or rather, build it up. Referring to Linux From Scratch.

https://en.wikipedia.org/wiki/Linux_From_Scratch

http://www.linuxfromscratch.org/

Re: The Collapse of the Unix Philosophy

#564

Post by yoklov »

moosingin3space wrote: post #231
CalChris wrote: post #155

Earlier quoted context omitted.

Well, if you don't get that someone else might see something as a flaw then perhaps you wouldn't understand that you may be defending a bad design choice. I use Rust. There's a bunch of things I do not like about Rust. Its macro language is nigh on unusable. A macro language should be an expedient; it should allow you to get textual things done, committing necessary atrocities along the way knowing that the result mu…

I never said Rustaceans don't see flaws or that they don't defend bad choices. But I've never seen someone say "if you don't think so, then you Just Don't Get It" or any variant thereof in the Rust community.

It exists, although it's often phrased more kindly. For example, complaining about lifetimes is often met with a comment that you probably don't understand them yet.

Re: The Collapse of the Unix Philosophy

#565

Post by spyrosg »

zzzcpan wrote: post #526
marcosdumay wrote: post #503

Earlier quoted context omitted.

Plan 9 is not "better enough". The other ones had fundamental non-technical problems that hurt their adoption (Plan 9 had those at the beginning too). Back to Plan 9, you can expect something that is just slightly better than your current options, and that keeps being this way to steadily gain adoption until it's popular. But that requires it being no worse than the current on any popular use case. Plan 9 may have a…

Plan 9 had fundamental technical problems too. Like most of the systems of that time it was designed with small single-building kind of networks in mind and didn't offer any value once large planet scale networks came to life. Also everything could have being implemented on top of any unix system, but wasn't that interesting for anyone to bother.

Didn't Plan 9 eventually get some mechanisms to facilitate interactions between such local-only networks around the world? 9grid and such.

In any case, Plan 9 is still ahead on quite a few fronts, with federated authentication that is simple(-ish) and works, a versioned filesystem by default, a unified namespace (the new interpretation of "filesystem") to access any resource you might want to use (instead of, today: DNS + TCP ports + HTTP URL's), and security by only exposing the necessary resources to processes, instead of exposing everything and then making up contrived access restriction schemes on top. (Smells of capabilities by Pike's own admission, I believe). That last part was mostly thanks to namespaces which Linux has picked up and popularised in a simple form with Docker... after 20+ years.

The important bits of the new architecture were also about the parts that were left out. No disk usage utility, based on the rapidly decreasing price of a giga bytes. Go and try to make contemporary sysadmins, who still partition their drives to this day, accept this highly distruptive simplification. Gotta create ourselves our busywork!

In the end, Plan 9 was made by /educated/ people with /resources/, and much of today's software isn't. No surprise it's better made.

(edit: some structure added to my rambling.)

Re: The Collapse of the Unix Philosophy

#566

Post by spyrosg »

gkya wrote: post #516
marcosdumay wrote: post #503

Earlier quoted context omitted.

Plan 9 is not "better enough". The other ones had fundamental non-technical problems that hurt their adoption (Plan 9 had those at the beginning too). Back to Plan 9, you can expect something that is just slightly better than your current options, and that keeps being this way to steadily gain adoption until it's popular. But that requires it being no worse than the current on any popular use case. Plan 9 may have a…

I'll say that if you could run a web browser on Plan 9 and maybe there was a POSIX or a Linux compat layer, it could've become popular. It'd be a boost to porting efforts if it was a usable desktop OS. Give me the best OS, but if I have to write a whole desktop/server stack on it to make use of it, I'll stick with what I have at hand. A plethora of software is available for Unix and it's why it's here still. Had I th…

Your stated reasons aren't valid. I think they ported Mozilla until 2002 (Russ Cox, maybe?). There was also a compat layer: APE.

As a counter to your argument: a system that has little capability compared to the well-established alternatives, starts from nothing, yet takes over the world: Linux.

I really believe there was no greater reason for Plan 9's failure to catch on (or at least it's ideas) than my peers not being interested in their own education.

Re: The Collapse of the Unix Philosophy

#567

Post by OJFord »

TeMPOraL wrote: post #440
OJFord wrote: post #276

Earlier quoted context omitted.

Yes, yes, yes. I'm saddened that tabs have essentially 'lost' - they seem to me in every way superior to spaces, but I would never use them in a new project simply because it would be likely to throw off others, and perhaps tooling. Github, for example, does not play nicely.

They're superior only in C-like languages when you indent in constant-width levels, and then only if you use very short names in your code. Try using tabs to indent e.g. arguments to function one under another, and weep.

> Try using tabs to indent e.g. arguments to function one under another, and weep.

I despise that formatting, and use:

    fn_with_many_args(
        very_long_arg1,
        very_long_arg2,
        very_long_arg3,
        very_long_arg4
    )
which aligns fine with `\t\t`; so I shan't be weeping today, sorry! :)

Re: The Collapse of the Unix Philosophy

#568

Post by OJFord »

ktRolster wrote: post #315
OJFord wrote: post #276

Earlier quoted context omitted.

Yes, yes, yes. I'm saddened that tabs have essentially 'lost' - they seem to me in every way superior to spaces, but I would never use them in a new project simply because it would be likely to throw off others, and perhaps tooling. Github, for example, does not play nicely.

The proper way is tabs to the point of indent, and spaces thereafter. Even Github will work if you do that.

Github works better if you do that, agreed. But IIRC (I don't do this any more, so this is from memory) it uses eight space tabs as a default, and can only be changed on the 'raw' pages.

Re: The Collapse of the Unix Philosophy

#569

Post by int_19h »

EdiX wrote: post #364
int_19h wrote: post #308

Earlier quoted context omitted.

Powershell did one thing wrong, in that its tools emit objects , not data . In other words, they emit data with behavior (methods). This, in turn, imposes the CLR object and memory model on the whole thing, and makes the pipeline impossible to use between distinct processes. The right way to do this is to pick some reasonable text-based structured interchange format - s-exprs, JSON, whatever. Actually, it wouldn't be…

The problem here is that most unix tools (ls being the exception) do double duty, they both emit output for other programs and output for the user. Which one you get and how the user output is presented being controlled by flags. If you want them to only emit data in a standardized format you are implicitly cutting out the user. Since direct use by a human is arguably the main use case, output formatting needs to be…

> If you want them to only emit data in a standardized format you are implicitly cutting out the user.

This is only true if your shell just dumps the raw output as is. But it doesn't have to do that! If we have a standard structured data format for the output, then the shell can be the one to format it. The key point here is that formatting only needs to happen at the very last step of the pipeline, when it is known that the output is about to be displayed to the user.

Indeed, this is exactly what PowerShell does, and that bit does not require data + code. It just formats lists of objects into neat tables, using their metadata to generate headers.

Note also that this doesn't need to be baked into the shell itself. It can be a separate utility, that sucks in structured data, and outputs formatted user-friendly representation. So in a legacy shell, you could still do:

$ ls | fmt

and get more or less the same output that you see from ls today (but if you were to do just ls, you'd get JSON). Whereas in a new and fancy shell, you'd get |fmt appended automatically at the end.

This, by the way, is also how PowerShell does it, except that fmt is called Out-Default.

Re: The Collapse of the Unix Philosophy

#570

Post by gluggymug »

The comments on this thread have been more interesting than the article. I think the common theme is a push to innovate and take the next step in computer systems.

If we scan this thread we could come up with a list of issues/problems with UNIX. Human inclination is to instantly look for each solution as each problem presents itself. Eg. "Text as an interface is unstructured" -> "Use other formats". The end result becomes a lot of feature creep, adding layers over the OS to hide the usability issues of the past. Then, a new user comes along and wonders, "How did it all get so messy?"

The ideation-style approach to innovation is NOT to leap straight to solutions. Avoid analyzing the problems immediately. Don't criticize other people's existing thoughts.

Instead we use our creativity to add to the list of problems. We build it up even more. Add tangential issues that may be not just UNIX related problems. Add future issues. Add past issues. You keep adding until you exhaust all the avenues. You don't want to block your thoughts or anyone else's. If anything, the previous problem someone raises should inspire your next one.

Once you have drained out all the issues and you can't squeeze out any more complaints, then you can take a step back and look at all the problems as a whole. You group them into categories that have common themes. You try to generalize and re-express them in vaguer terms.

After you have your themes, you can think about making a list of solutions. Again you don't want to be critical about the feasibility of a solution. You just want to build a list of different solutions. Each solution should inspire a new different solution. There are mental exercises that you can do to inspire tangential thoughts - word games etc.

When you have a giant list of solutions, then you categorize again. Those categories are the start point to building something innovative.

The alternative is just another iteration of what already exists.

My own thoughts on this are that I seem to need "power-user" abilities way too much. My field is actually Hardware. Something is wrong if I am jumping through a lot of hoops outside of my specialty just to get work done. It's not just UNIX either. My friends and family often call on me to handle their Windows or Mac issues because I am the closest thing to an expert they know. They shouldn't have to.

Post reply on HN