st_goliath

> How feasible is it to make a crt from parts? [...] I've never seen a DIY CRT kit before.

The closest thing that springs to mind: A friend of mine once drilled a hole into an empty Vodka bottle, stuck two wires in it (one at each end), a hose adapter for a vacuum pump, "sealed" the whole thing with a hot glue gun and hooked it up to several scavenged microwave oven transformers in series. Yes, the output was rectified and capacitors were also involved.

Here are some pictures:

https://chaos.social/@itsyndikat/107846783094589995

IIRC what he wanted to do was plasma etching.

I suppose rearranging the electrodes (using a piece of sheet metal with a hole in it; both fed through the neck of the bottle) and wrapping the sides of the bottle with 4 strips of aluminium foil could get you a beam and some crude deflection control. Not sure tough what you would coat the end of the bottle with, but I guess vacuum coating would be applicable.

If that sounds absolutely insane to you, I'd wholeheartedly agree.

At least to my ears, trying to build a CRT from first principles, combined with learning-by-doing and learning-EE-from-youtube-tutorials, sounds like a fast path to end up either dead or in a permanent care facility. Not exactly something I'd hand out in beginner-friendly kit form.

If you're German-speaking: "Klopilot" and "Vibrierkot" are some modern day personal favorites.

On a similar, nostalgic note, I recall boot screens for "Sinnlos 98" floating around, back when modifying the bootup logo was a thing.

I'm pretty sure if you really want to, you could do something like this as a hobbyist with a Pentium right now.

Instead of futzing with wires on a breadboard you could simply designing a PCB up front, throw the design over the fence at JLC or PCBWay, insert coin, wait patiently at the mailbox, solder your scavenged Socket 7 onto the board.

The days of toner transfer and aquarium pumps are already long gone. Getting production quality, one-off, multi layer PCBs done as a hobbyist is dirt cheap these days, no government budgets required.

I've seen a similar project a while ago and thought this was about the same thing at first: [1][2]

Both essentially built a DIY chip tester for a 286 and both built around a Harris 80C286.

If I understood it correctly, the goal behind this project seems simulating the rest of the PC, purely for the challenge and learning experience, documenting the process of building the chip tester (and getting mildly philosophical in the process).

The other project was more directly interested in the 286 itself, undocumented instructions, corner cases in segmentation behavior, instruction cycle timing, etc. and also trying to find out if there are any difference between the Harris and Intel variants.

[1] https://forum.vcfed.org/index.php?threads/286-cpu-experiment...

[2] https://github.com/dbalsom/arduinoX86

Microsoft Research had an experimental OS project at one point that does just that with everything running in ring 0 in the same address space:

https://en.wikipedia.org/wiki/Singularity_(operating_system)

Managed code, the properties of their C# derived programming language, static analysis and verification were used rather than hardware exception handling.

> can't hear you from all the way up here ON THE MOON.

cough

https://www.quora.com/What-does-the-German-phrase-Hinter-dem...

Well, the name Davy originally proposed was alumium.

I propose we switch to that instead, so everyone can be annoyed equally and in the same way.

> I just found the acting in the first season really, "soap opera" like. I'm not sure how to describe it better.

When I first started watching, season 1 with its gratuitous 90s CGI, the dramatic musical cues, and Michael O'Hares rather stiff, wooden demeanor reminded me a lot of those live action cut scenes that some early CD-ROM games had. I remember thinking at first, that this is probably the kind of thing the local basement theater troupe would pull off if they were suddenly told to make a TV show.

> It's still one of my all time favorite shows.

Fully agree. If you haven't seen it yet, I'd highly recommend as well.

Don't worry, this will probably be flagged to death and gone from the front page real soon.

EDIT: and it's gone. From #1 on the front page to page 14 or so in about 35 minutes. To be honest, that took a lot longer than I expected.

> "I don't want to" is not a valid excuse

for the client. If you're implementing a server, "the client SHOULD but didn't" isn't a valid excuse to reject a client either.

You can do it anyway, you might even have good reasons for it, but then you sure don't get to point at the RFC and call the client broken.

> Viva.com's outgoing verification emails lack a Message-ID header, a requirement that has been part of the Internet Message Format specification (RFC 5322) since 2008

> ...

> `Message-ID` is one of the most basic required headers in email.

