301–310 of 316 posts
//rolling my eyes into the back of my head//
Earlier quoted context omitted.
You're ignoring the supply chain side. RHEL RPMs are signed by Red Hat. Flatpaks are signed by... whoever happens to maintain that flatpak.
Er, yes? I am ignoring the supply chain, because I'm commenting on the sandboxing, which is separate from who's publishing the software. (The only connection I see is that whoever publishes the flatpak is responsible for setting the default sandboxing config, which is important but I don't know how else you'd do it. But then RPMs aren't sandboxed at all, so what does it matter who signs it? We're talking about sandbo…
But at any rate the multiple runtimes with multiple upstreams are why it's a non-starter from a security PoV; the uselessness of sandboxing is more just icing.
Earlier quoted context omitted.
That's roughly what our workflow does (DFARS requires it or something like it for CUI) and this story annoys me because the entire selling point of RHEL (which is what we use) is that you aren't having to audit a bunch of random upstreams because they do it for you. It's why their going all-in on flatpak was such a surprise to a lot of us.
That's fair. Maybe some large organization will be willing to sponsor their maintenance of RPMs, or of the Flatpaks directly. After spending hours trying to package even simple programs in RPM and DEB, I am very sympathetic to the idea that one cross-OS packaging format is enough. Why shouldn't there be "enterprise audited Flatpak" like anything else?
Flatpak will be the recommended way to get / install LibreOffice on RHEL and Fedora. In https://lists.fedoraproject.org/archives/list/devel@lists.fe... it states: "the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term." Install instructions are already written: https://acces…
It lets them focus on more enterprise-y features and improve overall security. Such a minor amount of work saved, if any, and it's all for cost savings, with a reduced user experience. Yup. Redhat as IBM. Modern IBM has fallen so far, and could never, ever create or originate something like redhat. So buy it, they did, and now legions of managers preen, and describe how to "improve" redhat, each cutting, shaving cost…
Earlier quoted context omitted.
CERN researchers mostly use Windows and macOS, even if the LHC cluster is powered by Linux. Back in 2003 - 2004, I was one of the few in my group, ATLAS/TDAQ, that bothered to have a laptop with Scientific Linux, and I doubt it has changed. All of those projects are a by product that Red-Hat Enterprise Linux also needs a graphical user interface, not a desktop product on its own.
To say it was like this in 20 years ago and I doubt it has changed is pretty crass. Especially for such as Desktop Linux which is essentially unrecognizable from 20 years ago.
One of the reasons why eventually I moved from a UNIX zealot, to someone that uses Google, Apple and Microsoft platforms.
And with exception of an aging netbook, only as Desktop VM.
Also as long as there is some form of POSIX support, it is good enough, regardless of the OS.
Earlier quoted context omitted.
That tends to wave away the responsibilities of the distributor. The distributor's job is to package software. In effect, putting it in their repo is sort of vouching for it-- they know it's going to work properly with the rest of the repo, and be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) If you just…
> a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. No, it looks a lot like Android or iOS, where the OS vouches for what the app can and cannot do instead of…
Earlier quoted context omitted.
Full or no filesystem access is very, very far from proper sandboxing.
Sandboxing is also an orthogonal question from packaging. OpenBSD sandboxes applications using pledge; it doesn't require maintaining multiple parallel runtimes to do it.
Earlier quoted context omitted.
In general a program that calls `dlopen()` must either ship with the libraries being opened (in the case of OpenSSL, which iirc only does this with libcrypto or one of its targets in some cases?) or be able to resolve them without the help of the loader via default paths. But all that said if you don't want your app to explode on different distros you always need to vendor your dependencies, including transitive depe…
Yeah, that's kinda the problem. If your dependencies are complex enough you may have a tough time figuring out when you've packaged everything. Surprises may be lurking anywhere. It might be loading files based on something read from a config file, or concatenating tokens, so you'd have a hard time knowing you got everything for sure without reading the source for every library your application loads, and every libra…
And also the situation isn't really different on Windows except that you have to do it from the start because there is no illusion of the base system providing a bunch of random libraries for you.
This LWN article makes the matter supremely confusing. The linked mailing list post is way better and clearer and it would be good to get this submission changed to it: https://lwn.net/ml/fedora-devel/20230601183054.12057.45907@m... Key excerpts: > … the LibreOffice RPMS have recently been orphaned … > … will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way…
This is probably how things will be moving. It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere.
Earlier quoted context omitted.
The biggest minus of containers for me, including Flatpak, are that even with xdg desktop portal workarounds they still fail to actually integrate into the desktop and make or break features that depend on this simply don't work. And because it's a container it's nigh impossible to debug and find a fix. In the end containers are even more fragile than depending on system libs and fighting future shock.
> xdg desktop portal workarounds Desktop portals are not "workarounds", they are the new correct APIs to use