261–270 of 286 posts
Unix is the ultimate example of "worse is better." VMS, which is what the article is about, was definitely more elegant, easier to grok, and far better documented. So was IBM's VM which had what we now call "containers" working simply and reliably 30 years ago.
> VMS, which is what the article is about, Interesting then that it barely mentions VMS.
Earlier quoted context omitted.
The concept of the git staging area is utterly superfluous. All local changes that are propagated to the version control system should go directly into a durable commit object, and not to a pseudo-commit object that isn't a commit, and that can be casually trashed. 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. F…
I like the staging area, though–at any given time I always have code that I do not want to put in a commit object (perhaps I changed some build flags, or my IDE touched some files I don't care for, or…) However, I do agree 100% that all the terminology is pretty bad.
Earlier quoted context omitted.
> largely (functionally) indistinguishable from a UNIX machine Although 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.
That's a cosmetic difference. 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…
But yes, your inability to search anything up or to understand the basics of Unix constitute a complete design failure.
This brings back memories (of ten years ago). 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 mo…
Funny, today one of my coworkers was talking about how she used IDL at one of her previous jobs, and later I happened to see this comment. Neat coincidence :)
Earlier quoted context omitted.
The back story to this is that the DIGITAL Command Language (more or less the equivalent of an Unix shell), with its excellent filesystem-level features and the environment around it (e.g. the well-written and extremely thorough documentation) was very much light-years ahead of anything you could get on most Unix environments at the time. Going back to the Unix shell felt a bit like a step back. FWIW, there are plent…
Ah yes! 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 viscera…
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.
Earlier quoted context omitted.
The sin of Git's staging area is that Git forces it into the default interaction path—requiring you to take it into consideration whether or not you're interested in only committing some of the changes. Git should default to including all changes, and iff you direct it to (i.e. by explicitly specifying `git add`) should you have to take into consideration the notion that some changes are staged and others aren't.
I'm generally also one of the git sceptics - Though I loved staging for a while as for the fine grained control. `git add --all` just might not do the right thing - for paranoids like me. Just recently got to know you can skip the staging by appending the paths of the changed files you want to commit after `git commit -m "awesome commit"` - neat.
git commit --patch
It combines with --amend.
Earlier quoted context omitted.
I like the staging area, though–at any given time I always have code that I do not want to put in a commit object (perhaps I changed some build flags, or my IDE touched some files I don't care for, or…) However, I do agree 100% that all the terminology is pretty bad.
Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.
Earlier quoted context omitted.
The issue with git is that no matter how well documented, the user interface is horribly designed. For starters, how many different things does "git checkout" do, and how many of them actually reflect an intuitive meaning of "checking out" ?
Some time ago, some UI designer asked, on HN, for what open source program should they build a UI to establish their reputation. I suggested "git". That was rejected as too hard. They just wanted to put eye candy on a command, not have to rethink its relationship with the user.
"Anyway, have you ever tried to use man? It's fine as long as you know what you are looking for. How would you ever find out the name of command given just the function you wanted to execute? You can't. " One of my gripes with UNIX systems is how opaque they are
Anecdote this jogged from my memory: my first Unix experience was NetBSD on a SEGA Dreamcast game console, of all things. This must have been some time in 2000 or 2001, but I remember sitting there trying every possible command I could think of trying to find one that did anything at all so i could keep going and learn more. The DOS commands I knew obviously didn’t do anything. Neither did anything like ‘help’ or ‘?’…
Pretty much each point raised in this post(?) are correct, current and relevant even 26 years later. 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 somethi…
> Have you ever tried to read git documentation? It is the most useless godawful piece of nonsense 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…