LEDs should last for tens of thousands of hours. There may have been a manufacturing defect in OP’s case.
Programmer in NYC
LEDs should last for tens of thousands of hours. There may have been a manufacturing defect in OP’s case.
It scrolls smoothly, it doesn’t snap line by line. Although once the scroll animation is complete the final positions of lines and columns do end up aligned to a grid.
Neovim (as opposed to Vim) is not limited to terminal rendering. It’s designed to be a UI-agnostic backend. It happens that the default frontend runs in a terminal.
I don’t know if it’s your cup of tea, but Neovide provides smooth scrolling at arbitrary refresh rates. (It’s a graphical frontend for Neovim, my IDE of choice.)
Well you’re really feeding my Nix confirmation bias here. I used to use Ansible with my dot files to configure my personal computers to make it easy to get set up on a new machine or server shell account. But it wasn’t great because I would have to remember to update my Ansible config whenever I installed stuff with my OS package manager (and usually I did not remember). Then along came Nix and Home Manager which combined package management and configuration management in exactly the way I wanted. Now my config stays in sync because editing it is how I install stuff.
Nix with either Home Manager or NixOps checks all of the benefits you listed, except arguably using a “known” programming language. What are you waiting for?
For the PaperWM fans, this is a dedicated WM based on the same idea
AFAIK the best thing you can do to improve your coffee-freezing process is to prevent moisture from getting into the beans when you thaw. If you let it, moisture from the air will condense on the cold beans. So keep the beans in a closed, airtight container until they come to room temperature. (Airtight because water vapor is air.) So yeah, jars are good for this. Or sealed freezer bags should work too.
Well ok, they both use symlinks but in different ways. I think what I was trying to say is that in NixOS it’s symlinks all the way down.
IIUC on Fedora Atomic you have an ostree image, and some directories in the image are actually symlinks to the mutable filesystem on /var
. Files that are not symlinks to /var
(and that are not inside those symlinked directories), are hard links to files in the ostree object store. (Basically like checked-out files in a git repository?)
On NixOS this is what happens if examine what’s in my path:
$ which curl
/run/current-system/sw/bin/curl
$ ls -l /run | grep current-system
/run/current-system -> /nix/store/p92xzjwwykjj1ak0q6lcq7pr9psjzf6w-nixos-system-yu-23.11.20231231.32f6357
$ ls -l /run/current-system/sw/bin/curl
/run/current-system/sw/bin/curl -> /nix/store/r304lglsa9i2jy5hpbdz48z3j3x2n4a6-curl-8.4.0-bin/bin/curl
If I select a previous configuration when I boot I would get a different symlink target for /run/current-system
. And what makes updates atomic is the last step is to switch the /run/current-system
symlink which switches over all installed packages at once.
I can temporarily load up the version of curl
from NixOS Unstable in a shell and see a different result,
$ nix shell nixpkgs-unstable#curl # this works because I added nixpkgs-unstable to my flake registry
$ which curl
/nix/store/0mjq6w6cx1k9907vxm0k5pk7pm1ifib3-curl-8.4.0-bin/bin/curl # note the hash is different
I could have a different version curl
installed in my user profile than the one installed system-wide. In that case I’d see this:
$ which curl
/home/jesse/.nix-profile/bin/curl
$ ls -la /home/jesse | grep .nix-profile
.nix-profile -> /nix/var/nix/profiles/per-user/jesse/profile
$ ls -l /nix/var/nix/profiles/per-user/jesse
profile -> profile-133-link
profile-130-link -> /nix/store/ylysfs90018zc9k0p0dg7x6wvzqcq68j-user-environment
profile-131-link -> /nix/store/9hjiznbaii7a8aa36i8zah4c0xcd8w6d-user-environment
profile-132-link -> /nix/store/h4kkw1m5q6zdhr6mlwr26n638vdbbm2c-user-environment
profile-133-link -> /nix/store/jgxhrhqiagvhd6g42d17h4jhfpgxsk3n-user-environment
Basically symlinks upon symlinks everywhere you look. (And environment variables.)
So I guess at the end everything is symlinks on NixOS, and everything is hard links plus a set of mount
paths on Fedora Atomic.
If you put an FHS on the actual system you wouldn’t be able to install multiple versions of the same package, updates wouldn’t be atomic - you wouldn’t get the big selling points of Nix.
When science kills the mystery, semantics keeps the debate alive!
To answer your other question, yes there are still single-cell organisms evolving into new species all the time, in the ocean and elsewhere. That includes new multi-cellular species evolving from single cells all the time. But it takes a long time to develop from cell, to clump of slime, to something with legs. So you might not notice the changes if you aren’t super patient.
Or were those separate questions? Are you asking if chickens descended from single-cell organisms? Yes they did. With a lot of steps in between.
For some more detail see https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g
“Atomic” is a catchy descriptor! Atomic distros for the Atomic Age! It could be an umbrella term since NixOS and Guix are atomic, but instead of images and partitions they use symlinks, and patch binaries to use full paths for libraries and programs that they reference. So there are image-based distros, and I guess expression-derived distros which are both atomic.
I haven’t tried image-based distros. This post fills in some gaps for me. Thanks for the write-up!
Although they’re not in the search, they are in the manual so you can find them searching that page. This one is listed as,
security.pam.services..fprintAuth
But it does take some inferences to find this, and to realize that you can put doas
in place of ``
I did some digging around in the manual, and I tested this option which seems to work:
security.pam.services.doas.fprintAuth = true;
On my machine that adds this line to /etc/pam.d/doas
:
auth sufficient /nix/store/fq4vbhdk8dqywxirg3wb99zidfss7sbi-fprintd-1.94.2/lib/security/pam_fprintd.so # fprintd (order 11400)
Edit: Note that the NixOS option puts in the full path to pam_fprintd.so
. That’s necessary because NixOS doesn’t put so
files in search paths.
Without doing more research I don’t know how to add arbitrary options to pam files in case you run into something that isn’t mapped to a NixOS option yet. The implementation for the pam options is here; there might be something in there that would work.
There is a bug report with some discussion here: https://github.com/ValveSoftware/steam-for-linux/issues/8076
Here is a source with lots of detail on how carbon emissions compare: https://www.theguardian.com/business/2023/dec/23/do-electric-cars-really-produce-fewer-carbon-emissions-than-petrol-or-diesel-vehicles
The tl;dr is that EVs have lower lifetime emissions. If the relevant grids use low-carbon sources then emissions are far lower. (But not as low as bicycles.)
I did not realize nano implemented syntax highlighting!
Oh right, there are some particular things that are helpful for a deeper language understanding.
Type classes and algebraic types are for sure standout features of Rust that make it better than most languages. Much of my experience before Rust was Typescript, but I have some background in Haskell so I was fortunate to have a head start on these concepts. I haven’t done any Rust interviews - my current role switched from Haskell to Rust after I joined. So I don’t know what interviewers are asking.
None of the prior languages you listed use manual memory management (which was the same for me). And even if you have that background, Rust does some things differently. (Although from what I understand explicitly codifies a number of ideas that experienced C++ devs have in their heads as “good practice”.) I think you’ll want to study up on how memory works. One of my favorite resources for this is Logan Smith’s Youtube channel. Those videos get me thinking about how this stuff I take for granted really works. The first two Rust videos on there, Use Arc Instead of Vec and Choose the Right Option are good ones to watch. Even if you opt not to use Arc<[T]>
or Box
it’s useful to understand how those differ from Vec
and String
.
Closures are weird in Rust, and are worth understanding. You have to choose between Fn
, FnMut
, and FnOnce
. Plus there is the move
keyword. I love the post Finding Closure in Rust for explaining what’s going on there. (It takes the implement-your-own-version approach which is a genre where I’ve incidentally seen some other gems, like Implementing a simple Promise in Javascript, and The Git Parable for understanding how git really works.)
Another area that is helpful to study is Rust’s implementation of async
. It is similar to async
as you’ve seen it before, but also different. For example in Javascript when you call an async function like, say, fetch
it dispatches network requests right away. But in Rust a Future
does not do anything until you call await
on it. Learning about async
leads into understanding of some more general language features. At the shallower end you learn about functions that return types based on trait, like impl Future
or Box>
because Future types often can’t be named directly so you have to describe what trait they implement instead. (This is very similar to how you work with functions that return closures.) At the deeper end you learn about working with Pin
. You can get a deep dive on that in Pin and suffering by fasterthanlime. All of that guy’s posts are useful, but they are deep plunges so it can take some motivation to read them.
Since I seem to be recommending people to learn from I’ll add Mara Bos’ blog. She’s the Rust Library team lead. Her blog gets into some of the nitty-gritty stuff that gets you thinking about the language on a deeper level. She also wrote a book recently, Rust Atomics And Locks. I haven’t read it yet, but it looks useful.
Hey, you’re on a similar path to me. I’ve been on a Rust job for the past year.
Being a general-purpose programming language Rust can be used in a lot of contexts. The work I’m doing is all API server stuff, which I’m sure you already have a solid background in. There are some niches where Rust stands out that might be worth studying depending on your interest, but none of these are essential to Rust work generally.
nostd
, and learning about controlling hardware.
I think you can mount an ISO image under your running system and make changes. I found a couple of guides that might be helpful:
How to Mount an ISO File on Linux
Edit and repack .iso bootable image
I haven’t done this before, but I think you can
chroot
into the mount directory, and run package manager commands in the mounted image to install another package.Or I have an alternative suggestion that might or might not be easier. I’ve been hearing a lot about immutable/atomic distros, and people designing their own images. You could make your own ublue image, for example, with whatever you want on it.
A promising looking starting point is github:ublue-os/startingpoint. Ignore the “Installation” instructions, and follow the “ISO” instructions instead.
Or I saw recently an announcement of a new way to build atomic images that is supposed to be easier than ever, BlueBuild