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

becomethewaifu_at_tech.lgbt@momostr.pink

Profile Code

nprofile1qqsr7hy8lgkwker80xg9jkgkk7xrfw0u0r0ffzgtxqtfy7jjnf4r3xspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsphrcnu

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub18awg073vadjxw7vst9v3dduvxjulc7x7jjyskvqkjfa99xn28zdqj7pj7v

Show more details

Last Notes

2026-04-29 16:31:51 UTC

- reply

Honestly I didn't really even *see* much in the way of carbonated beverages over in Japan other than Coke and 'simple' fruit flavors (One dominant flavor, not a complex blend), so that's not all that surprising to hear. The vending machines were *dominated* by things like iced tea and canned coffee, and they tended to have a much larger variety than US vending machines do, at the expense of less stock of each item.

2026-04-29 14:05:50 UTC

- 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-03-25 22:12:46 UTC

- reply

One of the crawler landmines I have somewhere in my stack is a zip bomb, but that's reserved for the bots trying to hit wp-admin/ on a non-wordpress site...
Just make sure your server is set to always return it *without decompressing it* even if the client claims to not support decompression; that was a thing the "AI" crawlers did as an attempt to counter the bomb. (So any clients that "don't support" compression just get the tiny gzip stream, even if it doesn't actually blow up in their face)

2026-03-25 00:21:11 UTC

- reply

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

2026-03-24 23:47:22 UTC

- reply

Oh hey, libel-as-a-service! Given that they appear to be outright pretending the headline is from the site in question with no *clear* "we pulled this out of a robot's ass" indicator, and they *know full-well* that "AI" is a bullshit fountain that doesn't even have the *concept* of "truth", I'd say that meets the bar of "knowingly false statements", regardless of any 'fine print' disclaimers they might try.
"it only lies 30%* of the time" is an *admission*, not a defense... They *know* it's prone to spitting out falsehoods, and have done nothing to correct it. Because *nothing they can do* can correct it, as the bullshit-fountain is foundational to the architecture of LLMs
* Number pulled out of my ass, not the real statistic. But the point is they *know* that "statistically plausible output" is not always *correct* output.

2026-03-22 21:46:44 UTC

- reply

There's been a *whole* lot of work put into that fairly recently, in the form of virtio-gpu and "DRM native context" which *should* be GPU-independent. Though the issue with the latter is that it breaks the core isolation mode of qubes, by giving the guest pretty much direct access to a rather large amount of host kernel surface area.

2026-03-20 00:08:34 UTC

- reply

Allergies are weird. I usually don't get them very much here, even near the arboretum in the middle of Tree Jizz Season (where you can see literal *clouds* of pollen blowing around; to me they're just like any other dust cloud though), but over in Japan I had to wear a dust mask outside for my entire trip to avoid being a walking snot factory...

2026-03-19 16:08:04 UTC

- reply

Same thing I say to my coworkers when I pull a fix for some *really* weird behavior out of nowhere. "Because I broke my lab setup in the exact same way before."
I'm my team's resident hat-wearer for anything relating to SMB, NFS, and oauth authentication for similar reasons, as we very rarely touch those ourselves. I've managed to break those in a *lot* of different ways over the years. Did you know that linux's kernel NFS client gives *completely unintelligible* errors if the server is missing an SPN? And that the server gives *no* errors?

2026-03-17 21:37:12 UTC

- 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 UTC

- 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:46:52 UTC

- reply

And as long as it's a point-to-point tunnel, that's also fine. The important part is nothing outside of the hosts that *process* the actual request traffic ever gets to see plaintext.

2026-02-19 15:41:29 UTC

- 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)

2026-02-18 22:36:23 UTC

- reply

I could tell almost instantly just by the way they were talking about it that it was pretty much guaranteed to be all in their head. With enough exposure to that type of stuff, you start to spot behavioral patterns that give off red flags long before what they say actually confirms it.

2026-02-18 21:22:50 UTC

- reply

reminds me of that time I accidentally let it slip that I work in tech when talking to someone on the subway (who I didn't know) and they *immediately* pivoted to the "my ex keeps hacking my stuff" neurosis...
I just disengaged with "I don't work in that type of tech, so I can't really do tech support" because I already knew full well to not even go *near* that can of worms, much less consider opening it...

2026-02-13 22:06:25 UTC

- reply

Comments are [still available on the forum](https://arstechnica.com/civis/threads/after-a-routine-code-rejection-an-ai-agent-published-a-hit-piece-on-someone-by-name.1511649/post-44249736 ), though aurich locked them when the article was pulled. "we probably won't have something to report back until Monday"

2026-02-08 23:54:44 UTC

- reply

Looking at the issue tracker, it seems that the current maintainer has a serious case of "doesn't understand jack shit about why things are done the way they are"... They *removed a bunch of tests* "because the test data is slow to download"<code>There's no point in keeping the issue tests in there once the issue is closed (as you can get them back from the commit history) </code>
My good dumbass, the point of tests aren't just to know when an issue is fixed, *they're to prevent it from re-occurring in the future* when someone who wasn't around for that bug makes changes or an "optimization" to the code...

2026-02-07 16:34:55 UTC

- reply

Yeah, KYC stuff *required by the government* should be able to take advantage of an "oauth-like" service provided by said government. *Age* verification more invasive than a yes/no question should be absolutely verboten online, IMO.
(Though I'd *also* allow for http response headers or meta tags, to have a *defined* mechanism to tell software *running on the device* "this site should be blocked if the user is under 18" akin to youtube's provided mechanisms to enforce "restricted mode", rather than relying on giant third-party site categorization lists...)

2025-12-09 15:26:20 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

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 UTC

- reply

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

2025-05-31 17:29:38 UTC

[@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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

#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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

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 UTC

- 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 UTC

- 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 UTC

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 UTC

- 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 UTC

- 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 UTC

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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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...

2024-09-26 16:09:38 UTC

- reply

I'd put Junji Ito as more "horror creepy" while Onimai's anime is more "I feel like I need to bleach my eyeballs" *weird* creepy.
Coming from the manga, the anime added a *lot* of "fanservice" that wasn't in the original (although all the piss-fetish stuff was the original author, that was just *weird.*) which *significantly* ups the creep-factor to me. As for the social interaction "age-gap" stuff, from what I can tell in the manga, most of the actually *weird* interactions are also weird *to mahiro* for exactly the reasons you'd expect them to be in real life, so I'd put most of the creep down to either "plot reasons", "comedy/drama", or "unintentional"? (aside from the piss fetish)

2024-09-26 15:48:45 UTC

- reply

IMO the correct answer to Onimai being "creepy or cute" is somehow "yes."

2024-09-20 02:20:53 UTC

- reply

If that keepout on the rightmost module is for an antenna, I'd suggest flipping the module around so you can have that be at the edge of the larger board. Not sure it actually *matters*, but there's probably a good reason most of the boards I've seen do it that way?

2024-09-16 22:29:07 UTC

- reply

My approach uses the wonderful "100GB of zeros compressed into 10MB and served with transport compression headers" which usually makes most poorly-written bots fuck off in short order when they OOM...