Programmer in NYC

  • 0 Posts
  • 52 Comments
Joined 2 years ago
cake
Cake day: May 7th, 2023

help-circle



  • (This is probably explained in the article, but I don’t have a subscription.) The National Ignition Facility (NIF) creates fusion by bombarding a fuel capsule with lasers. The laser beams are reflected many times to build up energy, and to converge on the capsule. There is energy loss during that process so the laser energy that goes into the capsule is a small fraction of the electricity used to fire the lasers. When they say they got twice the energy out, that’s compared to the laser energy going into the capsule, not the energy required to fire the lasers. So its a long way off from a practical power plant, but still important progress.

    The purpose of the NIF is to study what goes on inside the capsule - for better understanding, and to figure out how to get the most possibly energy out of a fusion reaction. Once they have figured that out a possible next step is to design a system that delivers laser beams with less input energy. It’s easier to do that after you know the ideal way for beams to interact with the capsule. Or maybe we never build a power plant based on the NIF design, but the findings help to make other reactor designs work.


  • 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?



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




  • hallettj@beehaw.orgtoAsklemmy@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    4
    ·
    9 months ago

    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.





  • hallettj@beehaw.orgtoLinux@lemmy.mlNixOS - edit system files
    link
    fedilink
    English
    arrow-up
    13
    ·
    edit-2
    10 months ago

    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.



  • hallettj@beehaw.orgtoRust@programming.devWorking as a Rust dev
    link
    fedilink
    English
    arrow-up
    4
    ·
    10 months ago

    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.


  • hallettj@beehaw.orgtoRust@programming.devWorking as a Rust dev
    link
    fedilink
    English
    arrow-up
    8
    ·
    10 months ago

    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.

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