kbolino

Given .NET's release cadence, 7-8 years of LTS would mean 5 concurrent versions: 1 STS release and 4 LTS releases. This is still a lot of old versions to keep updating, of course.

Anyway, the critique was less about the exact length of LTS, and more about the lack of significant difference between LTS and STS.

This whole thread is a bit of a tangent, but I'm not sure the STS/LTS distinction makes much sense for the end user. STS gets a relatively generous 2 years of support (cf. Java at 6 months) while LTS gets a relatively anemic 3 years of support (cf. Java at 8+ years [1]). Plus, with yearly releases, every LTS expires at the exact same time as its successor STS. Are STS releases generally less stable or more experimental than LTS releases? Otherwise, this feels like a valueless distinction.

[1]: https://www.oracle.com/java/technologies/java-se-support-roa...

There's one (usually minor) caveat here, which is around strings. In .NET, like Windows*, strings are UTF-16. If you call into native code that uses UTF-8 strings extensively, then they have to be marshalled (when passed to native code) and unmarshalled (when received from native code), which takes additional time and memory. I've run into this lately, which has led me to write special CStr/CString types (idea borrowed from Rust) to avoid unnecessary, especially round-trip, (un-)marshalling.

* = Technically, Windows now supports the UTF-8 "code page" where applications can use UTF-8 natively, but all NT system calls use UTF-16, so the conversion still has to happen somewhere

It might be worthwhile to balance these positive claims against the language's own stated limitations [1].

Also, I took a closer look at the actual benchmark results [2]. For memory usage, at least, the median would show Goose using slightly more memory than the well optimized C++ and Rust. It looks like the mean is skewed in Goose's favor by a couple of benchmarks where it does extremely well due to its variable-length enums.

[1]: https://aardappel.github.io/goose/docs/tutorial.html#18-limi...

[2]: https://aardappel.github.io/goose/bench/results.html

Robert Griesemer, the youngest of Go's original authors (the other two are Rob Pike and Ken Thompson) was 45 when they started working on Go.

> there should be an easier way to "pin" a dependency, other than vendoring

Put this in your go.mod:

  replace example.com/package-to-pin => example.com/package-to-pin v1.2.3

Then go.sum will do its actual job (along with GOSUMDB) and ensure you only get exactly the revision of the code that you want.

Display scaling 100%: 12px font, 48px button

Display scaling 75%: 9px font, 36px button

Where's the setting for 12px font, 24px button?

At 100% scaling with "Compact view" on, Windows 11's File Explorer takes 135 pixels to get from the top of the titlebar to the top of the content. The same dimension in Windows 7 is 92 pixels. That's almost 50% vertical space bloat for no discernible benefit.

> UX is meaningless for a boot mechanism standard.

Well, all I can really say to this is that yes, this attitude is exactly the problem here.

Of course, the world looks different now than it did 25-30 years ago, and all Intel really set out to do back then was to get away from BIOS and all of its limitations. This was especially important for their now-defunct "IA-64" (Itanium) project, but it ended up lasting anyway due to x86-64 happening.

Nevertheless, for most of us, UEFI rolled out in the 2010s, at a time when Internet connectivity was generally a given, and hardware capabilities had already moved well beyond where they were when Intel handed the matter off to UEFI in the 2000s.

Hardware makers have consistently shown contempt for software and user experience, regarding it somebody else's problem. Of course, a consortium of many hardware makers is not likely to develop opinions or sentiments that none of them individually would have. But it does show how parochial and short-sighted they were and often continue to be.

Yes, there are multiple different platforms that use UEFI. They can each have their own standard way of using it, though.

> Your computer's awful implementation says nothing about UEFI as a whole

This is just a copout. Of course the crappy implementations many people have to deal with cast the whole thing in a bad light. If nothing else, UX is a distant-to-nonexistent concern of the UEFI standards, and that's part of the problem.

However, you are also right that this doesn't hardly make UEFI any worse than BIOS.

