KDE and GNOME seeks $100k to turn Flathub into a Store for the Linux desktop
github.com
github.com
I think the only issue I ever had with them was the inability to inject files inside. Do you know if that's possible?
I was trying to use a browser, I think Vivaldi, that had instructions for enabling widevine by copying a file to a certain directory, but I couldn't find a clean way to do so.
It will depend how an app has been packaged, but when well done the sandboxing is invisible.
Now, maybe the Linux approach is so good and useful in other ways that it's worth putting up with that, but it is a big problem and people are going to solve it, one way or another. If the model can't be changed, then the only solutions available may be bad, but they'll be used, and widely.
No, it is not. If you want security you need dependency management and software lifecycle management on all OSes and platforms.
Multiple versions of openssl is a security problem that merely updating cannot solve.
Besides, sufficiently quality minded projects always wind up vendoring all of their dependencies anyway. There's a reason Chrome has their own fork of everything down to the compiler.
Plenty to criticise about it from a product perspective but from an engineering one it is kind of a marvel.
On my GFs computer Chrome starts in about 7 minutes after fresh boot, no other programs running, yet. From a fricking Samsung SSD, 8GiB RAM. All it has to do is show some fake tabs and render a single page content.
Tell about its quality to my GF. She's used to it, but some of these days, I'll check the DNS logs, to see if it's really loading all the 1000 tabs (she keeps open at once), for 0 reason whatsoever, or if it's just that slow to start one page.
There is something wrong with your GF’s computer. I have no idea what but a seven minute start time is absolutely atypical.
I actually know of quite a few people who use browsers this way, so it may not be a terrible idea to have something like this.
Also the same chrome profile starts very fast when she uses the "private browsing mode" which doesn't restore any tabs. So it really just seems like chrome having perf issues with tab restore with many tabs.
But anyway the point still stands: an outlier user with 1000 tabs open had a slow startup time doesn’t mean Chrome is horribly engineered. If it isn’t an extensions issue then it’s a minor bug.
It's not about quality. It's about reproducibility of the exact versions of all dependencies. It's about communications with repos not being subverted to load malicious packages. It's build security not app quality, though app quality is a part.
Meanwhile we have distros lagging behind for years to provide a new package because they can't break all the things depending on the old version.
I'm glad I left this category of problems behind me 5 years ago when I switched both, my personal and my work laptop to arch-linux/i3wm. These two machines have been running for 5 years, almost daily, with almost no issues, with the latest software packages. If the hardware lasts, I will go on like this for another 3 to 5 years and then upgrade hardware and (maybe) switch to wayland. I don't see anything on the horizon which would make me switch away from this setup.
Come to think of it I can probably prune one of the windows...
ETA: and maybe one of the workspaces...
Which part of Arch's design prevents the issue described in the grandparent post? The issue is "distros lagging behind for years to provide a new package because they can't break all the things depending on the old version", which is solvable either with enough manpower or by sandboxing a la NixOS, where you can keep old versions around indefinitely for the things that need them. Does Arch use such sandboxing now?
As a former long-time Arch user, you're correct. It's "just" a distro not unlike the biggest one. The reason Arch repos are fairly well updated and big is the relatively easy to understand PKGBUILD format and the tooling around it, which lessens friction on package management.
But this gets to the mindset that bugs me about Flatpak, the magical thinking that regressions don't happen. It's why Alice can't downgrade a system flatpak because it might introduce a vulnerability she uses to attack Bob, but it's absolutely fine if she upgrades to introduce that vulnerability.
Only when the version you want to downgrade to happens to be within the last 10 versions! Why 10? Beats me!
Case in point: the flatpak package for the Element messaging client seems to be the preferred installation method for non-debian distros. But for many users, encrypted message search is broken! [1] [2] Some users claim that downgrading can fix the issue, but the flatpak has been updated too many times now for any user to downgrade to an old enough version - tough luck!
[1] https://github.com/vector-im/element-web/issues?q=is%3Aissue... [2] https://github.com/flathub/im.riot.Riot/issues?q=is%3Aissue+...
It has access to X11 <https://github.com/flathub/com.spotify.Client/blob/0856c7641...>, so it could also be running a keylogger.
Sandboxing should be a separate tool independent of packaging systems and anything else .
With an open sandbox by default for many apps…
The first one is the second one.
Trying to make sense of Flatpak's threat model is just near-impossible. It might protect you from something, if the specific app's configuration told it to do so. Starting a random Flatpak app, you have no guarantees, and the UX doesn't communicate anything about this.
You are cherry-picking the spotify session token while many other applications have valuable personal data.
Also sandboxing is also implemented by the OS. It is not an advantage of flatpak.
but that's a problem, too.
i'd rather all things on a system be bottleneck-forced into using the latest version of security libraries that my system is actively updating; yes, this causes issues, but not issues like "There was a huge vulnerability found in X version Y, does it affect me?".
in other words, i'd rather have system breakage than insecurity. That's a personal taste, I admit.
that said, the sandboxing aspect behind 'the new ways' is fantastic.
Which is to say most people use a computer to run software, so if the software doesn't run the security is pointless anyway.
Sure, if only some software breaks and you can wait for fixes that's a tradeoff, but given that in package maintainer land those fixes could be months or years away...
And how many of them are critically out of date because the software maintainer didn't update? Who can say? That's the beauty of flatpack (not).
With flatpack you have all the downside of static linking with none of its advantages, how exciting. (and there's nothing as cool as having 7 full linux distros installed on your computer at once, just because software can't agree on which base image to use)
...until attackers find a vulnerability in some library, then you are really in trouble.
Just like docker, the bundling of tons of software into opaque blobs is terrible for security.
- Installation (no manually moving files from ~/Downloads)
- Launcher integration (no writing .desktop files by hand)
- Auto updating
As far as I saw, AppImage didn't have any of that. Though it was a while ago (and maybe some of this was my distro's fault). Has any of this improved lately?
How are people keeping their AppImages updated?
But Linux Desktop has a nasty habit of adopting over engineered solutions instead of simple ones, especially if any other desktop OS is doing it that way.
The only software I run as an AppImage is BitWarden (from the official GitHub repo[1]. It prompts to update itself when there's a new version which works very well.
ive been using flatpak more myself these days but i hope the appimage format sticks around because its handy being able to quickly try out some software and then delete it when you are done, or to try out a new version of something and have both running at the same time
Installation, launcher integration:
https://docs.appimage.org/user-guide/run-appimages.html#inte... https://docs.appimage.org/reference/desktop-integration.html
https://docs.appimage.org/user-guide/faq.html#question-how-c...
Updates:
https://docs.appimage.org/packaging-guide/optional/updates.h...
What was missing was convenient sandboxing. Firejail was recommended but with the responsibility entirely on the user to install and use it.
Flatpak doesn't limit access by default (or rather it does but apps can just ask more permissions at build time and it's not prevented by default IIRC) but offers the user some options for being more strict without needing extra tools.
Nor is their FAQ describing their sandboxing as a security feature, more like (limited) isolation technique.
But this isn't stopping flatpak zealots who just won't shut up about the "sandbox == secure" falsehood.
I don't know, I'd rather prefer a technology which is upfront about its lack of security than one which has glaring hole in what they call (a false sense of) "security". I treat flatpaks and appimages as mostly equal things and use them to keep and run proprietary stuff so that I know it won't be shitting its guts all over the host system.
In fact...I think I have all the software packages you have, except Obsidian, but also, Signal, Anki, and Element.
I did consider using it to deploy and update a CLI on (multiple) Linux(es), but found that the design of common shells make that kind of thing uncomfortable, as you need to teach them about autocompletion and the user also has to muck with getting the utility into $PATH. Normal-style packages simply have the privileges to muck with /etc and /usr/bin and that's the end of that, but it is somewhat unsatisfying that this is almost necessarily the case.
Commercial software would like a comprehensive and relatively stable API like what Windows famously provides. Flatpak's analog of the Windows API is the runtime. What level and duration of maintenance do Flatpak runtimes typically receive?
https://developers.redhat.com/blog/2020/08/12/introducing-th...
Well yes, these are all closed source binaries. In terms of usage it's not all that different to running them in a VM. In the bad old days we just did it in an XP windows VM instead.
They make so much sense and work so well. I feel like the people who dislike them either never actually used them, or they’re just the type of person who hates change and will never be happy with new things.
Last I checked Flathub shipped with VSCode and IntelliJ, despite both having major broken parts. The VSCode workaround back when I tried Silverblue was to run sshd inside toolbox and remote Flatpak VSCode into it. It was definitely not a frictionless experience. And IntelliJ having the terminal and debugging broken removes most of the useful parts of the IDE for me.
It is really strange that both this and "it's totally ok for packages to set their own security defaults" are true in Flatpak land.
Wireshark is a tool more in the realm of development/sysadminry, whereas flatpaks are designed for more traditional apps, like Discord or Firefox.
I wouldn't want my development tools to come from flatpaks even if they had full access to the system, because I wouldn't have control over dependencies. Traditional system package managers are a better fit for that, and on Silverblue you have Toolbox for that.
See, here's the problem with letting packages determine their own defaults. I want the ability to give a Flatpak those permissions, not that they be able to give them to themselves. As it is, Flatpaks can give themselves permission to $HOME without ever notifying me, which I think is just as silly.
In my opinion, Flatpak should support a user-definable default permissions template that says "always permit", "always deny", and "don't care" for any given permission.
> you have Toolbox for that
Actually I agree that when it comes to these collections of software to build an "environment" something like toolbox/distrobox is a better fit. I have my issues with both[0], but the base concept is sound.
[0] For instance: why is podman required? The container functionality required is built into the kernel and podman has a lot of features that are entirely unused. Even bubblewrap has all that's needed and it is included anyway because of Flatpak. I will probably end up writing my own replacement for these tools.
Using development tools as a flatpak is usually not a good idea for many reasons. That’s why Silverblue ships with Toolbox (https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...).
Flatpaks are kind of like Android APKs, except unlike Android, there’s actually an operating system worth interacting with. An IDE on Android usually needs to include all of the tools it needs. A flatpak is the same, except that’s hard to get right for every development setup, so a toolbox just lets you do whatever you want with it. They’re podman containers with extra features to integrate with the host.
I have all of my development tools installed in a single toolbox, and have .desktop files for the GUI ones so that I can launch them from the KDE app menu as if they were regular apps. With this setup I can use e.g. clangd with the LSP plugin in Sublime Text, execute CMake, use the embedded terminal (Terminus), or the debugger plugin with lldb.
Most of these are proprietary. I view these third-party stores mostly as a way to ship proprietary software. Not sure what else they add, and the downsides of having yet another package manager on top of your system's are obvious. I'm surprised KDE is behind this.
Some sort of packaging standard that works across distributions would be beneficial, but it'd have to be integrated with the system's package manager, not tacked on.
I am a Nix person who has been a bit obsessed with package management for a long time, and it's probably fair to call me a bit of a 'container skeptic'. I know many good reasons to prefer other means of installing packages, and I agree with most of them. I care about things like the extra storage overhead, the increased app startup time, the additional complexity associated with portals and sandboxing, the extent to which Flatpak applications do or don't support the available sandboxing features, and the orientation of Flatpak towards enabling a larger proprietary software ecosystem I'm not very interested in.
But despite all of that, and despite my interest in— and to some extent, commitment to— competing paradigms... I think Flatpak does what it tries to do pretty well. It seems to me that the engineers working on it have done a pretty good job of mitigating the downsides and risks, like library duplication and difficulty of shared updates, disk usage, etc. Considering what it aims to do, it feels pretty fast, reliable, and neat. And I trust it way more than an apt or dnf or pacman repo hosted by the likes of Zoom, Google, Discord, etc. It's a much better way to manage third-party software than anything else we've got.
I think it's clearly a good thing that the biggest and most popular desktop environments are coalescing around it. This is good news for desktop Linux users in general, and especially good news for those of us who don't run Ubuntu or derivatives. The more things are packaged for Flatpak, the lower the burden for practical usage of distros maintained by small or new communities.
...and their solution is running an antivirus scanner rather than stepping back and realizing that they're shooting their own feet clean off. And it's based on an absurd premise! Seriously:
> binary form, which is essential for low-friction compatibility with popular language-specific build systems
What? No it's not! Worst case, build in a container with the official tools. Best case, package the build tools like every other distro and enforce source availability and build reproducibility. I mean, NixOS is a bunch of volunteers doing (a better version of) what you're claiming is impossible!
(Granted, I assume the claimed reason is a lie and the real reason is to support proprietary software, which is... maybe reasonable, but pretending otherwise isn't.)
Although it provides its own solution to the Linux packaging problem, it's a single solution that comes with a whole load of baggage with it. It is not the panacea its proponents wants us to believe it is.
All kidding aside, I installed NixOS (it installs like any other distro, it's just that after that you are completely lost), but it's a real paradigm shift.
I'm just hoping for Ubuntu Declarative Donkey at this point and hope someone addresses the learning curve and the specialist language and tools used. I'd hate to invest all this time and then all other distros finally respond and it was not really worth it after all. I mean it looks to me like one can just put a Yaml file at the heart of Ubuntu and make that work. At least as step 1. Why is there no response from the classic Linux vendors? There are atomic distro's yes (ie Fedora Silverblue), but no real NixOS-like product. I want my personal system to live in Git.
Maybe I should just use NixOS.
[0] https://www.jupiterbroadcasting.com/
[1] https://www.jupiterbroadcasting.com/show/linux-unplugged/
I think NixOS tends to be mentioned more often than others because it provides a lot of clean solutions to common problems. Especially when some people claim these common problems are unsolvable, but NixOS does offer some sort of solution (that of course comes with it's own set of tradeoffs, every solution does).
If someone says "It's impossible to run a popular website with client-side analytics" and you frequently hang out on popular websites without client-side analytics, wouldn't you share those examples to show that the person might not know about those and could further their understanding?
Rather than being a cult in itself, there's a crowd of very vocal fanboys similar to the RIIR stike force. Pestering people with "why don't you use $thing" is not good advocacy.
nix-env -iA nixpkgs.zoom-us
nix profile install nixpkgs#zoom-us
(For proprietary software like Zoom, I think Flatpak might be preferable even to many Nix users like me.)
* Works on all (most) distros * Builds the packages from sources, binaries are only a cache to speed things up. * Bonus: already has a lot of software packaged
And proprietary works in the system too, the build step can just download the binary from internet. It's not a preferred way to do it, but you don't have to build a broken system just because of few packages without source access
"the nix ecosystem is like a cult. Not because it tries to be, but because the ideas are so good you cannot deny them."
/s
The fundamental idea is this: Every package is built in a "hermetic" environment that guarantees that the only inputs are the ones you have explicitly specified. Those inputs include tools, source files, compilers, build instructions etc., all specified by a hash. Those inputs themselves can then be packages build in this way, such that everything in your system forms a big Merkle tree.
This approach enables a number of excellent things - you get excellent build reproducibility, you can cache any step you want etc. A lot of the concerns you get with a more conventional system just go away.
People have objections to Nix(OS) - the language, the sporadic documentation, some of the design decisions made, the learning curve etc. But I think those (very reasonable) objections obscure the more interesting debate about the underlying approach and value.
Similar to how Git has a notorious CLI; but that doesn't invalidate the idea of DVCS (with alternative implementations in Mercurial, Bazaar, Darcs, etc.)
Because a) They're not the only ones working towards it, but they like to paint it that way and b) Their implementation is not the only correct way, and again they like to paint it that way.
The main people behind it may not feel like that, but the hype creates a very repulsive aura around the project for some of us. I just don't want to touch NixOS just because of the community and hype around it.
There are many ways to achieve this reproducibility, and the old school ways are not very behind when compared to NixOS. Some things are achieved differently, but it's perfectly achievable with Debian and RedHat packaging infrastructures.
I think it kinda is, but in a good way.
It's the church of reproducible builds, which is a good cause.
Package managers before nix simply didn’t solve the problem properly - they left behind garbage, couldn’t properly deal with multiple versions of the same package, etc. Easy way to check whether the package manager you have in mind is “sufficient” is to install the gnome group and the plasma group and remove them. How many orphan packages will you have as a result?
It is not a cult, people just like proper solutions to problems, and nix is unique in this regard.
More seriously, people who run NixOS are, generally and historically, people who have a lot of experience with package management and people who choose their Linux distro based on the tooling rather than based on defaults.
The Nix approach is conservative in some wonderful ways that are likely to appeal to longtime Linux users who appreciate the strengths of old-school system package managers as well as the defect of those systems, which makes Nix people want to cry out in response to container-based package management:
> You don't have to go that far! You can have all these benefits but keep fine-grained library sharing! The choice between static and dynamic linking is a false dichotomy!
because if you love what's great about traditional package management, that's really exciting.
Like if you want to select a desktop and are kind of new to desktop environments, maybe aim for the (imaginary example here) DE-5 level of standards-adherence. DE-4 and lower might suck in various ways even though they could have cool new features.
There are way too many benefits from the huge variety of DE approaches, including the benefit that Linux-critics often hide behind critique of a single desktop experience, which is lazy and attempts to steal focus from exactly this open, creative, diverse approach that is the jewel in the Linux ecosystem's metaphorical crown.
It's definitely great to see the groups working together on these projects that benefit everybody.
What's the difference? If everything works perfectly with everything else, and the standards adherence is so high that you can't tell the difference which apps are from which organization, then how is that not a "unified DE"?
OTOH, if you think there are good, detailed reasons why XFCE is not KDE is not Gnome is not LXDE, then you can probably see why standards are helpful, insofar as they can be designed to be reachable without compromising unique leverage points.
We of course already have something like this (POSIX, Freedesktop, etc). However neither is abided by very well and neither of them go far enough up the stack to deal with certain very visible issues of desktop application incompatibility.
What I think could be done to fix some of the compatibility issues (like when running QT on gnome or GTK on KDE or applications that eschew them both and have janky window decorations) would be some more serious standardization onto something like Wayland. We would of course need something more than a reference implementation for that, but fundamentally I don't see why that would be too restrictive for projects that still want to make their own widgets.
There'd also be a standard for e.g. IPC-based interoperation with file picker dialogs, such that if you were running GNOME as your DE, QT apps would (tell the DE to) pop the (GTK!) file picker to open a file, which would then signal back to the app through some standard message format for describing picked files (maybe with the file-handles themselves passed over a Unix domain socket, if you want something like macOS's sandbox-piercing file-open-intent tokens.)
There'd be a single "accessibility DOM" standard, so that a GTK screen-reader could read the text out of QT apps.
There'd be a single shell namespace standard, with one common set of abstract data types (with multiple implementations), so that opening some GVFS virtual folder in a KDE app would actually work — probably through D-Bus integration between the KDE app and some libgvfs host runner agent.
And so forth.
The ecosystems of each DE would remain distinct in development, with apps designed to fit well together... but the feeling of DEs being walled gardens would be gone, because the various standards would force each app to be a "chameleon" to whatever DE it's running under.
There are a few tiny attempts at this under FreeDesktop. xdg-open(1) is a good start. But we could be doing so much more.
I'm using a very minimal system without a lot of the easy to implement features on purpose, but absolutely can not live without some of the more difficult ones. So for me the adherence would be cherry-picked parts from 3, 4 and 5 and impossible to place on a chart. I don't think it would be a good fit for the modular unix philosophy.
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
[2] https://specifications.freedesktop.org/basedir-spec/basedir-...
As opposed to, say, standards that are based on general user experience aspects. Does the control panel offer printer settings yet, for example.
At the lowest level you have the kernels (KDE and Gnome both run on Linux AND BSD) which may or may not have drivers built in. Then comes the distributions which are opinionated in the kernel versions, packages and patches they add.
Some of those packages are desktop environments or window managers and they are opinionated in how they run other packages and their lifecycle. Some full featured others are tiling. Some of them run on both Xorg and Wayland.
Last we have the actual packages, and they need to work in all these different environments, sizes and lately different protocols. They need to support different drivers, permissions and file system hierarchies. They do this by relying on each other, a package handling video focuses on supporting video and sound drivers so other packages can import that package.
KDE might have a very polished and up to date settings panel, checking for all drivers and their features. But in reality it works as intended on Ubuntu, but Debian is behind and doesn't want to patch the drivers because stability, on Arch there was a regression and most of the BSDs don't even support the driver. And one time Linus came along and didn't listen to the warnings and fucked it all with one line.
Nobody controls all of these pieces and they're so spread apart that what might seem as simple as a panel for printer settings quickly gets very complicated. But I wouldn't have it any other way. For those who want the one size fits all there are already options.
And it's gotten better too - did you know KDE3 had it's own sound mixer daemon? It was called ArtsD. Now we have pulseaudio, or whatever, which is great and cross desktop
DBUS made it everywhere as well - I believe initially KDE3 as well did not have DBUS but had something called, DCOP. so - yeah things have improved a lot and many things - even command line tools 'playerctl' interop well based on this.
More fun is also like libreoffice is compiled with many different file pickers, so on KDE you can use the native Qt extended KDE file picker, and on Gnome you get the GTK one.
I used to be on this hill. All this leads to is inoperable software where each integration point is liable to break. I want to get away from the spyware that is Windows, the walled garden that is MacOS. If a uni-desktop is the price we pay, so be it.
Of these, I would say that Cinnamon is one that could be comparable to XFCE or even GNOME and KDE. Seriously, it's good. The system settings menu has all of the options one could need and the look and feel of the dektop is very customizable.
I'm a KDE user, but if it ever stopped working/disappeared I would use Cinnamon. In fact I plan to use it whenever KDE Plasma 6 releases to wait out until the it becomes more stable.
IIRC KDE committed to never break users again like they did with the first releases of KDE 4. It's expect the first releases of Plasma 6 that the distros will actually ship to be stable, and to be mostly a Qt5 → Qt 6 upgrade. You should be able to run a stable version of Plasma (5 or 6) in any case during this period. KDE 3 to 4 was a disaster; last versions of KDE 4 were rock solid. First versions of Plasma 5 were a bit lacking but rapidly became very stable and usable, and you could actually keep using KDE 4 in the meantime. I expect the Plasma 6 transition to be even smoother. I hope I'm not wrong.
But otherwise I agree, Cinnamon seems very good and I tend to recommend it and pick it for people who I install Linux for.
...though I do lament the loss of Desktop Cube.
Of course, coming from Awesome I am often annoyed at how Plasma doesn't have per-screen (X11 monitor, if I'm not mistaken) tags and per-X11-display workspaces don't really work that well.
What were your issues? What was the distro?
Forgive the vagueness, but I don't believe in memories and haven't kept a journal. Still, as completely unreliable and untrustworthy human memory is I am inclined to believe I had issues with Plasma 5 during the transition period.
Either way I think that still sounds better than the old 3->4 migration, and hopefully 5->6 can be better still!
No thanks. GNOME dev hubris is the reason I use KDE
Personal example from trying GNOME out recently: I have an external webcam, which means I need to move the GNOME panel clock since it's in the top middle of the screen (and thus blocked by the base of the webcam). You would _think_ that would be easy, but you have to get an extension just to move the clock! Apparently each panel "widget" (this may or may not be the official term) defines its own position on the panel. So, to move something, you need to either find an extension that does it (Frippery Move Clock[0] in this case) or edit the widget code yourself.
Maybe someone can chime in with a technical explanation, but my cynical take is that the GNOME devs don't even trust users to be smart enough to customize their own panel without breaking things.
</vent>
They say this is desirable functionality, but that they would want to subsume termites features in VTE and Gnome Terminal, and that was their rationale for rejecting the patch. Then they didn't deliver those features in a timely fashion.
That's just abhorrent behavior.
I'm gonna say citation needed on that one. In fact, I have seen many rants about desktop software trying to look like touchscreen software.
Now I'm writing this reply from KDE, quite comfortably, and it's quite stable. Comfortable, even. And it doesn't get stupid and die when I plug/unplug monitors and stuff.
I'm not really against it, but I don't use KDE or Gnome (or any of the others in your list) and it concerns me that people might start thinking of those as "being Linux". I'd hate to see a future where "We support Linux" means KDE or Gnome.
On the other hand, I have to admit I'm not really sure what that would mean. I guess only having "Flatpak" as an option would be a bummer, but I don't see that happening with the distros I use.
This would be terrible. Gnome and KDE have pretty conflicting ideologies. Gnome is super opinionated and Mac-like minimalist. KDE is all about user choice.
If they'd collaborate it would end up something in the middle which would suit nobody.
The problem with this is that Mac, unlike Gnome, actually works. Gnome just has weird holes where old functionality was removed (like application menus!) and never replaced.
Yeah. Without proper window management, middle click and other things I need 3rd party apps for.
...you can't compare minimalism/configurability in this way
Ed: one minor (but somewhat understandable annoyance) is the lack of a free/reserved for users modifier key. Macos with the adoption of bsd uses both command, option and control (even though it uses command for core things like copy/paste). The windows/super key is a blessing on Linux pcs - as it generally can be used for just that - window management).
I know some rebind caps lock as a super (ed2: I mean "hyper", I think) (aka ALL THE MODIFIERS) key on Mac - but that leaves control in the wrong place :/
Maybe there's no RSI in Palo Alto?
By now, Snap is such a fundamental part of Ubuntu that it begs the question whether Ubuntu is right for you if you want to avoid it. Why not use a derivative or upstream that makes different choices?
Seriously though, just install Debian. It's not hard, the netinstaller may be text-mode but it walks you through the simple steps one by one just like Ubuntu's GUI installer. Anybody who's comfortable using Ubuntu in the first place should be able to get through the Debian installer just fine.
(For work, where I just want something that won't make me "the asshole who chose [non-standard thing]". I prefer Void or FreeBSD or, sometimes, Debian, for my own stuff)
[EDIT] Oh, right, specifically for desktop? Yeah, I'd go Void or Arch probably. Buuuuuut if it were for work, I'd just use Ubuntu, even on the desktop, so it wouldn't be my fault when it misbehaves.
I meant more so for people who are somewhat active on these discussions but still go with Ubuntu.
Nowadays you can get a full featured, well integrated and properly working user land on Linux with next to zero customisation with systemd and Gnome. I really recommend using a distribution which stays as close to vanilla as possible.
Debian would still patch far too much to my taste without the integration anyway.
They remove/rebrand what they don't find free enough, want to make things "modular", want to split development and base packages, want to support a ton of architectures upstream doesn't care about and want to integrate things in their historic tooling. It has introduced some severe bugs in the past.
Edit: I just checked for the classic case of latest Python (3.11), and the answer for Debian is to build from source, which is annoying (not difficult to compile, but then future updates can't be pulled in via apt). Does Debian not have a vibrant PPA community to fill the gaps like Ubuntu?
Yeah, it does: the Ubuntu PPA community. (See https://wiki.debian.org/CreatePackageFromPPA, and similar.)
In my experience, the stability concerns are overblown, and it makes for a really nice rolling release system. I've had individual systems run for over a decade on a Debian testing install with rolling updates, and it's generally been far less of a headache than Ubuntu releases.
I like Debian, but after (free)Ubuntu pro, it really became attractive for me as a small server operator, its even better than free RHEL.
Its also much easier to install on cloud servers than RHEL.
"Ubuntu pro" is basically trying to fix this shortcoming compared to debian and to pay for a security team for universe. It is available as a subscription.
TLDR: If you use software from main it is completely irrelevant. If you use stuff from universe it is now as good as debian, if you pay (first 5 devices are free).
Running with the crowd has some advantages. Many feet passing on the path before you trample more bugs before you get there etc.
For anyone looking to use debian I highly recommend it and prefer it to any other distro.
This is nice if you're dual booting Windows 11. It's also probably going to increase the Ubuntu's representation in desktop Linux by virtue of booting without any EFI setup tinkering, because a lot of people's patience ends exactly where things cease to work as expected.
Since there are so many people that don't have this problem, I understand that it's something I'm doing wrong -- but I have never been able to figure out what that is.
This was well over a decade ago though :)
What I mean is that I can't get Ubuntu to work at all. On my luckiest tries, I've managed to get the desktop to show, but everything is still highly unstable and I've never pushed on to trying to install software.
I used to think it was driver issues, except I've had similar symptoms on three different machines. And before people jump down my throat -- I'm not saying this is a problem with Ubuntu. I admit that I must be doing it wrong. But it's a showstopper deal for me anyway.
Admittedly, the last time I tried was a few years back. Eventually, I just had to give up and move on with my life.
As a fairly begrudging Ubuntu user (I put it on a laptop because I didn’t want to screw around with finding drivers, memories of trying to get wifi working on Arch with some dongles haunt me), I have to say I don’t really like it much overall but they’ve got the “getting to the desktop” experience down pretty well.
No. I do tend to use old hardware, but tried it on a mainstream new laptop one time. On that, I couldn't get the WiFi to work with it.
What baffles me is that on all of these machines, Debian works out of the box. In fact, Debian's never failed me on any of the many machines (including laptops) I've put it on.
Ubuntu is based on Debian, so I can't explain the difference. As I said, it's been a while and perhaps they've fixed issues, but I've moved on. My life is no poorer for it.
The only thing is that it means I can't recommend Ubuntu to people (not only because I wouldn't be able to support them if they have trouble, but what am I supposed to say? "I can't make it work, but use this!"?)
Prevent dynamic linking?
Offer strong backwards compatibility?
Add support for a very wide range of hardware?
Put advertisements in the start menu?
Cause unexpected reboots for updates?
Send telemetry to the OS manufacturer?
Force users to get an online account unless they know the secret way to bypass the prompt?
Or is there a differentiator between Windows and Linux I am overlooking?
What you should look at is the difference between Debian and Devuan. Or between Debian and OpenBSD, to understand what the systemd project is doing, and how it’s doing it.
There are many of us that prefer Linux as it was before systemd.
systemd was actually inspired by launchd, not Windows. But I guess systemd, Windows and launchd do share one thing in common which is not having a bunch of bandaid shell scripts hanging the system together.
I don't think I've seen anyone complain about systemd's init system or service manager; it's always about the remaining 90% of systemd's scope and its tight coupling between all its parts (the tight coupling being the main problem).
Removing Snap is not that hard, the "hardest" part is making sure that Firefox is installed from the Mozilla PPA and even that takes just a moment once you have the script saved somewhere.
By the way I had a look at some Ubuntu derivatives like PopOS or Mint and I might take the plunge at some point.
In my case, it's because my options are pretty much Ubuntu or Windows for this machine, and there's no contest there.
Unless I have another reason to reinstall Linux, it’s far easier to uninstall Firefox and the other handful of Snap apps and just use Flathub/flatpak exclusively. I just need to be careful I don’t pick the default store app when searching for software.
In my experience Ubuntu's default store app can be safely uninstalled once you have Flatpack's store app. In fact I recommend doing that as their functionality overlaps quite a bit (e.g. you will get duplicated update notifications if you have both stores installed).
(The above assumes that you got rid of Snap. Otherwise you may still need the default one)
Ubuntu also as better hardware integration ( drivers ) and more modern kernels. AS a matter of fact it has many kernel for deferent usage.
People use Ubuntu because it works just fine out of the box, you don't need to install a third party non free drivers to get your wifi card to work. I still have nightmare with debian because they used to not ship proprietary drivers so you would have to cary a USB stick in the datacenter with drivers on it to make network cards working.
https://www.omgubuntu.co.uk/2023/01/ubuntu-zfs-support-statu...
But that doesn't change the fact that ZFS itself is in the Ubuntu repos, tested against Ubuntu's kernels (it's a kernel module, so this is important), and _really easy_ to install: `sudo apt install zfsutils-linux`.
Personally on my box, I boot off a small NVMe SSD formatted ext4 (installer defaults) and then have all my hard drives in a ZFS pool to store my data. If /r/zfs is to be believed, this is a common setup.
As for Flathub itself, it's like the Snap Store... but you aren't locked in, and the backend is open-source, and it's not directly owned by a distribution maker (even though it is definitely closer-in-kindred with the Fedora Project), which makes it far more palatable to people with even a modicum of understanding of the Linux and FOSS philosophy.
I harassed them nearly 6 years ago about this. https://forum.snapcraft.io/t/external-repositories/1760
cat << EOF > /etc/apt/preferences.d/nosnap.pref Package: snapd Pin: release a=* Pin-Priority: -10 EOF
One thing I don't do is use Flatpack, AppImage or any substitute for snap. If I wanted that functionality, I'd use snap.
I don't like apps installed via snaps (etc.) changing themselves almost seemingly stealthily.
I am not sure if this is the case, but in theory I love the idea that the app sandboxing can allow the Flatpak engine to be a source that can prompt users for permissions access (e.g. "app would like to access your location").
Last time I tried Flatpack I experienced a lot of integration issues, from GTK theming issues to applications missing features due to sandboxing.
Would love to see a high level medium-dive explainer on how Flatpack works to alleviate some of my concerns; predominantly around the limitations of sandboxing.
e.g.
Can OBS have unimpeded screen recording access? How does OBS compare in Flatpak compared to natively installed.
Can VSCode access any part of the FS without any performance overhead, what about language servers and that sort of thing?
Can applications like Discord that feature a voice-activated mic work? Can Discord access what game you're currently playing on Steam and set that as its status?
Originally, I thought Flatpack was much like old win32 applications where if you put a dll dependency next to the executable, it will use that rather than the system one. I got really scared of Linux app sandboxing engines when I tried Snapd and it started making virtual network devices and my system theme wasn't applied to the application - seemed very convoluted.
1. A strong push to help package maintainers fix sandboxing mistakes, expose the APIs that need to be exposed and lock down the APIs that are not needed. It used to be pretty bad but it's pretty rare to see sandboxing problems nowadays.
2. You can now use a tool called Flatseal, or in KDE a new builtin settings interface in Plasma 5.27, to modify sandboxing settings for applications in an intuitive way. If you're trying to use an IDE and just want to expose every permission to it, you can easily do that now.
3. Unrelated to Flatpak, Wayland is now getting a lot of the video capture and screen recording APIs that are needed.
I'm livestreaming on a regular basis, and moved from OBS as compiled by Arch Linux to OBS Flatpak. Everything just works (esp. the browser source that uses an embedded Chromium, which I never got to work with the Arch packages). Most likely that particular Flatpak is very liberal in its sandboxing, because it was even able to write into $HOME/obs-recordings/ without any permission prompt. I don't care about the sandboxing part of Flatpak too much in this particular case, so I didn't dig further.
I do hope the command-line UX around flatpaks (installing, updating, etc) improves a lot though as currently it leaves much to be desired.
There's far fewer applications because there's a very tiny market share compared to these two OSes. Not because of the lack of payment systems.
In his most recent talk he basically said, he was wrong, the Flatpak people did address most of the issue he had and AppImage was no viable.
I even don't have to manually write them, KDE has kmenuedit.
I think part of the problem with a lot of "selling stuff on Linux" has been mucking around with different dependencies for the thousand different versions of Linux.
Historically, this has led to a couple solutions: either a) Just officially support one distro (usually Ubuntu), or b) just don't release a Linux version.
Flatpak has actually succeeded in making a system that kind of works everywhere, and I think it actually has a shot of being an equivalent to the Mac App Store.
This I agree with, but not this:
> and does actually do a good job of making "one package manager to rule them all".
That's not its goal. There are no terminal apps in it, so everyone that wants to run custom packages from a terminal is still going to need something like apt/dnf/homebrew.
Regardless of your opinions of GNOME and KDE, it’s hard to argue Flatpak has anything but good intentions, it’s made by people who want the Linux desktop to be better
I am reminded of that one game dev who dropped Linux support because 99% of their bug reports were coming from 1% of their total playerbase (read: the Linux crowd).
You can fork the base repository and just add the packages you want to have installed on your host system. Everything else is handled with flatpaks or with distrobox containers, or you could technically install whatever else package management system you wanted to.
We have some people like System76 doing great things, but not in Europe and for all their great work its not the highest quality stuff from China with some serious limitations.
For all the things the European Union funds, from chip manufacture, HPC and many other project from large to medium to small. Why have we not seen a made in Europe Laptop/Desktop/Phone for the bureaucrats and engineers who do things like running states and building weapons and so on.
A fair amount of EU money goes into a lot of these distributed system and internet projects. And I'm not complaining, but we are spending a lot of time trying to make our system secure from everything other then direct attack. The fireware in the new notebook doesn't seem better then in the one before, in fact worse in some way.
We have most of the software, we have most of the things needed to do these things. An Open-Source computer for Europe (and anybody) would be a real counter-point to most of the other models out there.
In such an environment a real AppStore for Open Linux desktop could actually be a really good thing.
First, Windows caught up, Linux used to have things that windows didnt in the late 90s and early 2000s, not most linux only app have windows ports, you can run any linux app on windows WSL , and now windows also have powershell
Second, apple made a comeback, now many people who dont want windows use apple and get a unix experience if they wanted one
Third, end users shifted to tablets and mobile phone
The combination of all 3, leave little room for linux, no matter how good linux does , linux on the desktop only make sense for people who develop for linux on the server and want a similar environment on their laptop
1. https://sneak.berlin/20230115/macos-scans-your-local-files-n...
https://www.notebooksbilliger.de/
https://www.lenovo.com/pt/pt/d/portateis-linux
https://www.skroutz.gr/c/25/laptop/f/526320/Linux.html
The problem isn't the hardware per se, rather lack of focus on a single desktop experience like the competition.
For non-technical users and app developers.
And how did you come to the conclusion that "missing high quality linux desktops" are the thing "holding back" Linux?
Is this based on some statistical work you did?
If we talk about feelings - did you ever have the feeling that corruption, lobbying and blackmailing could play a role?
BTW - why do you think Linux is missing high quality desktops? I am working with very high quality Linux desktops since many years and I wonder why people are using such low quality desktop OS that are sold commercially.
> If we talk about feelings - did you ever have the feeling that corruption, lobbying and blackmailing could play a role?
If you want to make the argument make it, I will listen.
I working with Linux desktop for decades and like it. My point is that the hardware is the bigger issue.
If you use the gnome Software app, it merges flatpak, dnf, and the firmware updater in one “updates” page with a single button to update it all.
Perfectly true, and my comment was the kind of irritated snark about imperfect open source software that I don't like hearing from other people! It just so happened that I had launched Software literally about 5 minutes previously for the first time in months and it .. sat there and did nothing.
I do think it's a good idea though, at least while we have this hopefully transitional period of multiple overlapping packaging/update systems. I get a bit tired of having to think in terms of flatpack and dnf and asdf and cargo and pnpm and .. not to mention all the odd bits and pieces I install & compile from source and forget to update.
I guess it's mostly the kernel and my DE these days.
Also as far as I remember flatpack is something more complex than a simple package format, it has a runtime where each application runs in an isolated container where it can access only some of the resources (e.g. the filesystem). This adds to me useless complications to a system.
I think that the best approach to the integration of third party software is the one followed by ArchLinux, that is the AUR: a series of build instructions, maintained by the community, that allow you to package practically any piece of software that exists.
They are completely inadequate for closed source software like games. Flatpak provides a stable platform you can target and it just keeps working across distros and in to the future while rpm/deb packages require constant maintenance.
Flatpak also provides a long list of essential features like permissions, sandboxing, portals, etc which most other OSs do. The future of linux is likely immutable OS images with something like OSTree, and then flatpak for end user apps.
Why? What difference does make the license of the software? The only trouble is that the developer of the proprietary software has to package it in a number of formats and have repositories to download updates (that are HTTP servers with some special files in it). In reality to this day you just have to package a .deb, and if you want .rpm. For other distros these packages can be converted practically automatically (this is what is done with ArchLinux AUR for proprietary packages like Spotify or Chrome that are installed from the deb version).
> working across distros
This doesn't have a lot to do from the packaging format but on how you write the software. If you dynamically link 2000 system libraries you can as well use flatpack but the software will not work since typically on Linux the ABI is not that stable. If you have a single statically linked binary with MUSL libc you can as well package it as a deb and run it on Debian 4 that it will probably work.
> Flatpak also provides a long list of essential features like permissions, sandboxing, portals, etc which most other OSs do
They are not essentials. And they cause more problems to the user than what they solve. And don't talk me about using containers for security, since they don't provide any useful and proven safe isolation. On the other end you have SELinux/AppArmor that you can apply easily on any executable regardless of the packaging format.
> The future of linux is likely immutable OS images with something like OSTree, and then flatpak for end user apps.
This is wanting to go in the direction of what Apple does on macOS/iOS where the / is immutable. I think that people use Linux because it's different, if not they would just buy a MAC. These are complications that gets you in the way.
Linux users wants to be able to build the system by picking the components they want, not the components that Canonical or Red Hat decided that they must be present in their distribution.
https://ftp.fau.de/fosdem/2023/UA2.114%20(Baudoux)/container...
Erm...
> we also reduce the ability for users to scrutinise the source in the Flathub build system that was used to build their application
I don't think so
Appimage is macos flavor, it never needs your sudo to install the package, which is nice.
Flatpak is a redhat flavor(kind of), it needs sudo sometimes, but OK.
Snap is a ubuntu flavor(kind of), it is like systemd that can overtake the whole system, it can install package and even the whole system I was told, too much as a package manager for me.
I don't use Snap. Appimage is not as widely adopted as the rest two? I think Flatpak is a great middle ground.
It will be really cool if KDE and Gnome work together to build this.
This is kind of how immutable systems like fedora's silverblue, and suse's microos are setup.
The base systems are still built with rpm, but for user packages you either use flatpak or stuff in containers via toolbox or distrobox.
It's still possible to layer stuff on to the base image if necessary though.
Sandboxing and distro-agnostic packaging are definitely the way to go. They have some pain points but it's better to fix those than to go back to the older way of doing things.
It totally is! Why does a distro maintainer need to pack every known application into the OS and make sure it works? This kind of work does not scale.
What about appimage instead, like Krita? To me it's sounds like the best way to distribute a linux app in 202X...
Managing to make things run on Linux gives a sense of accomplissement, at the same time, I can understand why most people won't move to Linux anytime soon given all the complexity involved... or it's just me and there was an easier way to install flatpack at first place?
AppImage solves the packaging problem in a bad way (ugh, loopback mounts), but does not solve the dependency problem, try run AppImages compiled for Ubuntu on Fedora..
[Retort insult.]
AppImage is just the least bad solution - if nothing else it doesn't need some weird infrastructure to run. As a developer you just upload the binary to your site and as a user you just download the binary and run it.
Wow.
I hope, if this succeeds, it turns out to be a good thing.
It forces developers to use the app stores. I understand that many may not see this as a problem, but many developers (including myself) would very much prefer not to have to do that. So it's a disincentive to make software for others, at least for some.
In the case of this one, I also am very nervous about the incorporation of a payment system. I fear that will discourage the creation of quality free software, and I think quality free software is a huge benefit.
In short, I fear that this app store will resemble the Android Play store, or Apple's app store, and encourage the same problems and adverse impacts they have had.
Smells like that old MS attitude to me.
[1] https://support.endlessos.org/en/apps/flatpak [2] https://fosdem.org/2023/schedule/event/containerised_apps/ [3] https://www.codethink.co.uk/articles/2022/flathub-codethink-... [4] https://www.collabora.com/news-and-blog/blog/2017/08/17/debc... [5] https://github.com/Igalia/webkit-flatpak-sdk
The Azure dev tools on Linux i have tried are all Snap only, or a tar file and maybe an rpm/deb. At the moment they seem to avoid Flatpak like the plague.
As far as I'm aware, Ubuntu is still the biggest player in the consumer Linux market not counting Android. Given the need to balance upkeep costs with range of support, I can see why Microsoft chose just Ubuntu and threw the rest to the wind.
What if I need older version of some software? Or what if I need multiple versions of the same software at once?
- I don't know how to see running logs by default (if it's possible even) and it's a must when you have slow internet - sometimes it just hangs and I need to kill (probably leaving residue along the way)
hopefully my issues are my own OR it will get resolved as well.
other than that flatpak is amazing.
This is unacceptable. Open-source apps should always be built from source on a trusted infrastructure and ideally the builds should be reproducible. Otherwise, one of the main benefits of open-source software -- ability to verify its security -- is completely lost.
Fortunately, Flatpak != Flathub. There is also Fedora's flatpak repository and that's what I'm using. It doesn't have as many apps as Flathub, but their number is growing.
I prefer flatpaks to RPMs because of the sandboxing feature. While it's not perfect yet, I like that I can forbid most of my apps to access the network and to limit access to the filesystem and other system parts for apps that require network as much as possible. As a result, the trusted base of my system can be reduced significantly (and the base system can then use other method to confine its processes which on Fedora is SELinux).
Another benefit of Flatpak over traditional packaging systems is that it's a cross-distro package manager and the apps can be installed on any Linux distribution. Even if we end up with multiple Flatpak repositories like Flathub and Fedora Flatpaks with different approaches and philosophies, users of any Linux-based OS can then install apps from any repository they like, and OS developers can focus on the base system.
So in general I like Flatpak and I think it's a step in the right direction, but I can't say the same about Flathub. For me it's unacceptable to install anything from Flathub unless they fix their supply chain security flaws.
Some convergence of desktop and mobile is plausible over the midterm so it might be worthwhile to think how that could be orchestrated
We don't need yet another store. What we need is a simple registry of applications that are installed with the scripts to uninstall. We already have this, it's a package manager.
For soft that doesn't need a package manager, we have .appimage.
Instead of making it more difficult to package apps for Linux, focus on having few methods that are robustly supported.
How can application whitelisting be achieved?
Does Flathub come with any features that help with that?
If you need to tweak them, Flatseal is a great tool.
Personally, I still prefer my repos with shared libraries when possible. I'm also able to keep a mirror of the packages to cut down on bandwidth.
I haven't figured out how to mirror the flatpaks yet, mostly due to lack of effort.
I'm excited, it will be good to have a cross-distro app store.
I'd gladly donate or even keep a subscription to keep Flathub running.
The sandboxing features are documented: https://docs.flatpak.org/en/latest/sandbox-permissions.html
i like it because it actually solves problem (getting proprietary software like slack) instead of creating ones and/or getting in the way (i'm looking at you snap).
Flatpak enables people to publish a single package that just works on all distos and doesn't break every 6 months. It's removing the maintenance gatekeeping.
I think it will be interesting to see if tech like WASM results in packages which work across CPU architectures as well as Linux on ARM is very painful currently, let alone more obscure ones like RISC-V.
Anyone have the connections to make this happen?
Valve actually uses bubble wrap on the Steam deck for proton.
as in Ray Dalio?
Off topic: An idea that came to my mind a few days ago is that would have been great to add support for desktop apps to Podman by adding some extension or plugin capabilities to it instead of creating a new whole technology. Probably a silly idea though.
... Neither MacOS nor Windows do this; what are you targeting now?
I’d be happy to pay for Linux software but there is no way I’d want to be tied to a particular distro/repo/storefront.
There's basically Steam or DIY.
If they used the royalties to hire people to audit the packages I might even consider paying for free software, but I'm afraid it will turn into walled gardens where small developers have no say and the big ones just deal with the problems because it's the only option.
I hope it turns out to be better with KDE and Gnome that come from a FOSS background but money makes people greedy.
However, I don't really understand why something like Flathub is needed in order to sell it. That's not been a major issue in my experience.
Is the main point to provide a payment processing service?
Also this seems to be a confusion about what FOSS is. FOSS "freedom" isn't about "free as in beer", it's about "free as in speech." The GPL even welcomes commercial software, provided they include the source. I'd be thrilled to see a category of "paid FOSS" in the store, and I'd buy quite a bit of it if prices are reasonable and the software is useful.
Apparently changes in GTK4 made it easier to add
Looks like it's getting fixed, though.