Pollute your mount list and make your software start way slower and take up more space. Also sometimes break or require intervention for basic operation due to security restrictions on it.
The benefits are supposed to be that they're more secure, more portable, and don't junk up your system with files strewn everywhere.
Personally I'm waiting for a better solution than anything we've seen so far for the first of those benefits, and would prefer a cross-platform user-oriented package manager like Homebrew or Nix (but better-supported-on-Linux in the former case and with a UX less like studying for a math exam in the latter) for the other two. IMO every solution to these problems on Linux desktop currently sucks to one degree or another.
I admit I've not checked and have just assumed the package list is both ideologically- and mindshare-crippled, due to the GNU on the name and the seemingly low rate of use, respectively.
Nb I think free software goals are great and all but if I need Slack for work or need my proprietary wifi card to work using a binary blob then I f#cking need those things, and it's nice if my package manager can install them for me. It's also nice if it's got enough eyes on it that I essentially never run into a broken package, even when installing kinda-obscure things.
You can use Guix on distros with impure repos, not just the GNU Guix system, and use the host distro's packages for proprietary software (if you can't just use Slack's web client, or use a laptop with a freedom-respecting wifi card / a little dongle / ethernet).
Note that the sandboxing security theater of flatpak and snap etc is largely just that.
You can have very secure deb packages by having default-deny apparmor rules. This is basically how Android works, it just asks you to grant the permissions in real time (and uses a frankenmix of custom Google fu Android Java API and selinux).
You can also use cgroups to control kernel feature access like devices, networking, peripherals, etc.
It comes from both angles though. Having more software provide an apparmor profile (transpilable to selinux policies, etc) and having GUI-integrated permissions and cgroups control functionality in both software stores (via appstream? it seems to be the common thread) for both at-install and at-runtime permission grants.
The problem of course is inertia. Flatpak isn't even compelled to sandbox and its sandbox is not nearly as comprehensive as one would want when running untrusted software, not just potentially exploitable buggy trusted code.
>You can have very secure deb packages by having default-deny apparmor rules.
Nobody would do this on a desktop because it is massively inconvenient to go through every single app you want to run and debug which app armor rule that it's violating. Even when running a service with a pre-written app-armor profile you usually have to spend a while to figure out what the hell went wrong.
Flatpak's sandboxing is a complete joke and is entirely voluntary. Snaps have sane and granular permissions interfaces that you can easily toggle on and off. Canonical is actually enforcing auto-connect rules for the more potentially dangerous ones in their store. If you want to get a classic confined app in the store, it actually has to be approved by their security team.
These things are GREAT for security, which, to be quite frank, is a complete fucking disaster on Linux desktop. X11 is a massive security hole, no real mandatory access control, no sandboxing for apps, local privilege escalations out the wazoo, a quadrillion open security bugs in the kernel. Sure, you can try and set these things yourself, but that relies on the USER to properly configure these things, and if you don't know exactly what you're doing and screw it up (and there are no reliable, consistent guides on how to do these things), then you're just as insecure as you were before.
We're just fortunate that Linux on desktops aren't popular enough to be targeted, because we'd just be getting constantly owned thanks to this massively outdated security model. Windows is actually doing the security model a whole lot better these days, but their popularity and their tendency to implement them poorly and with bypasses to preserve backwards compatibility kind of cancels that benefit out.
It's a real shame that snaps have not taken off. If flatpak wins, and they don't massively overhaul the damned thing to actually add some semblance of sandboxing with permissions controlled by the user, then we're doomed.
Snaps have already taken off in a big way. Many individuals, companies and enterprises have selected Snap because of secure sandbox and automatic updates.
It is just that FUD from Linux Mint causes many HN articles with FUD.
Yeah, but Linux Mint still has snapd removed by default and refuses to support it; so do most of the other popular downstream distros (PopOS, elementaryOS) for desktops. Together, they have way more desktop share than Ubuntu does.
Sure, there are other distros not based on Ubuntu that technically support snapd, but I have yet to encounter one that does it well; Manjaro's still breaks on many snaps, Fedora's snapd stopped working completely for over 3 months and nobody noticed. Pretty much nobody but Ubuntu users actually care about snaps; Flatpak has way, way more support and penetration than snaps do, and it looks as if that isn't going to change any time soon due to Canonical's refusal to open-source the snap store. I don't think snaps have much of a future as a widely-supported method of package distribution if this doesn't change.
Also curious. I'm waiting, or even begging for something like flatpak on mac os just due to the number of times pip/npm/python in general has broken due to homebrew.
• Nothing available that's as lightweight and good as Apple's "office"-type suite.
• Nothing as all-around good as Preview (yes, seriously).
• Worse battery life, partly due to worse OS optimizations and partly due to not having Safari available. Solutions to this in Linux that actually yield good results usually involve hard-capping performance at a pretty low level, IME.
• Little things like screen recording and screenshot capabilities not being as nice for basic use, out of the box.
• AFAIK not only is the default English keyboard on Linux far worse at the task of writing in English than that on macOS, there's not a single alternative layout that's close to as good as the Mac default. Yes, I'm dead serious about this, and frankly it's friggin' weird they'd have such a significant advantage on something like that in the year 2020, and I really wish other operating systems would catch up because I do not like being forced to use Apple products just so my experience composing documents in English isn't bad. I do not understand how they still have such a large advantage here, but somehow, they do. Totally baffling.
• If you do anything serious with software-UI-related graphic design, or work closely with people who do, you pretty much need a Mac because odds are good you'll be using at least some mac-only software or have things shared with you that work only in mac programs.
• You lose a variety of time-saving integrations with i-devices, if you're someone who takes advantage of those.
Look up how you type: those • characters I used in my post, an m-dash (—), a c-cedilla (ç), a german double-S (ß), basic accented characters for various Western European languages (we have many, many loan words and phrases from those in English—façade, résumé, áñ∂ §ò öñ), punctuation for French and Spanish (no, you don't strictly need these for English—but in practice, depending on the register you're writing in, actually you do), major world currency symbols ($, £, €, ¥, ¢), basic mathematical symbols and mathy Greek letters (≤, ∑) and so on.
Look up how you do that on US English keyboard layouts in macOS, Linux, or Windows. Then check AltGr and US International alternative layouts for the latter two. Marvel at how macOS manages to crush all those options in usability with their default, without affecting the experience for someone who doesn't need those at all. Join me in wondering how no-one else has at least matched them on this, which is not some recently-added feature in macOS, but is practically ancient in computing terms.
> Look up how you type: those • characters I used in my post, an m-dash (—), a c-cedilla (ç), a german double-S (ß), basic accented characters for various Western European languages
No thanks! I already new how to type — (Compose - - -), and I was able to guess how to type the others simply by trial and error in less time than it would take to duck/google how to type them:
Compose + . + - → · (close enough for me Edit: Compose + . + = → •) ┃
Compose + c + , → ç ┃
Compose + s + s → ß
Compose + e + ` → è ┃
Compose + e + ' → é ┃
Compose + ` + e → è ┃
Compose + ' + e → é
Bonus:
Compose + - + > → → ┃
Compose + = + / → ≠ ┃
Compose + / + = → ≠ ┃
Compose + : + ) → ┃
Compose + L + L + A + P → (Edit: HN seems to have stripped out the last two, a smiley face emoji and the \\// / Star Trek/Live Long And Prosper hand. So I guess the compose key can type more characters than HN even allows.)
ß°ηυ5 þē 5€¢•ηⅾ:
Pressing the alt key reveals underlines under selectable gui elements. Press any letter that's underlined (while still holding alt) to activate the element (menu item, button, etc.). Try this in every GUI you use regularly and then race a macOS user stuck with reaching for a trackpad or mouse everytime they need to click something. Јоⅰη ⅿе ⅰɳ wօɳԁеrⅰηg Һօw ɳօ‐օɳе аt Аррⅼе tҺօυgҺt tо аⅾԁ tҺіѕ, wҺⅰϲҺ іѕ ɳօt ѕоⅿе rесеɳtⅼу‐аԁԁеԁ fеаtυrе ⅰɳ ԌΝU⁄Ⅼіɳυⅹ, Ьυt ⅰѕ рrасtіϲаⅼⅼУ аɳсіеηt ⅰη ϲоⅿρυtⅰɳg tеrⅿѕ (¡ΝаѕtУ Wⅰηԁоwѕ, рrеҺⅰѕtоrіс Wіηԁօwѕ 95, Һаⅾ tҺеѕе υηⅾеrⅼіɳеѕ аⅼwаУѕ ⌵іѕⅰЬⅼе!).
Great! Linux, I assume? goes looking OK yep, I'll enable it and start re-training myself on that, for when I'm not on mac. It's not quite as quick for most of the things I need frequently, but seems tolerable.
Remaining questions: 1) why would the default be bad? Like, why ever would one make a default bad if there are non-bad options? Especially for something everyone should want to be good on a computer, like composing text in the user's language, and 2) ugh of course even once enabled the default compose key is bad (there's a theme here) and both enabling it and configuring it depends on which WM/DE you're in, Wayland vs. Xorg, and so on, and from some googling it's even possible to run into inconsistent behavior between different friggin' GUI toolkits under the same DE.
OK that second one is a comment, not a question. Still.
I'd recently googled the problem of (specifically) typing an em-dash on Linux, and just tried it again, and sure enough this solution doesn't come up until the sixth hit, in an unassuming Google documentation style guide. "Just memorize a 4-digit number" is the overwhelming answer to that question, on search engines, for some reason, despite plainly being awful. Maybe the configuration hurdle and bad default behavior is why that's the go-to solution, I dunno.
[EDIT] none of the above irritation aimed at you, I hope is clear, and sincerely, thanks for the pointer.
1) why would the default be bad? Like, why ever would one make a default bad if there are non-bad options?
Because it is not bad, it just chooses different advantages and disadvantages.
Right Alt could be configured to do regular Alt modifier, or could be configured to enter additional characters (Alt Gr - third/fourth level).
The first case has advantage that Alt-based keyboard shortcuts on right side can be conveniently entered by one hand. That is why there are Shift, Control and Alt on both sides of keyboard.
Second case has advantage that you can enter more characters, but entering rightside Alt-based shortcuts is more awkward.
Conventionally, US keyboard uses the first approach (as there are less need for entering more characters), while many non-US keyboards use the second approach.
Also, why Compose key is not accessible by default? Because there is no Compose key on common PC keyboard (in constrast to some old Unix keyboards). Therefore, Compose key need to 'steal' some existing key, which is problematic, because users expect existing keys to work as expected. I personally use Menu key as Compose key, but other users may have different expectations.
I imagine it defaults to off and the top results recommend the Control-Shift-U<Unicode codepoint> because otherwise people switching from Windows would complain. It’s my understanding that on Windows typing these characters involves holding down Alt while typing arbitrary Windows-specific numbers on your number pad (What happens if you don’t have one? I’ve no idea!) — or more intuitively, opening a new browser tab, Googling the name of the character, copying it with a keyboard shortcut or context menu (I hate leaving X11 and not being able to simply highlight text and middle click to paste!), and pasting.
All distros I've seen allow you to choose a keyboard layout (and I think at least usually AltGr) at first boot, and I imagine this is how most people using primarily non-English type quickly, on any OS. I personally just use a little WM/DE agnostic script to make capslock useful and add a Compose key:
... and ‘xcape -e 'Shift_L=Multi_key'’ to make tapping Shift work as Compose (xcape is installed by a little bootstrapping script I run when I clone my dotfile repo). But this is better for me because I mostly use Compose for little things like curling my apostraphes (Compose + < or > + ' or " → ‘,’,“, or ”), not so many characters that it needs to be perfectly fast. I don’t have a monitor set-up that’s nonstandard in anything but aspect ratio, or use native apps I don’t trust (like Snaps), so I’ve never had a use for Wayland.
> • Nothing available that's as lightweight and good as Apple's "office"-type suite.
I personally create markdown documents in vis (a text editor like vim, but lighterweight — < 4 MB including optional syntax highlighting, and opens instantaneously enough that I use it to edit many of my HN comments, including this one, by pressing Control + I in my macOS-unsupporting browser) and can compile them to html with discount (< 1 MB) or to PDF, docx, reveal.js slides, etc with Pandoc. This is the peak of ‘lightweight and good’ to me. Apps like Abiword (an extremely lightweight WYSIWYG word processor, but I don't even know how tiny it is because it’s built in to the miniscule Puppy Linux distro that is currently running entirely in my RAM — making any traditional OS look bloated and sluggish to be constrained to run off a PCIE SSD at fastest) may better meet other people’s personal definitions of these words. Given the popularity of web “apps” like Google Docs, I think a native application like any in the LibreOffice suite is probably more efficient than most people care enough to notice.
> • Nothing as all-around good as Preview (yes, seriously).
Not having ever needed to fill out a PDF form, I won’t comment.
> • Worse battery life, partly due to worse OS optimizations and partly due to not having Safari available. Solutions to this in Linux that actually yield good results usually involve hard-capping performance at a pretty low level, IME.
“not having Safari available” — there are a million WebKit based browsers on Linux from the extremely Safari-like Gnome Web to Luakit to suckless Surf.
“hard-capping performance at a pretty low level” — Macbooks have their performance capped by cooling systems that can’t sustain high clock speeds anyway
> • Little things like screen recording and screenshot capabilities not being as nice for basic use, out of the box.
Speak for yourself, Simple Screen Recorder has been exactly that, simple and nice, out of the box, for me.¹
> • AFAIK not only is the default English keyboard on Linux far worse at the task of writing in English than that on macOS, there's not a single alternative layout that's close to as good as the Mac default. Yes, I'm dead serious about this, and frankly it's friggin' weird they'd have such a significant advantage on something like that in the year 2020, and I really wish other operating systems would catch up because I do not like being forced to use Apple products just so my experience composing documents in English isn't bad. I do not understand how they still have such a large advantage here, but somehow, they do. Totally baffling.
Like a sibling comment, I don't know what you’re talking about. However, I can say I love typing with my current layout.²
> • If you do anything serious with software-UI-related graphic design, or work closely with people who do, you pretty much need a Mac because odds are good you'll be using at least some mac-only software or have things shared with you that work only in mac programs.
~~ It’s too bad if this niche has failed to produce more portable programs. But I don’t see it as a failing of the OS for the vast majority of users.~~
elementary OS is itself a serious commercial software-related graphic design project. I am not aware of it’s designers using any macOS only software
> • You lose a variety of time-saving integrations with i-devices, if you're someone who takes advantage of those.
I don’t and I don’t see them as things to be taken advantage of by consumers as much as things to take advantage of and consume them and all their hardware-purchasing decisions through lock-in.
[1]: On the distro I use, PrintScreen instantly pops open a screenshot in a lightweight MS P
aint-style editor (mtpaint, which can crop with one shortcut). On ChromiumOS there’s one shortcut for fullscreen shot and one for drag-to-capture (Control + [Shift +] Show Apps IIRC), either one of which triggers a notification with a thumbnail of the shot that can be clicked to open the folder. I've also seen a small gui for taking shots of windows, areas, or the full screen with or without the cursor and/or a specifiable delay (on an old Puppy). I imagine elementaryOS has a very similar method to macOS, but I’ve never bothered to distro-hop to it because after using macOS for a while at school I didn’t miss it at home (it seems like a good OS only compared to Windows).
[2]: Eg. I can type a superscript one simply by tapping <Compose> <s> <1>, where Compose is mapped to tapping my left shift key. IIUC this would require installing third-party software like Karabiner Elements on macOS.
Yeah, I get there are other reasons people choose Linux—I do too, as I find Win10 intolerable as a working environment so if I'm not on Apple hardware, Linux is my only realistic option for getting things done while still being able to interact alright with the world outside my own computer. I just think that's a small set of the reasons one might find any Linux OS to represent a serious loss of functionality, versus macOS. I agree it'd be cool if more major/trendy design tools were cross-platform, but I work with what I've got.
I don't think the default US keyboard layout on mac makes typing superscript unicode easy but it looks like there are a ton of ways to make it easier, by pointy-clicky through the GUI settings to add either of a couple ways of typing them, by editing a keymap file, or yeah, by using any of several programs like Karabiner. That'd actually be a great addition to the default US English keyboard on mac—a toggle for Unicode super-/sub-script modes.
[EDIT] incidentally, have you observed significant power savings with Webkit browsers on Linux? I like Surf and given FF's ongoing shake-ups I'm giving other browsers a look again, for my browsing-on-Linux needs. On macOS I see something like a 15-20% gain in real-world battery life and noticeably-better overall system responsiveness, using Safari over Chrome or Firefox. Is a similar, dramatic effect noticeable in Webkit ports to other operating systems?
Unfortunately I don’t use GNU/Linux on the go enough to give you a good answer. Surf specifically is probably not good for battery life and now I realize I probably shouldn't have brought it up in this context, because it spawns a separate process per window/tab — it’s noticeably slower than any other browser I’ve used. But GNOME Web/Epiphany though does seem lighter than FF from my limited use of it, worth testing. Personally I use Palemoon as a FF alternative without the shakeups and because the Pentadactyl (fork of Vimperator) extension is beautiful, but I can’t vouch for it’s efficiency.
1) Rarely breaks. Worst I've seen is needing a permissions tweak after an OS upgrade, in many years of use. Back when I switched from Macports I switched because ordinary usage kept rendering Macports so goddamn broken that it was easier to nuke its directory and start over rather than figure out how to fix whatever my bold command of "install package" had destroyed this time. I've never seen normal or even slightly abnormal use put Homebrew in a broken state that required manual intervention to fix.
2) Command line UI is alright. This should be a given but isn't always.
3) Can manage proprietary software for me. There's almost nothing I use (maybe actually nothing?) on my Mac that Homebrew doesn't have an up-to-date package for, aside from Apple-provided apps.
4) Enough people use it that despite being a semi-free-for-all community-run thing packages are pretty much never broken, including the proprietary ones. I'm also continually surprised by how often I find some obscure thing with five stars on Github, want to try it out, and sure enough, there's a Homebrew package.
5) Lets you manage your packages with ordinary user-level permissions. No root elevation required.
6) I can clean practically all of what it's done and get back to a nearly-vanilla system (with the exception of some of the proprietary apps) by deleting one directory. My system and GUI will still boot like nothing's happened. IMO keeping your user-level packages strictly separate from the system-level ones, and managed totally separately, is absolutely the right way to go. I didn't realize how much I wanted this until I started using Homebrew on a Mac, after many many years of Linux package management.
7) It leaves system-level packages that it upgrades alone, so doesn't break core system stuff (I would fucking love this to become a norm on Linux—system uses and assumes latest LTS version for stuff like Python, but I can install whatever version I like for my own use, without affecting that whatsoever and without having to use a different goddamn version-management tool for every single language)
8) I'm pretty sure you can have more than one version of something installed at once and there's a command to switch between them (juggling symlinks, probably), but my recollection of this is vague and may be wrong.
9) If you're actually doing multi-user on your desktop/laptop I think it lets you have per-user install directories and active packages—but I don't really know anyone who does this, and haven't known people to share a computer, really, since over 15 years ago. Amusingly enough, iPads, with practically nothing resembling multi-user support, are the exception to this use pattern, as those seem to get shared among members of a family all the time.
Bad things:
1) Requires Ruby (seems like a dumb complaint, I know, but I hate installing an entire scripting language for a single command line tool, and no not all Linux distros ship with Ruby by default, far from it)
2) I dunno if it still does (I'm working mostly on Debian now) but for approximately forever it's had a completely braindead default for how often it auto-updates its package list when running other commands, and you had to go change that every time you installed it on a new machine so you'd not rip your hair out in frustration when your command to install a package was delayed because it'd been a whopping 16 minutes since the last time it checked for updated packages. Why the hell this didn't default to, like, 12 hours or something is entirely beyond me. AFAIK everyone hates the default behavior, to the point that it's become a common jokey-reference among Mac nerds, and I've never been able to figure out why anyone would want it.
Homebrew is solid, and I think you make a good list.
I had it break before with weird cyclical linking issues, but mostly it works good enough.
What I was more curious about is what specifically sets it apart from a solid Linux package manager?
> Lets you manage your packages with ordinary user-level permissions. No root elevation required.
This is the one major difference I'd say is not currently common on Linux. Could be easily solved by keeping package list databases in $HOME - the only reason root is required nowdays is because these are usually kept as 1 copy per system.
> This is the one major difference I'd say is not currently common on Linux. Could be easily solved by keeping package list databases in $HOME - the only reason root is required nowdays is because these are usually kept as 1 copy per system.
As I posted elsewhere, I think it'd actually be very hard to replicate the experience of Homebrew on macOS, on Linux, specifically for GUI programs, because not only is the the Linux GUI (and related multimedia capabilities, for that matter) so much more fragmented than macOS (where all that ships as one big, stable package) but that fragmentation bleeds through to and manifests in one's experience with individual applications. If not for that, yeah, it'd be very achievable.
Its package selection is also a whole lot bigger than most Linux package managers, in my experience. I don't think I've seen a selection nearly this wide since I was a Gentoo user, many moons ago.
The CLI is better than most Linux package managers—some of those are improving, though. Good error messages and "did you mean..." go a long way.
> think it'd actually be very hard to replicate the experience of Homebrew on macOS, on Linux, specifically for GUI programs, because not only is the the Linux GUI (and related multimedia capabilities, for that matter) so much more fragmented than macOS (where all that ships as one big, stable package
Curious about this, since as far as audio goes, as long as there's PulseAudio on the system, all others tend to have compatibility with it in mind.
> Its package selection is also a whole lot bigger than most Linux package managers, in my experience
That could be, but I personally haven't had an issue with the Arch repo + AUR selections, that's tens of thousands of packages.
> Good error messages
Hmm, these are mostly there, I just made a mistake on purpose and got this, (pacman):
error: invalid option: '--search' and '--sysupgrade' may not be used together
> and "did you mean...
Did you mean would be nice. Git has that and it's certainly helpful
> Curious about this, since as far as audio goes, as long as there's PulseAudio on the system, all others tend to have compatibility with it in mind.
There are hold-out ALSA users (even Linux OSS users still around, I think) and I gather people who need well-performing audio for Serious Work (particularly anything latency-sensitive or requiring that multiple streams be mixed at high quality without errors), and have decided to use Linux for it, end up having to replace or bypass PulseAudio one way or another (this info may be out of date, but given PA's history, I kinda doubt it).
I think the Pulse situation is very similar to the one with systemd (they’re even by the same author IIRC). There are some haters, but if you’re a hater-hater than you can just ignore them (eg. GNOME IUUC depends on both Pulse and systemd, and haters of the dependencies who want the DE just have to find their own shims, like Gentoo’s, deal with some error messages (random games and things often give me a lot of audio-related ones, but generally work ok anyway) or just leave for another DE or WM).
Oddly enough, my favorite package management experiences, by far, have been Homebrew on Mac and Portage on Gentoo. Talk about polar opposites.
I do think, unfortunately, that the experience of a very stable base of macOS with Homebrew on top would be nearly impossible to replicate on desktop Linux, because Linux's GUI layer is so intertwined with user software, and is so... uh, "free and libre", I guess, is a nice way to put it. You'd end up with a bunch of copies of KDE and Gnome libs and probably multiple competing IPC buses or god knows what, in no time. Maybe multiple sound daemons stepping on each other. You'd probably have issues like different apps deciding to do scaling or font rendering differently, or who knows what, because lots of "basic features" on macOS are instead choices on Linux.
> A mounted FS per installed application so you can run different versions side by side.
Does it strike anyone else as very telling that people looked at the problem of "we can't install more than one version of an application at a time because of how we structure our filesystem and hardcode paths" and decided that the solution was "let's give each application its own filesystem!"?
ISTM that anything which lets you install multiple versions side by side will require each version to have pinned versions of dependencies, transitively, until it's very close to the dominant node, which ultimately is the OS API, which in turn, done right, is backward compatible.
You can implement that versioned dependency DAG as a database of versioned libraries etc. combined with a version pinning database; or you can simply use disk space, and keep a copy of every dependency and put each in its own subtree, making the version pinning database implicit in the tree construction.
I don't see the latter solution as being intrinsically worse than the former. I don't think there's a real alternative either; the most reliable set of dependencies is the same set as the original binary was built and tested with.
(And of course it's not just libraries, but also configs of various flavours, assets, etc. If you didn't use the subtree approach, you'd need to reimplement it in a shim layer to simulate it, in order to package yesterday's applications today.)
For the record Flatpak solves the same issue without mountpoint spam by using OSTree zo store flatpaks and their shared runtimes. Not only that, it gets full deduplication of everything and diff downloads just by using OSTree.
AFAIK Snap has no deduplication of installed stuff & not even any dhared runtimes. Not sure if it has diff downloads.
I know, what's up with this? I always feel like the systems guys must know something I don't, and that it would be way harder than I'm imagining. But like.. haven't we learned enough in the last 30 years to know that we need something smarter for mutually dependent pieces of software? Why is nobody trying to do this?
I get that Docker, Snap, Flatpak, etc. are expedient in the here and now. But shouldn't we be trying to rebuild everything on top of nix, and then make nix completely transparent to most users?
From my understanding the new packaging is designed to move the control from the distribution maintainer to the developer. So depending on software and distribution you get a range of advantages and disadvantages. You can continue using apt, snap, flatpack,Stram and binaries from tar.gz so we only gained in choices.
Also, moving control from the user to the developer. Snaps automatically update, and until recently had no way to disable this behavior. This is a poor security choice, and means that a stable system cannot be made.
While apt can still be used, many packages were replaced by snaps, completely defeating the purpose.
Most notably the Calculator app. An app which started in less than a second on Ubuntu 16.04 and which now starts in about 4 seconds on Ubuntu 18.04. All so the developer can include copies of the system library dependencies that already exist in the main filesystem. An app that is notable for providing the user with the most powerful capability of performing arithmetic operations on a modern computer.
Snaps have done what countless desktop environments could never do. Make it faster to do math using Google than by using a local calculator application.
> (N.B. Various snaps for ripgrep on Ubuntu are also available, but none of them seem to work right and generate a number of very strange bug reports that I don't know how to fix and don't have the time to fix. Therefore, it is no longer a recommended installation option.)
I distinctly recall getting suggested by 'command-not-found' to install rg from a snap in some version of ubuntu, but I don't remember what version it was.
Just an hypothesis, maybe some Rust apps that can't be compiled with the toolchain in Debian/ubuntu have no pother choice then use snap/flatpack (so maybe at that time in an LTS ditro apt would not have worked)
This isn't it. They just package a version of ripgrep that does compile with their toolchain. ripgrep has been around for almost four years now, and I think the first release was around Rust 1.9 or so. So even Debian will have a new enough version to compile some version of ripgrep.
I used to include installation instructions for Ubuntu Snap, but they were so mis-managed (both from the perspective the maintainer of the snap and of the entire snap ecosystem itself) that they were causing giant headaches. It became such a problem that I specifically put a call-out to it in my bug report template: https://github.com/BurntSushi/ripgrep/blob/master/.github/IS...
Snap has been hugely annoying on multiple axis since day 1.
So you claim the package was in Debian and Canonical removed it to replace it with a snap? AFAIK if you want to push your stuff into Ubuntu you are always strongly encouraged by Ubuntu to put your stuff in Debian,
>While apt can still be used, many packages were replaced by snaps, completely defeating the purpose.
From my understanding there are not many snaps installed by default, and the ones installed by default are Canonical ones not some Solitaire game you found on a piracy website.
The issue with deb is you need to install the package as root. For example I needed a program to inspect a PDF, I found "PDF Master" and it had a .deb installed , but should I trust this program installer? Because I understand how deb works I downloaded the file, unpacked it and run the application without installing it, we need something that allows us Linux users to run random binaries without giving them root and would be cool if we had easy to use sandboxing and firewalls to prevent this apps connecting to who know what.
they bundle all of their dependencies inside the snap, so even if the projects the snap depends on makes breaking changes and you update your system with those changes, the snap will still work. Snaps also update on the fly without user interaction, which some people like and other people hate.
Personally, I think Flatpak makes more sense than Snap. Snap's all tied up with Canonical
I don't think anyone is upset about the ability of a snap app to update without user intervention. It's the lack of choice. You're forced to take updates.
Agreed.
I wasn't saying the 'ability' to update without interaction was something some people like and some people hate. I said they 'do' update without user interaction, etc etc.
I think we're on the same page. Thanks for articulating that bit of nuance.
Provide a recent version of Arduino on debian-based systems ;)
They're mainly useful for applications which either release too fast or too slow compared to regular distributions. The apps contain their own dependencies.
Another advantage is for messy applications. I'd much rather run Wine applications inside of a sandboxed snap than pollute my base system with all the multilib stuff that's required for wine.
Main benefit is the sandboxed app environment. Snaps are also bundled with their dependencies, so you don't need globally installed dependencies to run the app like you do with apt.
snaps are self-contained apps that ship with their own dependencies, so you get software directly from the developer and you'll be on whatever version they ship.
software installed with apt on Debian is fixed until the next release (unless you're on testing/unstable), so that would be the biggest difference.
yeah basically, although 'more complicated' depends on what you consider to be complicated, because another benefit is that you can be sure they run cross platform across any distro that runs snapd, and you don't actually end up replicating all dependencies in every binary, because snapd doesn't duplicate the ones already installed.
