1. 4

    IMO, the TrueOS folks are being way to optimistic. I recently switched back to FreeBSD from TrueOS, and a big part of it is that I don’t think they have a track record of being able to deliver their layer as a finished high quality project.

    1. 4

      I agree. The TrueOS guys are working on some interesting stuff but my experience, TrueOS never quite feels finished. Sometimes I think they’re trying to do too much, the big switch with OpenRC, meaning things are quite different from FreeBSD, a server version, desktop version, Lumina…

      I’d be more inclined to use TrueOS if they stuck closer to FreeBSD, but just made it easier to set up a graphical system. Right now they’re not exactly FreeBSD, but they’re not exactly something else. You cant quite apply what you know from FreeBSD though, because of how they do differ.

    1. 5

      So TrueOS is now called Project Trident, and there’s a new project that will take the TrueOS name and will add to FreeBSD at a lower level rather than just being a collection of packages on top of FreeBSD?

      1. 3

        Wow, it would have made much more sense if the announcement had been phrased that way.

        1. 1

          I’m still not sure if my assessment is correct.

        2. 2

          That’s what I took from it. The blog post was a bit hard to understand, I had to read it twice to actually figure out what they’re trying to say.

        1. 4

          Why the choice of Python 3? I probably wouldn’t use any tool like this that doesn’t solely depend on /bin/sh (or can’t be executed via /rescue/sh). The reason being is that if my boot environment is so screwed up that non-base applications (like python) don’t work, yet statically-compiled applications in base (like /rescue/sh) do work, I can’t use zedenv but I can use beadm. My main use case for boot environments is for installing updates and sometimes updates go haywire. I have hit, and am 100% sure I will hit, instances where my environment is so screwed up, only /rescue will rescue me.

          1. 3

            I wanted to build something that’s easily maintainable, and while sh is great, it’s not a programming language. I realize that complex applications can be created with sh, but over time they can become unwieldy. I think they are great for small scripts like starting up services in rc.d, and scripting things quickly, but when I want to build something that can be used or long-term, I would rather use a programming language.

            Part of the point of boot environments, you’re so that you don’t have to enter /rescue. You create a boot environment for the new update, do the update there, and if things go haywire you boot into the old boot environment. At that point, you can mount your broken boot environment, do some surgery, and once fixed you can reboot into it.

            If things are so haywire that all of your boot environments aren’t working, and you have to use /rescue, it’s probably not related to boot environments. If it is, you can always use zfs to fix your problem.

          1. 4

            I’m not clicking that :P

            1. 3
              1. 1

                No viruses… so far.

              1. 4

                I’m kind of disappointed declarative user profiles didn’t make it into the release. That was the big thing I was looking forward to.

                1. 2

                  That would solve a lot of problems and replace ad-hoc tools. I’m glad to see that this is on the roadmap for Nix!

                  1. 2

                    A lot of people, including me, are already using home-manager successfully. It has its own set of user modules (out of necessity) and works like NixOS’ configuration.nix. It also has a NixOS module you can use to put all your home-manager configuration directly into configuration.nix and have it apply in a single nixos-rebuild switch. Its state is moderately active, getting a decent amount of PR’s which are merged quickly. I and many others can definitely recommend it to anybody using NixOS.

                    In comparison, the PR you linked seems more dead than anything. The creators of home-manager (rycee) and NixUP actually intended to work together at some point, but from what I heard from rycee, there wasn’t much communication for a while now.

                    1. 1

                      How is it dead? It’s just been awaiting review for a while.

                      Home manager does seem like a good option, and I’m sure it works, but I’d like to see something that’s built directly into NixOS.

                      1. 2

                        No update in 6 months and very sparse updates in general, there have been a ton of merge conflicts for a while now. The author almost hasn’t been active at all the last 12 months. There have been multiple instances of him picking it up again, but then silence again (see the comments on the PR). It’s now the third oldest open PR in nixpkgs. It’s probably one of the biggest changes to nixpkgs too.

                        The main reason for the success of home-manager is probably just that the author set up a nice repository with a readme and spreading the word. And it’s completely usable on any Linux and even macOS, all in user space, the NixOS integration module is the cherry on the top.

                        1. 1

                          I see, that’s a little disappointing. I’ve been following the PR for a long time - while it will get put to good use either way, I even made an additional donation to Nix purely because I was hoping to see some work going towards it. I was hoping to see it merged soon. I guess I’ll have to start taking a better look at home-manager.

                          Do you know if there is any reason home-manager hasn’t been merged into NixOS? Is it not suitable to be in NixOS, or is the plan to get it in at some point?

                          1. 2
                            • Always having to do PR’s to the already PR-overloaded NixOS will probably reduce home-manager’s development speed.
                            • home-manager modules can’t be shared with NixOS modules as of now, which means there would be lots of duplicated functionality in a single repo, which nixpkgs maintainers wouldn’t like.

                            These are the reasons I can think of right now.

                  1. 5

                    Never thought i’d see Windows shipping tar, OpenSSH, and curl.

                    Looks like the WSL is getting a lot of work.

                    1. 8

                      Sort of an aside discussion, but the author’s choice to distribute the code as a Docker image: is that becoming a thing now?

                      I’m notorious among my peers for installing and trying everything under the sun, and usually having to blow out and reinstall my computer about once a year (usually coinciding with Apple’s release of an updated MacOS). Maybe I’m late to the party, but Docker images are a much cleaner way of distributing projects in a working environment, are they not?

                      1. 13

                        This feels like the kind of thing I’d be grumpy about if I were any older; software distribution is one of our oldest and therefore most-studied problems. Java tried to solve it with a universal runtime. Package managers try to solve it with an army of maintainers who manage dependencies. Giving up on all that and bundling the entirety of latex and all its dependencies (one of the intermediate images is 3 point 23 fucking gigs!) just to distribute a 279 line style file and make it easier to use feels… kind of excessive?

                        That said, I’m not old and grumpy and this is awesome. I kind of hope that this becomes a thing, it’s easy to install and easy to remove (and know that you’ve left no traces on your system) and this image will presumably be usable for a very long time.

                        EDIT: I wrote the above comment while I was waiting for the image to finish downloading. It’s now finished and the final image takes up 5.63GB of my disk space. I don’t mind for this one-off package but would certainly mind if this method of distribution started catching on. Maybe we should just all use nix?

                        1. 3

                          I wrote the above comment while I was waiting for the image to finish downloading. It’s now finished and the final image takes up 5.63GB of my disk space. I don’t mind for this one-off package but would certainly mind if this method of distribution started catching on. Maybe we should just all use nix?

                          Docker has some mechanisms for sharing significant parts of those images… at least if they’re created from the same base. The problem obviously is that people are free to do whatever, so that sharing is far from optimal.

                          1. 1

                            Agreed, I assumed this was going to be something like a 200 python script with maybe 2 or 3 dependencies.

                          2. 4

                            A docker image is the new curl|sh install method.

                            Basically ignore any concerns about security, updates, ‘I want this shit now Ma.’

                            1. 4

                              A random docker image is less likely to fuck up your home dir, though.

                              1. 2

                                I’ve spent a lot more time working with the shell than Docker. I find this Docker image a lot easier to understand and verify than various things I’ve been told to curl | sh.

                                1. 1

                                  Couldn’t you just download and verify a script with curl -o filename.sh http://domain.name/filename.sh? How does a random Docker image end up being easier to verify? With a script you can just read through it, and verify what it does. With a Docker image you basically have to trust an image from 2014 of an entire operating system.

                                  This honestly looks like one of the worst candidates for a Docker image. You have a tiny plaintext file which is all this is installing, and you are being told to download a multi gigabyte blob. I can understand why some people recommend using Docker for development, and running things and places you might not have control of the entire system, it here just seems unnecessary here.

                                  1. 1

                                    I don’t see how it’s installing just a style. It’s installing TeX, which is a big hairy package.

                                    When I pull down the install for rustup, I end up with a 360 line shell script, which isn’t super easy to verify. For haskell’s stack, it’s 720. I swear I’ve seen 1500 before.

                                2. 1

                                  Agree re security (you could get hacked) but at least it won’t accidentally wipe your hard drive while trying to uninstall (as has happened a few timed I’m aware of).

                                3. 3

                                  In this case especially, as the instructions to install and configure are pretty painful:

                                  https://github.com/Jubobs/gitdags

                                  Oh, there are none. But there is this:

                                  http://chrisfreeman.github.io/gitdags_install.html

                                  As an aside, the Docker image has a couple of features I’m quite proud of (in a small way).

                                  1. The default command of the container outputs help text.

                                  2. If the convert_images.sh script spots a Makefile, it runs it, eg:

                                  https://github.com/ianmiell/gitdags/blob/master/examples/Makefile

                                  which reduces build time significantly if you have a lot of images.

                                  1. 4

                                    Just scrolling through that second link gives me anxiety; oh my god this is going to go wrong in fifty different ways. Getting it all together in a configured package (docker image) was pretty smart.

                                    1. 3

                                      I don’t know… Looking at the second link, the install instructions are actually fairly simple if you have TeX and the dependencies installed. Even if you don’t, like it’s just a LaTeX distribution, the tikz package, and the xcolor-solarized package.

                                      In which case the instructions are only:

                                      $ cd ${LATEX_ROOT}/texmf/tex/latex && git clone https://github.com/Jubobs/gitdags.git
                                      $ kpsewhich gitdags.sty   # Check to see if gitdags.sty can be seen by TeX
                                      

                                      I feel like an entire Docker container is a little overkill. Might be an OK way to try the software, especially if you don’t have a TeX distribution installed, but it wouldn’t be a good way to actually use it.

                                      1. 1

                                        From the link:

                                        ‘First, do NOT use apt-get to install. The best is to install TexLive from the Tex Users Groug (TUG).’

                                        1. 1

                                          Yeah like I said, the instructions are fairly simple if you have a TeX distribution Installed. If that version does happened to be from a distribution, I’m sure it works anyways - he did say the best way.

                                          If you don’t happen to have TeX installed, it’s not that complicated to install it from manually from TUG anyways.

                                        2. 1

                                          Looking at the second link, the install instructions are actually fairly simple if you have TeX and the dependencies installed

                                          Yeah, I already have TeX on my system, so I don’t really see what the problem is.

                                        3. 1

                                          The default command of the container outputs help text.

                                          I haven’t seen that before; for a “packaging” container (rather than an “app deployment” container) it’s a nice touch I’ll be copying, thanks :-)

                                        4. 2

                                          I’ve used this very package with nix on OS X, I think a docker image is… a bit over the top personally. It wasn’t that bad to install and setup compared to any other latex package.

                                        1. 4

                                          Hopeful that someday it makes it to one of the BSDs. Fingers crossed.

                                          1. 4

                                            Yeah would be nice to see it be another quality VPN standard. One of the WireGuard developers did mention being open to porting it to the BSD’s, as well as re-liscensing.

                                            1. 2

                                              That was 2 years ago and it’s still GPL. It doesn’t look like they require copyright attribution from contributors, so re-licensing now may be difficult.

                                              I hope they didn’t believe what the self-proclaimed “hardcore BSD user” said in that thread, which is completely wrong.

                                              1. 13

                                                I’m still up for porting this to the BSDs. If you know any BSD kernel developers who would like to work on this with me, please do put them in touch.

                                          1. 2

                                            A nice description of how WireGuard works on Linux, and how it’s different from other VPN implementations.