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

LEDs should last for tens of thousands of hours. There may have been a manufacturing defect in OP’s case.

I realized I made an implicit assumption that I didn’t explain. You can use Nix without NixOS. But the configuration you’re looking at is specifically a NixOS configuration. The shortcuts for setting up nextcloud services are based on the NixOS module system. You could get the same setup with Nix without NixOS, but you’d have to reproduce some of the functionality that is provided out-of-the-box in NixOS. My answer is one way to use the functionality from NixOS without fully installing NixOS.

I think there’s a way that might be easy-ish. In short what the services setting does is to get necessary packages, write configuration files, and install systemd unit files. You can build a NixOS configuration, and symlink or copy the necessary systemd units and configuration files. I think that would work, and would not interfere with other stuff on your system.

NixOS configurations must be built with nixos-rebuild - you can’t use nix-build by itself. You can put your configuration wherever, and run:

$ nixos-rebuild build -I nixos-config=./configuration.nix

That will build everything in paths under /nix/store/ without touching anything else on your system. It will create a symlink in your working directory called result/ with a fully-built, bot not installed, NixOS. If you were running NixOS you would run nixos-rebuild switch to update symlinks to point to all of this stuff. But you’d skip that step.

result/etc/systemd/system/ contains systemd units. There will be a lot of stuff there that you don’t want. You’d need to selectively symlink or copy units from this directory to your /etc/systemd/ tree.

The units use full paths to binaries in /nix/store/ so you don’t need to do anything extra to install software packages.

You might need to symlink or copy configuration files for your services. Those should also be somewhere in result/.

If NixOS and Debian use the same systemd target names your services should run automatically on boot. If not you might have to do some fix-up, or run systemctl commands manually. I think you’d need to run some systemctl commands to start and stop services if you want to update without rebooting.

You can probably do all that symlinking just once if you symlink everything through that result symlink.

Edit: Although, taking a closer look at what services.nextcloud does I see that it does a lot, like initializing databases and creating user accounts if you choose to use a local database. It might be a lot of work to chase down all of the configuration that you would have to copy over. Running NixOS is definitely going to be easier.

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.)

If I’m doing more than one cracking two together is best. For the last one, countertop.

I get the flat, inside-the-sink idea. But I’d want to clean either way, and I clean the counters more often than I clean the sides of the sink.

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

This is basically the plot of Loki

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.

For some more detail see https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g

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.

• Crypto startups seem to be enthusiastic adopters of Rust. It’s not an area I want to get into personally, but this is likely the fastest path to a Rust job.
• Rust is probably the best language for compiling to WASM for running in browsers, in lightweight server-less functions, and as plugins. That could dovetail with your frontend experience. Although it’s a bit of an uphill battle to argue for WASM over Javascript in these cases.
• Rust makes an appealing choice for embedded programming as a safer alternative to C. This kind of work involves learning to program with nostd, and learning about controlling hardware.
• In non-embedded systems low-level pieces like device drivers are another good candidate for Rust.

Oh this is just the thing for playing bard, and casting “vicious mockery” several times per combat

The justification for invading Iraq was a claim that they were developing nuclear weapons. It was well known at the time that the evidence was flimsy, and that even if true it was a flimsy excuse for an invasion. The main piece of evidence was an intercepted shipment of aluminum tubes that were soon shown to have nothing to do with a nuclear program. (See https://en.m.wikipedia.org/wiki/Iraqi_aluminum_tubes). That one is not a conspiracy theory.

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

Thanks for the heads-up!

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.

The first computer I used was (I think) a CP/M system that could run BASIC, and I used to use it to play Castle in the early '90s.

The first computer of my own was a Gateway laptop for college in 2002. It was the first Wi-Fi device I laid hands on. I immediately set it up to play music to wake me up in the morning, and I listened to the fans running all night.