Programmer in NYC
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
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.
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.
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.Wayland replaces the older X protocol. It doesn’t have to operate with older protocols. You might be thinking of XWayland which is a proxy that receives X API calls from apps written for X, and translates those to the Wayland API so that those apps can run under Wayland implementations. Window managers can optionally run XWayland, and many do. But as more apps are updated to work natively with Wayland, XWayland becomes less important, and might fade away someday.
PipeWire replaces PulseAudio (the most popular sound server before PipeWire). Systems running PipeWire often run pipewire-pulse which does basically the same thing that XWayland does - it translates from the PulseAudio API to the PipeWire API. It’s a technically optional, but realistically necessary compatibility layer that may become less relevant over time if apps tend to update to work with PipeWire natively.
So no, both Wayland and PipeWire are capable of operating independently of other protocols.
It looks like there is at least one work-in-pprogress implementation. I found a Hacker News comment that points to github.com/n0-computer/iroh
NixOS puts your full system configuration in a portable set of files. You can easily reproduce the same configuration on another machine. I also like that instead of accumulating a growing list of packages that I don’t remember why I installed I have package lists specified in files with comments, and split into modules that I can enable or disable.
IMO NixOS works best when you also use Home Manager to apply the same benefits to your user app configurations and such. (OTOH you can use Home Manager to get those benefits without NixOS. But I like that I get consistency between the OS-level and user-level configurations, and that both use the same set of packages.) I use Home Manager to manage my list of installed packages, my dot files, Gnome settings, Firefox about:config settings, and so on.
You might be installing packages imperatively with nix profile install or with nix env -i. If that’s the case you’re not going to see the full benefits of a declarative system in my opinion. I prefer to install packages by editing my Home Manager configuration and running home-manager switch.
I like that NixOS + Home Manager automates stuff that I used to do by hand. A couple of the things that I do or have done are to,
Now I have that kind of stuff automated:
modifications = final: prev: {
neovide = final.neovide.overrideAttrs (oldAttrs: {
patches = (oldAttrs.patches or [ ]) ++ [ ./neovide-font-customization.patch ];
});
};
You can see that I compile some things from source. That’s fine on my desktop, but takes a while on my travel laptop. But I don’t need to compile on my laptop because I can use Nix’s binary cache feature. I push my NixOS and Home Manager configurations to Github, and I have Garnix build everything that I push. Garnix stores everything it builds in a binary cache. So when I pull my latest configuration version on my laptop it downloads binaries from that cache.
Sharing the link because it took me a minute to find it: https://codeberg.org/dnkl/fuzzel
I’m also a PaperWM fan. For switching I mostly use spatial window-switching controls: Meta+ left/right to switch windows, page up/page down to switch workspaces. Plus I use Gnome overview’s search-driven app finder, and Advanced Alt-Tab Switcher but only for its fuzzy search feature to switch to specific windows within an app.
PaperWM has an option to hide windows in a “scratch” layer. I put chat and music programs there, and summon them with AATS.
I have an ultrawide monitor, and I put a terminal and editor side-by-side in a ¼-¾ ratio. I set browser windows to ½ width. Those ratios let me see important parts of a browser window next to the editor if I slide the terminal out of view to partially expose a browser on the other side. Or I can move the terminal next to the browser and see both fully.
Yeah, that makes a lot of sense. If the thinking is that AI learning from others’ works is analogous to humans learning from others’ works then the logical conclusion is that AI is an independent creative, non-human entity. And there is precedent that works created by non-humans cannot be copyrighted. (I’m guessing this is what you are thinking, I just wanted to think it out for myself.)
I’ve been thinking about this issue as two opposing viewpoints:
The logic-in-a-vacuum viewpoint says that AI learning from others’ works is analogous to humans learning from others works. If one is not restricted by copyright, neither should the other be.
The pragmatic viewpoint says that AI imperils human creators, and it’s beneficial to society to put restrictions on its use.
I think historically that kind of pragmatic viewpoint has been steamrolled by the utility of a new technology. But maybe if AI work is not copyrightable that could help somewhat to mitigate screwing people over.
That sounds like a good learning project to me. I think there are two approaches you might take: web scraping, or an API client.
My guess is that web scraping might be easier for getting started because scrapers are easy to set up, and you can find very good documentation. In that case I think Perl is a reasonable choice of language since you’re familiar with it, and I believe it has good scraping libraries. Personally I would go with Typescript since I’m familiar with it, it’s not hard (relatively speaking) to get started with, and I find static type checking helpful for guiding one to a correctly working program.
OTOH if you opt to make a Lemmy API client I think the best language choices are Typescript or Rust because that’s what Lemmy is written in. So you can import the existing API client code. Much as I love Rust, it has a steeper learning curve so I would suggest going with Typescript. The main difficulty with this option is that you might not find much documentation on how to write a custom Lemmy client.
Whatever you choose I find it very helpful to set up LSP integration in vim for whatever language you use, especially if you’re using a statically type-checked language. I’ll be a snob for just a second and say that now that programming support has generally moved to the portable LSP model the difference between vim+LSP and an IDE is that the IDE has a worse editor and a worse integrated terminal.
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
chrootinto 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