1. 1

    I’ve enjoyed experimenting with sr.ht up until now, and I’m very excited to see how things will develop now that it’s an alpha. I’m honestly amazed by what you’ve been able to build so far, especially the build service. Keep up the good work Sir!

    1. 1

      Stow is cool and I remember looking at it when I was trying to find something better than git submodules, and symlinking for managing my dotfiles. I ended up going with vcsh, and myrepos, and have so far been really happy with it. It’s a bit more of a minimal solution, and a wrapper around git but it does what I want.

      1. 2

        That’s really cool, I’m impressed by the amount of common layers that can be achieved. I guess that makes sense though since there is so much reproducibility with nix.

        1. 2

          Flatpak is a definite no for me as long as they think it’s acceptable to dump things into $HOME. It’s 2018. No new application should do this.

          1. 3

            Can you elaborate on this? What do they dump in $HOME and where exactly? You can’t change it?

            1. 0

              Flatpak creates its own .var directory in $HOME.

              1. 3

                What’s wrong with that?

                1. 0

                  It’s my home directory, not the application’s.

            2. 3

              I have the same question as @andyc. Do you think of applications that create files, like rc-files, or folders on $HOME directory level or does this even include subfolders of the XDG base directories, e.g. XDG_CONFIG_HOME (~/.config/<application>)?

              Update:

              I just installed an application via flatpak and checked which folders where created/modified and it showed that flatpak does not respect the XDG directories specification, instead the application was installed into .var/app/. I assume that this is what you’re referring to?

              1. 3

                Yes, I was referring to the .var directory.

                But according to the Flatpak developers Flatpak adheres to the XDG spec and .var is “nothing to see here”: https://github.com/flatpak/flatpak.github.io/issues/191

              2. 2

                While I agree with you that they should have used a directory for ~/.var that adheres to the XDG spec - like ~/.local/var - they aren’t dumping configuration or any files besides that directory into $HOME. I would however like to see an explanation as to why it was necessary to use the ~/.var directory. Apparently after a discussion including XDG devs, they decided to go that route.

                1. 3

                  It has been a common issue of application developers to believe that their app is special and should be exempt from the rules. I have seen it many times, but the Flatpak devs invented a whole new level of entitlement.

                  1. 2

                    What’s supposed to be the correct way to do this?

              1. 5

                git is intended to be usable in a non graphical setting, anything that doesn’t render properly as text only has no place in my opinion. Emotions don’t belong in commit messages.

                1. 2

                  So stoked to finally see this come to ZFS. Adding the wrong device and causing problems has been one of the big things people point to being a common mistake for people with ZFS.

                  1. 3

                    Also makes migrating a pool to new hardware way easier. Remove the old vdev, wait for the new one to be built, no downtime in between.

                  1. 3

                    There’s something about break statements I’ve never liked, for some reason they always seem wrong. Not that there’s anything programmatically incorrect about using them.

                    I personally use next() instead whenever feasible, and like that python gives you a concise alternative.

                    1. 2

                      I have felt the same way for many years about break, but I can’t put my finger on it. Often it’s possible to factor the loop into a separate function and use return in place of break; for some reason this feels less dirty.

                    1. 1

                      Really excited to see this, I’ve been running games through wine using flatpak, and I found they run quite well. It would be awesome to see the full steam catalog available on Linux.

                      Really stoked that it’s open source, I look forward to seeing their improvements pushed upstream, hopefully this will benefit all users of wine.

                      1. 3

                        I’m John, I write about projects I’m interested in at the time or working on which are mostly related to System Administration, Unix and Linux.

                        https://ramsdenj.com/

                        1. 7

                          Now we have bpf too, which is supposed to be a higher performance firewall that will support the nftables API.

                          1. 1

                            While it reduces readability, I’ve definitely had cases where having assignment expressions would have meant one less function call. Used sparingly, I think it’s a useful tool to have.

                            1. 12

                              As someone who uses arch on all my developer machines, arch is a horrible developer OS, and I only use it because I know it better than other distros.

                              It was good 5-10 years ago (or I was just less sensitive back then), but now pacman Syu is almost guaranteed to break or change something for the worse, so I never update, which means I can never install any new software because everything is dynamically linked against the newest library versions. And since the arch way is to be bleeding edge all the time, asking things like “is there an easy way to roll back an update because it broke a bunch of stuff and brought no improvements” gets you laughed out the door.

                              I’m actually finding myself using windows more now, because I can easily update individual pieces of software without risking anything else breaking.

                              @Nix people: does NixOS solve this? I believe it does but I haven’t had a good look at it yet.

                              1. 14

                                Yes, Nix solves the “rollback” problem, and it does it for your entire OS not just packages installed (config files and all).

                                With Nix you can also have different versions of tools installed at the same time without the standard python3.6 python2.7 binary name thing most place do: just drop into an new nix-shell and install the one you want and in that shell that’s what you have. There is so much more. I use FreeBSD now because I just like it more in total, but I really miss Nix.

                                EDIT: Note, FreeBSD solves the rollback problem as well, just differently. In FreeBSD if you’re using ZFS, just create a boot environment before the upgrade and if the upgrade fails, rollback to the pre-upgrade boot environment.

                                1. 9

                                  Being a biased Arch Developer, I rarely have Arch break when updating. Sometimes I have to recompile our own C++ stack due to soname bumps but for the rest it’s stable for me.

                                  For Arch there is indeed no rollback mechanism, although we do provide an archive repository with old versions of packages. Another option would be BTRFS/ZFS snapshots. I believe the general Arch opinion is instead of rolling back fixing the actual issue at hand is more important.

                                  1. 8

                                    I believe the general Arch opinion is instead of rolling back fixing the actual issue at hand is more important.

                                    I can see some people might value that perspective. For me, I like the ability to plan when I will solve a problem. For example I upgraded to the latest CURRENT in FreeBSD the other day and it broke. But I was about to start my work day so I just rolled back and I’ll figure out when I have time to address it. As all things, depends on one’s personality what they prefer to do.

                                    1. 2

                                      For me, I like the ability to plan when I will solve a problem.

                                      But on stable distros you don’t even have that choice. Ubuntu 16.04, (and 18.04 as well I believe) ships an ncurses version that only supports up to 3 mouse buttons for ABI stability or something. So now if I want to use the scroll wheel up, I have to rebuild everything myself and maintain some makeshift local software repository.

                                      And that’s not an isolated case, from a quick glance at my $dayjob workstation, I’ve had to build locally the following: cquery, gdb, ncurses, kakoune, ninja, git, clang and other various utilities. Just because the packaged versions are ancient and missing useful features.

                                      On the other hand, I’ve never had to do any of this on my arch box because the packaged software is much closer to upstream. And if an update break things, I can also roll back from that update until I have time to fix things.

                                      1. 2

                                        I don’t use Ubuntu and I try to avoid Linux, in general. I’m certainly not saying one should use Ubuntu.

                                        And if an update break things, I can also roll back from that update until I have time to fix things.

                                        Several people here said that Arch doesn’t really support rollback which is what I was responding to. If it supports rollback, great. That means you can choose when to solve a problem.

                                        1. 1

                                          I don’t use Ubuntu and I try to avoid Linux, in general. I’m certainly not saying one should use Ubuntu.

                                          Ok, but that’s a problem inherent to stable distros, and it gets worse the more stable they are.

                                          Several people here said that Arch doesn’t really support rollback

                                          It does, pacman keeps local copies of previous versions for each package installed. If things break, you can look at the log and just let pacman install the local package.

                                          1. 1

                                            It does, pacman keeps local copies of previous versions for each package installed. If things break, you can look at the log and just let pacman install the local package.

                                            Your description makes it sound like pacman doesn’t support roll backs, but you can get that behaviour if you have to and are clever enough. Those seem like very different things to me.

                                            Also, what you said about stable distros doesn’t seem to match my experience in FreeBSD. FreeBSD is ‘stable’ however ports packages tend to be fairly up to date (or at least I rarely run into it except for a few).

                                            1. 1

                                              I’m almost certain any kind of “rollback” functionality in pacman is going to be less powerful than what’s in Nix, but it is very simple to rollback packages. An example transcript:

                                              $ sudo pacman -Syu
                                              ... some time passes, after a reboot perhaps, and PostgreSQL doesn't start
                                              ... oops, I didn't notice that PostgreSQL got a major version bump, I don't want to deal with that right now.
                                              $ ls /var/cache/pacman/pkg | rg postgres
                                              ... ah, postgresql-x.(y-1) is sitting right there
                                              $ sudo pacman -U /var/cache/pacman/pkg/postgres-x.(y-1)-x86_64.pkg.tar.xz
                                              $ sudo systemctl start postgres
                                              ... it's alive!
                                              

                                              This is all super standard, and it’s something you learn pretty quickly, and it’s documented in the wiki: https://wiki.archlinux.org/index.php/Downgrading_packages

                                              My guess is that this is “just downgrading packages” where as “rollback” probably implies something more powerful. e.g., “rollback my system to exactly how it was before I ran the last pacman -Syu.” AFAIK, pacman does not support that, and it would be pretty tedious to actually do it if one wanted to, but it seems scriptable in limited circumstances. I’ve never wanted/needed to do that though.

                                              (Take my claims with a grain of salt. I am a mere pacman user, not an expert.)

                                              EDIT: Hah. That wiki page describes exactly how to do rollbacks based on date. Doesn’t seem too bad to me at all, but I didn’t know about it: https://wiki.archlinux.org/index.php/Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date

                                2. 12

                                  now pacman Syu is almost guaranteed to break or change something for the worse

                                  I have the opposite experience. Arch user since 2006, and updates were a bit more tricky back then, they broke stuff from time to time. Now nothing ever breaks (I run Arch on three different desktop machines and two servers, plus a bunch of VMs).

                                  I like the idea of NixOS and I have used Nix for specific software, but I have never made the jump because, well, Arch works. Also with Linux, package management has never been the worst problem, hardware support is, and the Arch guys have become pretty good at it.

                                  1. 3

                                    I have the opposite experience

                                    I wonder if the difference in experience is some behaviour you’ve picked up that others haven’t. For example, I’ve found that friend’s children end up breaking things in ways that I would never do just because I know enough about computers to never even try it.

                                    1. 2

                                      I think it’s a matter of performing Syu update often (every few days or even daily) instead of once per month. Rare updates indeed sometimes break things but when done often, it’s pretty much update and that’s it.

                                      I’m an Arch user since 6 years and there were maybe 3 times during those 6 years where something broke badly (I was unable to boot). Once it was my fault; second & third one is related to nvidia driver and Xorg incompatibility.

                                      1. 3

                                        Rare updates indeed sometimes break things but when done often, it’s pretty much update and that’s it.

                                        It’s sometimes also a matter of bad timing. Now every time before doing a pacman -Syu I check /r/archlinux and the forums to see if someone is complaining. If so then I tend to wait for a day or two before the devs push out updates to broken packages.

                                      2. 1

                                        That’s entirely possible.

                                    2. 4

                                      I have quite a contrary experience, I have pacman run automated in the background every 60 minutes and all breakage I suffer is from human-induced configuration errors (such as misconfigured boot loader or fstab)

                                      1. 1

                                        Things like Nix even allow rolling back from almost all user configuration errors.

                                        1. 3

                                          Would be nice, yeah, though I never understood or got Nix really. It’s a bit complicated and daunting to get started and I found the documentation to be lacking.

                                      2. 3

                                        How often were you updating? Arch tends to work best when it’s updated often. I update daily and can’t remember the last time I had something break. If you’re using Windows, and coming back to Arch very occasionally and trying to do a huge update you may run into conflicts, but that’s just because Arch is meant to be kept rolling along.

                                        I find Arch to be a fantastic developer system. It lets me have access to all the tools I need, and allows me to keep up the latest technology. It also has the bonus of helping me understand what my system is doing, since I have configured everything.

                                        As for rollbacks, I use ZFS boot environments. I create one prior to every significant change such as a kernel upgrade, and that way if something did happen go wrong, and it wasn’t convenient to fix the problem right away, I know that I can always move back into the last environment and everything will be working.

                                        1. 2

                                          How do you configure ZFS boot environments with Arch? Or do you just mean snapshots?

                                          1. 3

                                            I wrote a boot environment manager zedenv. It functions similarly to beadm. You can install it from the AUR as zedenv or zedenv-git.

                                            It integrates with a bootloader if it has a “plugin” to create boot entries, and keep multiple kernels at the same time. Right now there’s a plugin for systemdboot, and one is in the works for grub, it just needs some testing.

                                            1. 2

                                              Looks really useful. Might contribute a plugin for rEFInd at some point :-)

                                              1. 1

                                                Awesome! If you do, let me know if you need any help getting started, or if you have any feedback.

                                                It can be used as is with any bootloader, it just means you’ll have to write the boot config by hand.

                                      1. 5

                                        Last time I checked the, ZFS was actually broken in the installer and hasn’t worked for quite a while. I haven’t heard the best things about how well it’s worked for people who have tried installing Antergos on a ZFS root. With how easy it is to install on Arch, I don’t think I’d recommend this to anyone, especially if it’s their first look at zfsonlinux, it might put someone off.

                                        1. 2

                                          the only complaint I have with arch is that pip install and npm install fuck the system up. the solution is you have to use them inside virtualenv, nvm.

                                          1. 7

                                            Which is not a distro problem, but a problem with the defaults of these third party language package managers. Everyone assumes sudo pip install requests is a great idea while have these issues when installing the requests lib from the repository.

                                            I’ve configured my npm to install in ~ for globals things, so it doesn’t mess up my system :)

                                            1. 4

                                              The problem isn’t really an arch issue, it’s related to the defaults of pip and npm. I’ve never had an issue with either negatively affecting my system if I set it up as the arch wiki recommends.

                                              For pip, use --user if you aren’t in a venv, for npm, set $npm_config_prefix to be located in ~.

                                              1. 4

                                                You install pip or npm with the package manager

                                                then you use them according to the man pages and it borks your system.

                                                This is a fault

                                                If special configuration should be done this should come when you install it with the distro package manager. That’s the whole point of a linux distribution. If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool. UX matters.

                                                1. 7

                                                  If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool.

                                                  Actually almost every popular Python package suggests using virtualenvs (or more recently, pipenv). AFAIK, sudo pip install is considered bad practice in the Python community.

                                              2. 7

                                                Yeah, my solution to the npm problem is to stay far far away from npm.

                                                1. 1

                                                  Not exactly a universally applicable solution.

                                                  1. 2

                                                    As a society, however, we’d all be better off if we could.

                                              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.