A Requiem for a Dying Operating System (1994)
user.eng.umd.edu
user.eng.umd.edu
POSIX is a monolith and really deserves to be improved. It's been around forever, yes. It will probably keep on being around forever, yes.
Take the tar command (please!), which is already a nightmare where lower-case `a' means "check first" and upper-case `A' means "delete all my disk files without asking" (or something like that --- I may not have the details exactly right). In some versions of tar these meanings are reversed. This is a virtue?
Pretty much the only consistent grep flag I know is -i. There's never been a standard for naming and abbreviating flags, which means that for EACH program you will have to learn new flags.
This becomes truly terrible when you get around to, say, git and iptables. Have you ever tried to read git documentation? It is the most useless godawful piece of nonsense this side of the Moon.
There's Google now, which means that the fundamental design issues of POSIX will probably never get issued. "Just google it and paste in from stackoverflow" is already standard, and people are already doing that for 5-10-year-old code/shell commands. What about 10 years from now, will googling best DHCP practices still find that stupid post from 2008 that never got actually resolved? How about 20 years?
I have honestly no idea how to even start fixing the problem. A proper documentation system would be a start.
I ran "man git" for the first time ever.
https://www.man7.org/linux/man-pages/man1/git.1.html
Heey, that's actually pretty good! I don't think it's "godawful". In the second sentence it recommends starting with gittutorial and giteveryday, for a "useful minimum set of commands".
https://www.man7.org/linux/man-pages/man7/gittutorial.7.html
https://www.man7.org/linux/man-pages/man7/giteveryday.7.html
I must admit, I still occasionally (regularly?) search for "magic incantations", particular combinations of flags for sed, git, rsync, etc. But the man pages are my first go-to, and they usually do the job as a proper documentation system. It's better than most software I've worked with outside (or on top) of the OS, with their ad-hoc, incomplete or outdated docs.
I see this type of remark against git quite often on HN and I think it's exaggerated.
I agree some of the porcelain are misleading and overloaded as convenience functions such as checkout, however a decent chunk of it is inline with the underlying data structure. Nothing is perfect, and git is pretty damn good - horribly designed? no, could do with some breaking porcelain re-writes? sure.
> git is pretty damn good
UI-wise, it really is not.
That commit object could be pointed at by a separate COMMIT_HEAD pointer. If you have a COMMIT_HEAD different from HEAD, then you have a commit brewing. Finalizing the commit means moving HEAD to be the same as COMMIT_HEAD. (At that time, there is a prompt for the log message, if one hasn't been already prepared.)
Your "staged" changes are then "git diff HEAD..COMMIT_HEAD", and not "git diff --cached".
Speaking of which, why the hell is "cached" a synonym for "in the index"? Oh, because the index holds a full snapshot of everything. But that proliferation of terminology just adds to the confusion.
I can't think of any other area of computing in which "cache" and "index" are mixed up.
git commit --patch
It combines with --amend.
However, if the staging area is relaced by a CHEAD commit ("commit head") whose parent is HEAD, then the problem of "stashing the index" completely goes away. You don't stash staged changes because they are already committed into the staging commit CHEAD.
That said, the stash feature could work with this CHEAD. Stashing the staged changes sitting in CHEAD could propagate them into the stash somehow (such as by a reference to that commmit). Then CHEAD is reset to point to HEAD, and the changes are gone. A single stash item consisting of work tree changes and staged changes could simply be an object that references two commits: a commit of working changes committed just for the stash, and a reference to the CHEAD which existed at that time. It could be that one is the parent of the other. So that is to say, a commit is made of the working copy changes, parented at the CHEAD. The stash then points to the SHA of that commit.
Intuitively, I know this would work, because in the existing Git, I could easily implement this workflow instead of using the stash. Given a tree of local changes, I could "stage" some of them by creating a commit with "git commit --patch". Then "stash" rest of them into another commit "git commit -a". Then, create a branch or tag for that two-commit combo, and finally get rid of it with "git reset --hard HEAD^^". Later, I could easily recover the changes from that branch, either by cherry picking, or doing a hard reset to them or whatever.
Speaking of which, an example of how stashes are limiting because they aren't commits, think of how you can't do:
git reset --hard stash@{0} # wipe it all away and make it like this stash
The requirement of reproducing working changes and staged ones from a stash represented as a two-commit combo is very simple. You cherry pick one normally and make it the CHEAD (the aforementioned special head for pointing to a commit being staged). Then the other one is cherry-picked with -n, so it is applied as local changes.
Indeed, in more erudite forums with smarter users, more level-headed, less biased opinions of git circulate.
Of course the next step is unlearning `git checkout` muscle memory and moving to using `git switch` and `git restore` more regularly.
Ahem, the command for "Reset working directory/Discard changes/Revert to last commit" is "git reset --hard".
That's the one I use.
"git checkout -f" does the same thing, but only because their different functionality coincides when there are no other arguments. When given a non-HEAD commit-id or branch-id they do different things.
I didn't think at the time to bookmark it with my "hn sucks" tag, and over the past year or two, I've tried several times to find it again, for reasons similar to[1], but I've been unable to.
When I first started using UNIX/Linux after learning the DOS shell, I never said that using commands like rm or mkdir were not intuitive and that it should be like using del or md instead. I just learned the different commands by reading through documentation.
Other OSes have a concept called forgiveness that allows you to easily reverse a change you made explicitly so that you can experiment with it and figure things out for yourself. The problem is that Unix fundamentally doesn't allow you to figure things out by yourself. You absolutely need either a manual (that you will never find if you haven't already been told how to find it), or you need to have someone you can ask questions to.
Much of the complaints about checkout have been split to other commands in newer versions. Does this make Git still invalid in your opinion?
https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-switch
They also fail to acknowledge that contemporary unix, aka Linux in it's many derivations and flavors, is entirely malleable at the source code level by it's users. That is a feature provided by literally no other operating system that is deployable at scale, and is, in fact, the singular feature that drives it's adoption -- not only is it 'free', you can hack it together in any fashion you damn well please, and you can use it to build peer-grade native applications, typically with little more than a tip of the hat as 'overhead'.
tl;DR: Some folks might miss the point because they are not sufficiently motivated to engage the *nix world with the degree of articulation required to tap into it's less than casually accessible capabilities.
My brain is really quite small compared to all the knowledge about computers that is out there. And my willpower too is very limited. So I would rather learn things I'd rather like to know, and be motivated to do things I'd rather get done instead of spending those precious resources of mine (and time! I will die in less than 25,000 days, that's a pretty small amount of time, you know) on something of dubious value.
Vs obtuse half broken shit people created out of whole cloth and refuse to fix.
Making a special snowflake that fits your brain better is good for you, but not necessarily anyone else.
Making something good for everyone will, almost inevitably, become a design-by-committee monstrosity that is as problematic as the tool being replaced.
The truth is, I am skeptical that these tools can be replaced by something that requires no effort to learn. At least, for the tools we already have, if you dont want to learn them, you can roll the dice and copy / paste from google overflow.
Yes, and that's why the parent's argument that "you can hack it together in any fashion you damn well please, and you can use it to build peer-grade native applications, typically with little more than a tip of the hat as 'overhead'" is not a convincing argument. Yes, you can learn a lot about it and tinker with it and "harness its power", as opposed to using something that's less flexible, but is already pretty damn ergonomical, and is much more accessible and easy to learn about (maybe to the point you're not even realizing you're learning).
> But the man pages are my first go-to
It's not strictly a logical contradiction, but doesn't make much sense either.
For Git, I usually turn to online documentation (at https://git-scm.com/docs) or, more often than not, search for keywords and, yes, end up at StackOverflow.
That supports the root-parent comment's point, that there are "fundamental design issues of POSIX", if users new and experienced must resort to such channels. It also implies that "man" as the default documentation system is not sufficiently meeting our needs.
Getting help on Unix commands, particularly in Linux, has always been a mess. On most Linux distros, typing "help" will give you help about the shell built-ins. Then, discovering "man", you soon find that the bundled GNU utils of course would rather you use their "info" system, which in turn may refer to a web page(!) for info.
I remember coming from the Amiga to Linux: I would not have gotten far without word-of-mouth help (and helpful computer magazine articles explaining a lot of the particularities of Unix). The Amiga, on the other hand, was a cheap home computer with an exceptionally thick manual detailing every single command clearly and succinctly.
The Open Group has the POSIX util spec published online[0] and also allow free downloads of it for personal use. Since I discovered it, I find myself using it much more often than man pages. I've made a little alias in bash that launches Dillo with the appropriate command page.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
I've taught undergraduate students some basic shell use for being able to compile their C programs. It's not really that bad. You have them use bash and you teach them some basic syntax and a few shell-usable programs, including man. You tell them that there is a lot of things the shell can do that we won't be discussing, so they have to be careful not use arbitrary symbols and to double-quote names. And I also tell them that bash is just one kind of shell, and that some systems have other shells by default, but we are working on a system which defaults to bash. I then tell them to check with "echo $SHELL" if they're on another system than the one we are working on, and if they don't see "/bin/bash" or "/usr/bin/bash" then they should ask someone for help.
That's enough to satisfy newbies in my experience.
Some systems will be weird. EG my default shell is bash, but my interactive shell for all my terminal emulators is fish. So "echo $SHELL" returns "/bin/bash", even from fish.
Of course I know this, I set it up this way deliberately so that only actual interactive shells (or correctly shebanged scripts) would be fish and everything else could be bash. But it would definitely confuse a beginner!
Being vaguely defined, it is of course open to interpretation and might vary from system to system, thus being a prime example of the kind of frustrating Unix gotchas that spawned the original article.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
Edit: To tie in to my earlier comment - where should I look for info on this variable in Linux? I know it exists, but how do I find out more about the behavior? 'apropos "\$SHELL"' gives me nothing. 'apropos SHELL' gives me a list of commands which doesn't include much of interest. Digging deeper, there's login(1), which briefly touches the subject, and environ(7), which gives a good description of it but of course dives in head-first and starts off by describing an array of pointers. Not overly helpful for the novice.
It is a way for applications to know where the shell to invoke is, not a way for a user to find out what program xe is using to run commands. echo $0 is more informative on that score.
man pages work pretty well for a lot of stuff that is POSIX. C interfaces and basic CLI programs you'll all find documented in man (with documentation beyond what is specified in POSIX).
The GNU folks have tried to push their info system, so maybe you'll find more details there for their commands. I guess most people use man because it's quick to access and a single page is easy to grep through. If that doesn't help, I'll just do a web search.
The man page for built-ins is never the quick reference I want, so I generally end up falling back to google for that stuff rather than try and figure out where it’s documented.
Anyway, TIL “help” is a command I can try.
I haven’t used it in awhile, but “cht.sh” is basically what I expect “man” to give me, but comprehensively, for everything, and by the program author(s).
Public repos with easily searchable source and a good README are even better tho, of course.
This is because Unix (or large parts of the environment) evolved over time rather than being designed at the beginning.
We started with the Bourne shell, then got the C shell, with the Korn shell splitting the difference between the two. Bash then came along taking lessons from each of those three, and then Z shell.
That's a few decades' worth of changes.
Only defect is they did not go with Yoda speak (Get-<TAB> is a much worse filter that NetA<TAB> to search for Get-NetAdapter for instance).
It's still a bit green on Linux environments, but it already beats many of the alternatives.
Microsoft at one time had a video interview on their "Virtual Academy" with one of the PowerShell creators, and he talks about how they kept trying to create a "unixy" tool for managing Windows machines, and it never felt or worked right. So then they looked at VMS and realized it was the perfect inspiration.
Most of what you love about PowerShell comes from VMS.
For anyone who's been put in charge of managing Zoom for their organization, may I recommend: https://github.com/JosephMcEvoy/PSZoom
"yacc" is not a command. It's an executable file that's read and executed. In fact, most of the things in a shell script are not commands, but files that are loaded and executed. If someone built a shell with everything built in it'd be a bloated monster full of inconsistencies and incompatibilities.
OTOH, PowerShell has "commands" or aliases named after Unix executables, such as "curl", that don't replicate the switches one would expect from the curl program.
> It's still a bit green on Linux environments, but it already beats many of the alternatives.
Maybe for Windows transplants. In general, not at all.
care to elaborate
In my experience, Powershell is so much nicer than bash that even on my work mac I tend to use it when doing stuff for me (not going to force it on my team)
I find it odd that you consider Windows and PowerShell a niche, when it seems to have been enthusiastically embraced by the community
Apart from the obvious compatibility and legacy factor, I think a major reason is that by the time someone has both enough knowledge and experience to formulate a proper solution and have felt the pain-points, they're already deep enough that they've internalized that this is The Way It Is and are somewhat comfortable with it, those annoying flags aside.
We tend to settle on the lowest common denominator, because consistency and time-to-ready trumps any actual improvements. For example, I'd so much prefer vim bindings in tmux but stopped using customizations like that completely since it turns out it's less of a hassle to just get used to the crappy standard ones instead of customizing it on every new host I start up.
If you can't get your friends off Facebook, good luck getting engineers off POSIX.
The documentation (and syntax, or lack thereof) of "tc" are significantly worse than git's. Unfortunately, the network management tool you are supposed to use these days, ip, is made by the same people, though somewhat less bad.
Second, take git documentation with humor: https://git-man-page-generator.lokaltog.net/
GNU packages often have documentation that's bad in the typical "Linux docs are bad" way. Try `man less`. First, it commits a grave sin in having a totally useless one-line summary, which reads "less - opposite of more". Funny, but totally useless and doesn't even remotely suggest what the command does (if you know what more is on UNIX, you surely know what less does). Or `man grep`. It's a reference page, very good for knowing what all the options do, but with no useful everyday examples, and with gems like these:
> Finally, certain named classes of characters are predefined within bracket expressions, as follows. Their names are self explanatory, and they are [:alnum:], [:alpha:], [:cntrl:], [:digit:], [:graph:], [:lower:], [:print:], [:punct:], [:space:], [:upper:], and [:xdigit:].
Self explanatory? Yes, if you used grep in the 90s. Is alnum alphanumeric or all numbers? Is alpha short for alphabet, as in what most people would intuitively call letters? What's xdigit? Extra digits? Except digits? Oh, it's hex digits. Pretty obvious that periods and commas are in punct... but also + * - {} are punct, among other stuff.
`man tar` is extremely comprehensive, an impressive reference, but very hard to figure out if you've never used tar.
I've been recently looking at FreeBSD documentation for common commands, and the source code as well. Both are so much better than the usual GNU versions you find on Linux.
Having used both Mercurial and git, it is my general experience that Mercurial has a much better documentation system. Git's documentation has improved, but mostly only in the more-well-used commands; when you want to reach for more exotic stuff, you start to find that the documentation is too full of jargon.
As a recent example, I wanted to get a list of files managed by git. Since I know mercurial best, I wanted the equivalent of hg manifest. Its documentation is thus:
> hg manifest [-r REV]
> output the current or given revision of the project manifest
> Print a list of version controlled files for the given revision. If no revision is given, the first parent of the working directory is used, or the null revision if no revision is checked out.
This is unusually bad documentation for mercurial--the short description and command name are reliant on jargon, and it's not aliased to "hg ls" or something like that. Okay, how about the equivalent git command? git ls-files looks promising. Here's its short description:
> git-ls-files - Show information about files in the index and the working tree
But its description is, um:
> This merges the file listing in the directory cache index with the actual working directory list, and shows different combinations of the two.
Mercurial suffers from a bit of jargon, but reading its description would enlighten you as to what it does without understanding the jargon. Git's documentation here starts with jargon, and then doubles down on it so that the more I read, the less sure I am about what it actually does. [In the end, by actually running it, I did verify that it's basically the equivalent of hg manifest].
Now both mercurial and git have a glossary (help glossary), but I've never seen anyone actually point a newbie to either one. Of course, here you can also see the world of difference in the documentation quality. Mercurial's glossary entry for the jargon term "manifest" says:
> Each changeset has a manifest, which is the list of files that are tracked by the changeset.
Now compare git's glossary entry for "index":
> A collection of files with stat information, whose contents are stored as objects. The index is a stored version of your working tree. Truth be told, it can also contain a second, and even a third version of a working tree, which are used when merging.
... and that is why people like me say that git suffers from poor documentation.
a += 5; // Add 5 to a
Entirely accurate, and totally useless.
How is this different than web pages or GUI apps? Everyone is different and a button that does one thing in one app/page does something different in another.
Have you tried to read GUI help files? They are written for 5 year olds and provide nothing you need as a dedicated user. Have you had to inspect the DOM of a website to try and intuit what something does it does not do?
Least with command line apps usually you have a --help or man page.
That's simply impossible with CLIs, you need at least read a "How to Get Started Immediately" note.
There's also Elvish, Nushell, and a few other attempts in a similar vein.
Using grep for '$' without being aware that grep patterns are regular expressions ((g)lobal search for (re)gexp, and (p)rint), and redirecting the output to the printer without first seeing what it might be (e.g. with .. | head -50) is pretty stupid.
Consider that this person's idea of solving the problem of "move occurrences of $ character to a different location within the line" in a bunch of files was to begin by searching for lines containing those $ characters and sending that to a printer. What? How is the hard copy going to help? Are you going to sit there manually typing in those paths and looking for those line numbers, to do the edit? If that is really the VMS way, who wants anything to do with it?
There's always `fgrep` or, IIRC, the POSIX-compliant `grep -F`.
More often than not, people don't want regular expressions.
Global Regular Expression Parser
that seemed plausible enough I never questioned it.
Care to explain what's intrinsically wrong with monoliths? I'd have thought that the most important point of a solution is whether or not it solves the problem, not the arhictecture by which it solves the problem.
But, as far as "what's wrong with monoliths" the biggest issue, IMO, is security. The more code you have, the more likely you are to run into security issues. By their nature, most security problems end up granting all access that a given program has. A monolith, by it's nature, usually has a LOT of permissions and a LOT of code.
Of course, this only matters when security matters. If you are making an app that isn't exposed to the internet then by all means make it a monolith. Otherwise, the best thing you can do for security's sake is to push for microservices with as limited a permission set as possible. That makes it so the exposed surface area is relatively small if any one microservice is compromised. (It's about risk management).
This is also why microkernels are so interesting to me. It's the same problem, a compromised kernel driver can do a whole lot of damage. So how do you solve that? By keeping the "root" kernel at a bare minimum and force drivers to run in user space as much as possible. That keeps drivers with security holes from giving an attacker full system control.
Have you ever heard about OpenBSD?
I want it to be improved but I fear it is becoming irrelevant. There are very few OSes left to be compatible with...
I mean yeah, there were more operating systems before, some of which were open.. but I'm not convinced it's necessarily bad to have one open system win.
If it didn't, I'm pretty sure there would be a lot more people using windows servers, which I think would've been far worse for the open community.
Also Linux Foundation was setup and is funded by big corporations like Microsoft, Google, etc in order to find ways to exert influence over Linux's growth.
Kinda, yeah. At least in the Desktop space it seems like it desperately wants to be and Canonical in particular works to push it in that direction. For instance, it is highly discouraged to install software from outside your distro's repository.
As is thinking that Linux of all OSes is in any way a walled garden.
And the general proliferation of Appimages, Flatpak, Nix, Guix, Docker containers, and of course local building of software all tell against the "using software from outside the distro's repos is discouraged" representation.
You can also distribute binaries on Linux easily enough. There's just no general reason to want to do so.
I feel the pain of the user in this particular case. But I also understand the frustration of the people who wanted to write their own smaller programs with less restrictions than the well architected but highly constrained VMS architecture. And ignoring such users can topple a better technology. That is why (a technically horrible) DOS spread like wildfire on personal computers, super unreliable Windows (Win 95 had to be rebooted daily) killed a much more robust OS-2, etc.
We can call such users who want capabilities quickly, even if they are not fully reliable "ignorant lemmings" or whatever, but ignoring them when a competitor does not is very risky. My 2c.
It wasn’t half bad. As multi-user systems went, it was actually quite good and we ran a number of projects on it before moving off to PCs, Sun Workstations and Linux in general.
I remember all the staples of the era: using Kermit to upload our assignments to the thing, dialing in from home at 2400bps, hacking our way “out” to the Internet, running out of our 50MB quota due to mailing-lists and uuencoded files fetched via mail gateways.
It was a lot of fun, and AFAIK there are some working VMS emulators around that I could install on a Raspberry Pi (and likely get a faster multi-user system than what we had then for hundreds of students).
I say it was an experience worth having, but largely (functionally) indistinguishable from a UNIX machine when accessing it via teletype (glass or otherwise).
I disagree. I first sat down at a VMS terminal in a library in North Carolina when the OPAC broke and dropped me back to a prompt. I knew Linux passably well at that point but had never used VMS before.
I typed ls, tried dir, that worked, and finally tried help. In half an hour I was investigating the university's network. It was a remarkably easy system to get oriented on. Conversely, no one can be expected to get anything vaguely comparable when sitting down unattended at a unix shell for twenty minutes.
It is absolute garbage.
$ help
help: UNIX System On-line Help
Choices description
s starter: general information
l locate:find a command with keyword
u usage: information about command
g glossary: definition of terms
r redirect to a file or a command
q Quit
Enter choice >That design (a nested heirarchy of help topics/subtopics, with some navigation hacks to make getting around easier) was quite good.
But then came hypertext in the form of the web, and at that point, the "help" command just looks like crap.
GNU bash, version 5.0.18(1)-release (x86_64-pc-linux-gnu)
These shell commands are defined internally. Type `help' to see this list.
Type `help name' to find out more about the function `name'.
Use `info bash' to find out more about the shell in general.
Use `man -k' or `info' to find out more about commands not in this listAlthough they were functionally similar, there were some practical considerations...
I will say that path names in unix were a simple and elegant , compared to what VMS used.
I recall VMS paths were something like [foo.bar.bletch]something.txt
At the time this was a little cumbersome, but looking back it is much worse.
The real difference is when you try to work out whether your binaries are (supposed to be) in /bin, /usr/local/bin, /sbin, etc, whether settings for a specific application and/or daemon are in $config or $.cfg or $.conf or $.cf or $d_config or .ssh and .bshrc in your personal directory, and where your web server and mail logs are.
Because they might be in /var/log - or equally they might not.
Unix was "designed" by hyperactive comedy racoons with ADHD. There's no reason - beyond lack of attention span and professionalism - why basic features and expectations couldn't have been standardised. But the Unix way is to get something sort of working without paying much attention to what other people are doing, lose interest in it, and move on.
Or to hammer away at something for decades adding more and more obscure edge case config options in a text file, all of which need to be set carefully because otherwise the application fails - probably silently, maybe leaving a log message somewhere completely unexpected - and most of which are irrelevant to 90% of users who just want Something That Works.
But yes, your inability to search anything up or to understand the basics of Unix constitute a complete design failure.
yes, mostly.
> Unix was "designed" by hyperactive comedy racoons with ADHD.
I have met the authors of lots of significant parts of unix and I have found them - universally - to be smart, competent and introspective.
I also found it interesting that most (85%) of top athletes were introverts.
Now to compare VMS with unix, you'll find there are some things that are better because capitalism works. Someone was in charge of VMS development, and people were paid to solve specific problems for the operating system or customers. But some things are worse because people were in charge of making trade-offs for current customers vs future direction.
On the other hand, unix also has some points in its favor. A lot of things have appeared that would not survive in a commercial business. Ideas seem to live or die depending on their merits more than by fiat.
The thing is - when people want "something that works" it usually involves tradeoffs that people don't want. You can run an older version of centos/rhel and you will find more 'it just works' at the expense of (relatively) older software. (or you can go look at the source and fix it yourself)
Why is that better though - isn't that just sheer familiarity?
NB It looks ugly to me as well but a lot of syntax looks ugly until you become familiar with it (C, PostScript, Lisp, Python all seemed pretty weird looking to me first time I used them and I came to really like all those languages over time).
ADFS::Symbiote.$.SchoolWork.English.Essay
Given a current filesystem and a current disk, just the path from the root ($) directory was needed.
VMS knowledge came in handy years later when I had to work in VMS Fortran on the company VAX - I even coded the VMS Fortran random number generator in g77 (thanks to the excellent documentation) for consistency when we ported our code to DOS after the VAX was shut down.
As funny as this is, the actual origin for "grep" is even more interesting – and, at least to me, quite mnemonic. "grep" comes from ed, and stands for the command "g/re/p", that is
global/regular expression/print
* https://www.youtube.com/watch?v=NTfOnGZUZDk
For those unfamiliar, Kernighan is the "K" in K&R C and the "K" in AWK:
I don't know how I ended up subscribing to Lex Fridman's podcast, but it's both wonderful and somewhat bizarre to me.
On the one hand, he comes across as the kind of character you'd expect in a horror film. Meticulous, well-dressed, friendly, but affectless in his speech and oddly emotionless and formal.
But then the actual questions he asks, and the observations he makes, are IMO a step above most interviewers. I can think of a number of 'greater' interviewers, but he's definitely well in the 'very good' range.
My apologies if Fridman reads this comment. I definitely don't want you to stop doing things the way you do :). It's just somewhat different, in a strangely 'boring' way, that I'm not used to from most good podcast hosts that I'm familiar with. Most are, sometimes to the point of irritation, exceedingly affable and chatty.
Are you aware of the The Report Of The Week channel run by 'Review Brah'?
He's saying it as if it's a bad thing?...
alias copy_files_from_one_place_to_another=cp
this tells me short names aren't a problem to begin with. And everyone would have the same discoverability problems with longer ones.
$ shopt -s extglob # to enable extglob
$ cp work/!(*.bak) prod/
the glob stuff is a case of power vs convenience. but you can do very similar with bash [] or {} syntax.
not being apologist, but I like unix approach of blurring the lines of a computer user and programmer. It makes everyone up their game both ways. Users being more demanding, and code being more accessible.
I grew up on Unix in the 80's, cut my teeth on MIPS RISC/os and then Irix and SunOS and all the joys of the very first days of Linux, oh my .. and I was fully prepared to be an SGI fanboy for the rest of my life - and then, they abandoned Irix and shipped NT. sadface
So when the tiBook came out, and it was promised to have a Unix on it, I jumped off my Indy and O2 workstation onto Apple - a company I'd never imagined, in my wildest 80's and 90's fever dreams, would become the one company still standing in the Unix wars. The tiBook was just soo good, and despite all of its warts in the early days, MacOS X' underpinnings with Darwin were just good enough to swing the decision to use it as a Unix-developers machine. And, it has been solid for 20 years as a platform in that regard, although the writing is definitely on the wall for us Unix geeks who nevertheless carry a Macbook.
If only SGI had made a laptop, and not been wooed away from sanity by the NT freaks. Can you imagine if SGI (Nvidia) had made that laptop before Apple did .. ? I sure can.
A number of legendary companies with great potential misstepped, GRiD, Blackberry, Be, MasPar, Thinking Machines, GO corp, Intergraph, heck go back to the Evans & Sutherland LDS-1 in 1969 or when BBN decided not to get into hardware after making the first internet hardware ever, the IMP. Or how about how SRI fumbled the ball after Englebarts work or SDS, who made a bunch of the NASA Apollo hardware.
The world is littered with great technology companies that didn't stick around because we determine success and failure by handshakes on the golf course.
You're right about that golfing handshake.
I take no position on whether this was good or bad overall; it's just a statement of fact. Lots of us who would've otherwise needed to shift to Linux for LAMP development or whatever after the dot-com crash migrated to the Mac instead, because it meant a unix laptop that Just Works that also allowed us to run native MS Office, etc. That was a powerful value proposition (and remains one).
" the writing is definitely on the wall for us Unix geeks who nevertheless carry a Macbook."
I do not yet see this writing.
One of my gripes with UNIX systems is how opaque they are
Later on they would ship the Adobe red/blue/green PostScript books with OpenWindows.
Including the famous bug for tunefs which is still current in FreeBSD (talk about slack in addressing the real issues!):
"You can tune a file system, but you cannot tune a fish."
https://www.freebsd.org/cgi/man.cgi?query=tunefs&sektion=8#e...
I had to learn VMS in a hurry in the last two months of 1986. I had the full binder set on a shelf in my toilet (Cambridge, UK). You could not have put a VAX in there :)
Well of course not; that would be "tunefsh", which no one has gotten around to writing.
In my personal experience, powershell is fantastic for writing scripts and tooling, but not really so great for actual use as a shell. What makes a good shell is speed and 'muscle memory', imo.
Your 'simple' pipeline becomes hard core once you take into account all other things you require like grep, awk, sed, xargs, mount etc. Hack, even basic boolean stuff is from another dimension with executables like `[` or `true/false` (yeah, I know mostly builtin nowdays)
That's the whole point of unix. Non-integrated tools that talk to each other using plain text.
Just as you have to look at a text output of a unix command to figure out how to parse it and extract the subset of information you need from it, so do you have to look at the help metadata of a PS command to figure out how to extract the subset of information you need from its output.
The advantage of having objects instead of text is that if you thought you could parse the filename of grep matches by substring each line of `grep -H`'s output with `:`, you failed to account for filenames with colons. With PS's sls, its help metadata tells you it outputs `Microsoft.PowerShell.Commands.MatchInfo` objects, and the documentation for that type tells you it has a `Filename` property of type string.
One PS command is not "integrated" with another PS command; they're all integrated to .Net and a bunch of built-in PS types.
https://devblogs.microsoft.com/powershell/verb-noun-vs-noun-...
https://ilovepowershell.com/2013/08/05/microsoft-virtual-aca...
Discovering the cmdlets is not as trivial as it could be, because they are named verb-first instead of noun first. Get-<tab> is not as useful as NetAdapter-<tab> might be, but since things are named sensibly you can do a little guess work and use tab-completion to find what you're looking for in the vast majority of cases.
Irrelevant. Use
Get-Command *network #network anywhere in noun
gcm *-network* #network as first word in noun
But, experience is more important. Simply do everything in posh, even if there is a handy gui. After a few months you are closer to pro then with any books.
I have looked but failed to find a VM image or even images of installable media to build one online. If you know of any, I would like to know -- and if you don't know of any, but have the skills, I think you could do a big service to the OS research community by making and sharing either install media or a VM or both.
Ever heard of search engines?
No, not really can you proof that in any way?
It was developed by the same core team that created Plan 9, and Limbo is the evolution of Alef, that Rob Pike wasn't happy to have to drop for Plan 9 3rd edition.
https://en.wikipedia.org/wiki/Alef_(programming_language)
> Alef appeared in the first and second editions of Plan 9, but was abandoned during development of the third edition.[1][2] Rob Pike later explained Alef's demise by pointing to its lack of automatic memory management, despite Pike's and other people's urging Winterbottom to add garbage collection to the language;[3]...
> The Limbo programming language can be considered a direct successor of Alef and is the most commonly used language in the Inferno operating system.
https://en.wikipedia.org/wiki/Inferno_(operating_system)
> Inferno was based on the experience gained with Plan 9 from Bell Labs, and the further research of Bell Labs into operating systems, languages, on-the-fly compilers, graphics, security, networking and portability.
For some strange reason many stop at the middle station, instead of going all the way to the end.
For one, you can have sub-directories inside the bin directory. This lends to a nice hierarchy of commands and encourages writing small single purpose commands instead of large monolith commands. An example of this is the `ip/ping` command.
Another feature uses the union file system which prevents me from having to mess with $PATH locating commands.
apropos
Are 2 options
^^ also works fine ..
$ help
GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
These shell commands are defined internally. Type `help' to see this list.
Type `help name' to find out more about the function `name'.
Use `info bash' to find out more about the shell in general.
Use `man -k' or `info' to find out more about commands not in this list. (base) user@myMachine ~ % help
zsh: command not found: helpIf this is how VMS advocacy looks like, I'm not surprised it disappeared.
What's more, and this keeps behind repeated and emulated, I do not understand how being arrogant, condescending, insulting, full of bad faith scorn and hatred is supposed to make me be part of a group or use a tech, API, stack, framework or what not.
"I'm a VMS user", they seem to say, "watch me be a nasty person."
Am I being trolled? Probably :(
FWIW, there are plenty of complaints about things other than syntax after the fifth paragraph or so, too ;).
Documentation for VMS and the whole shebang of layered products.
Until this day, in my book, the absolute gold standard when it comes to documentation.
Having the arguably best tools suite to develop (LSE, Debugger, what have you) also didn't hurt.
I still believe it the best operating system I ever worked with.
Ironically the article describes quite precisely why DEC failed.
Most of the company had a visceral hate of anything Unix and anybody involved with anything that even smelled faintly of Unix was a second class citizen.
Well, looking at Ultrix may have been the main reason for that. Ironically and decades later they had one of the best Unix offers on the market with Tru64 Unix.
DEC was in many, many respects an awesome company. Shame that Compaq (and later HP) never really had a clue about what they actually got there.
Source: I worked for DEC from 90 - 94.
Reminds me of ye olde UNIX-Hater's Handbook[0]
Amen to that! I started my career in a VMS shop, did a lot of DCL scripting. I have never seen better technical docs, before or since.
Of course, sh was just "rm -rf * .??*" and that is so much more discoverable because nothings says "delete all your files" more than some line noise.
Unix has a lot of issues on a lower level, but very few people discuss that, since it's a complicated topic.
Douglas Adams may well have had Unix in mind when he described the products of the Sirius Cybernetics Corporation thus: "It is very easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words --- and this is the rock solid principle on which the whole of [its] Galaxy-wide success is founded --- their fundamental design flaws are completely hidden by their superficial design flaws."
I optimistically hope a not-too-future (within 10y?) major version update of Windows is in reality a *nix distribution. As long as they can keep runtime compatibility with older versions of Windows software, I think it'd be a big win for Microsoft for various reasons.
The only real challenge would be to get driver vendors in line.
People have been down the Windows CE and Windows RT rabbit holes before. Windows Nano does nothing there.
In the server space, it's a possibility, but why? Other than running MS specific software, what is the benefit?
On the other hand, even with WSL2, Linux is not going to have it's mythologized "year of the desktop", unless you count Chromebooks. So Windows will maintain its niche there.
It is like saying that in ten years we will only have Pepsi Cola. As the only soft drink. You can get Pepsi Cola Mint ,Pepsi Cola Cherry, Pepsi Cola regular etc.
But no matter what it will always be Pepsi Cola.
I want more, a lot more viable operating systems than we have ow. Now is a sad place to be.
Linux was never created to be a modern operating system.
Parts in Windows NT -> were derived from VMS, though more and more of it removed. Some parts were removed and had to be reinvented (WSL).
Bacm in the days, you could pick different hardware you could pick different oses (often tied to specific hardware).
I liked Atari ST TOS/GEM. I thought it was way ahead of its time.
I did not think that PCs in the beginning of the Atari STs were even comparable. Lots of peple loved the Amiga, great machine. Some people had the Archimdes. (ARM). You had Macs with PowerPC. Lots of choice and lots of competition.
Now you buy a computer of a specific design with little direct competition, though that is improving now.
And you can pick between Linux or Windows.
A single computer architecture. A singe choice +1 for operating systems.
I would really want to own a POWER powered Linux machine but the are tragically expensive.For the most part they do share the same architecture still.
On mobile, we have Android or iOS. Android has a lot of shared architecture for obvious reasons and iOS most certainly does.
It is like the American election, which white geriatric misogynists would you like?
Linux is fully geriatric. WindowsNT is getting there too.
Can we please have a couple of teenage operating systems? Some new viable babies?
And hey, I’m sure if you work on implementing one maybe others will be interested in writing software for it. And that’s kind of the point, I guess: it’s a huge undertaking with little financial value for a business as opposed to extending on existing work. Standards give us a common language.
I very much hope you are wrong, as this will signal the death of personal computing.
I imagine it'd be more holistic and maybe not so similar to current desktop distros. No X11 for sure, but not sure if it'd even be wayland.
May not even be Linux - BSD seems more likely of the two, especially considering licenses. Remember that Apple did the same transition with OS X (which has roots in BSD).
What does that have to do with anything? Yeah, they're often anachronistic, but that's to be expected of something with over 2 decades of ABI compatibility.
> No X11 for sure, but not sure if it'd even be wayland.
WDDM and DWM have supported features for over a decade that Wayland still doesn't support.
That's a rather unfair claim. Hundreds of books and tutorials have been written to introduce people to Unix...
This was written decades ago, when computers mostly lived in universities and the only way to learn Unix was by etc.
It's also coming either after, or at the same time as books like "The Magic Garden Explained" which explains SVR4 in considerable detail.
You should read stuff like this as at least 90% sour grapes. Is there value from some of the criticisms along the way? Sure, but mostly they're just angry because the thing they liked is clearly going away.
The denial about the platform's future was SUPER strong. TeleCheck IT and software development, at least in those days, was staffed by people who would either move on quickly or stay forever. They mostly hired right out of college, too, so the lifers were people who had never worked anywhere else. (This kind of employment monoculture is pretty destructive, IMO -- get some new ideas in there!)
This created a super weird environment. Everywhere else I worked back in those days was rife with industry publications, curiosity about how other systems worked, excitement about developments in software or networking even if they were on stacks or platforms other than whatever the site used, etc.
Not so there. I think this may have been mostly because to read, say, InfoWorld in 1994 would have made it much harder to avoid how narrow a niche they were occupying. The nature of the systems and software there meant people who stayed were gaining skills not useful anywhere else; pretty much everything (even the database system) was built in-house.
People were out the door constantly, going to other big tech employers in the area to either (a) pick up more marketable skills or (b) pick up a huge bump in pay. That's what I did after 2 years. (Turnover in the dev group was something like 35% a year, which is HELL on institutional knowledge.)
All that said, you could see SOME of the appeal of staying on VMS from their POV. Clustering was a big deal, because downtime cost dollars. File versioning in the OS -- which I still haven't seen implemented the same way anywhere else -- was fucking genius and made rolling back a bad release almost trivial.
But when you decide to ignore where the market is going, and stay on a doomed platform, there are real costs to pay.
Last-Modified: Fri, 08 Dec 2000 14:02:09 GMTWhich also makes this article closer to 1969 than the present day.
So you're a system administrator, and you want to change a user's password?
$ set default sys$system
$ mcr authorize
UAF> modify jimbob /pass="whatever"
UAF> exit
...while on just about any nix, one might simply:
# passwd jimbob
<< enter the new pw twice when prompted >>
For every example of the original author complaining about *nix, I could probably find a counter-example of VMS being awful. Really, I think it reduces down to this: people prefer to stick with what they're used to, and what they were trained on. Anything else is "awful" and "inferior."
Long ago I had my personal trials and tribulations with Unix. Fortunately, OS/9 [1] was there to help with that journey of discovery.
[0] https://www.itprotoday.com/compute-engines/windows-nt-and-vm...
Starlink was one of two somewhat similar subject-specific networks set up in a period of enlightenment by the UK Science Research Council (as I think it was then) operating in the 1980s, particularly for largely interactive analysis. The other was an un-named and ill-publicized one for nuclear structure as opposed to astronomy. I don't know about Starlink, not being an astronomer, but I guess it was also rather ahead of its time, like the nuclear structure one.
Obviously it had changed in astronomy by then, but I didn't see the attitude that physicists (and later, structural biologists) shouldn't write software or build the necessary hardware before or around that time. We had people and job titles like "physicist-programmer", and did what was necessary, and we did fit the facilities to the problem (when not working at foreign labs). The software systems were designed to be user-extensible anyhow, in our case.
Personally I was glad to have the lightning-fast interactive graphics system on the nuclear structure GEC systems, and not the stodgy performance -- even when they weren't running something like Macsyma -- of all the VAXen I used. VMS was somewhat inscrutable to a physics hacker anyhow, so I don't understand why Unix made it more difficult, though I hold no particular affection for Unix.
I think it's worth pointing out that in the 80s/90s (and in the research in personal computing that preceded that period), there was a very different attitude about what it could mean to "use a computer." The demarcation between a "user" and a "programmer" was not so clear. Today it is stark. The author is sort of joking with this line, but it's likely that the unixification of computing has contributed to this divide.
It took a long time until a meaningful part of humanity got access to computers. The fraction that had access to timeshared machines via serial terminals was tiny.
In the age of the PET, the Apple II, the C64, it was usual to boot up your home computer and be greeted by a BASIC prompt (REPL, if you allow me). It was an immediate introduction to programming - a language was there, built into the computer's firmware, and you could just start writing code one second after powering the thing up. You could write programs that looked comparable to what you could buy at a store or type in from a magazine.
CP/M and then MS/DOS were a bit different. You were dropped into an OS shell rather than a programming environment. In order to program, you needed to explicitly start an interpreter or a text editor. You still could write programs that looked like professional apps on the platform, but you had to get a language, which was not usually provided.
Then the GUIs came. Now, in order to write programs for Windows, or the Mac (oh boy!), or anything else graphical, you needed to get developer tools. Microsoft's came in a crate. A Hello World app would be hundreds of lines. In order to make something useful that looked decent, you'd need to learn a lot. By then, most timeshared system users were left behind, as terminals couldn't cope with user expectations.
What was once a small crack is now a vast chasm.
Which brings me to another point: this divide has gone hand in hand with the idea that parts of a computing system should be universally swappable. But that prevents any "holistic" nature to a computing system, and therefore we get caught up in the idea of individual languages rather than environment and how everything works together.
Interesting then that it barely mentions VMS.
Please, can you offer an example for this?
Is that a defining characteristic of "elegance"? So far from the threads here all I've come away with is that VMS was easier to learn and/or had better docs, not that it was necessarily any better at actually performing work.
So, in that sense, yes. VMS was more elegant than Unix because its design, syntax, and documentation made it easier and faster for users to grok and complete their tasks. As far as how fast or well the programs run, that's all about implementation details.
I worked in astrophysics for a while, and maintained a large codebase that included a ton of Fortran, and had a lot of references to Vax VMS systems within the comments as that's what the team I worked with used mostly through the 80s and early 90s before moving to Linux.
One of the things that didn't seem to happen was C - there was some code here and there (I wrote a module for IDL - IDL is a proprietary scripting language that mimics and interoperates with Fortran in a lot of ways). Fortran was able to stick around because of a lot of work on great compilers, and I think, in general, the great speed up of commercial hardware has made the need for hyper optimization less necessary for a lot of day-to-day physics study.
Then someone introduced me to a sort of minimal unix that was running on top of VMS. Although I had never seen Unix before then, I immediately saw the advantages and switched over. If I had to do something on VMS, it was painful.
Later the company got first generation Sun workstations, running unix on metal, with large (for the time) graphic displays. SO advanced...and so much fun (except when I had to do stuff in C--mainly our team used LISP or Prolog). Eventually we even got an ARPAnet connection. But I digress.
There are manuals for old Unix versions here, maybe start with V7 if interested: http://man.cat-v.org
The paper "Program design in the UNIX environment" or the book "The UNIX Programming Environment", both by Rob Pike and Brian Kernighan, might be of interest.
https://blog.poggs.com/2020/04/21/openvms-on-a-raspberry-pi/
The prices that Bell Labs was allowed to charge for symbolic UNIX licenses were a gift, when compared against traditional commercial OS prices in the 70's.
VMS was designed to sell mainframes so your choices were limited outside of that until the pedestal and workstation market arose around 88 (Alpha), MicroVAX, etc. Even then it was only DEC hardware. That's how you kill an OS.
Had UNIX been sold with a price tag similar to VMS, without source available for universities to play around, and it would have been long dead by now.
It was introduced in 3.0BSD, it's pretty old :). As for usage, while I'm not a native French speaker, I don't think I've heard it used as a noun that often. I can't speak (heh :P) for Canadian speakers of French -- perhaps there are different norms for the use of various idioms there, and I learned French in Europe -- but over here I don't think anyone ever had trouble figuring out what the apropos command would do...
Also not saying apropos is incomprehensible, just that 1 it sounds weird as a Frenchman, 2 there could have been a simpler alternative: “about”.
FWIW, though, the noun form is even less uncommon in languages that borrowed the expression from French. In my native language (also a Latin language, so borrowing it was straightforward), its use a noun is very limited. Saying that a book is "full of à-propos" (as in "pleine d’à-propos"), for example, wouldn't mean it's apt, or very relevant, it would mean that it's full of subtle, possibly contrarian or lewd motives. That's more or less how it's used in English, too.
To non-French speakers -- given when apropos showed up, the Unix audience was very American-centric --, who've only heard it used in the other sense, it actually sounds very appropriate, possibly even more appropriate than about, given how apropos (the program) works.
> Actually, the answer is easy. Operating systems cost hardware manufacturers, and therefore consumers (us), money. Unix is free, and whatever its defects at least no one blames the hardware manufacturers
I don't think it's good to make the command name an English word. Perhaps it would make the command easier to discover, but it would also introduce certain unpredictable connotations.
For instance, if the command was called 'remove', then someone might presume that it was being 'removed,' and 'replaced,' somewhere else. 'Remove' has the connotation that you are taking something and necessarily putting it somewhere else, which is not what 'rm' does.
'delete' has less ambiguity, but I'm not confident that similar mixups wouldn't happen. It's better for the command to be something ideosyncratic so that the user goes in with no assumptions about its function.
To paraphrase Rob Pike, the command is not remove, but 'rm'. It's called 'rm' because rm is what it does.
http://mail.9fans.net/pipermail/9fans/2016-September/035429....
Tell that to linux nerds who encourage people on forums to install arch from scratch if they want to learn about how computers work.
15 years ago it was "install gentoo to learn how computers work" but all it really teaches you is how the gentoo/arch install procedure works, or, more likely, how to type in commands from a HOWTO one after another.
The flip side is UNIX which tries to pretend things are OK even when they are strange. For instance, you might fill the disk with a log file, then 'rm' the log file and note that the disk is still full. The file is still taking up space on the disk, even though it is invisible. The space isn't released until that process closes the file or gets killed.
Contrast that to VMS which, given an impossible situation, will do nothing. (as in "not do anything") Recovering from a "full disk" on UNIX is usually routine, but on VMS you will probably be recovering from tape or calling the factory for support.
This guy
https://www.youtube.com/watch?v=r1Esq1l0Yoo
(the year after that album was released) got mad because a midwestern state university student had a "non-traditional" student spamming hundreds of USENET newsgroups. The university couldn't throttle the spammer because he'd had already won a "free speech" lawsuit against the university newspaper.
The antagonist saw this as an existential threat to the net one Friday night and went Ender Wiggen on his ass.
He thought he'd fill the disk quota on the spammer's account on the VAX/VMS system so the spammer couldn't log in and delete his received email -- an excellent implementation of quotas meant you could usually get the victim running to 'mommy' (the sysadmin) for help.
The antagonist used ftp-to-email gateway servers to vastly amplify the attack and confuse people about the origin. At the last minute he found a way to get the ftp-to-email gateway servers to send email commands to each other in a cascading way.
The target campus went down in about 30 minutes, and, logged into the VT-100 terminal in his dorm room, the antagonist realized that he'd miscalculated and the attack was possibly 20,000 times larger than planned.
The target campus didn't come back until Tuesday evening, probably the disk was full for the whole VMS Cluster.
The spam stopped. They never proved anything, but a few days they shoved an empty SUNtape into the antagonist's hand that allegedly held the files from his account at his campus central computer center account -- just "being a jackass on social media" was a good enough reason.
About a decade after that incident, I had "the same thing" happen to an email server running Linux on this box
https://en.wikipedia.org/wiki/Cobalt_Qube
during the 'Love Letter' virus crisis. I had email accounts getting millions of emails a day on that badly underpowered machine, a beta-test model with a 2% slow real-time clock.
In 15 minutes I had the email server shut down, the disk full condition cleared, logs working correctly again.
I brought up qmail and did not like what I saw in "top" so I shut it down. I wrote a uniq|bash|awk script that picked out virus-sending ip addresses from the logs and piped the bash script into bash to block them at the firewall.
I brought qmail up and it was good, good enough to go to bed. By the next morning the viral load was serious so I automated the firewall script, installed an anti-virus scanner, etc.
In wartime, VAX/VMS gives up the fight but UNIX soldiers on.
The biggest was that I wanted a machine of my own to work on, not just a shell account on a big Vax with a tiny quota. The price of the lowest-end, used machine with a hope of running vms at a decent clip was astronomical, upgrades were proprietary and expensive. I think the machine in my office at the time came with a perpetual single user vms license, but if I wanted to create shell accounts for my friends, buying license paks was also quite expensive.
If I wanted to, say, run irc on the vaxstation, instead of the handful of popular clients that one could build on Ultrix, there was a single vms port, and to build it would require licensing a compiler. Downloading the source would require buying the tcp/ip module license as it would be years before that was bundled in.
So if I ditched the Vaxstation and got one of the MIPS based DEC pizza boxes, I could put Ultrix on it and at least get the GNU toolchain installed and be able to build and run a bunch of the software I wanted. My older colleagues who preferred working with VMS would spend weeks attempting to port some popular utility to VMS, which seemed goofy to me at the time.
Within a couple of years 386BSD and Linux came along, and my plan to save up the 5kUSD or so to buy my own DECStation quickly vaporized when I saw that pretty much everything I wanted to run on Ultrix would build on Linux, so I certainly had no more interest in VMS after that.
Now a couple of decades later, I sometimes think about the things that I desperately miss about products like VMS. The expansive, exhaustive documentation. The robustness of the systems in production, the great interoperability between the various compilers.
We also got pretty amazing support from DEC, but the amount of money that we paid for all those things was breathtaking. If you were using custom software for critical businesses or processes, it was not a terrible arrangement, but if you wanted to stick an email server in the closet of your small business and you weren't already a fan of VMS, it would have seemed crazy to choose one of those boxes. They were very much a premium product in a space where developers with DIY tendencies where suddenly being presented with heaps of cheaper choices, even if they weren't as reliable or well-documented.
I'm very curious to see what becomes of the x86_64 port; now that I'm a little older, more patient, and have a few bits of software that I'd like to stay running all the time, it might be nice to have the option. I think I even remember enough DCL to get around :)
Our bodies are the same way.
> Unix and C however form a powerful deterrent to the average astronomer to write her or his own code (and the average astronomer's C is much, much worse than his Fortran used to be). The powers-that-be in the software world of course have always felt that "ordinary" users (astronomers in this case) should be using software and not writing it. The cynic might feel that since those same powers nearly all make their living by writing software, and get even more pay when they manage other programmers, then they have a vested interest in bringing about a state of affairs where the rest of us are reduced to mere supplicants, dependent on them for all our software needs. It is clear that Unix does not pose an insuperable barrier --- the ever-expanding armies of hackers out there are evidence enough that the barrier can be scaled given enough time and enthusiasm for the task. But hacking is not astronomy, and hackers are not astronomers, and it is astronomy and astronomers I worry about. We shouldn't have to scale the Unix barrier, and it is all the sadder because, since the advent of a VMS-based Starlink, ordinary astronomers have had something denied to most other scientists in this country --- readily accessible, reliable, user-friendly computing power that can be easily harnessed to a particular astronomical requirement.
I've spent the past hour or so figuring out what I think about this. It's easy to dismiss this piece of rhetoric as flawed reasoning or as irrelevant today. For example, I'm not sure if Unix was ever to blame for the self-serving user-developer dichotomy discussed in that quote above. After all, the Unix philosophy is all about small tools tied together with scripting, not the mega-packages mentioned in the article. And was there really not a good Fortran option for Unix in 1994? Or was Starlink (or its Unix-based successor) just too cheap to buy whatever good Unix Fortran implementation might have existed back then?
But the software development priesthood is still a problem; I'd say it's worse today. It's what worries me the most about the future of computing for the next generation, including my nieces and nephew. Will they be able to help shape the software that runs so much of their lives if they can't land a job at a handful of tech behemoths? Much of that software is even built on a foundation of Unix and more generally open source, but the power of that foundation isn't available to the end-users.
However, the free software movement's answers to these problems are hampered by their own elitism, which is in fact largely a continuation of the Unix elitism this article bemoans. It's true that we have much better languages than C, there are usable GUI desktop environments for free Unixes, and there are even whole open-source integrated development environments that one can run on a free Unix. But at some point one still comes in contact with the same arcane, haphazardly designed command-line environment that this article and the UNIX-HATERS Handbook rightly ridicule.
So if we actually want a system that's both free and open from top to bottom, and actually approachable to most people, then maybe we need to finally let go of Unix, or treat it as only an expedient substrate as Apple and Google do. Or as another writer put it, we need to free our technical aesthetic from the 1970s [1].
[1]: https://prog21.dadgum.com/74.html
Disclosure: I happen to currently work for Microsoft, on the Windows accessibility team. But these opinions are entirely my own, written on my own initiative. And yes, the fact that I benefit somewhat from the user-developer dichotomy enforced by the likes of my employer makes me feel uncomfortable. But I'm not sure quitting would actually help anything.
I don't know where this free software elitism is prevalent, as someone involved with it in research since before the term became necessary. I could appreciate the UHH, by the way, from a time when Unix was largely not free software.
Compared to what? If I want to quickly bang out some code and run it, installing fedora (or another distro) is probbably the least painful way to get it done.
I would say that Windows is a powerful deterrent to the average person writing their own code much more so than Linux.
Back then your choices on UNIX were to either accept whatever your vendor included (which would mostly be C), or buy a disk set of some other tools and hope they actually worked on your machine.