Section 3.6. of the RFC in question (https://www.rfc-editor.org/rfc/rfc5322.html) says:

    +----------------+--------+------------+----------------------------+
    | Field          | Min    | Max number | Notes                      |
    |                | number |            |                            |
    +----------------+--------+------------+----------------------------+
    |                |        |            |                            |
    |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

                             ... bla bla bla ...

     /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
    | message-id     | 0*     | 1          | SHOULD be present - see    |
    |                |        |            | 3.6.4                      |
    |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

                             ... more bla bla ...

     /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
    | optional-field | 0      | unlimited  |                            |
    +----------------+--------+------------+----------------------------+

and in section 3.6.4:

    ... every message SHOULD have a "Message-ID:" field.

That says SHOULD, not MUST, so how is it a requirement?

Up next: forgotten Piet[1] autorun feature discovered in MS Paint. Customers complain after removal, insist they have existing legacy applications depending on it.

[1] https://en.wikipedia.org/wiki/Esoteric_programming_language#...

yes, e.g. the version of Windows 3.x and accompanying office suite that I used as a child had German words next to the icons. The idea of labeling a pictogram with text isn't a concept that suddenly breaks when using a language other than English.

> Colors and pictures aren’t exactly free of cultural baggage, either.

I remember being really confused that I had to click on a picture of a frying pan for "search".

It's a DataExpert OPTI-495SX: https://theretroweb.com/motherboards/s/dataexpert-opti-495sx

It is running some AMI BIOS variant with a copyright date of 1992, I currently don't have the exact version string around to compare with the ROM dumps on retroweb. vbindiff says the "F" and "M" images are identical and the "H" only has a few 1-byte differences, mostly typos in ASCII strings.

I've written a small boot sector program once that tries out memory and CPU information gathering techniques, so I know the INT 15h, E820h, E801h are not implemented but INT 12h and INT 15h AH=88h return something sane. When I have more than 16M installed, the later reports the full 31M of HIMEM, but I'm not sure how the ISA memory hole factors into this.

From what I saw glancing at the scanning code yesterday, syslinux 6.x should fall back onto AH=88h if AX=E820/E801 doesn't work. It's interesting to know that this worked in older SYSLINUX, I'm curious to check out what changed.

Have you tested this on an actual 486?

Sadly, it does not seem to boot on my 486 DX2, I even stuffed 32M of RAM into the machine (8*4M, maximum the mainboard supports), more than the recommended 20M.

I have copied the floppy image from the site. It churns for about a minute and a half, loading kernel and initrd, then says "Booting kernel failed: Invalid Argument" and drops into SYSLINUX prompt.

EDIT: I tried a few more floppies to rule that out as the cause of the problem.

Here are some screenshots: https://imgur.com/a/floppinux-0-3-1-Mdh1c0w

EDIT 2: I cloned SYSLINUX, checked out the specific commit and did some prodding around.

The function `bios_boot_linux` in `com32/lib/syslinux/load_linux.c` initializes errno to EINVAL. Besides sanity checking the header of the kernel image, there are a few other error paths that also `goto bail;` without changing errno.

Those other error paths all seem to be related to handling the memory map. I know that the BIOS in my machine does not support the E820h routine. I have a hunch that this might be the reason why it fails.

The website has an image gallery where people ran it on actual hardware: https://krzysztofjankowski.com/floppinux/floppinux-in-the-wi...

Most of those machines seem to be newer systems which probably support E820h, except for another 486 DX2 with a similar vintage as mine, that also failed to boot.

You might be thinking of ar, the classic Unix ARchive that is used for static libraries?

The format used by `ar` is a quite simple, somewhat like tar, with files glued together, a short header in between and no index.

Early Unix eventually introduced a program called `ranlib` that generates and appends and index for libraries (also containing extracted symbols) to speed up linking. The index is simply embedded as a file with a special name.

The GNU version of `ar` as well as some later Unix descendants support doing that directly instead.

Yes, one can only hope Ken Shirriff eventually happens to come across one of those models, but I guess they are probably very rare these days.

Besides the multiplication, the 386 had quite a number of teething problems[1], including occasionally broken addressing modes, unrecoverable exceptions, virtual address resolution bugs around the 2G mark, etc...

A while ago, there was also an article posted here that analyzed the inner workings of the Windows/386 loader[2]. Interestingly, Windows simply checks a pair of instruction (XBTS/IBTS) that early 386 steppings had, but was later removed, raising an invalid opcode exception instead.

Raymond Chen also wrote a blog post describing a few workarounds that Windows 95 had implemented[3].

[1] https://www.pcjs.org/documents/manuals/intel/80386/

[2] https://virtuallyfun.com/2025/09/06/unauthorized-windows-386...

[3] https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11...

Fun little tidbit: The 0x40-0x4f range used for the REX prefix actually clashes with the single-byte encodings for increment/decrement.

When AMD designed the 64 bit extension, they had run out of available single-byte opcodes to use as a prefix and decided to re-use those. The INC/DEC instructions are still available in 64 bit mode, but not in their single-byte encodings.

If you have JavaScript enabled, that is. JWZ at least does the redirect on the server side.

The following is pulled in from `https://soc.me/assets/js/turnBack.js`:

    const undesirables = [
      "news.ycombinator.com/",
      // "reddit.com/", // disable temporaily
      "lobste.rs/"
    ] ;

    if (undesirables.find(site => document.referrer.includes(site))) {
      window.location.replace(document.referrer);
    }

I wonder why Reddit is "temporarily not undesirable".

> Thought for 37s

> ...

> Ah - that makes sense, that's why it's on fire

oh how very relatable, I've had similar moments.

I knew about SEDs (smoke emitting diodes) and LERs (light emitting resistors), but what do you call the inductor version?

> how to exceed the normal limits on Linux kernel modules.

Uh, what limits? I'm not aware of anything that would stop your module, once probed, from reaching around the back of the kernel and futzing around in the internals of another driver/device in a completely unrelated subsystem, or subsystem internals. SoC/SoM vendors love to pull that kind of crap in their BSPs.

> hooks the VFS to allow dynamically remapping file paths on a per process basis

Instead of messing with kernel VFS internals, you could try:

- patching the offending application or package (ideally make the path configurable and contribute that back upstream)

- running the application in a mount namespace and bind-mount something over the path

- use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)

