Emelia/Emi

If you can't be with your waifu, become her. She/Her, Rather skittish. Am a giant nerd for trains, old computer stuff, and IPv6.

Follow requests subject to a loose vibe check.

Gender: HTTP 418 I'm a teapot
Location: HTTP 401 Unauthorized
PGP: 8900D5D4DB0AB41140C4012E379261EFD5FEA871
Age: Pre-Y2K
Optimal operating temperature: 68F/20C
Absolute Maximum operating temperature: 74F/23C
Storage Capacity: ~70TB

Public Key

npub18awg073vadjxw7vst9v3dduvxjulc7x7jjyskvqkjfa99xn28zdqj7pj7v

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsr7hy8lgkwker80xg9jkgkk7xrfw0u0r0ffzgtxqtfy7jjnf4r3xspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsphrcnu

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub18awg073vadjxw7vst9v3dduvxjulc7x7jjyskvqkjfa99xn28zdqj7pj7v

Show more details

Last Notes

2026-08-27 21:42:51 GMT

- reply

If the decals are too transparent with a single print, maybe try overprinting the same pattern? That might make the toner layer thick/dense enough to be fully opaque.

2026-08-25 00:39:45 GMT

- reply

Yeah, transactional filesystems are fun, and would eliminate the data *corruption* issues as the server can autonomously rollback "dirty" data, but isn't really relevant to data *loss* which is the main reason clients stall: any data that hasn't had a successful COMMIT (close() or fsync()) remains "dirty" in the client's buffers, so the client risks losing that data if it doesn't stall until the server comes back.
The other thing is that applications generally aren't designed to "gracefully" handle IO errors, even if it's just an EAGAIN "not-failure", so in certain cases it's better to stall awaiting completion or hard error than to fail with a "soft" error. With interactive programs, you can safely "fail fast" when saving and tell the user to pick a different spot, but non-interactive stuff can't really handle that, so would likely just crash.
It makes a *lot* more sense once you consider that it was once commonly used as a rootfs for workstations that didn't have their own disks...

2026-08-25 00:21:58 GMT

- reply

"Yes." NFS was designed with one goal in mind: data integrity. If the server said it committed some data, that data *will* be there when it comes back. But clients thus *wait* for the NFS server if it isn't responding, instead of immediately failing IO operations and likely crashing programs or corrupting data, *supposedly* resuming "seamlessly" when the server starts responding again.
But as part of that, if the server doesn't come back up in *exactly* the same position *and state* as it was when it disappeared, clients may freak the fuck out due to shitty error handling.
Though Linux has especially shit recovery handling in my experience, I suspect the stalled IO continues to hold a critical lock rather than "rewinding", as you can't "remount" the filesystem to change things like "the relevant IP addresses." So there's effectively no way to "recover" a mount if it didn't manage to auto-recover.

2026-08-25 00:03:41 GMT

- reply

You can upgrade a ZFS pool incrementally these days, replacing one drive at a time, then grow the vdev to fill the new drives. Does it get you the new space immediately? No. But it doesn't make you invest in new drives *all at once*.
The biggest issue is the "separation of concerns" between the block layer and the filesystem. ZFS may be somewhat more integrated across the layers than most filesystems, but the vdev layer is entirely unaware of individual files so relies more on a "somewhat smarter" implementation of traditional stripe RAID, and can't really use the fancy allocators that place each copy of a file on different devices that BTRFS and bcachefs use.
If you're that concerned about mix-n-match drives, ZFS probably isn't for you. It's a *very* opinionated filesystem, but those opinions eliminate a significant number of potential problems. Look into unraid if you want cheap "mix-n-match" drives. (or Ceph, but that's *really* designed for systems "too big for ZFS"...)

2026-08-24 23:29:29 GMT

- reply

"anyraid" hasn't really been a thing until relatively recently to my knowledge. Standard "dumb" stripe RAID is just as picky about using the lowest common denominator of all the drives in the array. And the trick is to replace like-for-like unless the size isn't really manufactured anymore (I have an old 1TB "scratch array" that's currently down a drive, and I literally *cannot* find any new 1TB mechanical drives to replace it, to the point I'm contemplating switching it out for an SSD...)
The only filesystems I know that actually support mixed-size drives are BTRFS (which *still* doesn't have a journal for raid5/6, so you're stuck with an inefficient raid1 if you don't want to risk parity corruption that's quite hard to detect until it bites you on the junk) and bcachefs, and the latter was kicked out of mainline for *multiple* reasons, stability being one of them...

2026-08-24 14:23:52 GMT

- reply

That, plus IIRC Oracle refusing to say they *wouldn't* sue someone about it because the license has some "if you're *really* pedantic" incompatibilities with the GPL.
Personally if it wasn't for the developer going insane, I would have preferred bcacheFS simply for better "hybrid" array support (mixed spinning and solid-state pools in one filesystem) but that also got kicked out of mainline for good reason, so ZFS it is for me.
(I still have a single BTRFS pool from back when I was too broke to afford anything but wildly mismatching disks, but everything newer than that is ZFS)

2026-08-23 01:00:41 GMT

- reply

