61–70 of 102 posts
> My recollection is that most CP/M programs were configured via patching. I honestly would have liked that better for a lot of programs than the dotfiles they litter all over my home directory.
Earlier quoted context omitted.
Which is irrelevant to TMP or TEMP. It could simply be: When envars were added to MSDOS…
Multics had envars in the 1960s and Unix in the 1970s, why were they ‘added’ to DOS when it was so close to an older OS, why didn’t it inherit them from CP/M? Did it get TMP from CP/M and introduce TEMP because computers were bigger but then?
I love rotary woofers :) I hope to get one some day.
> My recollection is that most CP/M programs were configured via patching. I honestly would have liked that better for a lot of programs than the dotfiles they litter all over my home directory.
If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more projects adopt it, even holdouts like Firefox.
Earlier quoted context omitted.
The ZX81 didn't have so much software around for it - what there was mostly came on tape, or was typed in¹ on the ghastly membrane keyboard, and what there was was very limited in capability (the default RAM size was one kilobyte (yes, just 1024 bytes, though typically you'd buy a "ram pack" upgrade to 16k). Then it was very rapidly superseded by the more capable ZX Spectrum machine. So odds are your Dad didn't patch…
Cool, yeah, he had the 16 kb extension and his own software written on a cassette/tape. He says hi back, for him it was purely a work machine (PhD in Chemistry, never did anything with computers as in CompSci), he doesn’t remember too much from back then but he said he loved the architecture of it.
Their success was largely down to their very low price point (clever cost-shaving engineering) at a time when there was a huge untapped public interest in computers.
Earlier quoted context omitted.
If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more projects adopt it, even holdouts like Firefox.
I don’t mind ~/.* for config, especially when the config is just one or two files. What I don’t like is programs like go and cargo treating my $HOME as a dumping ground for every file they want to download and/or cache.
And if you install more than one version of go, they get placed in $HOME/sdk [0]. Last I checked, this path is hard-coded with no override, despite this being a known issue for 8 years.
Earlier quoted context omitted.
Which is irrelevant to TMP or TEMP. It could simply be: When envars were added to MSDOS…
Multics had envars in the 1960s and Unix in the 1970s, why were they ‘added’ to DOS when it was so close to an older OS, why didn’t it inherit them from CP/M? Did it get TMP from CP/M and introduce TEMP because computers were bigger but then?
> My recollection is that most CP/M programs were configured via patching. At least that’s how I configured them. I remember my WordStar manual coming with details about which bytes to patch to do what. There was also a few dozen bytes of patch space set aside for you to write your own subroutines, in case you needed to add custom support for your printer. Huh. That is interesting, it was before my time, and I never…
It was necessary because both RAM and disk space were so severely limited, and because almost every computer came with an assembler.
Many CP/M programs were expected to run in as little as 32K RAM, and 130K of slow-ass floppy disk. Or worse – From a cassette tape. If you had 64K of RAM and a 360K disk, you were something special.
Unlike today, most programs were optimized for the bottom of the market, not the top. You wanted your program to run on as many system as possible so you could sell more copies. You didn't just shrug your shoulders and tell people to upgrade their hardware. The failure was yours, not your customers'.
There simply wasn't room for any kind of external configuration file, or a program to generate that configuration file. Common functions could be accessed via a command-line parameter, but even that logic eats valuable bytes.
Today people complain about the MacBook Neo having just 8,000,000,000 bytes of RAM, saying you can't do anything in such a limited space.
Meanwhile, in 1978, people could write an entire rudimentary IDE in 2,048 bytes.
Earlier quoted context omitted.
If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more projects adopt it, even holdouts like Firefox.
I don’t mind ~/.* for config, especially when the config is just one or two files. What I don’t like is programs like go and cargo treating my $HOME as a dumping ground for every file they want to download and/or cache.
OK. I love Raymond’s blog but this is crazy. Microcomputers existed only as a prototype in 1973 (things like Intel’s Intellec dev systems) and there were no operating systems for them. Strictly speaking, Kildall did start developing CP/M in 1973, but at that point it ran only on a simulator on a PDP-10 mainframe. 1979, sure. 1973? Way too early…
Which is fun, because this is the same time difference between 2020 and now
And then we think we didn't have ChatGPT in 2020