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.

                                                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.