Is... has System 76 fixed the godawful keyboard yet? The gazellel prof 76 I have is a real pain to type on. It would be a fine laptop if not for the double-blasted horrible keyboard.
Norway has had 0.02 as the legal limit for _many_ years now, this basically means that you cannot drive after a single half liter of beer, glass of wine or a shot of whisky.
I.e. all driving after drinking is drunk driving. BTW, when Norway introduced a legal driving limit in 1936, it was the first country in the world to do so:
This web site (in Norwegian) shows the current rules: 0.02 to 0.05% leads to a fine of 1.5 months worth of your gross salary (or average income if you're a stock broker or similar), which means that it can get very expensive indeed when if the driver is a rich idiot. (Those fines are for when you are stopped without any accident, in a crash they will go up and your insurance won't cover anything.)
At 0.12%, i.e. 50% over the US limit, you are looking at at least 21 days in prison on top of that huge fine.
We have a lot more Teslas per capita here than in any other country but I haven't heard of a single drunk driving incident so far.
"Fast cars don't kill people, bad drivers kill people."
We already dropped 32-bit support in DFly. There are many good reasons for doing it on Linux and the other BSDs as well. I will outline a few of them.
(1) The big reason is that kernel algorithms on FreeBSD, DragonFly, and Linux are starting to seriously rely on having a 64-bit address space to be able to properly size kernel data structures and KVM reservations. While (for FreeBSD) 32 bit builds still work, resource limitations are fairly confining relative to the resources that modern machines have (even 32-bit ones).
(2) Being able to have a DMAP makes kernel programming a whole lot easier. You can't have one on a 32-bit system unless you limit ram to something like 1GB. Being able to make a DMAP a kernel-standard requirement is important moving forwards.
(3) Modern systems are beginning to rely more and more (on x86 anyway) on having the %xmm registers available. To the point where many compilers now just assume that they will exist. ARM's 64-bit architecture also has some nice goodies that it would be nice to be able to rely on being available in-kernel.
(4) Optimizations for 64-bit systems create regressions on 32-bit systems. Memory copies, zeroing, and setmem, for example. Even if 32-bit support is kept, performance on those systems will continue to drop.
(5) There is a lot of ancient cruft in 32-bit code that we kernel programmers don't like to have to sift through. For example, being able to get rid of the EISA and most of the ISA support went a long ways towards cleaning up the codebase. Old drivers are a stick in the craw because nobody can test them any more, so the chances of them even working on an old system is reduced for every release. Eventually it gets to the point where there's no point trying to maintain the old driver.
(6) People should not expect modern features on old machines. The cost of replacing that old machine is minimal. Live with it. It's part of the price of progress. If the industry is a bit slow understanding what 'old' means, than the fewer systems which support these older architectures the better, it will make the point more obvious to the corporations who've lost their innovative edge.
(7) For ARM, going back to the corporate point, there's really no reason under the sun to continue to produce 32-bit cpus, even for highly embedded and IOT stuff. The world has moved on, and even embedded systems have major resource limitations in 32-bit configurations. If kernel programmers have to put an exclamation mark on that point, then so be it.