[08:05] <lotuspsychje> https://www.omgubuntu.co.uk/2019/09/ubuntu-19-10-faster-boot-lz4
[08:28] <tarzeau> lotuspsychje: we use that since over a year, but with xz,  how does it compare to that?
[08:28] <tarzeau> mainly because /boot got full
[08:29] <tarzeau> https://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO#The_file_test_results
[08:29] <tarzeau> i'll stay with xz
[08:29] <tarzeau> we hardly ever reboot
[08:30] <lotuspsychje> cool
[08:30] <lotuspsychje> might be more handy for regular desktops
[08:31] <tarzeau> best thing ever, if you ask me. we also use zram and btrfs fs compression 
[08:31] <tarzeau> and eatmydata for all the deb packages installation (speed boost 100%), about 4500 packages
[08:31] <tarzeau> and now i test mimalloc for special applications
[08:32] <tarzeau> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931079
[08:32] <ubottu> Debian bug 931079 in wnpp "ITP: mimalloc -- compact general purpose allocator with excellent performance" [Wishlist,Open]
[08:32] <lotuspsychje> !info eatmydata
[08:32] <ubottu> eatmydata (source: libeatmydata): Library and utilities designed to disable fsync and friends. In component main, is optional. Version 105-7 (eoan), package size 5 kB, installed size 24 kB
[08:32] <tarzeau> you basically call eatmydata apt-get install all your 4500 packages
[08:32] <lotuspsychje> cool
[08:32] <lotuspsychje> didnt know that1
[08:33] <tarzeau> we got install times from 2-4 hours down to 0.5-1 hours (without ssd)
[08:33] <tarzeau> d-i even has support for it, which we didn't turn on still
[08:33] <lotuspsychje> huge improvement!
[08:46] <lotuspsychje> tarzeau: im gonna skip 19.10 and start with 20.04 devel :p
[08:47] <tarzeau> i'm on 19.10, and wait for 20.04 to become available (the code name is what?)
[08:47] <lotuspsychje> no codename yet before 19.10 release
[08:47] <lotuspsychje> but my bets are= funky flamingo :p
[08:50] <tarzeau> still 34 days until release according to http://bootes.ethz.ch/bts/
[08:50] <lotuspsychje> !19.10
[08:50] <ubottu> Ubuntu 19.10 (Eoan Ermine) will be the 31st release of Ubuntu, scheduled for October 2019 ( https://wiki.ubuntu.com/EoanErmine/ReleaseSchedule ). It will be supported for nine months. Join #ubuntu+1 for support and questions.
[08:51] <tarzeau> wonder when maps.ubuntu.com comes
[08:51] <lotuspsychje> whats maps gonna do tarzeau 
[08:51] <tarzeau> like maps.google.com or maps.apple.com
[08:51] <tarzeau> but in ubuntu colors, hah
[08:51] <lotuspsychje> lol
[13:02] <tarzeau> will ubuntu 20.04 default to wayland or not?
[13:03] <lotuspsychje> no
[13:03] <lotuspsychje> i think ive seen an article it will be still xorx tarzeau 
[13:03] <lotuspsychje> *xorg
[13:04] <tarzeau> can you find that article again?
[13:04] <lotuspsychje> https://www.phoronix.com/scan.php?page=news_item&px=No-Wayland-Default-20.04-LTS
[13:05] <tarzeau> thanks!
[13:05] <lotuspsychje> welcome tarzeau 
[13:06] <tarzeau> one reason less to switch back to debian from ubuntu
[13:06] <tarzeau> but the forced chromium snap still is a big reason to
[13:06] <tarzeau> we already have debian, just not for workstations (only servers)
[13:06] <tarzeau> but i have absolutely no strong opinion to stay with ubuntu
[13:07] <lotuspsychje> i would help you if we had a wishlist tarzeau but i know not enough of the reason why they want snap only chromium7
[13:07] <lotuspsychje> -7
[13:07] <tarzeau> ah popularity-contest, popcon.debian.org would work again, unlike popcon.ubuntu.com
[13:07] <tarzeau> fine for me, need to find more reasons to switch to debian, only issue might be about nvidia cuda repo if that stuff doesn't work with debian i'm out of luck
[13:07] <lotuspsychje> tarzeau: can you come up with a decent reason we could create a bug, to NOT have snap only?
[13:08] <lotuspsychje> as community we got some powers too right
[13:08] <tarzeau> no, they're fully onto the systemd, gnome, snapcraft.io 
[13:08] <tarzeau> i doubt
[13:08] <tarzeau> i feel part of the debian community, and there i can make software packages. :)
[13:09] <lotuspsychje> tarzeau: well, if the snap version doesnt do what you need it to, then lets file a bug there?
[13:09] <tarzeau> and the reason i run kfreebsd clearly is systemd can't infect it
[13:09] <tarzeau> lotuspsychje: and they'll fix it and make it work with snap?
[13:09] <lotuspsychje> yes, but then your issue could be solved?
[13:09] <tarzeau> i'm not using any single snap. we remove it completely from all our ubuntu machines
[13:09] <lotuspsychje> right i see
[13:10] <tarzeau> ah on that single package. who knows if they'll mass migrate more packages to snap?
[13:10] <lotuspsychje> tarzeau: i got an rss news stream @ ##techrss you should see the daily snap releases..
[13:11] <lotuspsychje> they surely will move more stuff towards it my guess
[13:12] <tarzeau> can i view them with a web browser? i don't have an rss reader
[13:12] <tarzeau> they'll end up in version hell, and bug reports
[13:12] <tarzeau> unmanagable
[13:12] <lotuspsychje> few last ones: <[GH0ST]> News from snaps: New Snap: nax <https://uappexplorer.com/snap/ubuntu/nax>
[13:12] <lotuspsychje> <[GH0ST]> News from snaps: New Snap: proxyproxy <https://uappexplorer.com/snap/ubuntu/proxyproxy>
[13:14] <tomreyn> your web browser is anything but the kitchensink, including an rss reader
[13:16] <lotuspsychje> tomreyn: what do you think of this chromium going snappy?
[13:17] <tomreyn> maintaining chromium-browser as a rolling release is probably easier as a snap than as a .deb
[13:17] <lotuspsychje> i kinda understand tarzeau too in heavy mass use/production they dont want to choose snaps
[13:18] <tarzeau> with debs we are in control what we update and what not, with snaps we are not
[13:18] <tarzeau> and if snaps are loaded in memory and get updated, old ones removes
[13:18] <lotuspsychje> yeah auto snap refresh in dmesg all over here
[13:18] <tarzeau> that's bad for the user. we have machines with uptimes more than a day, and software also keeps staying in memory
[13:18] <lotuspsychje> the logs have an own life these days tarzeau 
[13:19] <tarzeau> we centrally log stuff, can be turned off by filter
[13:19] <lotuspsychje> just for fun i put on a daily journalctl -f
[13:32] <tomreyn> oh i can totally understand and appreciate the stance of a company admin wanting to have controllable deployments of application versions / states.
[13:33] <tomreyn> (and on a personal level, too, actually)
[13:36] <tomreyn> on the other hand, if there are no patched packages you can upgrade to, since the software is not in main/restrcited, but is security critical to desktops, then you *might* actually want to accept the limitations / issues snaps introduce. or choose to use a software that is in main instead.
[13:37] <tomreyn> (or use 3rd party builds of this software)
[13:49] <tarzeau> we accept anything but snaps (nor flatpaks or appimages)
[13:49] <tarzeau> running an own reprepro for patching broken stuff (which is not small)
[13:49] <tarzeau> bionic, 286 packages
[13:50] <tarzeau> can provide a list/dump of the names if interested?
[13:50] <tarzeau> ah 233 really (excluding the i386 stuff)
[15:27] <tarzeau> lotuspsychje: it's fun how ltsp guys remove snapd though: http://wiki.ltsp.org/wiki/Installation/Ubuntu
[15:28] <lotuspsychje> ubuntu-server has the choice right for snap/non-snap if i recall?
[18:42] <tomreyn> tarzeau: were you saying you're doing your own security patches on top of packages which are not / no longer in 18.04 as .deb's?
[18:43] <tomreyn> and chromium-browser is one of those?