HN user

st_goliath

5,454 karma

https://infraroot.at/

https://goliath32.com/

https://github.com/AgentD/

https://hn-wrapped.kadoa.com/st_goliath?share

Posts184
Comments407
View on HN
goliath32.com 5d ago

The Zilog Z80 has turned 50

st_goliath
288pts119
en.wikipedia.org 26d ago

Thomas Salme

st_goliath
15pts0
sigma-star.at 1mo ago

TrustZone Intermezzo: Broken OP-Tee Memory Isolation on i.MX 8M

st_goliath
1pts0
www.youtube.com 1mo ago

Shouting in the Datacenter (2008) [video]

st_goliath
3pts0
www.youtube.com 2mo ago

The Long Road To Windows 95 [video]

st_goliath
2pts0
words.filippo.io 2mo ago

Registries Considered Harmful

st_goliath
1pts0
oldcomputerssucked.com 3mo ago

Old Computers Sucked

st_goliath
7pts0
www.youtube.com 3mo ago

Building a Homebrew Computer Like it's 1995 [video]

st_goliath
2pts0
www.youtube.com 3mo ago

Is 1995 the Last Time I Install Debian? [video]

st_goliath
2pts0
github.com 4mo ago

BasicBox: A 486 PC emulator written in Visual Basic 6

st_goliath
3pts1
www.youtube.com 4mo ago

Pentium 4 – 5GHz overclocked (2003) [video]

st_goliath
3pts0
sigma-star.at 4mo ago

Data Confidentiality via Storage Encryption on Embedded Linux Devices

st_goliath
2pts0
www.youtube.com 5mo ago

Giant stop killing games updates 2026 [video]

st_goliath
5pts0
www.os2museum.com 5mo ago

The History of a Security Hole

st_goliath
39pts2
github.com 5mo ago

SL(1): Cure your bad habit of mistyping

st_goliath
1pts0
eprint.iacr.org 5mo ago

False Assurance in Formally Verified Cryptographic Libraries

st_goliath
2pts0
mas.to 5mo ago

Do not put code diffs into Git commit messages

st_goliath
20pts1
winworldpc.com 5mo ago

Microsoft Wine Guide

st_goliath
2pts1
en.wikipedia.org 5mo ago

1961 Goldsboro B-52 crash

st_goliath
2pts0
www.upi.com 6mo ago

AI-generated police report states Utah officer was turned into a frog

st_goliath
5pts1
picoide.com 8mo ago

PicoIDE – An open IDE/ATAPI drive emulator

st_goliath
186pts46
www-user.tu-chemnitz.de 8mo ago

Encoding x86 Instructions

st_goliath
106pts39
lwn.net 9mo ago

How programs get run: ELF binaries (2015)

st_goliath
141pts11
en.wikipedia.org 9mo ago

IPv9 (China)

st_goliath
2pts0
www.youtube.com 10mo ago

Realtime Linux Beyond Preempt_rt: Xenomai's Dual-Kernel Approach [video]

st_goliath
2pts0
www.youtube.com 10mo ago

Steve Jobs and NeXT Part 2: The Long Road to Mac OS X [video]

st_goliath
9pts2
lwn.net 10mo ago

A fork for the time-zone database? (2021)

st_goliath
2pts0
www.youtube.com 11mo ago

Attempting to Build a Radio to Receive Pictures from Space Like It's 1994 [video]

st_goliath
1pts0
www.youtube.com 1y ago

The end of Stop Killing Games [video]

st_goliath
4pts1
dosmandrivel.blogspot.com 1y ago

The First DOS Machine (2007)

st_goliath
4pts0

While I know about the DSKY, I keep wondering if they were the first ones, i.e. inventing that way of entering data into a computer and others copied it later on, or if it was a already a more widespread and known pattern and the AGC copied it.

I know that other machines existed that used a similar system. I recall being asked, circa summer 2009 or so, to set up extensions on a quite old PABX that was configured that way.

The PABX was a huge electrical box full of giant PCBs stuck into a backplane (S-100 or maybe something proprietary?). I didn't get a good look tough, the box was mounted under the ceiling, directly above a desk with a terminal that you used for configuring it. There was a binder with laminated, typewritten cards, documenting "verbs" and "nouns" that you entered into a numeric keypad. As said, it worked like the Apollo DSKY, but the "display" was single slot that you had to squint through at just the right angle to make out faint numbers on a mirror, aimed downwards at some back projection thingy.

I guess very few around here remember the minor fuzz about this from a few years ago? The Linux Kernel Project became their own CNA (CVE Numbering Authority). A CVE is now slapped onto practically every bug fix that is back ported to a stable kernel, resulting in a flood of CVEs.

A blog post about this, published at the time: https://sigma-star.at/blog/2024/03/linux-kernel-cna/

The title is editorialized (i.e. the OP made it up), the link simply goes to the kernel CVE mailing list archive.

