> And about those WWII bombing raids? Midway through our work, we noticed a demolition team carefully dismantling a live 500-pound Allied bomb just 350 feet from our location. According to a local office worker, this wasn’t unusual; numerous unexploded bombs had been found on-site in the years prior, prompting evacuations in 2004.

If you live in Europe, there's a reasonable chance you've had the experience of being (or living) in the proximity of an uncovered leftover WW2 bomb at some point that needed to be defused. Because those bombs didn't all disappear in the 40s.

I'm guessing in this case that could've meant somebody could've found that entire hangar and its contents and just cleaned the "junk" out entirely.

> We can safely assume that the final decompiled code is way more readable/usable than the original.

Have you looked at any rediscovered repositories lately?

It's a pretty daft assumption that the original source code wouldn't carry more value than the decompiled machine-generated "source code". And much more so.

Certainly from the game historian's perspective. Just think about it. Inline comments, logs, scraps of documents/notes, variable/function naming, scrapped files and artwork, engine code, etc. These things are essentially a time capsule treasure and a peek into the history of the game, no matter their state.

If you've seen any rediscovered source code releases of old software, e.g. 86-DOS, Prince of Persia, Command & Conquer, Little Big Adventure, even Apollo or any of the "the making of"-style game releases built around it (Karateka, Ninja Turles) you'd probably think differently. These are super interesting to dive into because they capture the thoughts and decisions of the developers at the time.

Here are also some interesting articles to showcase what that means: https://gamehistory.org/category/source-code/

[1] https://www.sciencedirect.com/science/article/abs/pii/S01475...

How can you honestly say that though. A blatant overgeneralization of a large group of people, but this has been a recurring theme on HN lately.

So I would agree that people spouting anti-US sentiment have been conveniently downplaying, leaving out, or haven't been educating themselves on, this important part of US-European history, but what's new.

In the meantime, streets have been named after Marshall, plaques and statues have been erected (including recent times) at least in the more Western parts of continential Europe where much of the Marshall Plan funds ended up, and its extreme importance is quite an ingrained part of WW2 school history education. Just as one example, Arnhem was largely rebuilt using these funds and has historically paid homage and still does today with such tributes and memorials.

According to the Nexperia 2024 annual report [1], they had just committed to _invest_ in the Hamburg site for their WBG/SiC/GaN production lines. Closure of the fab in Nijmegen was actually reported by NXP[2] not Nexperia - different companies.

[1] https://www.nexperia.com/dam/jcr:fc307e7e-e159-482c-b21b-0f9... [2] https://bits-chips.com/article/closure-of-nxps-nijmegen-fab-...

Just my two cents: have you considered using a server/daemon process that runs separately and therefore more controllably outside a DAW (and therefore a client-server approach for your plugin instances)? It could allow you to have a little bit more OS-based control.

Just to give some counter-weight to this, the Netherlands has a self-employment rate that is significantly higher than the EU average [1], one of the higher EU rates of high-growth micro/small enterprises [2], a whole array of tax benefits for the self-employed and SMEs and a relatively fast moving law system that makes it increasingly easier for SMEs to be founded. And let's not forget a bunch of capitalist/financial scoops (first stock market, 1602; first investment banking, 1700s; first investment fund, 1774; etc.) some of which still have a presence today. Needless to say my experience is quite the opposite.

[1] https://www.cedefop.europa.eu/en/tools/skills-intelligence/s... [2] https://ec.europa.eu/eurostat/statistics-explained/index.php...

The split is around 50%-50% with a majority of states actually having a bicameral system where these branches are separated, and this practically includes all major economic states of the EU as well as Poland and the EU itself. [1][2]

In recent legal material, your country (Poland) is a well-known example of an EU state where the governing party has been systematically breaking down this bicameralism and state of law to accomplish exactly what you're describing though.

[1] https://en.wikipedia.org/wiki/National_parliaments_of_the_Eu... [2] https://data.ipu.org/compare?field=country%3A%3Afield_struct...

Even though Wikipedia classifies it as vaporware, there are prototype cards and manuals floating around showing that these cards were in fact designed and contained programmable pixel shaders, notably:

- The Pyramid3D GPU datasheet: http://vgamuseum.info/images/doc/unreleased/pyramid3d/tr2520...

- The pitch deck: http://vgamuseum.info/images/doc/unreleased/pyramid3d/tritec...

- The hardware reference manual: http://vgamuseum.info/images/doc/unreleased/pyramid3d/vs203_... (shows even more internals!)

(As far the companies go: VLSI Solution Oy / TriTech / Bitboys Oy were all related here.)

They unfortunately busted before they could release anything, due to a wrong bet in memory type choice (RDRAM, I think) and letting their architecture rely on that, then running out of money, perhaps some other problems. In the end their assets were bought by ATI.

As for 3dfx, I would highly recommend watching the 3dfx Oral History Panel video from the Computer History Museum with 4 key people involved in 3dfx at the time [2]. Its quite fun as it shows how 3dfx got ahead of the curve by using very clever engineering hacks and tricks to get more out of the silicon and data buses.

It also suggests that their strategy was explicitly about squeezing as much performance out of the hardware, and making sacrifices (quality, programmability) there, which made sense at the time. I do think they would've been pretty late to switch to the whole programmable pipeline show, for to that reason alone. But who knows!

[1] https://en.wikipedia.org/wiki/BitBoys

[2] https://www.youtube.com/watch?v=3MghYhf-GhU

Nothing against FreeBSD (happy user here) so there's probably some good reasoning behind this.

I believe one of the first BSD versions containing sendmail (by Eric Allman) is this one: https://github.com/weiss/original-bsd/blob/bd282c88c1b3c2575... (almost 40 years ago!)

Its a little hard to read due to the format, but here's some explanation of the (1983, earliest?) config file that was used back then: https://github.com/weiss/original-bsd/blob/bd282c88c1b3c2575...

From what I grasp, it started as an extensive dynamic parser that needed to understand a lot of rules, and I guess with each new RFC and version, the rules needed to be extended too. And the config file could be loaded into a memory image to improve performance.

I don't know whether this was for some simple form of tamper resistance (I do not believe they actually used the security Torx), or rather for some reasons related to manufacturing and maintenance, which I find much more likely.

As the article points out, Torx does have superior torque handling, especially in a time where "lesser" screws may have been more common in PCs, and the use of automatic torque-limiting screwdrivers during manufacture and service would've been an advantage.

The transitions really seem to take their time. Combined with the number of "pages" you need to get through as well, makes it an experience that feels a bit slow.

I get the sense that these visual page transitions are becoming quite a thing, also with modern self checkout counters in supermarkets.

But who knows, perhaps they are trying to hide some kind of background loading action.

Can't really tell from the CAD renders, but I can imagine there may be some space still left there.