You could just copy the large-object implementation as normal "user" tables, which can be scaled much higher with a different object key and table partitioning, if you can afford to ditch the built-in abstraction provided by large objects. (though again, if you're running into the 32TiB table limit, you should *probably* be looking at something that can properly shard the storage and IO load across multiple machines. Most of postgres's transactional magic is just copy-on-write and a garbage collector, so shouldn't be *that* hard to replicate large object semantics with a separate object store like Ceph if you treat objects as immutable copy-on-write and have an index to easily check if an object is "orphaned."

2026-08-22 22:11:36 GMT

- reply

That's the 32TiB limit I mentioned, so if you're hitting *that* you probably need something bigger than postgres...

2026-08-22 22:07:48 GMT

- reply

It's apparently 2k, per the stackoverflow post I linked, at least at the time that was written, and the OID is per-object, not per-fragment (fragments have an additional "fragment number" field), so that won't actually screw you over as much as you might think, at least in regards to the hard limits. Performance, though, is a different story...

2026-08-22 22:00:53 GMT

- reply

For context, [the actual limits](https://dba.stackexchange.com/questions/127270/what-are-the-limits-of-postgresqls-large-object-facility ) are a maximum total size of 32TiB, 4TiB per object, and 232 objects (as the object key is a 32-bit oid). Not that unreasonable for storing a small number of larger objects like videos, but the continued use of a 32-bit key for this is rather odd for a database that can otherwise scale to the moon...

2026-08-18 09:45:38 GMT

- reply

The UK's defamation laws are *royally* fucked, to the point the US had to pass a law explicitly rendering their "judgements" unenforceable here. *Truth is not an absolute defense* in UK defamation suits, somehow.

2026-08-14 20:43:32 GMT

- reply

Given that you're usually supposed to recapture the refrigerants when decommissioning refrigeration systems in a lot of places, I'm surprised it's even *legal* to sell something without the service ports necessary to do so...
If I had to guess, the regulations probably only require that for the "particularly nasty" ones, and propane isn't 'that' nasty compared to many of the modern refrigerant hydrocarbons?

2026-07-25 23:10:50 GMT

- reply

I do think there's plenty of room for change in response to something like that, but it *cannot* be the irrational emotion-driven stuff that 9/11 was here in the US, yeah.
It's hard to describe just how Boston changed after the marathon bombing, but most of it was generally hidden well under the surface, not a big public security-theater like TSA. It didn't really change our perception of 'safety', and we didn't start serializing pressure cookers, it simply shattered the illusion that "stuff like that doesn't happen here" so we started implementing controls against the most obvious methods.
The most visible change is bollards. Bollards *everywhere*. And if you need something portable and permeable to people on foot, they make those too. And if you *really* need to stop a car, like across long straight cross streets they can build speed on, dump trucks full of dirt and larger snowplows work great. Those won't budge for anything smaller than a bus.

2026-06-23 21:48:57 GMT

- reply

I tried the "milk tea" one from my local place, and it's really tasty. Understandable about the bubbles though. (They're just tapioca, so they soak up whatever fluid they're in. It's not really *possible* to give them a different flavor AFAIK)

2026-05-11 14:03:31 GMT

- reply

I wonder if the 'raw' depth camera is even accessible to regular software? If it works in NIR, I'm half tempted to play around with it simply for that... (In MacOS that is. I'm not allowed to put Asahi on my work mac for obvious reasons, and my only "personal mac" is an old Core2-era mini I use for firewire DVcam stuff)

2026-04-29 14:05:50 GMT

- reply

My (very) limited Japanese can corroborate that the label certainly says "Blueberry," yeah. Not exactly sure what was going through their head with that mix, cherries and carrots aren't flavors I'd think of as going well together.

2026-04-18 15:06:05 GMT

- reply

If you have a flatbed scanner, one of the tricks I've seen is to scan the flattest side of the PCB with a ruler next to it, which avoids the perspective distortion of a photo, and can give you reasonably accurate measurements.

2026-03-25 00:21:11 GMT

- reply

(You can also explicitly specify curl.exe in powershell to bypass the obnoxious alias)

2026-03-17 21:37:12 GMT

- reply

That was one I was (fortunately, it turns out) unfamiliar with. Looked up a summary of the drama, and What. The Fuck. Yeah, that's *bad*.
And here I thought I already knew "bad endings"... Nah, this one was worse. *Much* worse. Now I must go bleach my eyeballs with some trashy isekai... At least a few of those aren't *terrible* due to the sheer *quantity* of them...

2026-03-04 16:48:20 GMT

- reply

