Just a basic programmer living in California

  • 2 Posts
  • 93 Comments
Joined 2 years ago
cake
Cake day: February 23rd, 2024

help-circle
  • I’ve done that too, and it’s not the same IMO. Ansible doesn’t put entries in the boot loader for older system states you can boot into in case you break something. It’s possible that Ansible configurations aren’t idempotent. The exact versions of packages that get installed can’t easily be managed with Ansible if you’re also regularly updating packages. There’s lots of stuff that is much easier to configure with NixOS and Home Manager. I found my Ansible configs were always out of date, which doesn’t happen with NixOS where editing the config file is how you make any system changes.


  • I think there are arguments for NixOS for a casual user despite the learning curve reputation. But there are also downsides to consider.

    The pros:

    • There is a good, user-friendly installer that makes it easy to get a working system
    • From what I can see setting up KDE is pretty easy - there are configs online that you can paste into configuration.nix without modification
    • NixOS is good for gaming with proprietary drivers and Steam - again it’s a matter of pasting a few lines of configuration
    • Like with other distros it’s easy to recover if something breaks
    • Unlike with other immutable distros you get a lot of options for tinkering with your system, and experimenting. You can dip your toes into the advanced stuff, going from casual user to Linux expert at your own pace, with the safety line of being able to roll back changes at any time.
    • If you stick to the basics you can have a very stable, very update-to-date system without much difficulty.

    The cons:

    • To get the full safety of rolling back a previous point in time you need to ditch channels, and instead use pinned nixpkgs revisions. The best way to do that is probably using flakes - but whatever strategy you use you need to depart from the setup the installer gives you, and learn enough to remake your configuration.
    • You’ll find contradictory instructions depending whether they’re written for use of channels or flakes.
    • Going beyond the basics of installing packages, and using premade NixOS modules gets you into the infamous learning curve. For example I’m guessing that managing kwin scripts declaratively in Nix config might be an adventure. But managing them by hand the way you do in Fedora might be the same. (I haven’t tried this, so I’m not sure.)
    • There is some stuff you have to know, like if you want to run binaries that weren’t built for Nix you want to set up nix-ld first.
    • If you’re building software you have to learn to do things the Nix way because of the lack of FHS. That’s great for Nix fans like me, but frustrating for some.
    • There is no graphical software center, nor automatic updates. You have to use the workflow of installing stuff by editing your config file, and get used to using search.nixos.org to find stuff. This is a pro from the perspective of having a stable system that can be rolled back to earlier states, but might feel less user friendly than a GUI workflow.

    Even if you set up flatpak (which is easy to set up tbf) you’re probably going to be managing flatpaks using the CLI.

    It would be easier for me to recommend NixOS if the installer set up a flake configuration with more niceties pre-installed, like nix-ld. The next best thing would be a de facto standard flake starter configuration for people to copy. But like I said, I think there is a case.







  • My work is using Coderabbit, and I’ve found its feedback to be pretty helpful - especially since I’m working with a language I don’t have a whole lot of experience with (Python). I check what it tells me, but it has taught me some new things. I still want human reviews as well, but the AI can pick up on detail that is easy to skim over.

    It doesn’t cover bigger picture stuff like maintainability, architecture, test coverage. Recently I reviewed a PR that was likely AI generated; I saw a number of cases where logic duplication invited future bugs. (Stuff like duplicating access predicates across CRUD handlers for the same resource, repeating the same validation logic in multiple places.) Also magic strings instead of enums, tests of dubious value. Coderabbit did not comment on those issues.

    I’m also getting feedback from Sonarqube on the same project, which I think is static analysis. It’s much less helpful. It has less to say, and a lot of that is pointing out security issues in test code.


  • I did the swipe to complete an -ing suffix, and yes, I see the appeal!

    Entering punctuation is a bit slow using long-presses on the apostrophe key. Maybe I can get used to using the symbol layer instead.

    Oh! You can swipe from the 123 key to type a symbol from the symbol layer in one gesture! That’s great! It even works for comma! Kinda accidentally - given the comma position I’m swiping over question mark, backspace, comma which gets a net result of typing just the comma. I wish it would go back immediately to the ABC layer.

    Moving the cursor by holding and dragging from space feels better than the similar feature in gboard!

    I miss the gboard backspace feature where you can hold and drag to selectively delete.





  • In typography there are three distinct lengths of dash-like symbols:

    • em dashes are as long as the letter “m” is wide
    • en dashes match the width of the letter “n”
    • hyphen is the shortest, and is the symbol on standard keyboard layouts.

    Traditionally em dashes are used for punctuation—such as to separate clauses where the second clause expands on the first.

    En dashes are used for ranges, like 1–7, or to join words or phrases together.

    Hyphens are used within words, such as to indicate compound-words.

    I think people were more particular about these uses when using typewriters. Like you could type two hyphens, and that would get you the same length as an em dash, and would look like one continuous symbol.

    Nowadays the hyphen is the only easy dash to type, and it doesn’t look like one continuous line when typed twice. So instead of using an em dash people often use a hyphen with spaces around it, and people tend to use hyphens for ranges too. But ChatGPT knows the typography rules, and it likes to be technically correct.

    I’ll note that I’ve just found that on Android you can get em or en dashes pretty easily by showing symbols, and then doing a long-press on the hyphen symbol.

    ———

    Not written by ChatGPT, I’m just like this


  • Fugitive, the vim / neovim plugin. It does everything the CLI does, but uses vim interfaces very effectively to enhance the experience. For example it’s quite good for selectively staging changes from a file. I also like the option to open a buffer with the version of a file from any specified commit.

    I also tried neogit which aims to port magit to neovim. I didn’t like it as much. Partly because as far as I could tell at the time it lacked features compared to fugitive. But also because it seemed to want me to do everything through UIs in its own custom windows. Fugitive is integrated more thoroughly into vim via command mode, and special buffers.


  • I usually use git add -p to selectively stage hunks. But in git add -i I think running the patch command does the same thing to get into patch mode.

    If patch mode shows you a hunk, and you only want some of the lines you can press s to split into smaller hunks. Then you’ll be prompted whether to add each smaller hunk separately.

    If you want to stage a change that is on the same line as a change you don’t want to stage, or on an adjacent line, then you need to use e to edit the hunk. Git stages whatever changes are left when you’re done editing. The file in the working tree on disk is unchanged.





  • It’s hard to predict the future, but I can point to a couple of indexes.

    TIOBE measures language popularity according to a variety of factors. It has Java on a steady downward trend over the last couple of decades, but shows it as still very relevant. TIOBE does not show comparable growth for Golang. I don’t see much growth in the top 10 for languages that are especially suited to autoscaling. C# looks to be steady as a language in a similar niche as Java.

    OTOH another survey from devjobsscanner that looks purely at job postings shows Java openings as very steady over the last couple of years. It also shows Java as more popular than Golang.

    So I don’t know exactly what conclusion to draw from that. But learning a new language can be a helpful exercise regardless to broaden your perspective, and to keep your skills sharp.

    Personally for the purpose of producing resource-efficient binaries for scaling I prefer Rust. It’s design incorporates some correct-by-construction strategies that promote high-quality code. And it’s well-suited for compiling to WASM so you can do stuff like deploy small services to Cloudflare workers for wild scaling. But I guess Rust isn’t making a big showing in the popularity charts. And Golang is popular for its lower learning curve.