BIOS had to be replaced. It didn't have to be UEFI, but it did need to be something, even just a new 64-bit stage would have gone a long way. But nobody made such a thing, and the alternatives that actually exist like Coreboot do a lot less even than BIOS did. Past a certain point, pretending to be smol-bean 1980s/'90s hardware stops being a fun game and starts being a real limitation holding things back. Said "hardware abstraction layer" was getting to be more like a bunch of increasingly hard-to-maintain lies told to BIOS rather than a real service provided by BIOS.

Yes, it is about the same, that's the point. If you are worried about this or future compromises of TLS/PKI, using SSH naively is not any better.

It's also an indictment of Apple's relationship to open source software. Never mind contributing back to upstream, they haven't even made the change in their own fork to support their own keychain.

SSH in typical use is not vulnerable to a compromised root certificate, instead it's "just" vulnerable to you having no idea whether you can trust that host key or not, so you just blindly say yes and hope for the best. At least if the key changes, you'll know something was wrong; maybe it was this connection that got compromised, maybe it was the first connection that got compromised, maybe the legitimate host just rotated their keys, who knows. SSH security against MITM is mostly based on lack of motivated attackers and wishful thinking.

Sandisk doesn't make DRAM.

Micron's stock price did go way up, after they stopped selling DRAM to the consumer market. It has been flat for several months though.

For comparison, SK Hynix stock is flat YoY and Samsung's stock did go up this year, but has come back down a bit (they're also much more diversified). Those are the only other companies outside of China that actually make DRAM at scale. There's also CXMT, which is making inroads, but its stock is not traded on any open markets, and the company is heavily backed by the Chinese government.

Note: I've deleted this once, and edited it even after reposting it, apologies for rapid changes

I've been trying to piece together what was actually there based upon some historical sources [1], [2], [3] and it's quite murky to me. As far as I can tell, scroll-follows-mouse was not truly possible in Windows 95, because the custom MSH_MOUSEWHEEL event lacked a way to carry the keyboard state, and an unfocused window would not have received the keyboard events to infer it correctly, so it would have been broken in a lot of edge cases. Then, Windows 98 added the standard MS_MOUSEWHEEL event, which does carry the keyboard state, but only 32-bit applications are able to access it, so the O/S locked scrolling to the focused window. Finally, Windows 10 pulled the plug on 16-bit compatibility, and so could and did make true scroll-follows-mouse possible.

[1]: https://devblogs.microsoft.com/oldnewthing/20080806-00/?p=21...

[2]: https://web.archive.org/web/20070503040017/http://msdn2.micr...

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

The conspiracy is real, it's even been proven in court, but as things stand, it's also necessary because of the factors you describe. Investors will not touch the DRAM market with a 10-foot pole, so it has had to rely on self-funding. While there have been state subsidies too, price fixing has proven to be the most effective way to survive the extreme volatility and fund the massive capex necessary for each generational leap. They have gotten a bit more sophisticated about it since the court case 20 years ago, but as far as I can tell, it's basically the same as it's ever been. The lack of effective competition is a function of the market itself, not any tilted scales. If anything, tilting the scales on purpose with greater state involvement is the only way to change the dynamics, but few states have the capacity and competence to carry that out effectively.

Yeah, I'd say the bigger point is that the latency gap isn't really there anymore. Old keyboards, cheap keyboards, expansion ports, and external hubs can still cause problems, though.

Windows 95 didn't even have scroll wheel support in the first place. Tweak UI allowed you to turn on focus-follows-mouse (aka X-Mouse), but that's a different thing.

> USB is just fundamentally adding wrapping layers that introduce latency over the direct polling PS/2 used

PS/2 did not use polling, it was entirely event-driven. On keypress, the keyboard sent a serial message to the 8042 controller [1], which then raised the appropriate interrupt line on the CPU, which caused the keyboard ISR [2] to be executed. The serial clock was a bit flexible, but usually sat around 10-16 kHz [3], and so the 11-bit serial message took at most 1 ms to send.