A lovely video from a Shenzhen factory, mass producing disposable vapes, in case someone's interested: https://www.youtube.com/watch?v=WohEiRvn2Dg+

Most likely a promotional from the looks of it. I myself stumbled over it a about a year ago, when someone posted it on an IRC channel.

The icon is supposed to represent one of those waving cat figurines: https://en.wikipedia.org/wiki/Maneki-neko

It has some long tradition placing those visibly on the podium. As the story goes, the idea is that you can immediately see if the video stream freezes up (because the cat in the video suddenly stops waving). You wouldn't immediately catch that in between talks (when you have some time to fix the issue) if the camera was just pointed at an empty stage with no movement. I think at 30C3 or so, I saw one that was placed so that it would repeatedly knock on the microphone as well.

Anyway, the waving cat has become a bit of a meme by itself and mascot of the VOC, hence also the (animated) icon in video player.

That literally is quick access, it does the same thing in both cases, trying to get rid of the linear scan and having to plow through data unnecessarily.

If the archive is on a hard disk, the program reads the directory at the end and then seeks to the local header, rather than doing a linear scan. Or the floppy motor, if it is a small archive on a single floppy.

If you have multiple floppies, you insert the last one, the program reads the header and then tells you what floppy to insert, rather than having to go through them one by one, which you know, would be slower.

In one case, a hard disk arm, or the floppy motor, does the seeking, in the other case, your hands do the seeking. But it's still the same algorithm, doing the same thing, for the same reason.

> ... a partial download would be totally useless ...

no, not totally. The directory at the end of the archive points backwards to local headers, which in turn include all the necessary information, e.g. the compressed size inside the archive, compression method, the filename and even a checksum.

If the archive isn't some recursive/polyglot nonsense as in the article, it's essentially just a tightly packed list of compressed blobs, each with a neat, local header in front (that even includes a magic number!), the directory at the end is really just for quick access.

If your extraction program supports it (or you are sufficiently motivated to cobble together a small C program with zlib....), you can salvage what you have by linearly scanning and extracting the archive, somewhat like a fancy tarball.

> rodent controlled surveillance drones

See also: WWII era, pigeon-controlled guided bomb: https://en.wikipedia.org/wiki/Project_Pigeon

Much smaller than that, some might even say a utility box is overkill: https://old.reddit.com/r/techsupportgore/comments/nvwcuh/the...

You can use `git format-patch` to export a range of commits from your local git tree as a set of patches. You can then use `git send-email` to send that patch set out to the appropriate mailing list and maintainers (or just do it in one step, send-email accepts a similar commit range instead of patch files). It talks directly to an SMTP server you have configured in your `.gitconfig` and sends out e-mail.

Of course, `git send-email` has a plethora of options, e.g. you'd typically add a cover letter for a patch set.

Also, in the Linux kernel tree, there are some additional helper scripts that you might want to run first, like `checkpatch.pl` for some basic sanity checks and `get_maintainer.pl` that tells you the relevant maintainers for the code your patch set touches, so you can add them to `--cc`.

The patches are reviewed/discussed on the mailing list that you sent them to.

On the receiving side, as a maintainer, you'd use `git am` (apply mail) that can import the commits from a set of mbox files into your local git tree.

Now that's funny. The irony here is that, besides German (native), I do speak some HSK4-ish Mandarin as a 3rd language. A few years ago, a single line Chinese comment next to a blob of magic hex values did help me figure out a bug in a touch controller driver :-)

> ... don't require absurdly bloated development environments.

Outside hobbies, I've been mostly away from this field for little over a decade by now. Is it still that bad? I remember back then, every single professional electronics engineer that I met had this die hard belief that this was simply how things work:

You want to use DerpSemi micro controllers? You must install DerpStudio '98! Not the later 2005 version tough, that has some major UI bugs. You want to program a HerpSoft PLC? You need EasyHerpes IDE! What, command line toolchain? Text editor? You must be completely insane!

It's been somewhat of a personal fight against windmills for me back then. That, plus suggesting that we are actually developing software and the C/Assembly/VHDL maybe shouldn't be an undocumented, tested-only-once pile of spaghetti based off a circuit diagram inside one guys head (and no, a 50 line comment block with a German transcription of the code below is not documentation).