kbolino

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.

You wouldn't. Let's Encrypt doesn't verify anything more than that the requestor of the HTTPS certificate currently has control over the domain. The equivalent would verify nothing more than that the requestor of the S/MIME certificate currently has control over the email address. This part is actually a fairly standard procedure already, as a lot of websites will send verification emails to fully activate new account signups.

Why such a long lifetime?

If you could actually solve the deeper problem of the sender being able to find the correct certificate to use for the recipient(s), then the lifetime could and should be as short as possible, as in days not years. The recipient can decrypt the message forever, as long as they continue to possess the private key, even if the associated certificate expires. Short-lived certificates are the only effective mechanism for dealing with key theft and mis-issuance that works at scale.

Without major cross-national legal changes, OV/EV certificates on the open web are pointless at best and misleading to the point of being dangerous at worst. They remain quite useful in specific scenarios outside of normal web browsing, but that's not the issue at hand.

SQL parameter bindings solve only one part of the problem, that of putting variables into value positions. They don't solve the problem of putting variables into name positions (you cannot "SELECT FROM ?" or anything like it), and they certainly don't solve the problem of dynamic SQL. This is somewhat orthogonal to the topic at hand, but the mentality should be that the problem space is still quite open, with the existing solution being a starting point, not an ending point.

It's not a threat.

Most websites don't use CAA records at all. The records can only narrow what CAs are acceptable down from the end user's root trust store, they can't add new CAs to it. And CloudFlare is typically in charge of managing its customers' certificates, so they add CAA records for their own CAs.

If you don't trust CF to manage your certs, you are not in their target market and generally should not use their products.

https://developers.cloudflare.com/ssl/reference/certificate-...

I'm responding to both your comments to me in one place. My memory here is fuzzy, especially of 16-bit Windows (which I did use, but I was a child at the time). But, from what I can gather, there is an important difference between 16-bit and 32-bit Windows programs.

In 16-bit land, WinMain is an application entrypoint, and launching an already-open application again causes its WinMain to be invoked with hPrevInstance set to a non-NULL value. Here, the distinction between "process" and "application" was nonexistent/irrelevant.

In 32-bit land, WinMain is a process entrypoint, hPrevInstance is always NULL, and launching an already-open application again causes a new process to be spawned by the O/S. If the application wasn't coded for explicit coordination (using O/S-level mutexes or IPC mechanisms), then two or more running copies of the same application are not aware of each other, do not share any resources, and for a long time were not treated as a single "application" by the operating system.