[00:32] <jrwren> https://pop.system76.com  interesting to see the marketing diverge from ubuntu, even though it is still ubuntu based.
[00:32] <jrwren> "Pop!_OS uses APT and Flatpak package management"
[00:32] <jrwren> system76 knows about the snap/snappy lie
[02:14] <llua> what lie?
[02:36] <jrwren> that it is a good thing. ;)
[12:46] <mrgoodcat> I have not yet used snaps. is it the default installation mechanism on ubuntu these days?
[12:58] <cmaloney> It's what they are convincing commercial folks to use for their software
[12:58] <cmaloney> For other software it depends on the group and whether Canonical has other things for their GSoC folks
[12:59] <cmaloney> I think one of them was "snapping" tootstream at one point, but like most things once the GSoC stopped then the person disappeared and it hasn't been updated since
[13:00] <cmaloney> At least I haven't touched it, and I have no desire to touch it
[14:38] <jrwren> mrgoodcat: chromium in 20.04 is a snap. so if you install 20.04 you are using snaps for at least that one thing.
[14:39] <mrgoodcat> I'm only using ubuntu on the server these days
[14:39] <jrwren> same.
[14:39] <jrwren> but no, it isn't the default for everything. It is still debian based and apt.
[15:26] <mrgoodcat> i'm not really even all that familiar with snap as a concept
[15:26] <mrgoodcat> never really paid that much attention to it
[15:27] <jrwren> its a terrible system that does solve some problems that you probably don't have.
[15:27] <jrwren> the terrible part is: no source packages, so building a package yourself isn't reproducable or even possible sometimes.
[15:28] <jrwren> server push: your system is always talking about to the snappy server and you ahve zero control of when updates get to you or if you even want them.
[15:30] <jrwren> i mean... if you control the box, you could make an iptables rule blocking the communication... but if you have 2 snaps installed and only want ot upgrade one, there is no way. You are not in control.
[15:36] <cmaloney> That's the main thing that I really don't like about snaps
[15:37] <cmaloney> And that's before we get to the "what happens when the community gets bored" aspects
[18:04] <mrgoodcat> super weird that you can't toggle automatic updating per-snap
[18:04] <mrgoodcat> is that an intentional design decision or just a missing feature?
[18:05] <mrgoodcat> i'm sure from the standpoint of someone writing software that they want to package for linux, it is probably great
[18:06] <mrgoodcat> as an open source maintainer myself, I can see some value in "guaranteeing" that all users are on the latest version. since i write a library not an application, auto-updating couldn't work for me though
[18:07] <mrgoodcat> when you say no source packages, I assume you mean there's no equivalent of `apt source <package>`
[18:07] <cmaloney> correct
[18:07] <mrgoodcat> can't remember the last time i used that feature in apt (not implying it's without value, just that I don't use it)
[18:08] <cmaloney> Let me paint a hypothetical: how do you handle beta releases with snaps? :)
[18:08] <cmaloney> or backward-incompatible changes
[18:08] <mrgoodcat> backwards-incompatible changes seems like a bigger deal than beta to me
[18:08] <mrgoodcat> for beta, you can easily just have a second snap for your beta channel
[18:09] <mrgoodcat> obviously that isn't without problems, but it's doable
[18:12] <jrwren> yeah, they have beta channels and you can bounce between versions.
[18:12] <jrwren> but you still have no control over which version is in that channel.
[18:12] <mrgoodcat> one snap can have multiple channels?
[18:12] <jrwren> no.
[18:13] <jrwren> it is a different snap.
[18:13] <mrgoodcat> bummer
[18:13] <mrgoodcat> not that surprising though
[18:13] <jrwren> but with the same name.
[18:13] <jrwren> snap install --beta myapp # gets a diff version
[18:13] <jrwren> so you can't have the beta and non-beta installed concurerntly? apparently? I dunno.
[18:14] <jrwren> which is weird, because they way they are packaged and installed there isn't much of a tech reason you could have both installed.
[18:14] <mrgoodcat> just installed the go snap to see what all this is about
[18:15] <mrgoodcat> looks like it has channels built in
[18:15] <mrgoodcat> stable/beta/edge for each 1.x version
[18:15] <mrgoodcat> plus an overall stable/beta/edge version
[18:15] <mrgoodcat> oh and candidate
[18:16] <mrgoodcat> so it looks like you can't prevent bugfix updates, which _shouldn't_ introduce backwards breaking changes, but we all know that's a lie a lot of the time
[18:16] <jrwren> its not a bad system if tehre were just a few changes.
[18:16] <jrwren> but until there are, I'll prefer flatpacks
[18:17] <mrgoodcat> isn't flatpak for desktop apps only?
[18:18] <jrwren> I don't know.
[18:18] <jrwren> I never thought snaps would get used for server or dev stuff until they were.
[18:18] <jrwren> I mean... go... go of all things is about the dumbest thing to use a snap for.
[18:18] <mrgoodcat> it was the first thing i thought of lol
[18:18] <jrwren> it is literally untarring a tarbal to get a go compiler.
[18:19] <jrwren> yeah, I'm not attacking you.
[18:19] <mrgoodcat> the reason would be to get automatic updates
[18:19] <jrwren> the fact that it is there at all amazes me.
[18:19] <jrwren> someone thought, "yeah, this will be useful" ?
[18:19] <mrgoodcat> I'm primarily a tsc developer, and I like to essentially always run the latest version except when some compiler change breaks my build (which has happened but is uncommon)
[18:19] <jrwren> But..... there are probably peopel out there using ubuntu-core alone with use cases we can't really imagine.
[18:19] <jrwren> so I should jsut STFU
[18:19] <jrwren> yeah.
[18:20] <jrwren> for go, tsc, node... just don't even use debs ;)
[18:20] <mrgoodcat> would never want my CI to update the compiler automatically though
[18:20] <jrwren> right?!?
[18:20] <mrgoodcat> for node I use nvm, for tsc I use npm, nvm is installed directly
[18:20] <mrgoodcat> locally anyways
[18:20] <mrgoodcat> for CI everything is installed directly
[18:21] <mrgoodcat> these days all my CI is run in containers anyways
[18:22] <jrwren> yup.
[18:23] <mrgoodcat> hmm looks like flatpak skips out on sandboxing too
[18:23] <jrwren> containers really throw things like snap a wrench, cuz you've already got yoru base OS image, tiny as possible, I hope, do you really want to pull another one for the ubuntu-core for the snaps to use?
[18:23] <jrwren> yeah, which SOUNDS bad at first... until you realize that a ton of snap apps aren't sandboxed.
[18:23] <cmaloney> Honestly I wish more of the effort would go into debs and ppas
[18:24] <cmaloney> I think PPAs are still the bee's knees
[18:24] <jrwren> yup
[18:24] <cmaloney> but it seems like the half-life to a release's debs is 1 year
[18:24] <jrwren> but making debian packages is even more challenging than making snaps.
[18:24] <cmaloney> and then it dries up
[18:24] <cmaloney> I looked at the snap file for tootstream and couldn't figure it out
[18:25] <cmaloney> honestly, and this is going to sound strange, but RPMs had the most readable format for building packages
[18:25] <jrwren> yup
[18:25] <mrgoodcat> jrwren: the packager supporting sandboxing is the first step to getting more sandboxed apps. I don't think you can brush that away so easily
[18:25] <cmaloney> I still haven't built a .deb package
[18:25] <jrwren> rpmspec was nice and clean and all in one place.
[18:25] <jrwren> mrgoodcat: i'm not brushing it away, i'm just saying it ain't all there.
[18:26] <cmaloney> The problem I'm seeing is that snaps are recreating some of the wall-smashing silliness of Docker without the large community to bash things into working
[18:26] <cmaloney> so you get half-assed docker
[18:26] <jrwren> snaps also break some pretty basic unix/posix stuff: https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu2004SnapsHomeIssue
[18:27] <cmaloney> and docker already feels half-assed as it is
[18:28] <cmaloney> "Although the messages do not say this, the Snap system ignores any $HOME environment variable that you might have set; what it cares about is where /etc/passwd says your home directory is (after any symlinks are resolved). "
[18:28] <cmaloney> FFS
[18:28] <greg-g> ohey, speaking of /home, ya'll see homed yet?
[18:28] <greg-g> :) :)
[18:28] <jrwren> homed?
[18:29] <cmaloney> greg-g: systemd's home stuff
[18:29] <greg-g> yup
[18:29] <cmaloney> I'm grateful there's still BSD
[18:29] <greg-g> https://www.techrepublic.com/article/linux-home-directory-management-is-about-to-undergo-major-change/
[18:29] <cmaloney> for when my computer becomes an unusable teetering mess
[18:29] <greg-g> it isn't yet?
[18:30] <cmaloney> not quite.
[18:31] <jrwren> i'm typing to you on a kb plugged into a mac in an iterm window to an ubuntu server... its a mess.
[18:32] <jrwren> that TR 404s for me
[18:33] <jrwren> https://systemd.io/HOME_DIRECTORY/  for crypto home dirs it is actually a good solution IMO
[18:33] <jrwren> i watched the All Systems Go talk that Pottering did and it made good sense.
[18:34] <jrwren> but then... i actually really like systemd... so... I'm crazy
[18:34] <cmaloney> My only concern is corner cases where it doesn't.
[18:34] <cmaloney> eg: $HOME directories
[18:34] <cmaloney> where we're putting in patches on top of patches to make shit work again the way it worked before
[18:35] <jrwren> but that is exactly what systemd has never done. we had patches on patches before. systemd throws everything out and starts from scratch.
[18:36] <jrwren> resolvconf & dnsmasq... IGNORE those... systemd-resolve for you!
[18:36] <mrgoodcat> think i'm with jrwren here, encrypted home directories are a Good Thing
[18:36] <mrgoodcat> I also have no real qualms with systemd
[18:37] <jrwren> systemd... its like upstart only better!  ;)
[18:37] <cmaloney> Encrypted home directories are great until you have a hardware issue
[18:37] <mrgoodcat> I was annoyed when it was first introduced because I needed to learn a new way to manage services and such
[18:37] <cmaloney> and then you have no home directroy
[18:37] <mrgoodcat> or backups apparently
[18:38] <jrwren> yup.
[18:38] <mrgoodcat> if you're not backing up, not having an encrypted homedir isn't saving you from hardware failures
[18:38] <cmaloney> Right, but if you're having hardware failure you limit your chances of recovery considerably
[18:39] <cmaloney> with an encrypted filesystem
[18:39] <mrgoodcat> ¯\_(ツ)_/¯
[18:39] <jrwren> ugh... SSD in my wife's laptop died yesterday. completely gone. doesn't even show as a device. i think we ahve some backups.
[18:39] <cmaloney> remember when people compressed their filesystems back in the 40MB days?
[18:39] <mrgoodcat> i do not
[18:39] <cmaloney> bad sector = bad boom
[18:39] <mrgoodcat> i am 28 years old
[18:39] <jrwren> yup.
[18:39] <jrwren> Stacker
[18:39] <greg-g> barely a mr ;)
[18:39] <jrwren> DiskDboule
[18:40] <jrwren> now we have the same thing at a filesystem level.
[18:40] <cmaloney> mrgoodcat: It's a lesson that we learned early on
[18:40] <mrgoodcat> I have never had a computer that isn't backed up regularly
[18:40] <cmaloney> the more layers to the data the more chances for failure
[18:40] <mrgoodcat> I also would consider lacking FDE a non-starter for a computer for personal or business use
[18:40] <jrwren> just turn on ZFS compression!
[18:40] <cmaloney> Oh I agree with the backups, but not having to go to backup is a good thing
[18:40] <jrwren> just turn on BTRFS compression.  ;)
[18:41] <cmaloney> just mount /dev/null /home
[18:41] <cmaloney> best encryption and compression on the planet
[18:41] <cmaloney> write once, read never
[18:42] <mrgoodcat> I very rarely have to even consider multi-user systems anymore luckily
[18:42] <jrwren> your ext4 or XFS doesn't do compression?  Run those on ZFS!  https://serverfault.com/questions/617648/transparent-compression-filesystem-in-conjunction-with-ext4
[18:42] <jrwren> 🤕
[18:42] <greg-g> there's already untold lateys between me and where my data lives, really. The diskdrive lies to the kernel, the kernel lies to the user space programs
[18:43] <mrgoodcat> if I did, I would be very uncomfortable with having a homedir that was not encrypted
[18:44] <jrwren> it is pretty cool we are starting to be able to control how the kernel lies to the userspace!  https://lwn.net/Articles/818285/  ;)
[18:44] <jrwren> mrgoodcat: yeah, exactly. the whole system encryption... is that LUKS?... is probably enough for single users systems.
[18:46] <mrgoodcat> i'm not even using single-user so much as single-application systems now
[18:47] <mrgoodcat> and that's assuming that layer isn't abstracted away already, which it is most of the time in my work
[18:48] <jrwren> what really makes me sad about snaps is that the reason they seem to be used because an app needs different deps than the system deps, and they do solve that problem, but that problem could also be solved by exception in some debian packaging requirements. But instead of letting pragmatism rule, idealism rules.
[18:48] <jrwren> mrgoodcat: yeah, a single app container is such a different thing than a single user laptop workstation
[18:48] <mrgoodcat> I have also never worked on an application that was not containerized and globally distributed though, so I think of server operating systems a little differently. it's little more than a comodity to be thrown away to me. nothing persistent on them anyways
[18:49] <jrwren> exactly.
[18:49] <mrgoodcat> my personal and work computers are both macbook pros now
[18:49] <jrwren> and yet... someone has to run the servers that those containers run on ;)
[18:49] <mrgoodcat> yea, but that's not my problem
[18:49] <mrgoodcat> I assume they're not using snaps
[18:50] <jrwren> well.. i think if they are using the canonical distribution of kubernetes, they might be.
[18:51] <mrgoodcat> the last app i was working on used the managed gcp kubernetes service, the one before that used aws ecs (elastic container service is not kubernetes, but is a managed service which solves similar problems)
[18:52] <mrgoodcat> now I work on a tracing
[18:52] <mrgoodcat> agent
[18:52] <cmaloney> I would not assume they weren't using snaps. :)
[18:52] <cmaloney> Authy is using snaps for their desktop application instead of the Chrome extension
[18:52] <cmaloney> and it's mildly irritating
[18:52] <mrgoodcat> cmaloney: I'll rephrase. As long as the service continues to operate as expected, I don't really care what they use
[18:53] <cmaloney> Hoep you never have to maintain someone else's bad decisions. :)
[18:53] <mrgoodcat> also, I very much doubt the people running managed container services at large cloud providers are using snaps :)
[18:54] <mrgoodcat> something tells me kubernetes being updated in gke is a titanic effort
[18:55] <jrwren> what is authy?
[18:55] <cmaloney> Two-factor authentication client
[18:56] <cmaloney> cloud-synced
[18:56] <cmaloney> so I have the same codes on my phone as on my desktop
[18:56] <cmaloney> kinda handy
[18:56] <jrwren> that sounds nice.
[18:56] <cmaloney> mrgoodcat: All I'm saying is that when things go to shit you just remember that still small voice that was cryig off in the distance. :)
[18:57] <greg-g> +1 to authy, that plus bitwarden is what I use
[18:58] <cmaloney> I was using the Google Authenticator, but having it on the desktop was a killer feature for me
[18:58] <mrgoodcat> i'm using 1password. all my 2fas are in google authenticator, but i've been meaning to move them to 1password so I don't have to play with my phone to get them
[18:58] <cmaloney> and it just works better
[18:59] <jrwren> i use DUO... cuz I live in ann arbor and I work for Cisco ;)
[19:00] <jrwren> the best is when the server uses duo push. no code to enter, just tap yes.
[19:00] <mrgoodcat> 1password uses touchid to unlock on macos which I appreciate
[19:00] <jrwren> i keep forgetting mac has touchid now
[19:00] <mrgoodcat> I also have a family account so having my passwords, but also shared family passwords in there is nice
[19:00] <mrgoodcat> i have the new 16" mbp with the improved kb
[19:01] <mrgoodcat> not that I ever use the built-in kb anyways
[19:06] <jrwren> love my cherry mx blues :)
[19:06] <mrgoodcat> just moved my digital ocean 2fa to 1password
[19:06] <mrgoodcat> I knew this was going to be a killer feature, but damn this is the best
[19:06] <mrgoodcat> why did I put this off for so long
[19:30] <brian__> "Should Poettering not be able to develop a solution for the SSH conundrum, systemd-homed will have to be relegated to desktops and laptop distributions, leaving servers out of the mix."
[19:30] <brian__> ok, because no one has ever wanted to SSH into their desktop machine.
[19:31] <brian__> (IRC needs a sarcasm tag)
[19:31] <Scary_Guy> Just use /s
[19:32] <jrwren> you'd still be able to ssh to your desktop machine after you've already logged into it once.
[19:32] <jrwren> who logs out of their desktop?
[19:32] <jrwren> every?
[19:32] <jrwren> ever?
[19:34] <brian__> True, although there's probably at least one failure case where you can't login locally (maybe a b0rked apt upgrade followed by reboot?).
[19:35] <jrwren> isn't that true regarless of systemd-homed?
[19:35] <brian__> Well, SSH would (hopefully) be an option in that case, assuming SSH wasn't b0rked as well.
[19:36] <jrwren> there is an old solution to that... enable ssh as root.
[19:38] <cmaloney> I log out of my desktop
[19:38] <cmaloney> if I can't ssh into my desktop then it's a complete nonstarter
[19:38] <cmaloney> I also ssh to fix things
[19:38] <cmaloney> JFC, no
[19:38] <cmaloney> enable ssh as root? WhyyyyyyyY?
[19:38] <jrwren> i don't use a linux desktop or laptop so WTF do I know ;)
[19:39] <cmaloney> cue my rant earlier about breaking shit that worked
[19:39] <cmaloney> and having to work-around "correct"
[19:39] <jrwren> but it doesn't.
[19:39] <jrwren> it doesn't exist as yet.
[19:40] <jrwren> we don't nkow if that will be an issue.
[19:40] <cmaloney> Right. That's why I'm waiting and seeing
[19:40] <jrwren> same.
[19:40] <brian__> Unless your distro makes the decision for you.
[19:40] <jrwren> and that is another thing nice about systemd, it really is a component system, you don't have to use parts that don't work.
[19:40] <cmaloney> But I can totally see one dippy use-case start ruining things for non-traditional usage
[19:41] <cmaloney> Just means I'll have to install Ubuntu Server and run apt-get install ubuntu-desktop
[19:41] <jrwren> well yeah, that is what we see with snaps... broken for non-traditional usage.
[19:41] <cmaloney> Sorry.... snap get --whatever-the-fuck ubuntu-desktop
[19:41] <jrwren> and heck. thatt isn't even non-traditional, it is just a tiny but out of hte norm.
[19:41] <cmaloney> jrwren: More like "lacking imagination and POSIX documentation"
[19:42] <jrwren> lol
[19:42]  * cmaloney pulls the rant box
[19:44] <brian__> I use snap, but only so that I have automatic updates for software I can't get through a debian repository. So far, that's mostly been limited to JetBrains products.
[19:45] <brian__> But then again, I use Debian, not Ubuntu. ;)
[19:46] <brian__> If Debian starts pulling the "you have to install our distro through snap" card, I'm looking for a new distro.
[19:46] <jrwren> they won't.
[19:46] <jrwren> debian hasn't adopted snap at all AFAIK.
[19:46] <jrwren> heck, can you even apt install snapd in debian? don't you ahve to add a PPA or curl|sh or something?
[19:47] <brian__> Snap is part of the basic debian repository. Fortunately, that's as far as it goes.
[19:47] <jrwren> oh, it is built in now. that is... good I guess.
[19:57] <Scary_Guy> "snap your fingers snap your neck"
[19:58] <Scary_Guy> Anyway I remember having to install it for $something but now I don't use it or the $something.  I should really just rip it out.
[20:08] <jrwren> old, but I had missed it: https://arstechnica.com/gadgets/2020/03/ubuntu-20-04s-zsys-adds-zfs-snapshots-to-package-management/
[20:08] <jrwren> very interesting.
[20:10] <mrgoodcat> brian__: I think it's incredibly unlikely homed would be released and go into wide usage without ssh support
[20:21] <brian__> mrgoodcat: One would hope so.
[20:23] <brian__> I can't help but remember the shitstorm that raged when many distros were early adopters of systemd, though.
[20:23] <jrwren> only from a select few loud people who wish linux was freebsd.
[20:23] <jrwren> "who moved my cheese!"
[20:35] <cmaloney> I can say that my main concern is that everything is essentially moving into init and become some binary blob crap
[20:35] <cmaloney> I hate how systemd takes over logging
[20:35] <cmaloney> but I'm also over it
[20:38] <cmaloney> I just don't want to see the usability that I've come to expect under Linux being supplanted by some of the design decisions I didn't care for under Windows
[20:39] <cmaloney> in order words, don't break grep
[22:56] <jrwren> i hated how systemd took over logging until I saw journalctl used really well.
[22:57] <jrwren> being able to say, "show me the logs from this datetime to this datetie" and get results instantly, not some slow read the file line by line grep that parses the text date.
[22:57] <jrwren> its a major usability increase.
[22:57] <jrwren> it is just a learning curve.