I started PC programming in 1982, had to teach myself asm almost immediately in order to write a hardware interrupt handler for the serial port.
Back in those days code size was important, and for any driver/TSR type program it was simply crucial. Here in Norway we needed to load the KEYBNO.COM program which took over the keyboard interrupt and provided the official Norwegian layout, including the 'æÃÃ¥ÃÃÃ...' keys for our 3 extra letters in the alphabet.
Over the years, Microsoft/IBM had many version of this driver, the final one which also did text more font layout changes (at least for the default 25x80 mode) was up to 60 kB. This was large enough that lots of US-developed engineering/DB applications simply didn't fit, so I wrote a replacement:

All keys (including Ctrl- and Alt- modified combos) were handled, along with font remapping for 25x80, 43x80 (EGA only) and 50x80 (VGA only) screen layouts, using a total of 704 bytes. It became so popular that Compaq/HP stole it to give to their customers, then when we caught them red-handed (they had not figured out how to get rid of my startup Copyright message) they refused to pay but promised to not do it again.

Half a year later we caught them again, they had started telling customers that they had to keep it a secret.

Terje Mathisen

NIST have always been the world leader in creating ever more accurate clocks, the current masers work in picoseconds and below, so allowing the reference to drift by 4.8 microseconds means that precision dropped by at least 6 orders of magnitude.

If allowed to propagate to the GPS control clocks, this would have been enough to totally destroy the navigation system since a clock that is off by 4.8 us corresponds to a position error of 1500 kilometers. (OTOH, USNO has its own large ensemble of atomic clocks, so they don't depend short term on NIST updates.)

Full disclosure: I worked with the NTP Hackers (network time protocol) team for 20+ years, so I'm probably a bit more interested in precise timekeeping than most. I have personally soldered together 4 or 5 GPS-based reference clocks that would deliver 25-35 ns RMS precision.

Proprietary service drops support for proprietary protocol..

Nope. That's why I changed all my players to BlueOS.

Full disclosure: I was somewhat involved with the Quake development, helped Mike Abrash a little bit to optimize the asm code that actually made a pure SW 3D rasterizer fast enough to be playable.

The Castle Wolfenstein - Doom - Quake progression might seem from the outside to be a fairly linear upgrade path, but in reality Quake was at least an order of magnitude harder to achieve.

Just the number of amazing ideas John Carmack managed to come up with in order to make a real 3D game possible will forever give Quake a special place in my programming heart.

Terje

I replaced all my SONOS connects with BlueSound node Nano devices. A pricey replacement, but worth it.

As a bonus I was now able to turn off SMB1 on my home Samba server !

I'm Norwegian, have driven EVs since around 2000, and only EVs since March 2016:

This was the first time I could buy an EV which had both a long enough range to drive up to the Telemark mountains to go skiing, and had the 4WD to reliably get up hills on snowy/icy roads. At the time, this was a Tesla Model S, which we since sold to our son, replacing it with the "made for Norway" Model Y (which has been the best-selling vehicle in Norway for the last 3 years).

As noted above, we started with a lot of EV incentives, we saved over $5000 per year in gas and toll road fees until around 2020 when they (as planned) started to roll back some of those incentives.

However, all of that doesn't really matter: By now it is pretty much inconceivable for most Norwegians to buy any new non-EV vehicle: They are just so much better!

Terje

> Every large NAS vendor (Synology, QNAP, etc) has their own SMB server they wrote themserlves

That's untrue. Both Synology and QNAP use Samba. QNAP contributes code and bugfixes back to samba.org (Hi Jones !).

The upstream Linux kernel doesn't differentiate between security bugs and "normal" bug fixes. So the new kernel.org CNA just assigns CVE's to all fixes. They don't score them.

Look at the numbers from the whitepaper:

"In March 2024 there were 270 new CVEs created for the stable Linux kernel. So far in April 2024 there are 342 new CVEs:"

Yes ! That's exactly the point. Trying to curate and select patches for a "frozen" kernel fails due to the firehose of fixes going in upstream.

And in the kernel many of these could be security bugs. No one is doing evaluation on that, there are simply too many fixes in such a complex code base to check.

Oh that's really sad. I hope they use a more up to date version of Samba :-).

I don't see that argument in the blog or paper.

Did you read them ?

There are many more unfixed bugs in vendor kernels than in upstream. That's what the data shows.

You're missing something.

New bugs are discovered upstream, but the vendor kernel maintainers either aren't tracking, or are being discouraged from putting these back into the "frozen" kernel.

We even discovered one case where a RHEL maintainer fixed a bug upstream, but then neglected to apply it to the vulnerable vendor kernel. So it isn't like they didn't know about the bug. Maybe they just didn't check the vendor kernel was vulnerable.

I'm guessing management policy discouraged such things. It's easier to just ignore such bugs if customer haven't noticed.