It is USB that uses polling. The keyboard describes itself using endpoint descriptors, and after obtaining these, the host controller periodically polls it with an IN token, to which the keyboard responds with its state changes since the last poll [4]. The earliest USB keyboards preferred fairly slow polling rates, but modern keyboards can be polled every 1 ms [5]. If directly connected to a motherboard USB port, a modern USB keyboard will have pre-software input latency on par with a PS/2 keyboard.

[1]: https://wiki.osdev.org/I8042_PS/2_Controller

[2]: https://wiki.osdev.org/Interrupt_Service_Routines

[3]: https://retrocomputing.stackexchange.com/q/15607/25565

[4]: https://threeboard.dev/documentation/threeboard/how_usb_keyb...

[5]: https://www.usb.org/sites/default/files/hid1_11.pdf pp. 68-69

Indeed!

> The axiom is “monomorphic data, polymorphic code”. In other words, unlike languages like Haskell and OCaml that generally rely on uniform representations (boxing) to enable polymorphic code generation, data layouts will stay the same under polymorphization, and only function ABIs will change. [...] Go’s gcshape is somewhat analogous to our concept of data layouts.

https://goals.rust-lang.org/2026/polymorphization.html

There's also the basic problem that an attacker who can serve you a falsified A record for a domain can also serve you a falsified CAA record. This is why CAs are required to use "multiple perspectives" when validating domain ownership before issuing certs, whereas web clients generally don't have access to redundant infrastructure like that.

Certificate keys aren't used for encryption anymore anyway.

A modern TLS connection uses an ephemeral key-exchange protocol where both parties opaquely agree to a one-time-use random encryption key that is not knowable to any other party, not even someone who can gain access to either party's private key. This is called Forward Secrecy (originally and sometimes still known as Perfect Forward Secrecy or PFS, but the use of the word "perfect" in any cryptographic context is akin to naming a ship "Unsinkable").

Most apps don't need access to all web sites, they just need access to specific services. If the developer of the app controls some or all of those services, then the app can be coded to require the use of OV/EV certificates. With that rule in place, the app can then also inspect the subject DNs and check for the presence of its own organization details. The end result would be kind of like certificate pinning, except a little more flexible.

For documents, yes this includes things like DocuSign, but also signed PDFs, signed XML, etc. Any situation where a business, nonprofit, government agency, etc., is corporately attesting to something, like the signing of a contract or the public release of a statement, can use an OV/EV certificate.

I've looked at this question a bit more closely, and it seems that the Baseline Requirements for WebPKI do not require key rotation unless key compromise is known to have occurred. In other words, while you must get new certificates regularly, you can continue to use the same keypair for them, as long as it continues to meet the security requirements and you don't think it's been stolen. It seems they have judged certificate mis-issuance to be a much more likely threat than key theft. I'm not sure if that same premise would still apply to e-mail, but I wanted to make this correction.

Outside of regulatory requirements, they're useful for code signing (the extra hoops frustrate malicious actors, the legal identity behind the cert can be targeted for banning/suing/prosecuting), apps connecting to their own home services, and document signing, off the top of my head.

This is a bit of a tangent, but Go generics aren't monomorphized. Each instantiation is "stenciled" down to its GC shape and then the differences among types with the same shape are handled using a "dictionary" which is kind of like Swift's witness tables or Go's own interface vtables. See this description for details: https://github.com/golang/proposal/blob/master/design/generi...

The typical end result sits somewhere between monomorphization and type erasure in terms of generated code and runtime indirection.

That only applies when you're replying to someone. It doesn't apply to new conversations or adding someone new to an existing conversation.

Certificate revocation applies to all uses of PKI, not just web browsers. In fact, it is an even bigger problem with email, because there are so many more email addresses than web sites.

But you can't re-use the private key, and you can't keep the same one around for very long. In a thread about "why can't we do Let's Encrypt but for email", surely we must start by accepting one of the most important lessons of the modern WebPKI era, which is that CRLs and OCSP do not work at the scale involved here, which has led to keys and thus certificates being constantly rotated.

Somebody else already said "key management is the hardest problem" and I wholeheartedly agree.