5,657 karma · joined August 28, 2019
https://goliath32.com/
https://github.com/AgentD/
https://hn-wrapped.kadoa.com/st_goliath?share
Ah yes, the good old "old PC" folder that you would find on pretty much every Windows PC that used to have another "old PC" folder inside it somewhere, possibly inside an "external HDD (old)" folder :-)
Until the PC (or the HDD inside it) died surprisingly, people didn't have backups, or the backups turned out to be burned CDs that were scratched up and/or sat on a sun illuminated shelf for years.
I was at a class reunion a few years ago where it turned out, I was somehow the only one who still had (digital) photos from early-to-mid 2000s.
> ... even more ephemeral as people started putting data in the cloud where it will eventually be wiped when the accounts stop being paid or lost when the company goes under.
Or the photos they upload gradually degrade in quality as the company repeatedly plays with re-compressing stuff to squeeze more space out.
People have observed old (10+ years) photos on Google Drive to start getting blurry, having weird artifacts, color banding, etc... IIRC there was an article posted on HN at one point with some particular egregious examples. Techmoan also mentioned this in a video some time ago, commenting that the same thing happened to old YouTube uploads of his from the 2000s.
https://www.starringthecomputer.com/help.html
From the site:
> The following films do not appear on the site because I believe the computers they feature are mock ups and therefore do not qualify.
Yet the article goes about the most ass backward way of explaining 8086 segments and constructs a convoluted mental picture of dividing memory into overlapping chunks.
It's really, really simple: segments on the 8086/88 are 64k sliding windows into an 1M address space. You can move them around at 16 byte granularity.
You need more than 64k for code + data? No problem, the CPU knows when it's fetching an instruction vs when it's fetching data, you can have two sliding windows: code (CS) and data (DS). Split them apart, and it's not much different than a Harvard-style machine and gives you access to more than 64k at a time.
Still need more? No problem, the CPU has a hardware stack with dedicated push/pop/call/ret instructions and a base pointer for stack indexing. It knows when it's accessing the stack, so we can split the data window into regular data (DS) and stack data (SS). Oh, you occasionally want to copy stuff between segments or somewhere else in memory? Well, to encode 3 segments we need 2 bits anyway, let's throw in an extra data window (ES) and some DS-to-ES copy instructions.
Michael MJD did a video on this recently, showing off necessary modifications on a vanilla GameCube and the installation procedures: https://www.youtube.com/watch?v=ESV3Qib8eJI
Also, it's not Commodore but someone playing "Weekend at Bernie's" with what's left of the brand. The real Commodore went through bankruptcy and liquidation in 1994.
The version of the SYSLINUX bootloader that it uses had a bug in the fallback path if E820 memory information is not available from the BIOS, and the BIOS on my machine indeed does not support it, or E801 for that matter[3].
I have not gotten around to further testing and fixing the actual issue in SYSLINUX yet (also one of the RAM sticks has sadly developed a parity issue, so I'm stuck at 16M for now). However, I did manage to dig up a newer 486 machine[4][5]. From some testing just this weekend, the BIOS on that one does support INT 15h, AX=E820. I'll have to dig up more memory, but I'm looking forward to another round of trying to get this to boot on the actual hardware, once again :-)
[1] https://news.ycombinator.com/item?id=46866544
[2] https://news.ycombinator.com/item?id=46873814
[3] https://imgur.com/a/GCG9jO7
I'm pretty sure the people who have fond memories of growing up with a C64 or watching ToS are of an entirely different generation than those with fond memories of flip phones and cyber/color-puke ads for transparent plastic gadgets.
> BASIC Beige Edition
There's a missed opportunity for a better ToS joke here: "Beige... the final frontier"
And of course, browser engines also do the same things for certain websites:
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
Someone later went on to do just that and responded in the Accursed farms forum, Ross mentioned that in his July 2015 follow up video[2]. In the video he showed some map screen shots from the forum, including a surprisingly intricate map that was apparently only used for the the spinning car menu screen. IIRC the reverse engineering project was not quite complete at the time, since the README doesn't mention any of this, I assume this project is unrelated?
That said, it would be amazing to eventually get the extracted maps integrated into noclip.website[3].
[1] https://accursedfarms.com/index.php?af-posts/537/test-drive-...
[2] https://accursedfarms.com/index.php?af-posts/522/follow-up-e...
The bomb aboard Pan Am Flight 103 (the Lockerbie bombing) was hidden inside a Toshiba 'BomBeat' RT-SF16 radio.
https://en.wikipedia.org/wiki/Borussia_Dortmund_team_bus_bom...
As for the Windows 3.x based industrial equipment: Some industrial devices I have worked on in the past turned out to actually be ARM based, running Linux, but the software went a long way to convincingly fake old Windows style UI or emulate a DOS prompt. I was once tasked to extend such a UI library to faithfully reproduce Windows 98 style color gradient borders.
Only once have I seen an actual embedded 486SX with my own eyes, but not in active use anymore. Last year, someone dragged a dusty, old, weirdo Siemens telephony box to the the local Hackerspace. The box itself had a design language that screamed "Star Trek: Voyager". I found a UART, it was running "On Time RTOS-32" which, according to the German Wikipedia, was an RTOS with a Windows API compatible userspace, developed by a German company in 1996 and discontinued in 2023.
Actual context: Linux 7.1-rc4 release, Linus remarked on a specific documentation change.
The Register somehow turned this into an "article" that says a lot less with roughly the same number of words, and provides "context" by linking to a number of unrelated articles.
Doesn't that kind of completely miss the entire point of the hobby? Like attending an online language class in your spare time and then just using deepl in a separate tab?
I have a 486 PC sitting in my living room. For shits and giggles, I've cobbled together a FAT12 boot loader that runs a program directly off a floppy and played around from there.
And even by that little that I played around so far, I managed to run into more than one issue where something would work perfectly fine in Qemu, but not on the real hardware. Bochs appears to be more faithful, but also not 100% exact.
Btw. did you know that Windows 9x has an interesting TLB invalidation bug that apparently went unnoticed for decades and now triggers in KVM on AMD Zen 2 and newer CPUs? (see: https://github.com/JHRobotics/patcher9x)
AFAIK, part of the reason Linux no longer supports i486 is that it made CMPXCHG8B a hard requirement (and also RDTSC). You would need to maintain a completely separate implementation of a bunch of low-level locking primitives. I'm somewhat skeptical how well that will work when your testing relies entirely on emulation.
> ... someone else should do this, of course.
of course ;-)
I guess you have never encountered the anger and wrath of a retiree who's into ham radio and has the regulatory office on speed dial.
With sharp rise times, synced up to a common clock, even after soldering in a whole bunch of capacitors, you can still stick a probe pretty much anywhere and see switching spikes all over the place, from power rails to completely unrelated signals that are supposed to be stable. Using actual TTL, there was another funny lesson what this weird "fanout" value in the datasheet meant.
A similar lesson I learned that way (and a very memorable one :-)) was about flyback diodes.
Not sure, probably isn't street legal. But for the curious, it has been done before: https://www.youtube.com/watch?v=5Fqpp-IAXF0&t=25s
"No, we can't switch to OpenOffice you weird Open Source hippie! I can't e-mail documents to other people anymore, nobody can open them. Besides, the UI is all different, I won't be able to find anything!"
Then Office 2007 happened, tossing out the waffle menu for the ribbon and people started receiving e-mails with strange docx/xlsx files that nobody could open. IIRC that was still an issue 3 years later.
But no, when Microsoft does it, it is different: "This is progress! Are you against progress, you weird Luddite?"
I remember by the time Windows 8 was released ("Kachelofen edition" - "hurr, your desktop is a tablet!"), I was discussing with a Unix graybeard friend in the cafeteria how long it will take until the complainers accept that "this is the way now". I think it was him who suggested that if Microsoft sent a sales rep around to shit on peoples lawns, it would take at most a year until they start defending it as the inevitable cost of technological progress.
No matter how slow and bloated the GitHub web UI gets, or how many nonsense anti-features Microsoft stuffs into it. People will accept it and find funny excuses (network effect will be the main one).
:-)
Let me guess, ".*@.*\..*"?
Direct3D called its variants DXTn, later rename to BCn. From what I recall, Microsoft had some sort of patent licensing deal that implicitly allowed Direct3D implementers to support their formats.
OpenGL had an extension called GL_EXT_texture_compression_S3TC[2].
Under "IP Status" the extension specification explicitly warns that even if you are e.g. shipping graphics cards with Direct3D drivers, supporting S3TC, you may not legally be able to just turn that feature on in your OpenGL driver.
[1] https://en.wikipedia.org/wiki/S3_Texture_Compression#Patent
[2] https://registry.khronos.org/OpenGL/extensions/EXT/EXT_textu...
Down the hallway from my office used to be the management of a small hotel chain. We often had lunch together and I got to hear a bunch of interesting anecdotes over the years.
Way back when they started up and didn't yet have enough cash to actually own the buildings they operated in, they rented. One of the buildings turned out to have numerous issues (holes in the roof, gaps near exterior walls, etc...). To the point that they eventually didn't pass a fire inspection. They repeatedly asked the owner to have it fixed. Pressed for time, they themselves eventually payed someone, out of their own pocket, so it would at least be up to code for the fire inspection.
From what I was told, the owner threw a tantrum over them modifying the building, terminated the contract and sued them. Successfully.
If you are a tenant in a rental apartment, you'd probably have more leniency on the legal side (compared to a company renting a business property). But still, I'd be very careful making any assumptions about the legal situation rather than risking some sort of Kafkaesque legal mess.
Over here at least, it is very common in apartment complexes that the apartment owner is a different person/entity than the building owner and only the later has the rights to mess with stuff installed in the walls (e.g. plumbing) and especially stuff elsewhere in the building (e.g. an external intercom system). If you ask the landlord to fix it, the best they could do is forward that request to the building owner. If you pulled a stunt like the OP did, there's a good chance that the building owner will sue your landlord.
From the article: the code was broken.
The breaking bug was discovered in 2023 by syzbot, a fuzzer, and found out to have been introduced in 2016. This means that probably nobody has been using UDP-Lite (at least on a recent kernel, even LTS) for quite some time now.
It is now 2026, it has been proposed and discussed to remove UDP-Lite entirely, the patch set has gone through several iterations on the netdev mailing list. Apparently nobody complained that, actually, they do need that and it has been merged to the netdev tree, likely ending up in the next release.
There is actually an interesting question here: was '%n' always in printf, or was it added at one point?
I took a cursory look at some old Unix source archives at TUHS: https://www.tuhs.org/cgi-bin/utree.pl
As far as I can tell from the PDP-11 assembly, Version 7 research Unix (relevant file: /usr/src/libc/stdio/doprnt.s) does not appear to implement it.
The 4.1BSD version of that file even explicitly throws an error, treating it as an invalid format specifier.
The implementation in a System III archive looks suspiciously similar to the BSD one, also throwing an error.
Only in a System V R4 archive (relevant file: svr4/ucblib/libc/port/stdio/doprnt.c) I found an implementation of "%n" that works as expected.
I guess it was added at some point to System V and through that eventually made it into POSIX?
Nowadays, you have to wait for the thing to finish booting.
In the future, you have to wait for the ads to finish playing?
Or maybe, ever since you became aware of it, you started increasingly becoming aware of it?
About a week ago, completely out of the blue, YouTube recommended this old gem to me: https://www.youtube.com/watch?v=z0jQZxH7NgM
A Pentium 4, overclocked to 5GHz with liquid nitrogen cooling.
Watching this was such an amazing throwback. I remember clearly the last time I saw it, which was when an excited friend showed it to me on a PC at our schools library. A year or so before YouTube even existed.
By 2005, my Pentium 4 Prescott at home had some 3.6GHz without overclocking, 4GHz models for the consumer market were already announced (but plagued by delays), but surely 10GHz was "just a few more years away".
This sentiment is not a recent thing. Ever since GPGPU became a thing, there have been people who first hear about it, don't understand processor architectures and get excited about GPUs magically making everything faster.
I vividly recall a discussion with some management type back in 2011, who was gushing about getting PHP to run on the new Nvidia Teslas, how amazingly fast websites will be!
Similar discussions also spring up around FPGAs again and again.
The more recent change in sentiment is a different one: the "graphics" origin of GPUs seem to have been lost to history. I have met people (plural) in recent years who thought (surprisingly long into the conversation) that I mean stable diffusion when talking about rendering pictures on a GPU.
Nowadays, the 'G' in GPU probably stands for GPGPU.