Threads for jedahan

  1. 13

    For those looking for more detailed examples of just how much difficulty can be encountered by trying to learn and use Nix, I can highly recommend . Its long, detailed, and can show some of the good and bad outcomes of the deeper issues touched on in the original post.

    1. 6

      The addrspace keyword seems quite nice for microcontrollers and the like

      pub const will_be_placed_in_flash: i32 addrspace(.flash) = 123;
      pub fn readFlash(ptr: *addrspace(.flash) i32) i32 {
          return ptr.*;
      1. 2

        Wow this is very handy. I assume we’ll be free from trying to understand linker scripts in the future?

        1. 10
        2. 1

          I’m super excited to revisit some Zig GBA stuff that’s floating around online with this.

        1. 27

          I’m a bit sad that this is not including nix as a package builder because nix has wonderful support for creating minimal containers out of a fixed predefined list of dependencies.

          You can just say “build me a container with package X y and z” and you will get one with these packages and all dependencies and nothing else. No cleanup needed, no way to accidentally leave unspecified stuff in the container.

          1. 10

            I think that offering Nix can be a bit of a bittersweet solution, cuz now you need to try and make your stuff “nix compatible”, which can be tough according to what I see around here (and my couple of attempts of just trying to make a dev environment. Granted I am not an expert)

            Another tool I think works here but kinda suffers from a similar style of problem as nix is Bazel. It offers some isolation capabilities (when set up with remote caching you can get massive speedups on big projects), and instead of describing your container as a set of build steps, you’re desribing it as a file tree (cuz that’s what it ends up being!)

            You can get good speedups just from making it so that (for example) your webpack step and your check steps can run in parallel, just from the build description making it clear to Bazel that they aren’t dependent on each other.

            But, like nix, Bazel has a bit of the “do you want to use this? fix your software” problem. Luckily there are a lot of people with an abundance of cleverness who have built out really good tools to handle common languages, but it’s still uphill for some projects

            1. 4

              There is this fairly wide gap between what you need to just play around with some code and what you need to make a build/deploy/run in prod setup work long term. Bazel, and Nix solve the second one at the cost of sometimes requiring you to go quite deep on how stuff get’s built and run. Language based package managers allow you to just play around at the cost of sort of ignoring anything that’s cross-language in many cases.

              It would be nice if there was a gradual path from playing around to productionizing but there doesn’t seem to be.

              1. 7

                Its more than just learning how the package you want gets built and running, but where and how the nix definitions you are likely to be importing have decided to wrap those build systems. This is true of most package managers that define their own DSL, but comparatively speaking the nix DSL for package building is much less ‘standardized’ in what you are supposed to do.

                Two examples of the fallout of the difficulties mentioned (by me and @zaphar):

                1 - I have never seen two experts on nix agree what nix-specific tooling they use in their stack, but they all seem to agree that just following the main nix documentation is not enough.

                2 - I have never seen two nix definitions for an individual package written ‘from scratch’ by two different folks look the same / only differ in what package-specific options they cared to need.

                To contrast, most gentoo ebuilds, exheres definitions, arch linux (src) pkgbuilds, and kiss package definitions often converge very very quickly, so looking at examples and building off those examples give someone who is learning the system much more confidence when starting out, and when becoming an intermediate user.

          1. 6

            I made this dumb little script to replace Docker-Desktop. It uses multipass to create an ubuntu vm, and sets up podman for it. Any feedback is appreciated.


            podman-desktop --cpus 2 --disk 10G --identity ~/.ssh/github 
            1. 8

              I have a lot of problems with systemd, with many articles showing how to do simple things in a complex way.

              This is the first article I’ve read showing actual examples of complex things made simple with systemd, and appreciate it.

              1. 3

                Reproducible builds + dns-sd / local-peering is a great match. Excited to experiment with GUIX now that the user-friendliness seems to have passed my personal threshold.

                1. 3

                  Cool article, thank you for writing. It is not easy to make Haskell approachable and I think this article does a good job at that. Figure I would share a non-haskeller’s immediate unfiltered thoughts in the interest of keeping up discussion and learning.

                  To me, the do notation example (vs Functor/Applicative) is more readable because there are less symbols, and combinations of symbols to parse. To the point where in the do notation, I can infer what it does without having to learn how it does.

                  do notation example
                  -- assuming NoBuffering mode
                  getName :: IO String
                  getName = do
                    putStr "Name: "
                    name <- getLine
                    putStr "Surname: "
                    surname <- getLine
                    return $ name <> " " <> surname

                  There are 3 symbols to learn or infer: <-, $, and <>.

                  My guesses are <- binds, <> concatenates, and $ does something string-related or maybe apply-related

                  Functor / Applicative methods
                  getName :: IO String
                  getName = (<>) <$> get "Name: " <*> ((' ' :) <$> get "Surname: ")
                      get s = putStr s >> getLine

                  There are ~5 symbols to learn or infer: (<>), <$>, <*>, (' ' :), and >>

                  Lots more questions to unpack in the second one

                  • why do we need the parens after <*>?
                  • why is there the : in (' ' :)?
                  • what other ways are there to write get s that help me understand how >> works?

                  After reading the first example, I’d expect the second example to look something closer to:

                  unholy mess of imperative thinking
                  getName :: IO String
                  getName = (<>) <$> get "Name: " <> ' ' <> <$> get "Surname: "
                      get s = putStr s >> getLine
                  1. 5


                    Open Hardware, Free Software. The only blob is for 5GHz WiFi.

                    Now I just need some libre power line adapters.

                    1. 1

                      Have any performance and stability tests?

                      1. 1

                        What’s the OS of the router?

                        1. 1

                          OpenWRT based TurrisOS

                          1. 1

                            Does it have a version with 8 LAN ports? What about 2.5 Gbps Ethernet?

                      1. 13
                        1. 3

                          Wow, this is really amazing. I would love to see more, how did you make it and how does it work?

                          1. 4

                            I made something similar:

                            Sadly, it did not go well with the kids. They unplugged it all the time and it takes a minute to boot. They are back to cheap CD players.

                          2. 1

                            I really like that!

                            Now you have to make the music change when you shave that yak.

                          1. 1

                            A few of us wrote a small zsh prompt called geometry that centers a bit around this idea. You define two arrays, one for left prompt, one for right prompt. The right prompt functions are all called and updated async, left prompt sync. We ship a decent amount of functions that are defined but not enabled. Kinda looks like this:

                            function slowhi() { sleep 7 && echo 'hi!' }
                            GEOMETRY_PROMPT=(geometry_status geometry_path)
                            GEOMETRY_RPROMPT+=(pwd slowhi)
                            1. 1

                              Cool concept. I tried to run this but it starts running into this error after a few updates

                              geometry::rprompt:2: can't clobber parameter GEOMETRY_ASYNC_FD containing file descriptor 11

                              Secondly, I noticed with the slowhi example here that the whole RPROMPT only updates after 7 seconds. Somehow I thought async function updates completing independently would make RPROMPT update with them.

                              1. 1

                                Thanks for testing it! Made an issue for tracking