Your post advocates a

    ( ) technical ( ) legislative (X) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
    ( ) Spammers can easily use it to harvest email addresses
    (X) Mailing lists and other legitimate uses would be affected
    ( ) No one will be able to find the guy or collect the money
    ( ) It is defenseless against brute force attacks
    (X) It will stop spam for two weeks and then we'll be stuck with it
    (X) Users will not put up with it
    (X) Microsoft will not put up with it
    (X) The police will not put up with it
    ( ) Requires too much cooperation from spammers
    (X) Requires immediate total cooperation from everybody at once
    (X) Many email users cannot afford to lose business or alienate potential employers
    ( ) Spammers don't care about invalid addresses in their lists
    ( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
    ( ) Laws expressly prohibiting it
    (X) Lack of centrally controlling authority for email
    ( ) Open relays in foreign countries
    ( ) Ease of searching tiny alphanumeric address space of all email addresses
    (X) Asshats
    ( ) Jurisdictional problems
    (X) Unpopularity of weird new taxes
    ( ) Public reluctance to accept weird new forms of money
    (X) Huge existing software investment in SMTP
    ( ) Susceptibility of protocols other than SMTP to attack
    ( ) Willingness of users to install OS patches received by email
    ( ) Armies of worm riddled broadband-connected Windows boxes
    ( ) Eternal arms race involved in all filtering approaches
    (X) Extreme profitability of spam
    (X) Joe jobs and/or identity theft
    ( ) Technically illiterate politicians
    ( ) Extreme stupidity on the part of people who do business with spammers
    (X) Dishonesty on the part of spammers themselves
    ( ) Bandwidth costs that are unaffected by client filtering
    ( ) Outlook
and the following philosophical objections may also apply:
    (X) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
    ( ) Any scheme based on opt-out is unacceptable
    ( ) SMTP headers should not be the subject of legislation
    ( ) Blacklists suck
    ( ) Whitelists suck
    ( ) We should be able to talk about Viagra without being censored
    ( ) Countermeasures should not involve wire fraud or credit card fraud
    ( ) Countermeasures should not involve sabotage of public networks
    ( ) Countermeasures must work if phased in gradually
    (X) Sending email should be free
    (X) Why should we have to trust you and your servers?
    ( ) Incompatiblity with open source or open source licenses
    (X) Feel-good measures do nothing to solve the problem
    ( ) Temporary/one-time email addresses are cumbersome
    ( ) I don't want the government reading my email
    ( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
    (X) Sorry dude, but I don't think it would work.
    ( ) This is a stupid idea, and you're a stupid person for suggesting it.
    ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!

But we all know that is not the typical scenario.

Back in the day, you could read a stories on Slashdot practically every other week that usually went something like this: Company/institution does something stupid, somebody finds out, tries to be a good citizen and tells them. The organization then throws a tamper tantrum in the media, fires the legal department on all cylinders, screaming "hacker!" and throwing the book at them. The most egregious cases usually happened in the US, the CFAA happens to be a particularly strong book to throw.

People eventually got the hint and either talked to the press instead, or organizations like the CCC (at least in this part of the world) and let them deal with the organization and not talk to them directly.

At least in my perception/memory, it started improving over the 2010s, but stories like this are now starting to pop up again in recent years. I guess we have a new crop of computer enthusiasts who need to learn the same lessons again.

Of the top of my head, the CTF group in Malta comes to mind who gave a talk at (last years?) CCCongress. A badly worded E-mail asking about a bug bounty resulted in several arrests, house searches and ultimately a presidential pardon (https://timesofmalta.com/article/pardon-issued-students-lect...).

Well, the angle is kind of important here. The company gets their name in the news, they have a reasonable explanation why they were scraping around, and we end up with a story about innovative tech company whiz-kids who made a funny discovery, while it was the webdevs on the other side that goofed up.

Imagine a private individual just scraped the website (or simply clicked 'view source') for no reason in particular and then told people about it... They'd be labeled an uber-haxxor, face a civil lawsuit asking for ridiculous damages while being threatened with a prison sentence over CFAA violations. Hell, that might even drive some people to suicide.

The next hard drive was an order of magnitude larger than the old one, and so on.

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.

8086 Segmented Memory Was a Good Idea.

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.

They announced it, they haven't released anything yet. There is not a single real photograph of an actual device on the site. There's a wait list where you can sign up for eventual pre-orders, with an offer that they'll ask you for slightly less money.

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.

This project has a website that was previously posted on HN[1], I (unsuccessfully) tried to boot it on an actual 486 machine[2], as the site boasts about supporting that.

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

[4] https://imgur.com/a/am486dx4-retrotank-VUOTahf

[5] https://theretroweb.com/motherboards/s/zida-4dps

This is really confusing brand/product combination. Who is it trying to appeal to?

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"

In October of 2013, Ross Scott did a review of Test Driver III in one of the early "Ross' Game Dungeon" episodes[1]. IIRC in the video, he mentioned that he's fascinated by game maps to the degree of a slight obsession, and would absolutely love if someone could reverse engineer the game assets and extract the maps.

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

[3] https://noclip.website/

I wonder how many of those are actually still out there. According to Wikipedia, Intel kept making replacement parts (386 and 486) until September 2007, but personally, I have never come across one in actual use. My own career in this field began with an internship in 2008. My day job includes working on a PLC runtime with a code base older than myself, originally written for DOS, but every industrial PC (or other x86 based embedded device) I have ever got to play around with had at the very least a Pentium class CPU in it.

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.

LLMs actually makes retrocomputing a lot more "fun" because you can slop out things that would take way too long to do by hand for pure art and exploration.

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?

...powered through emulation under a modern CI server...

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

This is why lab exercises are important. I remember first building some actual TTL circuits on bread board, I learned very quickly that this whole digital stuff is a lot uglier and messier than on paper or in the simulator.

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.

Oh, this is just the usual Microsoft Stockholm syndrome. I've been witnessing this for over 20 years now and have been told that it has been a thing for much longer than that.

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

Yes, the underlying S3 texture compression algorithm was patented in the US in the late 90s. The last, relevant patent expired in 2018[1]

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

For repairing a broken thing? After provably trying in vain to get the landlord to fix it?

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.

It's interesting how they found the unused code.

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.