My two distro recommendations for "you install it and then never need to touch the thing again" are Mint and Debian. I installed the latter for my father (who's technical knowledge only really extends as far as "knows or can figure out how to put in the wifi password on most devices") several years ago when he wanted to get away from windows, and the only real issue since was the laptop *physically getting stepped on* at one point and thus needing a replacement screen.
Yeah, debian stable doesn't come with the latest and greatest versions of everything, but for the vast majority of people it doesn't *need* the latest and greatest versions of software. It just needs to *work*...

2026-02-19 15:41:29 GMT

- reply

Unless those apps are running localhost to the reverse proxy, Wrong. Any traffic containing credentials should be encrypted over the wire, and yes, that includes LAN. That's frequently a blanket requirement for insurance and security certifications these days. Yes, even if the reverse proxy is terminating TLS from the client.
(Of course, I'm not a moron, so *homelab*-grade software can allow for running without TLS and there's approximately a 99.99% chance you won't have any problems with that. But if you want to use it for anything *remotely* serious, Encrypt Yo' Shit)

2025-12-09 15:26:20 GMT

- reply

Interesting to see a bit of the process, and I think one of the issues might be the compression-induced "vaseline filter" on the image in the original post? Your post has a much less compressed version that's much sharper and thus more *obviously* not AI (My initial verdict was "probably human, low confidence" due to the compression making it hard to *confidently* determine "human" until your post)
(But I can *see* where the original accusation was coming from, even if I would never have made it myself: with the heavy compression in the original post it's *much* harder to determine if possible "tells" are actually *tells*, or just Compression...)

2025-11-30 03:46:38 GMT

- reply

So copying the PDP-8 completely is out, but what I meant is that you can still "define" the jump target as "the instruction before the subroutine" even if the word at that address is never actually used by the CPU.
(Or you could go the Cursed Option, if you're not doing a true harvard arch: instead of just writing the PC+1, write a *jump instruction to* that PC, which *also* gets the target increment for free thanks to that behavior. Then the 'ret' is just a hardwired jump to that 'thunk')

2025-11-30 03:38:52 GMT

- reply

Technically you wouldn't even need to add a NOP, since the first instruction would never actually be executed (unlike with delay slots), you can just subtract one instruction-length from the target address when assembling it (or simply define it as "the instruction *prior* to the target function, which need not be a valid instruction", similar to PDP-8 subroutines. Although that also wrote the current PC to the target address to function as the return pointer)

2025-11-26 16:47:14 GMT

- reply

Yep. one of the "trainings" I had to do on it conflated "confidence about" with "use of" the damned things. There was no option for "I don't use them *because* I'm confident about how they (don't) work"

2025-11-10 18:23:27 GMT

- reply

That assumes an internet connection fast enough to keep up with the volume of data that needs to be backed up, and LTO tapes are a lot less delicate to ship than spinning rust is. (And keep "shelf-stable" a lot better when unpowered, whereas SSDs are "Just Don't" and most spinning rust doesn't like sitting idle either).
But that's quite a bit more cost effective *if* that assumption of good internet holds.

2025-11-03 20:09:58 GMT

- reply

Unless there's some requirement for diodes on the output of the rows due to the logic interface, you could eliminate the diodes entirely with the exact same ghosting. (if you hit switches SW9, SW10, and SW11 at the same time, you'll get a phantom SW2 as well)
For ghosting to happen, there needs to be at minimum three keys held down to form an "L" shape on the matrix, so "extremely unlikely in the course of normal typing" but *gaming*, where you frequently press and hold multiple keys at once, might have issues depending on the exact mapping of keys to column/row.

2025-10-31 18:12:00 GMT

- reply

Missing NS or glue records somewhere if I had to guess. Whoever you register it through is *supposed* to tell the TLD operator about the nameservers for the domain so they can create the proper NS records for it in the TLD zone.dig +trace
might show you where the discontinuity is, if you haven't tried that already.
(I also had a problem when I switched DNS providers due to my ISP using an extremely aggressive DNSSEC cache that *never* updated the DS record until TTL expiration, even in the case of a failure, so the entire domain SERVFAILed for a few hours until that expired...)

2025-09-12 20:05:29 GMT

- reply

Did it involve the Therac-25 story? That one's made even 'better' by the older models having the exact same software issues, but *had hardware interlocks* that properly tripped when the bugs put the machine into an unsafe configuration...
EDIT: Also, a note for proper interlock design: add a few "overlapping" sensors and cross-check them to check for bad sensors. If the "door shut" and "door open" sensors are active at the same time, *something's* gone wrong with one of them, and the system is now in an unsafe-to-operate state until a human goes and fixes the conflicting sensors.

2025-09-08 12:57:12 GMT

- reply

I've been tempted to mod one of those old staples easy buttons into a push-to-talk for when I'm in the office. Teams (or even windows itself, by muting the input) *really* needs global push-to-talk...

2025-09-06 23:15:59 GMT

- reply

At least with the dishwasher pump I had the freedom to tip the thing backwards so I could prod at the underside unimpeded... First time it turned out the pump wasn't broken, the impeller was just jammed by a load of beans (WTF?) and the second time was a *big* giant glass shard from Something. How the hell those even made it through the sump filter, I have no idea.
From the second photo you posted, I suspect what happened is that water got through the seals and corroded away the innards until either the windings shorted or the assembly seized; I suspect the cracked magnet was caused by the corrosion (probably rust-jacking from the corroding bits), but is otherwise unrelated to the motor failure.
(This also reminds me to spin my garbage disposal, since I never use it and it tends to seize up with rust if I don't spin it once every 2 weeks or so...)

2025-09-06 22:52:35 GMT

- reply

Sorta reminds me of the time that I had to replace the belt on a dryer: I had gotten the belt around the drum, but in order to properly wrap it around the tensioner I had to have each of my arms shoulder-deep in a different hole, with my head mashed up against the frame, thus doing the whole thing totally blind. Thankfully it was a pretty simple arrangement...

2025-08-20 23:20:09 GMT

- reply

Honestly the right thing to do at least for the 2fa case would be to use hardware-bound secrets and attest *that* fact specifically, which is a much smaller security boundary and vulnerability surface to 'trust', which mostly eliminates needing the entire OS image to be "verified" in some way or another.
But unfortunately banks and lawyers will still probably be banks and lawyers unless the regulations are clarified or rewritten...

2025-08-20 21:56:28 GMT

- reply

And that's honestly a pretty significant problem that demonstrates that any government entity pushing for it knows jack shit about *actual* security, because outside of a few specific "I have legitimate reasons to care about the exact firmware running on a given device" cases, the security model of device attestation is nothing more than a bandaid over bad design.
If a bank app is literally just their website in a tin, they have *zero* legitimate reason to care about the specifics of the OS I'm running, regardless of what the government thinks. If I can freely access what's effectively an identical interface from a PC running windows 7 without any secure boot or remote attestation, there's no justification to force it on mobile users just because it's a feature that exists. Why does the *entire OS* need to be as 'trusted' as the dedicated secure element for anything a banking app would need to do?

2025-08-20 19:52:35 GMT

- reply

IMO a better option would be for governments to properly regulate the usage of remote integrity attestation as "presumed anticompetitive collusion until proven otherwise" in consumer contexts, unless there's an actual justification other than "because it's there", as well as a requirement to minimize which features actually *depend* on it, so "website in a tin" apps can't artificially restrict OS choice just so they can cover up their failure to properly check privileges and permissions on the server side...
(The *only* case where it makes actual sense to me is MDM on corporate-owned/BYOD devices ensuring that they remain in an authorized configuration that supports the required security controls. And *maybe* payment apps that interact with the secure element, but isn't that also the *whole damn point* of the SE?)

2025-08-16 20:13:41 GMT

- reply

This is why my only NFS exports are complete BTRFS subvolumes or ZFS datasets. Those are both proper mountpoints, so they get distinct fsids, which *are* checked by default AFAIK? (you need to use the non-default crossmnt or similar to get an export to even *accept* more than one fsid in my experience)

2025-08-04 23:50:59 GMT

So I just found a bug in gedit, probably an off-by-one. Loading a large (~4k lines) UTF-16LE file results in gedit 'skipping' a byte and mangling the rest of it about halfway down. Unfortunately the files I have aren't good samples to be able to identify exactly where it is, though...
(I know full well that it's gedit being dumb, because A: it works in the original software, and B: this file decodes fine via both iconv and *python*, with gedit able to open the resulting UTF-8 output just fine. Python has *notoriously* picky decoders in my experience)

2025-07-27 22:24:39 GMT

- reply

My employer's retention policy training had me going "They were retaining ID documents that they *didn't legally need to?* Yeah that's damn near gross negligence levels of fuckup *on top* of the open bucket..."
PII Data isn't oil. PII Data is nuclear waste, and government identification is particularly spicy. Unless you're legally required to keep it, *get rid of it ASAP*.

2025-07-25 14:41:28 GMT

- reply

The problem is that as hardware has progressed, the tech stack has eaten *all* that additional performance and more. Bloated Java applets and flash would probably *fly* on modern hardware, for a 'fair' comparison.

2025-07-11 23:41:41 GMT

- reply

A lot of services *will* spambucket mail coming from a domain without SPF, but often won't outright *reject* it, because SPF was a retrofit and they wanted back-compat for postmasters that couldn't be assed to set it up. Not that they *shouldn't* codify it in the RFCs as a SHOULD eventually, just that they haven't chosen to do that yet for Internet Politics reasons.
Explicitly telling MTAs "this domain shouldn't be allowed to send email" on the other hand removes all ambiguity, regardless of future RFCs.

2025-07-11 23:31:07 GMT

Random admin advice: Do you have any domains? Add a wildcard v=spf1 -all TXT record to your DNS zone to prevent spammers from impersonating nonexistent subdomains, regardless of whether you actually use the domain for email. (If you do use it for email, the specific sending domains should already have their own SPF records, which override the wildcard)
Normally I don't like cloudflare, but they have a [reasonably good article](https://www.cloudflare.com/learning/dns/dns-records/protect-domains-without-email/ ) on why (and how) you should do this.

2025-06-23 19:40:00 GMT

- reply

That is a *tiny* condenser unit. I didn't even know they *made* ones that small.

2025-05-31 17:29:38 GMT

[@privateger](https://plasmatrap.com/@privateger ) Dockerized postgres/mysql *in general* is a footgun. It's fine for "sqlite-ish" stuff like dev machines needing a test DB the software can talk to, but for anything else, *put it on a VM or bare metal*.
(Or a systemd-nspawn container, which can be a normal mutable OS install just like a VM, but running as a container)

2025-05-12 20:03:47 GMT

- reply

Sanitizing, validating, and *normalizing*. Don't forget the last step, lest you have three different versions of the same key in a supposedly-unique column because someone did UTF-8 crimes.

2025-05-08 12:47:06 GMT

- reply

MS-DOS and friends used that exact method, albeit with a few more registers available
The 6502 had a bunch of performance constraints around BRK (shared handler, so you have to test a flag from the stack to know if it's a BRK), which is presumably why the apple 2 and c64 didn't do software interrupts and instead provided a fixed-address thunk-table of sorts, similar to modern dynamic linkers.

2025-03-15 18:09:20 GMT

- reply

(Fully agree) And in a lot of places it's also not just how (not) easy it is, but lack of bandwidth: the major ISPs out in the US usually provide *wildly* asymmetric bandwidth to residential customers, on the assumption that anyone that wants to host stuff is A Business and can pay Business Prices... I live less than a few miles from a major internet exchange, and yet I get a whopping *20Mbps* upload. For over *400* down. If I wanted to give friends access to that nextcloud instance, it would be slower than dirt for anything more than a few images at once...
My parents' internet only gives 10Mbps up, and since that's where most of my lab is (slightly cheaper electric), I can't even stream 1080p in realtime without crunching it down to the point 720p genuinely looks better..

2025-03-10 17:45:56 GMT

- reply

Same here, given that my grandfather literally did exactly that a few years back.
My bigger problem is that I've since picked up anime figures and model trains, the latter of which in certain configurations are even more expensive than old computers, given that they require a good bit more horizontal space to operate... And I still have access to the MIT flea market in the warmer months... (you can find all *sorts* of fun shit there. SGI machines, NeXT boxes, a SparcStation lunchbox, Old telephony line cards, etc.)

2025-03-07 23:13:13 GMT

- reply

Indeed. Not mine, thankfully.
Degaussing a tape is a great way to quickly erase all the data on it, but it also erases *all* of the data on it, including critical metadata and servo tracks, which the drive needs to keep the head properly aligned. (hard drives and burnable optical media have similar structures: the actual writing head tracks and floats in a 'groove' of sorts, because it's nowhere near accurate enough to maintain a consistent position relative to other tracks without it)

2025-03-07 22:15:03 GMT

Ah, lazy resellers... I just acquired a bunch of used (the listing had clear pictures of new-in-shrinkwrap tapes...) LTO6 tapes that *still had data on them* from the last person that used them. (Some mac backup program. Unknown which one, but the tape "header" file started with RxvrDlt)
At least they didn't "erase" them with a degausser, which destroys the tape...

2025-03-05 05:52:23 GMT

- reply

The latter is actually piping the output of a subshell into stdin, although it is the same construct as other FDs. From some digging, the correct forms are either<code>exec 3<> /path/to/file bwrap --seccomp 3 ... </code>
or <code>bwrap --seccomp 3 ... 3</path/to/file </code>
depending on if you want the fd to be read/write or read-only.
And /proc/$pid/fd/ is one and the same with the integer file descriptors, it's just a way to see which process has what files open, and optionally to access them "out of band" (which is occasionally useful, since you can retrieve open-but-deleted files that way)

2025-03-05 05:29:41 GMT

- reply

The only way to invoke child processes on linux is via exec() and friends, so if you're invoking bwrap via popen() (even if via an abstraction) all you need to do is clear the O_CLOEXIT flag on a memfd you stuff the BPF code into (which would ideally be done by the abstraction, of course)
bwrap does it that way because seccomp stuff is "a bit too unwieldy" to describe in command line parameters, since it takes compiled BPF bytecode directly. Much easier to make a memfd and pass the blob along that way. (If I had to guess, the reason it takes an fd over a filename is because you can use anonymous memfds without needing a writeable tempdir? not sure why there's not a "from file" option though; at least there's *probably* a bash-fu way to pass an fd for a file to something. Never had a need to, so don't know off the top of my head)

2025-03-05 04:39:36 GMT

- reply

Oh yeah, there *definitely* needs to be a more idiomatic way to use bwrap and kin. Especially given that some of the options use fds, and most non-C languages have abstractions that hide the raw integer; an idiomatic library wouldn't require every user to break the abstraction just to use the seccomp parameters.

2025-03-05 04:20:55 GMT

- reply

The problem is that setting up namespaces really needs a clone() call where you continue execution in the child process before actually jumping into the target code, and AFAIK a lot of non-C languages don't really support that all that well without some pretty gnarly FFI shenanigans: plain fork() or clone() can hurt pretty bad for processes with a lot of frequently-touched RAM like a JVM (or anything with a compacting GC, really), and the mitigations for that are "do not use this for anything but immediately calling exec()" levels of footgun, so you'd practically need to call into a separate executable regardless...
At least since you're usually passing the argv array directly to bwrap instead of a single big string that needs to be parsed, it's not anywhere *near* as prone to command injection vulnerabilities as system() is, since it's much harder to confuse something that doesn't really need to actually *parse* all that much...

2025-03-05 02:04:01 GMT

- reply

Yeah I'd say for media files, unless you have a specially-hardened fully-memory-safe parser (that supports first-class resource limits for stuff like zip-bomb prevention), you're better off stuffing that off into a subprocess call to let the OS do the resource limits for you, even if the subprocess is still using "safe" parsers.
If you're using subprocess sandboxing anyways, I'd also consider looking into cgroups for additional resource limits; they can do a lot more than you might think, including memory and CPU time and such *as a subset of their parent cgroup*, so you can make it so they can never starve the service itself of CPU time, even if you have the service already limited by a cgroup and accidentally start shitloads of them at once.

2025-03-05 01:22:38 GMT

- reply

For sandboxing: Do what nautilus does and use something like bwrap ('bubblewrap') to stuff it in a micro-container with no access to anything but OS library paths and a tempdir for input and output files. It works similarly to apple's "blastdoor" setup.
Optionally, use something like apparmor/selinux on top of that, as you can define 'child' policies under a parent policy that are far more restrictive than generic policies for them can be. (I have no idea as to the actual terms for this, I just know it's possible from looking at CUPS. This would require some shenanigans/effort to pull off, however)

2025-03-02 01:48:32 GMT

#cuteposting [source](https://www.pixiv.net/en/artworks/120840360 ) "What, exactly, is *that*?"
https://media.tech.lgbt/media_attachments/files/114/090/299/210/237/580/original/2764029a5aeeaa54.jpeg

2025-02-25 01:54:34 GMT

- reply

Lunchbox! We need more modern computers in that form factor... (Like "actually sturdy ones you can put the screen on top of" rather than the flimsy little micro-PCs these days)

2025-02-23 02:48:59 GMT

- reply

My favorite is either the "exploding capacitor" or [this one](https://www.pixiv.net/en/artworks/112207676 )
https://media.tech.lgbt/media_attachments/files/114/050/907/454/016/273/original/0ec30d22f7a5f5bc.png

2025-02-22 02:15:44 GMT

- reply

There are certain IP address ranges that shouldn't even be *physically connected* to internet-facing networks, much less routable...

2025-02-21 00:00:18 GMT

- reply

Debian at least ships it pre-configured for sshd (and has a bunch of "ready to use" filters that you just need to turn on with a jail config), but I mostly just use it to keep the logspam down; nothing gets logged if their traffic gets dropped by nftables.
I treat it as more of a "really, stop knocking on my door" tool than an actual security boundary, as any half-determined attacker (like the various "AI" scrapers) would just keep trying from different IPs.

2025-02-19 00:58:48 GMT

- reply

Nope, was just the drive being "too new" or similar for the original IBM firmware. Cross-flashed it over to BDT firmware (the original manufacturer of the thing) which is *way* more up-to-date, and it detects the drive perfectly.
Also, I still get a kick out of how the library deals with unlabeled tapes when running an inventory: It keeps retrying at different focal lengths, until it eventually gives up and *pokes at the slot with a stick* to physically verify whether there is or is not a tape there. (The back of the slot has a "nobody's home" barcode to speed up scanning empties)

2025-02-19 00:16:29 GMT

- reply

...and it looks like the drive is actually an OEM locked-down drive that won't operate in any of the 'standard' libraries, even HP's own. The drive doesn't even say which OEM it was sold to.
If I can't get the HP "personality" to recognize the drive, I may actually have to return it to the sender as "item not as described - is locked to libraries of an unknown whitelabel seller"
The particularly infuriating part? *all these fucking libraries are the same damn part*: A BDT FlexStor II. Except the HP model uses a different LCD for whatever reason.

2025-02-18 23:51:27 GMT

- reply

And turns out the sheet metal is *way* softer than I'm used to. A shitty pair of pliers later, and the drive now connects fine.
Of course, the drive's fan is *way* louder than the enclosure, given that it's a half-height drive and thus a 1U fan...

2025-02-18 23:19:03 GMT

Tape library arrived. Is *big*. And also in surprisingly good condition, because the seller *properly packaged the fucking thing*, even if they had to do a "build-a-box" tape-fest because they didn't have one the right size for it.
It has since been configured to use exclusively IPv6 for the network management interface, because that's what my lab runs on. Thankfully that's only really needed for inventory moves, aka load/unload; AFAIK normal "usage" can hopefully be done via the SCSI media changer interface over the SAS port.
I also confirmed that I do indeed need to bend the drive sled back into shape before it will fit, which is annoying since I won't be able to load the drive for transport to its final destination... (which is also where the tools to fix it are)

2025-02-14 16:04:44 GMT

- reply

IMO the only "application firewalls" that should even be a thing are simple 'stupid' ones: rate limiting, bot rejection via injected proof-of-work challenges, and "this client is spraying *known* exploits and so is clearly malicious" (requesting wp-admin on a non-wordpress site, verbatim exploit attempts towards unrelated applications, etc., *not* "potential" exploits)

2025-02-14 05:08:51 GMT

- reply

IMO there is a good reason for the BIOS to have at least a primitive networking stack: network booting. But *by god keep that disabled unless actually attempting netboot*. Outside of that very specific scenario, the BIOS should *never* touch the network card. (Traditionally this was implemented in the network card as an option ROM, but with onboard Ethernet I don't see a problem embedding the relevant module into the BIOS for cost reasons, assuming it lies dormant until called upon to netboot)
I set up a netboot server in my lab for various install/recovery media and never looked back. No more random "did I get the partitioning right on this flash drive?"

2025-02-13 05:39:36 GMT

Note to self: btrfs and kernel-nfsd *really* do not get along. I'm getting deadlocks every few days on my server because of it.
And unlike last time, it doesn't appear to be related to 'loopback' NFS, so this is very definitely "someone did a fuckup with lock ordering again" and not an actual "dependency loop"...
At least I'll soon have enough tape to be able to move the beast of a dataset over to ZFS, although I'll need some new drives as the existing pool is "a bit mismatched" (which btrfs is fine with, since 'raid1' really means "two copies of each extent, on separate devices" which doesn't particularly care about device size)
(if anyone wants to take a look at it, I can upload the stack traces; it's an unmodified debian kernel version 6.12.9-1~bpo12+1 with openzfs. The latter doesn't appear anywhere, and continues working as if nothing went wrong, so I'm pretty sure that's not a problem)

2025-02-10 22:46:31 GMT

- reply

"stealthy" as in "unlikely to get detected *by the victim*". Someone would have to notice and track down the connection to that channel in the first place, unless discord is actively looking for "anomalous" activity.
Stealth in malware is not absolute, it's merely a delay, and this is a rather effective way to obscure the communication channel, even if it does end up biting the creator in the ass when its discovered.
Certainly less obvious than the old IRC C2 setups...

2025-02-10 22:30:16 GMT

- reply

I mean, if you're not aiming for corporate targets, that's actually a pretty stealthy and reliable way to do it. Looks just like legit discord traffic, so impossible to block at the network layer without either invasive TLS inspection or flat-out blocking discord entirely.
The only "non-stealthy" part is if *discord* notices and bans you...

2025-02-09 22:23:24 GMT

Source of tobacco stench identified: some asshat is either smoking in the hallway, or dragging their smoke back into the building with them. It was *much* stronger in the hallway when I walked through it at the right time.
The hallway's smoke suppression system (keeps the hallway at a higher pressure to keep smoke from apartment fires within that unit) was dutifully doing its job and forcing all the stink into the nearby units.
And unfortunately I think the landlord may not have a recourse against them if they're smoking off-property, even if they come back still radiating the stench of a thousand burning tobacco farms... Of course, *I* have a recourse against them under existing legal precedent, but that requires *money and time* to actually sue the other tenant (it falls under "nuisance" and "violation of quiet enjoyment")

2025-02-08 02:16:28 GMT

- reply

In other words, the problem isn't a "lack of crew", it's poor safety standards with regards to handling the results of defect detectors, combined with overly-long trains. The biggest problems with the long trains themselves are stopping distance and "how long it takes the crew to walk back to inspect it."
The former is what led to the derailment, as they couldn't stop the train in the time between the last detector going "holy fuck" and the wheel falling off, and the latter leads to even more management pressure against stopping the train if a defect is perceived as "marginal": a stopped train not only delays the train, it delays the *line*, and the longer that train is stopped (because it takes fucking forever for the engineer to walk a mile down and back to inspect it) the bigger the hit to the company pocketbook.

2025-02-08 02:09:26 GMT

- reply

If this is the incident I'm thinking of, it was a "hot box" bearing failure from an ancient freight car that was made with journal bearings (which are much more prone to hot box events) and was detected multiple times by wayside defect detectors (which is what allows them to safely run with so few crew the vast majority of the time) so it wasn't particularly a "lack of crew vs train size" problem in this instance: as they complied with the safety rules by-the-book, and unscheduled stopping of a train is a *big fucking deal*, more people almost certainly wouldn't have stopped it.
The actual problem was insufficient standards for addressing a hot box event: they had *two detectors in a row* fire off about it, with the temperature skyrocketing between them, but because the temperature was slightly below the magic "threshold," they kept going until they hit the third detector, which then told them that the bearing was pretty much a liquid. It failed while they were in the process of stopping the train.

2025-02-05 04:19:34 GMT

- reply

And not just key management. By incorrectly conflating encryption with authentication and flat-out blocking access to the encrypted sectors, they made it effectively impossible for an end-user to even verify that the drive was *encrypting the data in the first place* without getting into invasive analysis techniques most places wouldn't bother with.
My ideal "self-encrypting drive" would just be encryption *offload* to trusted hardware, like how the PS3 does it: there's a hardware "ENCDEC" block in the southbridge that transparently intercepts sector data to/from the drive to do encryption, so the CPU doesn't have to pay it any mind at all, but it's still done in *trusted hardware* vs "whatever random drive you happened to shove into it"

2025-02-03 02:51:57 GMT

- reply

To clarify the last part, 'device' is the technical term for "the assembly that screws into the wall box and has the outlets on it", not the appliance plugged into the wall. So the daisy-chaining occurs entirely within the wall, same as what's inside of a power strip.
The only 'daisy chaining' from actual *appliances* that I'm aware of is older desktops (as in "they sit under the monitor" desktop) like my SparcStation having an AC passthrough (usually switched?) for the monitor, using a C13 socket.

2025-02-03 01:42:42 GMT

- reply

The "single 15A outlet on a 20A circuit" is mostly the spirit of the "no oversized breakers" rule. Where you have *multiple* 15A outlets, the most likely source of overload is "too many things," so no individual outlet is overloaded, but with only a single outlet, the *only* way to trip the breaker is to overload that outlet, meaning that the breaker must be matched to the outlet's rating.
EDIT: but it's also perfectly fine to use 12-gauge wire on a 15A circuit, and in fact it's quite common: "it's what we had on hand", thermal derating in a full conduit, voltage drop for long runs, etc. so the easiest fix if you do accidentally do that is to just swap out for a 15A breaker on that circuit.

2025-02-03 01:41:48 GMT

- reply

For the first part, mostly just that some people are *idiots* and would plug them into the same circuit, but most of the actual *safety* issues only come into play if the different plugs are not sufficiently isolated from one another (such as with the "microwave transformer jankwelder" using two 120v plugs to get 240v) at least assuming the breakers are working as intended. If they're not isolated, the exposed metal bits on the unplugged end can rise to 120v if only one is plugged in. Specialized equipment, like servers with redundant PSUs, are generally installed by people that "know what they're doing" and as such are not subject to that rule.
The daisy chaining is perfectly safe: there's a two-screw "bus bar" on each side of the device that handles all the 'passthrough' current.

2025-02-03 00:58:24 GMT

- reply

A single load using multiple plugs is generally "frowned upon" for very good reasons, so the only valid reason to have a 20A circuit feeding 15A outlets is simply to have *more* 15A outlets, or multiple <15A high-draw loads on the same circuit (which under load calculation rules is effectively the same thing: max outlet count is based on estimated load per outlet)
The 'daisy chain' configuration I was talking about is for the in-wall wiring: power from the breaker goes to one device, then it's "daisy chained" *through* that device to the next one.
Also, the only case where you *can't* use a 15A outlet on a 20A circuit is when you only have a single outlet. It's actually rather difficult to break that rule though, since the vast majority of devices are duplex (two outlet), and as such meet the "more than one outlet on the circuit" criteria.

2025-02-03 00:13:32 GMT

- reply

I'm not kidding about the "15A" outlets almost always being 20As with a different plastic face. If you take one apart, you can see the bits for connecting to the 20A's rotated blade. IIRC either NEC or UL requirements were updated to effectively require that a while back, explicitly *because* you can make a legal 20A circuit out of multiple 15A outlets, and one legal wiring configuration effectively "daisy chains" the outlets (takes up less space in the box than a pigtail, but is also somewhat harder to work with, IMO. Wago pigtails all the way)

2025-02-03 00:05:58 GMT

- reply

The kitchen circuits themselves are perfectly legal: they have more than one 15A socket on each 20A leg. The requirement is because the circuits may have *multiple* high-draw appliances on them, not a single big fat 20A appliance, so it perfectly complies with both the letter and spirit.
As for the range plug, I use the oven enough that it would be too much of a PITA, plus the thing's buried behind the oven.
The only reason a UPS needs a bigger plug than the load is because it needs to charge the batteries while the load is running. If you can charge them from a *separate* circuit, you can split the combined load.
The extension cord option relies on the outlets being "sneaky 20As" (because they *are* 20A outlets with a 15A faceplate) and putting a "15A" plug on the wall end of a big fat 20A-capable extension cord and just plugging the UPS into that instead. Basically making a really long adapter, since everything in that chain *supports* 20A, they're just physically configured to not "allow" it.

2025-02-02 23:43:33 GMT

And yet again I am reminded the hard way that I should have a UPS (My money's on "rat/squirrel" or "excavator"). Unfortunately the only UPSes big enough to run my desktop *won't plug into anything in my apartment* because the builders were complete cheapasses and ran 15A circuits.
And for the mandatory 20A circuits in the kitchen? 15A outlets "because fuck you that's why."
My only option for a UPS is one that either does some hinky shit to charge from a separate circuit than the load is on, or stringing a big fat 10-gauge extension cord across my shoebox from the kitchen after bodging a 5-15 make-a-cord on the wall end. (In the US all modern 15A outlets are really 20As with a different faceplate, so this is perfectly *safe* to do, if not quite "up to code"...)
(I *somewhat* miss my parents' basement, because the ceiling is unfinished I was able to run a big fat 20A circuit to the rack for the UPS, with room to upgrade to a 240v-30 feed for the fatass rackmount models if needed)

2025-01-22 01:48:00 GMT

- reply

As an aside, does GrapheneOS have a way to protect global settings against invasive apps that have *zero* business reading their state? I rather like having 'show taps' on, and my bank apparently thinks that's a "security risk"...
Honestly given that 99% of modern banking apps are literally a browser in a tin, and browsers *don't have that attestation bullshit*, I'd argue that they have no right to be attesting against the OS *at all* for 'basic functionality'. About the only place they have an actual reason to be doing so is operations involving the camera, where there's an actual justified need to ensure it's a real camera.

2025-01-22 01:42:21 GMT

- reply

Banks really need to get a reckoning with regards to this "checkbox security" bullshit. Unfortunately government regulation is often written as "you must follow every checkbox to the letter on this list written by an uneducated bureaucrat that went to defcon once" so the problem persists...
My bank's app won't run if *developer settings* are on, much less ADB. There's just 'a few' problems with that with regards to actual security:<li>Aside from mobile deposit of checks, there's nothing in the app worth locking down (it's a browser in a tin)</li><li>modern Android blocks debugging of release-build apps</li><li>adb no longer allows backups to access <code>/data/data</code> for non-debuggable apps</li><li>Apps can check if the debugger is attached</li><li>And finally, if I was somehow using the debugger to be malicious at it, I could simply jump over the checks</li>
(In other words, banning *developer settings* is in the words of raymond chen, a check that's on "the wrong side of the airtight hatch.")

2024-12-29 04:16:43 GMT

- reply

That sounds quite similar to how the apple 2 did "zero wait vram": the video generator only used the RAM on the second half of each cycle, when the 6502 always releases the bus. (And IIRC the video generator also touched every DRAM line, so it did double-duty as "free refresh")

2024-12-25 02:27:08 GMT

- reply

Maybe this design would work? Depends on what you want to put the outputs into, I guess.
https://media.tech.lgbt/media_attachments/files/113/711/088/587/821/625/original/50670555af52d174.jpg

2024-12-16 20:00:44 GMT

- reply

Long story short: CEO of Automattic sent a trademark threat letter to "WP Engine" because he apparently felt that they were "mooching" off of the codebase and wordpress.org (despite the code being *open source* and Automattic 'officially' having nothing to do with wordpress.org... it's owned directly by the CEO)
After being (rightly) told to fuck off because trademarks don't work that way, he threw a tantrum and IP-blocked their access to wordpress.org, as well as adding an "I am not affiliated with WP engine" checkbox to the login page.
Given how disruptive this is to WP engine, they filed suit for an injunction that was just granted, forcing wordpress.org to allow them access until the matter is resolved in court, which caused the CEO to go *mental*, and so instead of simply *removing* the enjoined checkbox within the 72 hours, they changed it to something nonsensical.

2024-12-16 19:43:46 GMT

Finally got around to setting up postgres "backups." (To a different disk on the same host. rsync to my NAS is TODO) Why does postgres streaming replication not support first-class bandwidth limits... I *really* don't want to simply *throttle the fuck out of it* directly with iptables... (I really wish docsis had better upload speeds...)
(Also, it's nice that pg_combinebackup exists, which allows for maintaining a rolling "base backup" for a retention policy, which is useful on small but high-turnover DBs, while still allowing for "every backup send is incremental")

2024-12-09 16:17:53 GMT

- reply

If most of what you're doing is copying large chunks of data, the DMA engine can do it a *lot* faster than the CPUs can: https://forums.raspberrypi.com/viewtopic.php?t=319315
And it also has hardware support for "2D" buffers of different sizes (assuming you want to transfer full strides of one or the other), so you can use it to put a smaller windowbuffer into the big framebuffer with minimal logic.
EDIT: forgot to link to an actual post on how to use it... https://iosoft.blog/2020/05/25/raspberry-pi-dma-programming/

2024-12-09 16:08:39 GMT

- reply

The 400 is the same chip as a 4 (4x A72), which does have some juice behind it, but I suspect the speed issue is that cache-miss memory latency is *atrocious*, given that the interconnect to the RAM has to go through the GPU. And a 1080p framebuffer is several times larger than the CPU's L2...
I suspect it's not that it's being done *wrong* so much as "massive memcpy is *always* going to be a bit slow on this architecture" and the best you can do is try to offload it from the CPU so that can spend time doing more useful things?

2024-11-20 01:28:06 GMT

- reply

That was another option that I was thinking of, and would probably work better since the composite out block is much less configurable than I thought I remembered... Just means you basically have no GPIO for other things.

2024-11-20 01:22:24 GMT

- reply

If you used a sync separator to pull the hsync and vsync off of the composite output (yes, the newer ones still have it, it's in the headphone jack), I imagine that you could *probably* set the scanout timings close enough to push some pixels coherently?
For some details, someone [did it with a beagleboard](https://trmm.net/Mac-SE_video/ ) using the PRUs, but the pi doesn't have those, so you'd need to see what you can do with the GPU hardware instead (thankfully it's actually quite well documented these days)

2024-11-18 19:05:35 GMT

- reply

If it's like most of the CRTs I've ever dealt with, the mains portion is separate from the spicy bits (which is the case with the minitel; the CRT driver only gets +24vdc and the sync/video signals), so it *should* just be a simple matter of figuring out what voltages are needed and acquiring the right bits to make them?

2024-11-18 18:53:01 GMT

- reply

...and this reminds me I still need to fix my minitel's CRT/PSU board... I initially thought it was a bad PSU so did a thing that *actually* blew the PSU, so I somehow need to conjure something that can spit out +-8v and 24v and then fix the still-broken CRT driver...
(I was already planning on replacing the PSU because it's 220v-only and I really don't feel like either wiring it to a dryer plug or hauling around a transformer with it...)

2024-11-15 21:12:08 GMT

- reply

'Kanchou' is basically the japanese version of "sack tap": put two finger pistols together side by side, then poke someone in the bumhole as hard as you can. Having chocolate stuffs basically named "sack tap" just feels *wrong* for some reason...

2024-11-15 21:07:47 GMT

- reply

Yeah, that's close enough to be "how did marketing not catch that?" (of course, given the English packaging, I'm not sure marketing knows enough Japanese *to* catch that...)

2024-11-07 18:03:10 GMT

- reply

In short: "interactive users" is a group that technically doesn't "actually exist" as a group you can add users to, but is managed on a per-session basis, so individual tokens can be "interactive" or "noninteractive", and you can set file ACLs to differentiate based on this.
So you can have the "privileged" folders/etc. accessible to a service account set to deny interactive, and anyone who logs in interactively would see "permission denied" regardless of the "real" permissions. (And any interactive login to a service account is generally an indicator of "shenanigans afoot" malicious or not...)

2024-10-29 20:41:21 GMT

- reply

That "autodetect" behavior can also be stupid in the reverse direction, too: if *one* of the dozens of APs in range was bought over from CN by a chinese international student (and thus broadcasting a CN country code), intel's logic apparently decides that the appropriate country code is china, despite *literally every other AP in range, including the one it's connected to* being set to US... (not that I can really use much of 5GHz regardless, considering that I live pretty much within LOS of a "very large" weather radar installation...)

2024-10-28 01:32:51 GMT

- reply

After thinking about lua for a bit, if you stick to the imperative C-like stuff, a "sufficiently smart compiler" (aka "basic type/const inference and load/store optimizations") can spit out what should be reasonably fast bytecode, without needing to do *any* expensive map lookups if you aren't using the bodged-on OOP bits or dictionaries...
EDIT: but doing that would kinda defeat the point of wanting an OOP language for this... The big problem is that the "objects are just dictionaries" model is *extremely* computationally expensive at runtime without spending multiple decades on an optimizing JIT engine that *still* occasionally falls back to an interpreter for edge cases (see JS) and that level of overhead is likely quite a bit more than an 8/16-bit machine can muster if you want real performance from it...

2024-10-11 02:01:48 GMT

- reply

That's where my big rack now lives, and the modem and router live in said rack, so nothing really wrong with that option IMO. (TBF that basement's a lot better than most unfinished basements I've seen; it has some paint on the walls and actually decent lighting. But it's still fundamentally concrete with some paint on it. Plus that's where main panel is, so we would have needed to run the power cables there anyways)

2024-10-11 01:43:44 GMT

- reply

Also, honestly? if the attic is far enough away from the main panel, I'd see about pulling an entire subpanel up there instead of individual circuits, simply for future expansion reasons. *especially* if you can't run conduit the first time. I learned that the hard way when we ran that 20A and wanted to run ethernet later. Had to open up the kitchen walls again to make the run.
Oh, and pull some ethernet/fiber at the same time if you can't leave a second pipe for it. Having a central riser for data *really* helps when you need to put a second office drop in. (my mother asked for one in her office because that room appears to have used proverbial lead sheeting instead of paint, despite the AP being all of about 15 feet away...)

2024-10-11 01:38:14 GMT

- reply

That's exactly what I did in my old cave: ran the window AC off the existing 15A circuit shared with the adjacent bedroom (it's a tiny one so that's fine) and dropped a new 4-gang box with a dedicated 20A feed to run all my lab shit. Said cave is now the guest bedroom since I moved out, and the massive outlet array is *really* out of place in the middle of an empty wall...