@jmc Yeah, that's the harder manual magic to do everything. git-absorb (in theory) automates basically the 'git commit --fixup=<find the right commit>' bit and will run the git rebase for you.
@mos_8502 My view is that the modern web is a marvel that is ruined by most of the uses of it. It's a relatively universal display system and application environment that provides massive power and easy of use (along with relative privacy compared to the alternatives).
Eg, I may snark on Grafana the company but Grafana the dashboard system is a cross-platform marvel that wouldn't have existed before the modern web. And at work we deliver forms via the web that would be (slow) email otherwise.
@mos_8502 As a minority platform person (Unix/X), cross-platform software means that I get it at all. If Grafana was a program, it would probably exist only on Windows, maybe Mac as a distant second. Or cost a lot for Unix 'enterprise' stuff.
(I've been around my work long enough that I saw our paper account request forms, although I never had to process any. That too is 'cross platform' in a very basic sense of 'forms that can be filled out online on any computer of your choice'.)
If you're a government considering whether it's worth ripping up IP rules, I think two of your questions are how long before the US comes back with another trade deal you want and what will the US do to you to retaliate for you ripping up IP rules. (There will be retaliation. Look at the US today and tell me there won't be retaliation for everything.)
That's why I think the US has to be basically gone for good before this is realistic.
If you're a company in a country that (hypothetically) has ripped up IP rules with the US and you're thinking of taking advantage of that, the question is: how long before the IP rules come back? If it's only a few years, this probably leaves you up the creek. You need them gone long enough for you to be solidly established with real power to stop them coming back, or to no longer need the lack of IP rules.
Given that the US is ripping up trade deals, it's nice from a certain perspective to imagine other countries also ripping up the onerous IP rules that are part of them. But this is probably not likely right away. Other countries (and potential industries) have to play a long game, where it's only worth ripping up those laws if a normal US administration isn't going to come back in N years and the US is basically gone from trade/etc for a generation+.
In the old days, 99% of abrupt program terminations were your code having a bug and crashing. These days there are a ton of things that can abruptly terminate even a well behaved program in many environments. Container management, container auto-scaling, something changing resource limits, another program eating memory and triggering an out of memory condition that terminates you, etc etc.
I will admit that until I saw the CouchDB post, the scenario of 'program writes but crashes before fsync, restarted program re-reads the just written data and assumes it's safe on disk instead of just in the kernel buffer cache' had not occurred to me. I guess everything that reads a WAL or other recovery file should immediately fsync() it on startup.
@jschauma You have my sympathies. I have yet to memorize how to turn off Bash smart/programmable completion (which routinely gets many things wrong when I have to deal with it), but I keep getting closer and closer every time I run headlong into it.
(One problem with Bash's programmable completion is that it puts you at the mercy of whoever wrote the rules for the particular program you're trying to use, and the quality of rules is somewhat variable.)
@mhoye It's kind of sad because Miller did give us the "this is the weapon of the enemy, we do not use it" thing, which is very Batman in sort of a good way. But some bright bits can't make up for everything else.
@lanodan People in your situation definitely have a different set of threats than 'ordinary' people (so far, who knows). Locally, corporations / universities / etc are very spooked about stolen laptops, discarded HDs, etc leaking stuff that gets them bad press and other things. (There's a whole category of "personal information' that organizations are legally obliged to safeguard if they have it, so laptop encryption for all.)
Blog post: Institutions care about their security threats, not your security threats https://utcc.utoronto.ca/~cks/space/blog/tech/InstitutionSecurityVsYourSecurity (sparked by a conversation with @mhoye ) tl;dr: I think this helps explain significantly different views around things like aspects of MFA, disk encryption, exposing who has accounts, etc. And also MDM as applied to personal devices, which is great for the institution and terrible for you since now the institution controls your personal phone. Your interests couldn't be more different.
@jdblair@mos_8502 I was going to mention MH. Plan 9 also did the 'mail is a filesystem' thing; when they supported MIME I think they made each MIME part a separate file, as you should (I'm not sure how they handled nested MIME parts but I'm sure they had a good answer).
MH is one of those so close yet so far things, and I say that as a very long time MH user. The idea is great, but the implementation is extremely tangled and has issues.
Did I just buy a (digital) album partly because of its name? Yes, yes I did, sometimes I'm slightly shallow[1]. On the other hand the last time I bought a digital album partly because of the cover it worked out extremely well[2].
@davecb Grafana dashboards definitely are alarmingly addictive, especially when compared to the alternatives. (Do I look at ours a little too often? Maybe. They're certainly an attractive hammer.)
TIL about dnstop, a top-like display of DNS query and response traffic (Linux only, I believe, but probably available packaged for your distro). This is going to be useful for us in the future.
@ireneista@awb I suspect that one reason POSIX never standardized troff is that AT&T was busy unbundling troff as an extra-cost option by the time POSIX started up (which AT&T called 'DWB', apparently officially short for 'Documenter's Workbench').
You might wonder how this affected Unix manual pages, especially for third party stuff. 'Badly' is the general answer ; people had to distribute preformatted manpages or resort to sometimes extreme measures, such as https://doc.cat-v.org/henry_spencer/awf/
I don't often say our servers are haunted, but I think one of our servers is haunted. Specifically, haunted by the ghosts of NFS v4 mounts that are no longer there.
NFS v4 in Ubuntu 22.04: apparently the gift that keeps giving. (Or my instrumentation is wrong but I more or less trust my instrumentation, as janky as it is.)
A little wish: new Linux init system projects should re-use the definite good ideas from systemd: * put every separate service in its own cgroup and use that for process tracking * capture output from the service's cgroup and log it (syslog is fine). * start and restart services in a controlled environment; no more leaking things from your session into the service on '/etc/init.d/whatever restart'. * optional non-daemonization mode * reliable 'is it running' status information for shell scripts.
As far as I can tell, /sbin appeared first in SunOS 4.0, where the hier(7) and filesystems(7) manual pages describe it as 'executable programs that are needed in the boot process before /usr is mounted'. They both claim that the SunOS 4.0 /sbin contained only hostname, ifconfig, init, mount, and sh.
According to these manual pages, SunOS 4.0 did not have a /usr/sbin. SunOS 3.5 doesn't seem to have had a /sbin.
(I'm so happy I finally found private copies of this SunOS 4.0 & 3.5 stuff.)