Chris Siebenmann

Got curious, tried to figure out what exactly is being blocked, and came across this, unsure if it just applies to emails, maybe not: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OnBlockingIPRanges (https://hastebin.com/share/fipayoqofo.vbnet) > [...] An open Internet is a great thing, and it would be nice to have one. But it is now less and less compatible with running systems that are useful to their users. I hate firewalling off large chunks of the net from our mailer, but I would hurt even more from our users fleeing email because of spam. And so I firewall. [...]

If they destroy the relatively high-trust internet, the low-trust replacement will require digital ID for every client, with non-neutral traffic price varying by {business digital ID, content}. No more free geese, even to check whether there is a golden goose worthy of payment. https://utcc.utoronto.ca/~cks/space/blog/web/WeShouldBlockForSocialRea…

It's an interesting idea, I've never tried it. It could also be a simple VM running a given OS (with reduced need for hardware support), or an application running interpreted code with the environment UI. Generally the idea is to expand UX in more interesting/fun directions without incurring significant hurdles associated with an OS (where everything needs to run reliably and be secure). I've found this quite interesting related discussion: "Classical "Single user computers" were a flawed or at least limited idea" https://utcc.utoronto.ca/~cks/space/blog/tech/SingleUserComputerFlawed (discussion on lobste.rs: https://lobste.rs/s/plkdy5/classical_single_user_computers_were)

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/HowWeSellStorage Perhaps the most interesting (though sort of irrelevant) part from a linked page on the site is that "cloud" storage is being sold as a one-time cost. A great deal (depending on price) if you ask me!

This example was performed on the block-special device, so there is no filesystem. dd uses a default block size of 512 bytes, according to the manual page: calling write(2) directly means you need to choose a buffer of some size. "bs=" sets both input and output block sizes, which probably isn't the best idea in this case. Block sizes are a tricky subject: https://utcc.utoronto.ca/~cks/space/blog/unix/StatfsPeculiarities https://utcc.utoronto.ca/~cks/space/blog/tech/SSDsAnd4KSectorsII

> I distinctly remember cks as the very guy who recommended ten years as an expiration date on my self-signed certificates Link? In https://utcc.utoronto.ca/~cks/space/blog/sysadmin/MakingSelfSignedSSLC… I see him saying he uses 27y (9999 days).

IIRCC it's not recommend to have swap on a zvol. So you would need a non-zfs managed partition/device for swap. Not sure about current status? https://github.com/openzfs/zfs/issues/7734 https://github.com/openzfs/zfs/issues/342 https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSForSwapMyViews

Another one of my favorites of his: https://utcc.utoronto.ca/~cks/space/blog/programming/CTriumph (the C Juggernaut) I like it in part because I lived through some of that time period (getting code running on early Macs) I can relate to people who just like programming in C. :-)

From a linked blog post of the author's: > Given that there are websites that are willing (or reluctantly forced) to allow Google(bot) access but would rather like to block everyone else, more than a few of them are probably using User-Agent matching instead of anything more sophisticated. (https://utcc.utoronto.ca/~cks/space/blog/web/SpiderUserAgentMaybeTooCl… Yeah, what a great idea to make all of our websites only crawlable by Google. Because competition in the search engine space is _so_ undesirable.

An idiosyncrasy I have about TIL posts is that I think they should focus on what you were able to got done/progress with. TIL posts that truly have been learned that day, or recently, often contain subtle errors explicitly or implicitly. Which isn’t a problem in and of itself but in a when such posts get used as the basis of someone else’s TIL post these errors often get compounded. As an example I find almost any TIL style post about a text editor to be like this. To give a contrast Chris Siebenmann‘s blog [1] does give focus to what was done. Also the author is reasonably good about making corrections in edits or follow up posts. [1] https://utcc.utoronto.ca/~cks/space/blog/

I have a very different understanding of the situation; the best description of the situation I can find is https://utcc.utoronto.ca/~cks/space/blog/programming/Go116OpenBSDUsesL… (discussed at https://news.ycombinator.com/item?id=25997506 ) - from that article, > The official API for Illumos and Solaris system calls requires you to use their C library, and OpenBSD wants you to do this as well for security reasons (for OpenBSD system call origin verification). Go has used the C library on Solaris and Illumos for a long time, but through Go 1.15 it made direct system calls on OpenBSD and so current released versions of OpenBSD had a special exemption from their system call origin verification because of it.

The reason that motivated me to run a mailserver is best described as an artisanal choice, not a practical one[0]. After all, I'm running this on a constrained system and certainly don't have ambitious to scale this to corporate scales. Like some other commentors here the point is mostly to learn and have something semi-useful at the same time (I've had some pleasant exchanges over my own email already.) [0] https://utcc.utoronto.ca/~cks/space/blog/sysadmin/EmailServersNoLonger…

Now I've read a bit of those links and also read a bit of the following other links: - https://utcc.utoronto.ca/~cks/space/blog/linux/KernelRcuNocbsMeaning - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux… - https://help.ubuntu.com/community/Grub2/Setup And I've changed the following line in my /etc/default/grub from: GRUB_CMDLINE_LINUX="" to GRUB_CMDLINE_LINUX="rcu_nocbs=0-15 processor.max_cstate=5" since my CPU has 16 threads. And I've saved it and have run sudo update-grub Now I'm about to reboot the computer and then hopefully it will be more stable from now on :) Thanks again for the help bilange.

> as far as I can tell it doesn't explain why it suddenly stopped being a problem on OpenBSD. It doesn't. It's just that as previously with macOS, Illumos, or Windows, the Go project ended up with its back against the wall: in this case, ultimately only the OpenBSD libc will be allowed to make syscalls so their choices are "use libc" and "no Go on OpenBSD". And in all honesty the followup https://utcc.utoronto.ca/~cks/space/blog/unix/CLibraryAPIRequiresC is much more convincing as to why it's a hassle to go through libc.

From a follow-up article [0]: > As it happens, I was mistaken about some aspects of the situation with chown. --- [0]: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/ChownSymlinkSafetyII

Follow up about “good” attachments is worth a read too: https://utcc.utoronto.ca/~cks/space/blog/spam/GoodAttachmentTypes-2019…

I've been following https://utcc.utoronto.ca/~cks/space/blog/web/Firefox56AddonWorry It's surprised me the amount some people rely on addons for their workflow and the amount of effort they will be going through to resist this change come 57. For my usage, I've found Firefox Klar/Focus (which I believe already include the speed improvements from 57+?) on Android and have been extremely impressed.

Good! The internet was great before advertising, and it'll be great after advertising. "essentially all of the ad supported sites I visit are diversions" - https://utcc.utoronto.ca/~cks/space/blog/web/AdSupportedWebDeathView

May I disagree partially, using this authors exact words? "... Unless you are a high risk target, spending almost any time beating SELinux into shape on your machine is a bad tradeoff and pretty much a waste ..." -- https://utcc.utoronto.ca/~cks/space/blog/linux/SELinuxToxicMistake If you are a high risk target, SELinux is a great option. Also, to refer to the partial disagreement, here is my exact feeling... "I'm a security aware sysadmin and yet yesterday I casually admitted that I made less-secure choices because the really secure option was too annoying and potentially inconvenient. In fact this is not the only case where I make this tradeoff, picking a less secure but more convenient option..." -- https://utcc.utoronto.ca/~cks/space/blog/tech/SecurityNotImportant

The part about how people "copied an existing init script or thought ... that init scripts needed LSB headers that looked like this" sounded like it to me. I didn't initially manage to follow the right sequence of links to find the example[1], but now that I have, the context seems to be that "System V init ignores all of these" (the parts people copied without understanding), so the description still looks applicable to that example. (They serve no purpose at the point in time when they're added by cargo-cultists but cause problems much later when someone/something assumes that they are actually meaningful.) [1] http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdAndSysVInitScript…

