Like you - I predominantly use pencil. The mechanical "pencil" I always keep on me is actually an Ohto MF-20K3B multi pen - it means I can have a nice black pen as well as a good mechanical pencil.
At least for Nix you _can_ cross compile, but cross compiled and native compiled derivations are not identical - so if you go the cross compiled route you will end up building everything.
Another option is to use Qemu and binfmt_misc - that way you do get the result of "native" compilation, but it's slow.
Is there anything wrong with Gecko architecture? So wrong that it's a major obstacle and cannot be changed? I don't know anything about its internals or browser engines in general, so I can't really comment on that, but what I do know from practice is that a complete rewrite is a very expensive and a very risky project, that will fail more often than not. There should be very serious arguments behind it, something a lot more serious than the age of the codebase or a new and shiny programming language.
It is a very big project and has a big potential for the classic double-free, use-after-free, null-dereferencing, one-off index errors etc. which they designed Rust to get rid of in the first place. I believe they had such a bug some months ago and that it was quite serious.
It's a lot easier to swap out the renderer or the CSS engine for a new one than it is the whole core of the browser engine.
Mozilla decided that replacing Gecko as-is was not reasonably likely to actually happen, and that further efforts towards Servo would be better made by continuing to evolve Gecko.
It seems to just ignore filters like “date listed” sometimes too. And people will list items at nominal prices and give the actual price in the description. Generally a poor experience.
> But AArch64 (or ARM64) and AMD64 did bring a lot more on the table than just larger address space. More registers, and a performance boost by just being better suited for the modern CPU core design.
There is the x32 ABI - 32-bit pointer length, but the AMD64 ISA. I don’t think it ever saw significant adoption though.
I’ve ended up settling on an old Apple Extended Keyboard II. I’ve had several modern keyboards end up dying - failing to register some keystrokes, whilst this thing has has been working for longer than my lifetime…
It's amazing how good true vintage ALPS keyboards are. I have a keyboard with Matias (ALPS clone) switches and they are great to type on, but the switches seem unreliable and I got tired of replacing them.
Inconveniently, vintage Apple keyboards require ADB to USB converters which aren't readily available.
I wish Apple would apply their design expertise to making a modern, reliable(!), electromechanical keyboard that replicated the feel and performance of classic ALPS keyboards.
I ended up making my own adapter based on a cheap CH32X035 dev board [0] - largely as an excuse to also write an 'RTOS' for RISC-V. The code is available on GitHub [1] though I haven't really documented it.
Yes, it’s unfortunate that Dell didn’t put this specific driver on their website for this specific model. However, I think the simplest explanation is that Dell is getting lazy with their driver coverage on their website, not some conspiracy to slowly boil the industry alive.
Use the common tools for exporting a driver from the OEM media if you can’t find it online.
[0] - https://blog.benjojo.co.uk/post/class-e-addresses-in-the-rea...
reply