If you can reasonably have the entire bottom layer be connected to ground without the top layer being too crowded, 2 layers could work.
Wires to the underside components? Can you solder them to thru-holes on the underside of the PCB instead?
You can put the MCU and other circuitry on the underside, but perhaps use at least a 3-layer PCB so you can run an internal ground plane under the power components.
Is this keyboard a one-off or are you doing production runs? Try to keep all the SMD components on the same side if you can.
If you’re using the pico rather than a bare RP2040, you’ll have a much harder time putting anything on the underside though.
Most GPUs will have fan spin & lights if only on pcie power (the pcie slot provides 75W without external connection), but then misbehave during display; I know it sounds stupid but make sure the 12V power connector on the top of the card is firmly plugged in, that connector in particular has a reputation for being unreliable.
C because it’s what is used for low-end linux & embedded work.
Shell scripts because they’re the caulk that holds a Linux distro together.
Rust when possible because it’s how I wish systems programming could be.
I remember old Tesla and Firepro drivers had a jank, proprietary alternative to SR-IOV but didn’t think any vendor (except Intel with i915’s GVT-g) had an implementation for their consumer devices.
Software to allow partitioning gpu resources among multiple virtual machines instead of just assigning the one PCIe device to a single VM. Very useful for having a single GPU do 3D acceleration on a host and multiple guests at the same time.
Your personal files e.g. ~/Documents are not recreated, you’ll still need backups of those.
caveats are you’ve got to use:
But all this can be written in the one flake, so yes nixos-install --flake <GIT URL>#<HOSTNAME>
Is sufficient for me to rebuild my desktop, laptop or server from the same repository.
I’ve never used Gentoo, and I’m sure there are other methods of achieving the same level of reproducibility but I don’t know what they are.
Nixos can be as modifiable as Gentoo with the caveat being it’s a massive pain in the ass to do some things. I have a flake for making aarch64-musl systems which has been an endeavour, and… It works? I have a running system that works on 2 different SoCs. I do have to compile everything quite often though.
There are efforts to recreate Nixos without systemd, but that’s a huge effort; because it’s very “infrastructure as code”, you have to change a lot of code where editing a build script would’ve sufficed on arch/Gentoo.
As for nix vs guix, guix was described to me as “if you only ever want to write in scheme”, whereas nix feels much more like a means to an end with practical compromises spattered throughout.
Perhaps, but when I accidentally nuked my system by dd’ing to one of the hard drives, being able to install the exact same system back onto it by pointing the installer to my git repository was an excellent experience.
Statically linking is absolutely a tool we should use far more often, and one we should get better at supporting.
Tailscale edits /etc/resolv.conf, since your DNS isn’t working start by making sure that file is how the archwiki suggests rather than what tailscale changes it to.
An uninstalled tailscale may still have left that file modified.
I wish.
It was a bcachefs array with data replicas being a mix of 1,2 & 4 depending on what was most important, but thankfully I had the foresight to set metadata to be mirrored for all 4 drives.
I didn’t get the good fortune of only having to do a resilver, but all I really had to do was fsck to remove references to non-existent nodes until the system would mount read-only, then back it up and rebuild it.
NixOS did save my bacon re: being able to get back to work on the same system by morning.
A few months ago I accidentally dd’d ~3GiB to the beginning of one of the drives in a 4 drive array… That was fun to rebuild.
It seems a lot of new developers want to do some things differently; old guard devs can either make some compromises, or accept that fewer new devs will want to be part of upstream.
Dunno man, when what the dev of 30+ years said was more or less “fuck off”, it seems that advice was in fact heeded
It’s a chicken and egg problem; manufacturers aren’t going to care to upstream drivers if not enough of their users are on Linux, which slows new hardware. It’s much better than it was, but still ongoing.
Amd’s 7000 series amdgpu driver was busted in several ways for like a year post launch, and is still missing tunables for many GPU features.
Manufacturers are capable of making out of tree and unfree modules, but honestly I prefer the slow progress if it means most driver work stays in-tree.
I actually think this is more an attempt to exploit Trump’s worldview; he’s well-known to view inter-state relationships as purely transactional, and from that lens it seems like a good deal.
Thing is, depending on how the war goes either Russia or the US will take everything they possibly can from Ukraine; it may well be that offering Trump something the US was probably going to try to take anyway is just about the smartest way to turn somebody who was initially hostile to continued aid into someone personally invested in the outcome.
Either Linus or Greg K-H, likely after feedback from many others.
We should be looking at his given reasons, not making assumptions based on some ineffable set of considerations that he might have.
Christof’s given reason of complexity is sensible, it’s also one already considered when allowing R4L in the first place; adding rust language support has been deemed worth the additional complexity.
I was halfway through a message about return path impedance, but remembered the pico is a carrier board with its ground built in it’s USB connector, and the switches are hardly going to care.
My bad, you’ll be fine 👍