> Is the 80% rule real or just passed down across decades like other “x% free” rules? As I understand it, the primary reason for the 80% was that you're getting close to another limit, which IIRC was around 90%, where the space allocator would switch from finding a nearby large-enough space to finding the best-fitting space. This second mode tanks performance and could lead to much more fragmentation. And since there's no defrag tool, you're stuck with that fragmentation. It has also changed, now[1] the switch happens at 96% rather than 90%. Also the code has been improved[2] to better keep track of free space. However, performance can start to degrade before you reach this algorithm switch[3], as you're more likely to generate fragmentation the less free space you have. However, it was also a generic advice, which was ignorant to your specific workload. If you have a lot of cold data, low churn but it's fairly equal in size, then you're probably less affected than if you have high churn with lots of files of varied sizes. [1]: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Work… [2]: https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSZpoolFragmentation… [3]: https://www.bsdcan.org/2016/schedule/attachments/366_ZFS%20Allocation%…

Author has an article on that too[1] To explain what I learned on my own: If you want to (for example) put 4 NVME drives (4 lanes each) in a 16x slot, then you need two things: 1. The 16x slot actually needs to have 16 lanes (on consumer motherboards there is only one slot like this, and on many the second 16x slot shares the lanes, so it will need to be empty) 2. You need to configure the PCIe controller to treat that slot as 4 separate slots (this is called PCIe bifurcation. For recent Ryzen CPUs, the first 16x slot usually goes directly to the CPU, and the CPU supports bifurcation, so (assuming your BIOS allows enabling bifurcation; most recent ones do) all you need to do is figure out which PCIe lanes go to which slots (the motherboard manual will have this). If you aren't going to use the integrated graphics, you'll need a 16x slot for your GPU. This will at best have 4 lanes, and on most motherboards (all 800 series chipset motherboards from all major manufacturers) will be multiplexed over the chipset, so now your GPU is sharing bandwidth with e.g. USB and Ethernet, which seems less than ideal (I've not benchmarked, maybe someone else has?). In the event that you want to do a 4x NVME in a 16x slot I found that the "MSI X670E ACE" has a 4x slot that does not go throught the chipset, and so does the "ASRock B650M Pro x3D RS WiFi" either of those should work with a 9000 series Ryzen CPU. ThreadRipper CPUs have like a gajillion PCIe lanes, so there shouldn't be…

The "#" key on the phone is called the "pound key" in the US and Canada. https://en.wikipedia.org/wiki/Number_sign#Names It still is, to this day: if you call an automated system such as voicemail, you may be prompted to "press 'pound'". This is really standardized, AFAICT, and no telephone system has told me to "press hash" or "press the 'number' key" [because that's ambiguous] cks has a history of #! but not an etymology: https://utcc.utoronto.ca/~cks/space/blog/unix/ExecAndShebangHistory He links to Wikipedia which documents a good history: https://en.wikipedia.org/wiki/Shebang_(Unix)#History I was trying to recall what we called it. I used SVR3, so I would've been using "#!/bin/sh" as early as 1990, and even more on SunOS 4 and other Unix servers. I can't recall having a name for it until "hash-bang" gained currency later. We knew it was activated by the magic(5) kernel interpretations. I often called "#" as "pound" from the telephone usage, and I recall being tempted to verbalize it in C64 BASIC programming, or shell comment characters, but knowing it was not the same. "The whole shebang" is a Civil-War-era American idiom that survived with my grandparents, so I was familiar with that meaning. And not really paying attention to Ricky Martin's discography. Wikipedia says that Larry Wall used it in 1989. I was a fervent follower of Larry Wall in the mid-90s and Perl was my #1 scripting language. If anyone would coin and/or popularize a term like that, it's Just…

(Note: that was in this article https://utcc.utoronto.ca/~cks/space/blog/programming/ErrorHandlingNotS… Yeah and more generally, the author seems to group Go and C on one side (langs where errors are values) and Rust in another, when actually in Rust errors are values just like in Go, and the ? operator just does early return (similar to if err != nil return from Go). Results just make it impossible to use the return value of some function without deciding what to do with its errors, which is awesome (you can't just forget to treat errors) The distinction between results and panics in Rust is also very instructive. Rust forces the developer to distinguish between recoverable and unrecoverable errors because after the program hit a panic (meant to represent unrecoverable errors) there is probably no meaningful way to continue the execution (data structures might be in an inconsistent state for example, if the panic happened in the midst of an update). Panics very often indicate a bug in the program (for example: array indexing with an out of bounds index means there was a bug while calculating the index) and no amount of error recovery will eliminate the fact that the program has a bug that must be fixed. It's absolutely the best default to interrupt the program after a bug rather than continue and propagate data corruption further. Now, what can happen is that a library you call considered some error to be unrecoverable (and thus threw a panic) rather than…

Monomorphization does not guarantee inlining of lambdas. You can perfectly well output a monomorphized version of the 'contains' method specialized to the type of a particular lambda argument and then call this lambda on each loop iteration in the generated code. (Rust's assembly output is pretty impenetrable compared to Go's, but I believe this is exactly what happens if you compile something like this without optimizations: https://godbolt.org/z/qaYbGMMzM) It does not surprise me that Rust inlines more aggressively than Go, but that doesn't have anything much to do with differences between Rust and Go generics or type systems. Adopting the type-level fiction that every lambda has a unique type does not fundamentally make inlining any easier for the compiler. It may well be that in Rust the monomorphization triggered by this feature of the type system leads to more inlining than would otherwise happen. But that is just an idiosyncrasy of Rust. Compilers can do whatever kind of inlining they like regardless of whether or not they think that every anonymous function has its own unique type. Edit: One further thing that's worth noting here is that the Go compiler does do cross-module inlining. So (unlike in the case of a typical C compiler) it is not the case that the kind of inlining we've been talking about here can only occur if the function and the lambda exist in the same module or source file. https://utcc.utoronto.ca/~cks/space/blog/programming/GoInlinesAcrossPa…

> POSIX allows file descriptors to be shared by an arbitrary number of processes, after e.g. forks or SCM_RIGHTS transfers (even though this use case is most likely very rare, so it’s not entirely impossible for this state to be moved to userspace). Normally it’s rare, except shell functionality crucially depends on it[1]. The way to think about this, IMO, is that while a disk file is more or less random-access, when you open it unavoidably turns into strange hybrid of a random-access byte array and a (seekable) byte stream (classically, the “file description”), and that is what the resulting fd and any of its copies point at. Seekable streams made some sense in the age of tape drives, but nowadays it seems to me that random-access files and non-seekable streams have enough of a gulf between them that forcing both to appear like the same kind of object is more confusing than helpful. (I don’t know what my ideal world would look like, given I still like to direct streams from/to files. I still dislike the “file description” business rather strongly.) [1] https://utcc.utoronto.ca/~cks/space/blog/unix/DupSharedOffsetNecessary

There's been a relatively comprehensive take-down on autoconf (1), that boils down to: It's an old piece of software, with basically no maintainers, which is fantastically difficult to make any changes to. Not... stable because it "just works"; unchanging because it's so enormously complex to make and coordinate even trivial changes, that it is effectively the peak of the software lifecycle, where something has accumulated so much technical debt you can no longer make changes to it. ...so; in that context, being a fan of some features that autoconf supports is interesting, but, makes absolutely no difference to the reality; that it needs to die in a fire and be replaced. Software, that you cannot change, is dead. Especially a build tool, that has failed to be maintained to changing needs of developers. If autoconf wants to live, people need a comprehensive plan to maintain it, not to sing praises of its current, clearly bad, state. > it has been popular to suggest that Autoconf should go away. Yes. ...because no one has a plan to maintain it or fix it. > Some of the people suggesting this have also been proposing that the replacement for Autoconf and the 'configure' scripts it generates be something simpler. Specifically who? Build systems are hard. No one serious, who understands what they're talking about and the context around it that I've seen is suggesting this. ...most people, seem to consistently be suggesting that the current state of autoconf is…

Honestly, I was never convinced that concentrating all developer effort onto Wayland was the best idea. Wayland seemed like a massive over-correction from X11, where the protocol and core were "simple" in comparison to X11 which did everything. Being simple, by itself, is not a virtue -- Wayland basically forced all the essential complexity of the problem to the compositors (a la Waterbed theory of Complexity [1]). Given there are so many compositor implementations, they essentially end up reinventing the wheels all the time. This is a bit better now with wlroots, but unfortunately, the ecosystem is already fragmented. I'm not saying X11 is superior to Wayland or vice-versa, but frankly I would be surprised if we couldn't improve X11 if it got 0.1% of the amount of effort collectively gone into Wayland. I would highly recommend reading through some of these blog posts who expound upon the problems of Wayland more eloquently than I can [2,3,4]. [1]: https://en.wikipedia.org/wiki/Waterbed_theory [2]: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/waylan… [3]: https://pointieststick.com/2023/09/17/so-lets-talk-about-this-wayland-… [4]: https://utcc.utoronto.ca/~cks/space/blog/unix/WaylandTechnicalMeritsIr…

A followup blog also worth checking: https://utcc.utoronto.ca/~cks/space/blog/web/URLPresenceNotGoodSignal > URLPresenceNotGoodSignal > There are a variety of situations where you (in the sense of programs and systems) want to know if a web server supports something or is under someone's control. One traditional way is to require the publication of specific URLs on the web server, often URLs with partially random names. The simplest way to implement this is to simply require the URL to exist and be accessible, which is to say that fetching it returns a HTTP 200 response. However, in light of web server implementations which will return HTTP 200 responses for any URL, or at least many of them, this simple check is clearly not sufficient in practice. The mere 'presence' of a URL on a web server proves very little. > If you need to implement this sort of protocol, you need to require the URL to contain some specific contents.

> What helped C was exactly the same as what made JavaScript sucessful, it came with a free beer platform (UNIX). Your saying that reminds me of this: https://utcc.utoronto.ca/~cks/space/blog/programming/CTriumph > This significantly understates the real appeal of C at the time, even and especially to people who had alternative languages. A great illustration of this is C on the early Macintosh. You see, unlike environments like MS-DOS (which had no language associated with it, just assembler), the early Macintosh systems already had a programming language; they were designed to be programmed in Pascal (and the Mac ROMs were originally written in Pascal before being converted to assembler). > This was more than just an issue of Apple's suggested language being Pascal instead of C. The entire Mac API was designed around Pascal calling conventions and various Pascal data structures; it really was a Pascal API. Programming a Mac in C involved basically swimming upstream against this API, full of dealing with things like non-C strings (if I remember right, Mac ROM strings were one byte length plus data). [snip] > Despite all of this, C crushed Pascal to become by far the dominant programming language on the Macintosh. [snip] C was enough better to displace Pascal in a hostile environment. > C did not win just because it was at the right place at the right time. C won in significant part because it was (and is) a genuinely good language for the job it does. As a result it…