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:
> … 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 that most people consume LibreOffice in the long term.
> Any community member is of course free to take over maintenance, both for the RPMS in Fedora and
the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and
dependencies and a significant amount of work to keep up with.
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.
Flatpak is a non-starter for me. The runtimes required by my office would mean 2 KDE versions and 2 Gnome versions installed as flatpak runtimes in addition to the KDE running on the host, which quintuples the security space I need to monitor.
Sweeping package management problems under a rug doesn't actually make them go away.
No, I trust my distribution to do that for me, and more importantly update libraries as needed. With snap and flatpack I have to trust every single upstream to keep track as if there is a problem i'm vulnerable until everyone updates.
I'm very interested in some sort of daemon that regularly scans for vulnerable binaries/libraries and produces desktop notifications about this and/or hosts a web interface to review issues. I do use clamav for malicious files, but bug advisories/vulnerabilities are another area I wish I could make convenient to monitor for personal computing. I've seen things like Splunk reports in enterprise settings, but not for personal 'digital hygiene'
Anybody have a list of open source solutions here?
Not all. But I'd wager it's not uncommon for a lot of linux people to periodically check their most used software with the largest attack surfaces. Browsers, document viewers/editors, mail clients, decompressors etc.
Just being sandboxed though isn't a help if you actively want the software to process sensitive data! If you want to read a private document in LibreOffice, you have to be sure your copy of LibreOffice and every library it calls is trustworthy and reasonably secure.
I dunno, if it's sandboxed and doesn't have network access then the only attacks I can think of are either really indirect (embedding an attack in saved files in hopes of hitting another user) or really targeted (altering a specific document or phrase when it's read). Assuming the sandbox works and includes blocking of network access, what attack do you see a word processor performing even when handed sensitive data?
Suppose your word processor is allowed to write to arbitrary files in your home directory. It writes a line into your .profile that CURLs your sensitive data to it's server.
This has a level of indirection, but that just delays things until the next login. With a little more work there are infinite other places you could inject that might run sooner.
> Suppose your word processor is allowed to write to arbitrary files in your home directory. It writes a line into your .profile that CURLs your sensitive data to it's server.
Yeah, that's like the poster child of sandboxing; I am very much supposing that my word processor is not allowed to touch arbitrary files.
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 sandboxing here.)
I dont care about sandboxing though; the valuable data is what the apps themselves are handling so it doesn't help.
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.
I literally don't care about sandboxing. The data the apps themselves handle is the only thing valuable; protecting the rest of the system is pointless since I can reimage essentially for free at any point.
If malicious software takes over my browser it can steal my identity, wreck my finances, and ruin all my business and personal relationships. The fact that it can't add a printer is interesting but not really at the same level of concern.
As far as I know, Flatpak offers a fair amount of control over sandboxing. It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your system. The alternative might be giving it access to one particular directories, and then copying files there when you want to work on them. But that's already pretty cumbersome, something only the paranoid would bother with.
Realistically, I know that I do not have the skills to evaluate complicated applications and their complicated dependencies for security characteristics, so I am 100% reliant on packagers, maintainers, etc. for my security anyway. I'd rather just donate to the people publishing and maintaining the packages and hope that they are doing the job well, than fruitlessly attempt to fuss over it myself.
> It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your syste
The good news is there is a solution to this. The trusted system shows a file picker, and then grants access to the sandboxes application.
I didn't realize this existed, it seems a lot like what Apple is doing for the photo gallery in recent iOS versions. That's a nice extra safety feature.
I suppose additional security features inspired by mobile systems couldn't hurt either. Like a pop-up whenever something accesses the clipboard.
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?
Sandboxing is also an orthogonal question from packaging. OpenBSD sandboxes applications using pledge; it doesn't require maintaining multiple parallel runtimes to do it.
Do you use flatpaks? Each application brings with it a desktop runtime (Gnome or KDE or sometimes just the FDo that underlies Gnome and KDE), and each of those desktop runtimes is versioned. The problem is these don't get updated on Flathub at the same time, so the vector art editor brings one version of Gnome and the IDE brings a different version of Gnome.
Now, it's possible to build my own flatpaks and keep everything updated, but if I'm doing that I might as well just build the actual software and use the distro's package management system.
> 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.
It does make sense for at least one distro to be offering this, as there are numerous reasons to favor the traditional linux distro way of doing things. Flatpak is better for a lot of use cases, but it's missing a lot by not having a centralized system of checks and balances provided by a Linux distro.
Fedora Flatpak brings back a lot of the advantages of traditional Linux distributions, but unfortunately Fedora/RHEL likely won't be maintaining a Fedora Flatpak version of LibreOffice.
Because there are pros and cons for each type of packaging but native distro packages and Flatpak will go-exist. It does already on my machine.
Distribution packages:
+ necessary for base system
+ small memory requirement
+ small package size
+ all checked by distro
+ work well together
+ on fix, fixes it for all
o lot of work for maintainers downstream
- bugs hard to figure out for upstream
- problematic with closed-source
Flatpak:
+ programmer packages is/her software once and only once
+ support all distributions i.e. Linux
+ use selected dependencies
+ control-groups and namespace are in place for lock-in
+ autonomous offline package handling e.g. “storeable on thumbdrive”
- huge maintenance burden, especially security, on programmer
- higher memory usage
- big package size
Usually if I see something entirely new (e.g. Marker some years ago) or something using Qt-Libraries (e.g. Zeal) instead of my native Gtk based environment, it is a candidate for Flatpak. Marker is now in native repos of Arch, therefore is use it now from there. While I kept OpenRA as Flatpak because I need usually the on provided by upstream.
I think Flatpak is ideal for new stuff and especially closes-source software. Programmers cannot do the repeated error of supporting some special outdated distributions. It is a miracle to me how anyone can think that packing for a specific distro is their job? It is not. The job is documenting how to package the software and allow redistribution. With Flatpak we allow them to do package themself if desired but just once and for all.
A weak point of Flatpak is that facepalm Canonical is doing it very own show with Snap. How often does Canonical need to fail with Mir, Unity, Upstart and now Snap? The server is closed-source and it is against the community. Even if it would be better it is dead. And no, we don’t need two competing…please just commit fixes to GNOME e.g. type-ahead-find?
And I don’t want to hype Flatpak:
GNOME-Software could use less memory itself, we need an easy approach for payment (and repeated payment?) and it stores many small file on disk. And I wonder which security requirements the Flathub requires?
> It is a miracle to me how anyone can think that packing for a specific distro is their job? It is not. The job is documenting how to package the software and allow redistribution.
I think the mentality of authors who package their projects for a specific distro comes from their familiarity with Windows, where there is only one distribution (more or less) and packaging for it is naturally the responsibility of software authors. They mistakenly apply their windows experience to the new task, probably entirely unaware of the faux pas.
Often, knowing that there are a myriad of Linux distros, they mistakenly assume that the community of linux users are expecting them to support dozens of distros individually, testing on each one, and they become reasonably upset with that (mistaken) obligation. So they stamp their foot down and say "I support Ubuntu 13.04 specifically but if you use another distro then you're on your own!!" Then they go on to complain about fragmentation and say that linux users need to pick one distro and stick with it. Really, nobody expected them to support any specific linux distro in the first place but that is poorly communicated to otherwise experienced programmers who are new to linux.
I also think it are developers familiar with Windows but didn’t want to start…with that.
I did wonder how even companies like Amazon came up with that approach? For example their own MP3-Downloader back then. So someone else has written “clamz”. Even Valve was on that train with Steam, first only shipped for Ubuntu until Arch and others nudged them and asked them “to allow redistribution.”. At least this shows, talking to each other helps :)
And now Valve uses itself Arch ^^
> A weak point of Flatpak is that facepalm Canonical is doing it very own show with Snap. How often does Canonical need to fail with Mir, Unity, Upstart and now Snap? The server is closed-source and it is against the community. Even if it would be better it is dead. And no, we don’t need two competing…please just commit fixes to GNOME e.g. type-ahead-find?
Hey now, Canonical provides valuable service of researching how to not do something so others can avoid those mistakes.
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.
... the new correct API to use to work around containers and all the problems being containerized causes.
>Portals are the framework for securely accessing resources from outside an application sandbox. They provide a range of common features to applications, including: Determining network status, opening a file with a file chooser, opening URIs, taking screenshots and screencasts [...]
All things being containerized messes up which require workarounds. xdg desktop portal attempts to provide these but most of the time it fails to do so fully.
I've tried several times to understand how Flatpak works and how to integrate a CMake build with Flatpak.. and I'm honestly befuddled. Granted a quick Google search does show the situation has improved a bit in the past year.
I imagine if you're trying to package a Zig or Clojure application it's going to be a lot of figuring things out on your own
AppImage is also troublesome. I just spent a good while debugging ours.
The TL;DR is that AppImage amounts to a self-extracting archive, and you need an application where all the binaries and libraries have a relative rpath. So rather than loading /usr/lib/libz.so, it uses $BINARY/../lib/libz.so.
That part's not too bad, but what can cause a lot of trouble is that there's a fair amount of stuff that uses dlopen at runtime. So you might find that you think you packaged everything, but then the app loads some module from the host system, the API isn't compatible and it explodes in some confusing fashion.
So yeah, Linux app distribution is a pain no matter what it seems.
And AppImage distribution has the same fundamental security problem as static binaries, making it difficult or impossible to replace downstream dependencies. When a dynamic library needs a security update (e.g. heartbleed in libssl), the shared library can be replaced system-wide. When a static executable or AppImage needs a newer version of a library, you need to update the program entirely, and there is no way to do so across all programs system-wide.
And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected.
But on a system where everything is updated at the same time through a package manager, I don't see that there's a material difference, unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.
> And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected
What's more common in practice ? Widely used libraries introducing critical vulnerabilities in 2023. Or old vulnerabilities being discovered/exploited, and patched?
> unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.
That's precisely the problem isn't it? What if "You the upstream app developer" is on a long vacation, or abandoned the project? Multiply this by N where N is the number of different app developers.
Compare with "you as the OS admin". If you're using your system, you update that vulnerable dynamic library, and you're done.
If users of other machines are on vacation or abandoned their machine, that's not your problem. Your system is secure.
So I feel parent's point had everything to do with dynamic vs. static linkage.
If a new version of a dependency introduces a vulnerability, then dynamic libraries allow you as the sysadmin to stick with the secure version.
For package managers, difference is how often the decision to update a library must be made. Dynamic libraries mean that the package maintainer of libFOO must be aware of security issues in libFOO, and update accordingly. Static libraries or AppImages mean that the package maintainer of every user of liBFOO must be aware of security updates in libFOO, which is a much higher burden.
You only need one hole. A newly introduced vulnerability compromises the system as soon as one package updates. A fixed dependency only works when every single program is updated.
Can't you just add an rpath to your main executable (which cmake does by default for release builds that aren't installed, fwiw) or use a launcher that sets LD_LIBRARY_PATH?
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 dependencies. That's just the sad reality of shipping programs that are dynamically linked.
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 library your direct dependencies load.
And then everything may still work until 3 distro releases later something finally becomes binary incompatible.
To be hones, developers should be doing that work anyway to figure out what dependencies they really need and which ones can be replaced by lighter ones that don't pull in gigabytes of crap.
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.
Red Hat will almost definitely work with upstream to "fix the problem". Red Hat engineerings mantra is "Upstream first", the financial cost of maintaining a difference from upstream is a detractor to encourage users from using upstream builds.
"It doesn't make sense for every single distro to maintain customized versions of user level applications"
Why it needs to be a customized package? Software is software and every Linux application which is open-source can be compiled and placed in /usr/local or whatever non-system level directory.
Why is it so hard to compile the latest supported version and package it in a distro-agnostic way?
Well your excerpts aren't really clearing up all confusion IMO, but even the original message is somewhat confusing too:
>> … 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.
Here you left out the part that they'll do that only until older RHEL releases, that still have LibreOffice support are EOL:
> We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9)
> with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat
> website). As part of that, 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.
I.e., they don't plan to fix anything besides issues w.r.t. the (only older?) release branches supported by RHEL <= 9, until that is EOL too.
And while they first hint that only RPMs packages are affected and implicitly suggest that distribution via Flatpack is the way forward (yuck), they then contradict that part by telling that they'd find it OK if a volunteer picks up LibreOffice support for both, RPM and Flatpack, up again in Fedora. I.e., reading that it seems that they don't plan to actually support the Flatpack distribution either? Or is this a Fedora specific Flatpack repo?
No, they plan to maintain the RPMs for RHEL 7/8/9 and to contribute fixes for Flatpak, which is how they expect people to consume LO (without Red Hat support) in RHEL 10 and perhaps in future Fedora releases.
I for one am a periodic LO user (for both work stuff and personal sheets like tax returns) on Fedora and will switch next week to Flatpak to start reporting bugs. I already use Flatpak for OBS, Ferdium and VSCode, with no issues except that I need to use ssh access to open VSCode projects on localhost (because of some known sandboxing issues).
> support for both, RPM and Flatpak, up again in Fedora
Fedora has a Flatpak repository that is separate from FlatHub. LibreOffice developers post their builds to FlatHub, and those are usable from Fedora without involvement from Fedora developets.
I think you may be misinterpreting it. They’re saying “we’re not maintaining LibreOffice RPMs beyond the current supported versions of RHEL, because we think Flatpak is the way forward, but we recognise that there are currently problems with it, so we will put some effort into fixing those, so that us no longer offering RPMs isn’t disastrous”.
"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."
I would not be surprised if more desktop applications also go to Flatpak on future versions of RHEL. It lets them focus on more enterprise-y features and improve overall security.
I think this is a small step in the right direction.
IMHO, Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources.
If you want to give that application access to everything your user has access to, that’s fine, but it shouldn’t be the default.
> I think this is a small step in the right direction
Yeah, I am obviously biased because I am a Red Hat employee but the truth is the Flatpak model makes a lot of sense for large desktop applications (LibreOffice, OBS, etc.) that anyway do Windows releases and therefore have to track vulnerabilities in their dependencies and release updates.
It may take a while to get used to it, but Red Hat has done a lot of infrastructure work to make this sandboxing possible (in RPM ostree, Flatpak, GTK+/GLib, PipeWire and many more places) and it's not a bad thing if they decide that the work is mature enough for them to reap the benefits.
> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources.
This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged.
Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
This isn't some untrusted unauditable binary blob from a possibly shady manufacturer.
It is a program that reads unstrusted binary blobs (many document formats) using C++ deserialization code that has a history tracing back to the nineties and even eighties (through StarOffice). I sure as hell want such an application to be sandboxed and ask for elevated permissions. This is pretty normal on other platforms like macOS (Office and iWork from the Mac App Store run sandboxed), iOS, and Android.
Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
You need more than policies. E.g. if a program cannot read outside its sandbox, you need some way to mediate access to files/directories on the user's request, which are provided by e.g. Flatpak/XDG desktop portals.
> It is a program that reads unstrusted binary blobs
When opening any office files from unknown or untrusted sources is something you feel you have to do, you're probably well off isolating that operation and thus limit the blast area.
For people working exclusively on their own files or with trusted colleagues, that is pretty much a non issue.
First you say that people should just audit the code if they don't trust it. Then you say if someone wants to read untrusted files they should just spin up a virtual machine?
So I need to spend thousand of hours reading libreoffice's and its dependencies' code, and then I still need to run it in a virtual machine when I read untrusted files (in case there are bugs that could be exploited)?
It makes zero sense to keep pushing that nonsense when the alternative is to sandbox apps to begin with. It makes EVERYBODY safe from backdoors and bugs, for FREE. Why do you fight it?
> First you say that people should just audit the code if they don't trust it. Then you say if someone wants to read untrusted files they should just spin up a virtual machine?
Because of an intended functionality of many of those file formats, which makes them quite dangerous when coming from untrusted sources: Macros.
> This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged.
Compressed source code archive is over 300Mb. That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed.
I don't read every line of code but yeah. I think I spend more time reading code for curiosity's sake than actually using many programs. I absolutely read build system scripts, I won't run make until I know what's gonna happen.
I also enjoy stracing random programs in order to figure out the exact set of system calls they're making, in which order and with which parameters.
So only people capable of auditing source code and build scripts deserve to be able to trust software? There should never be any other way to offer trustability?
Perhaps you missed the part about not needing distro-specific packagers by providing a way to run third party apps without having to trust third party packagers. You can deny access to the camera or filesystem or network without ever auditing the source code and trust that the software cannot misbehave in that aspect.
This isn't a knock on the value of package managers or maintainers. It's just an obvious step in better security. It seems silly to argue that integrity among package maintainers is the only safeguard we need. I personally like the little piece of plastic that my laptop has that slides across the built-in camera. It's not a software solution, or even an electronic safeguard. It's even better than the little DIP switch on my phone. I say, why not?
We could have both though. They aren't mutually exclusive. Also important is the option to intercept system calls and return fake data to the software. Give it a silent audio, black video, a limited view of the file system. That lets us control proprietary software that gets pissy when permissions are denied.
> So only people capable of auditing source code and build scripts deserve to be able to trust software?
I don't know about "deserve" but it's true that we have the knowledge necessary to understand what a script or program is doing.
> There should never be any other way to offer trustability?
Of course not. Someone else can audit it for you. If you trust that person, then you also trust the software that they audited.
Linux distribution packagers are the simplest example I can think of. If something makes it into a Linux distribution like Debian, it's pretty trustworthy. That's a big reason why we users like that model. It's also why developers hate it.
I'm unsure what your talking about. Surely SecDevOps would be mostly alerted when a vulnerability isn't caught by someone looking at OSS. Those vulnerabilities that are caught should be mostly invisible.
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 hand everything off to external self-contained images, you lose a lot of that.
I suppose you could do 'captive' collections of Flatpaks, designed to meet the same optimization and compatibility promises, but at that point, you have RPMs with extra steps.
Taken to an extreme, 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.
To an extent, I also just resent the entire "it works on your machine? We'll ship your machine" mentality-- Docker/Kubernetes and Flatpaks/Snaps are sort of variations on the same theme. They come from a mindset of infinite free resources-- the disc space for all those redundant dependencies is coming from somewhere-- and it would seem to make brittle, hacky code more viable because you don't have to FIX code that depends on unguaranteed aspects of an API contract.
> 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 the distributor and there are no privileged scripts running at installation time. You can try it already with Fedora Silverblue.
> be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.)
That's true, this is potentially something that is lost for interested people.
The point was less about the permissions themselves, and more that you're replacing a centralized "everything you want is in one ISO" model to having to retrieve a bunch of packages from third parties after the end of "the main install".
It's all open-source and auditable, so any odd application behaviour should be prevented in the first place. Sandboxing is great but cgroups are not a sandbox. I think the post shows also that the main problem is amount of maintenance for many distributions. Maybe better package tooling would help - in the end Flatpaks are just a middleway between completely integrated packages and distributing everything as a self-contained tarball.
Multiple layers of security. Yes in theory I could audit millions of lines of C++ code to see that LO does not access the microphone, but I also like that the sandboxing layer prevents it from happening entirely. I'd rather audit a permissions list than an entire codebase.
> Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications.
I think I understand this stance, but really, I would consider this to be a terrible outcome. If that's the direction things are going, I really need to stop procrastinating my move away from Linux entirely.
I am not particularly happy with Flatpak - I still think it mixes up two things (packaging, sandbox), and is not particularly good at the former. Nix actually solves the former issue, and does so splendidly. I would much rather see better sandboxes for linux.
Well, Nix mostly solves that issue so well due to a continuous massive offering of blood and sweat though, let's not kid ourselves. It's a significant amount of work to package arbitrary software because arbitrary software does weird and bizarre things.
But IMO the fundamental principles underlying the design are sound and granular compared to most of the alternatives, though, that's for sure.
Luckily (at least for me) Nix makes building and packaging arbitrary software fun. There's something to hacking derivations together, reading documentation, seeing it build and work.
At this point, there isn't a C project I can't package in fewer than a handful of sittings. Even when patches are involved!
I really don’t see how this comment is relevant to the conversation at hand.
None of this is about sandboxing libreoffice. It’s simply about a delivery method of getting a libreoffice on a system. Nix is absolutely 1000% not a mainstream solution that’s better than Flatpak for this.
If your hobby is tinkering with Nix and marveling at its supposed technical superiority, more power to you. It is absolutely not relevant to this conversation.
If I start up a nix shell with libreoffice installed within it, I will reliably get the same configuration the packager intended — so it is as relevant as it gets: if packaged correctly it will work on every system where tool X is installed.
I see the goalposts have moved again, now we're on "reliably get the same configuration...."
The conversation is about Red Hat not packaging LibreOffice for RHEL. The options in scope here are RPM or Flatpak. Nix isn't even under consideration. You jumped in to complain about not being happy with Flatpak because it's not good at sandboxing. Nobody brought up sandboxing until you waded in about Nix.
It's tedious how any conversation about anything remotely related to packaging or pretty much anything, somebody has to show up stanning for Nix.
I've been wanting to use LO's flatpacks on my fedora for a while, but I recently gave up and resorted to using the distros' RPMs even though they often lack behind. Global menu, Hi-DPI and kf5 VCL theming just don't work from the official flatpak on my latest KDE+wayland. It seems that several issues are compounded across several stacks (flatpak, dbus, wayland, …) and I don't think there's actually any workaround that works for me.
I really hope they get to the bottom of that before dropping the distro's RPMs.
RPM's are integrated into the OS by a maintainer, Flatpacks are isolated from the OS because of lack of a maintainer. It's not possible to have a cake and eat it too.
As much as I might dislike IBM, Canonical is doing the same thing. Many established distros are pushing containers for very practical reasons - they shift significant amounts of packaging work from distros to developers. It's annoying but it makes sense.
> If they aren't doing that, why do we need distros at all?
- To set up system daemons in a sane way. You're not going to containerize systemd.
- To set up and maintain desktop primitives. You're not going to containerize Wayland or audio systems.
- To integrate all these containers in a decent manner. Flatpak and its ilk have limitations that will have to be smoothed over by distros.
Will that mean a consolidation, since differences over packaging become less relevant? Maybe. I'm pretty sure we will still have significant differences between The Way RedHat Likes To Do Things, The Way Debian Likes To Do Things, The Way Canonical Likes To Do Things etc etc
The OP is burying the lede! The exciting news [0] is
> We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for
color-sensitive work, and a host of other refinements required by Workstation users.
This is a long-standing and important effort [1] to make Wayland more plausible for image/video-editing.
The companies I work at are all using either Google Docs or Office 365. The collaboration benefits are pretty immense, and can save people a lot of synchronization and communication effort. Most my colleagues see oldschool desktop document editing software as obsolete and frustrating to work with.
For Office 365 I totally see how it renders LibreOffice like local monolithic obsolete.
On Google Docs though, it's limited enough to hit some roadblock every now and then. Last time it was a gigantic csv that took forever to render as a spreadsheet. Other times it was formatting problems that made the document unusable. It's rare, but happens enough to warrant an alternative local office suite to deal with the exceptions.
Even as casual user who once in a while wanted to open and manipulate csvs in libreoffice I was hitting issues and it even straight died on me couple times. I dropped the attempts to use it after couple days
I think that's an optimistic read of their short and vague statement. Someone has to do the work of packaging it and if they're stepping back (for both RHEL and Fedora), who will do the work?
Yeah. Cloud office tooling has won, at this point. There will always be a handful of (mostly spreadsheet) users who insist on doing things locally, but at this stage that is emphatically a small minority. And of that market, LibreOffice has captured essentially none of it.
If you're collaborating with other people (with some narrow exceptions), the idea of sending around point-in-time snapshots of documents feels horrifying. And, to your point, LibreOffice is from an era when providing a plausible alternative to Microsoft desktop products was a big deal. It really isn't at this point. Mainstream users use cloud-based options and specific power users use Microsoft Office.
And most customer lists are on Salesforce. ADP has everyone's salary data. At the end of the day, the safe thing is to just disconnect all your computers from the internet. But that's not very practical so you decide how much of your company's time and energy you want to devote to reducing potential security exposure while your competitors are just taking advantage of available online services (with some level of security due diligence).
Fortunately you can work on shared cloud documents while still having more features and the faster response of local applications. I often work with local Excel or Powerpoint apps on cloud documents while another colleague is working on the same document. If I need to share the document, I just add someone to the share list. If someone emails me a document to work on I switch it to a cloud document and then share it back to them to try to change their habits of sending out discrete copies of documents.
Exactly. These SaaS solutions are way less (speech) free, with anything you write being a accessible to various powerful entities depending on legal jurisdiction you reside in.
A few years ago, Google Docs restricted access to a family member's documents for 'suspected copyright infringement'. When asked about this, I could not find an infringement, and even if there was one it may have been permitted under the exception to copyright afforded to 'educational establishments' in the 1988 Copyrights, Designs and Patents Act here in Britain (the relative was a teacher).
Thus, another problem is the SaaS providers ignoring the legal jurisdiction you reside in, and restricting technically rights you have legally!
Furthermore, Libre Office is not the slickest software, nor do they listen to their users. For about a decade people have been asking, Wth do you mean, I can't select multiple images in a doc and move them?! The team's response remains, You're not supposed to do it that way, you must first smush all your images down into one, then import and move that. This prescribes a waterfall model of doc creation; they're admitting Writer discourages experimentation and stifles creativity. Just a rotten UX and a rotten attitude. They should get better or get lost.
I would get mad over this stuff 10 years ago but it feels a bit strange to complain about libreoffice`s broken ux in 2023.
People who claim libreoffice can replace office remind me a bit of people who claim gimp can replace photoshop, or inkscape could replace illustrator. Laughable
That's a false comparison. You can still edit documents using LibreOffice installed via flatpak, or, like probably most users, use Google Docs, Office 365, or OnlyOffice.
Meanwhile without proper HDR support and better color management, Linux desktop is basically a non-starter for any professional creative use-case, including design, animation, illustration, image and video editing.
Ideally both would be done but they seem to have limited resources, so in this scenario I personally fully support their choice as it will enable Linux desktop usage to a whole new user-base (which is also a paying user-base, namely animation studios that use RHEL).
If they have real studios using it I'm guessing this just means plug and play HDR support? As opposed some previously working set up requiring tweaking it yourself?
To my knowledge, there was no working HDR of any kind until the last year, when Valve hacked in hardware-specific HDR into Gamescope, and even that only works if you really get your hands dirty.
Last month there was a hackathon with all the big players (Valve, AMD, Nvidia, KDE, Red Hat, Wayland) to finally settle on a plan for universal compositor HDR implementation.
No, HDR basically doesn't exist on Linux at this stage. I believe there's some (insufficient) scaffolding in the kernel for it, but no support in the common display stacks.
The former has tons of plausible alternatives which are already more frequently used than LibreOffice - and of course you can still use LibreOffice via Flatpak anyways.
The latter is a hard requirement to doing serious media editing work on Linux regardless of what software you want to use. And unlike the former, there's a dedicated customer base that wants it.
There were plenty of plausible alternatives before Sun bought StarOffice and made it Free software. There were plenty of plausible alternatives when the Libre folks "freed" LibreOffice from Oracle.
LibreOffice is still the standard-bearer for open source office suites. It isn't competing with WordPerfect or AmiPro or Lotus 1-2-3 or Quattro Pro like it used to. The proprietary stuff have largely died and lost to the two big gorillas.
It is as important as ever to have the likes of LibreOffice around. There are plenty of plausible alternatives to Redhat itself, but surely everyone understands how important they and their like have been and continue to be.
Only the color sensitive part is exclusively related to image and video editing. It's an interesting question, over the past few years I've only sparsely done document editing in anything but Google Docs (which I still find absolutely terrible). Most of the "documents" I write goes into systems such as Confluence or various wikis, rarely do a produce an actual document in a word processor.
I might be completely wrong, but it seems like word processing is becoming a bit niche, something limited to legal and sales teams.
I tend to prefer Google over other docs tools. Occasionally I hear that people feel it's terrible, but I don't understand why. Would you mind sharing a few things that bug you the most?
Document management is probably the thing that bothers me the most. Once a document is in Google Docs, it's basically impossible to find again, unless you link to it from somewhere else. Documents is some weird hybrid document/webpage/wiki thing. I hate that it doesn't have save button, completely breaks my workflow that it saves everything all the time. Sure I can make a copy, but how to I replace the original document afterward?
Finally, person preference, I don't like browser based apps. I get lost if I have more than two browser windows and five tabs open, why would I want yet another thing running in the browser then?
I generally like Google Docs and find it does a good job of implementing the feature set that most people actually need without a lot of the cruft you find in something like Microsoft Office. And I'm minimally organized enough I can usually find my own documents without much trouble.
I'll sort of agree with a couple of your points though.
Better version control would be appreciated. I had a problem just this past week because I was extensively rewriting someone else's doc and I felt I needed to work on a copy to straightforwardly preserve the original. And this ended up causing confusion.
Searching for the right "shared with me" document out of the hundreds that get shared on a regular basis--many of them routine meeting agendas and that sort of thing--is really hard and I regularly have to try to figure out who the owner is and other characteristics that will let me track it down.
Funny how even the term "word processing" has gone out of common use. Yesterday I was reading Becker's Writing for Social Scientists, 2nd ed. This is a 2007 revision of a book originally published in 1986, and includes at chapter titled "Writing with Computers" which includes much of the chapter "Friction and Word Processors" from the 1986 edition. I recall a moment of bemusement realizing how archaic the term "word processor" sounded to my ear.
>Funny how even the term "word processing" has gone out of common use.
You're probably right. I'd probably just say I'll write something up or I'll share a Google Doc or something along those lines. And we'd just create "some slides" or "a slide deck" and no one would imagine for a second we were going to create actual 35mm slides. We still use "spreadsheet" though.
I just don't understand this kind of comment. I've used Google docs for many years with dozens of collaborators. Could it be better? Sure. But "absolutely terrible"? That sort of comment makes it hard to take any other part of the comment seriously.
Image and video editing. The vast majority of VFX shops run on RHEL/ Alma. I expect the microscopic fraction of users who use desktop Linux, then the even more microscopic fraction of users who use Linux for Libre Office is just not worth supporting over other more important things.
Besides, I think you can just install Libre Office using Flatpak.
Of course one could argue that the hardcore Linux (er, GNU/Linux) document creator will use Emacs with AUCTeX (or canny uses of org-mode), with rendering via XeTeX/LaTeX/LuaTeX... Or markdown piped through pandoc, for those who want to take it easy.
LibreOffice, it's a slippery slope... Next thing we'll be using the mouse and ditching the tiled window manager.
Wayland/HDR etc is much more important for those who need it than using LibreOffice (which still will be available) when there are plenty of online solutions that work fine
How does this make one drop LibreOffice as a package?
If I focus on video editing, do I drop... say, Thunderbird, because of "adjusting my engineering priorities"? What are users of my distribution supposed to use, by default? This sounds weird, if not disingenuous.
> And if users aren't allowed to voice concern then they will make many more mistakes.
Generally, RHEL does exactly what RHEL customers want. They are extremely loyal to their user base.
The issues come when these changes set a trend and ripple to the rest of the community, and affect people who would never become a RH customer in the first place (e.g. anti-systemd fanatics)
I'm not convinced that people who are not paying Redhat for RHEL Workstation support count as customers on this question.
But this is still an odd statement. Previous customers who very much relied on LibreOffice might move to some other platform or at least some other support service. Thus they would no longer be Redhat customers and Redhat would still be loyal to their customers.
I suspect the number of RHEL Workstation customers to be a relatively small part of Redhat's customer base. And those that depend on LO support to be even smaller. I don't expect this to affect RH's bottom line in any negative way.
Either way, there is significant back-and-forth conversation between Red Hat and their users. And because of that, when the RHEL 9 deprecation rolls around in 2034, a lot of those users are likely to be well-prepared for a switch to either Flatpak or the upstream LibreOffice rpm.
I have zero doubt that Red Hat has consulted the users of Red Hat Enterprise Linux that matter, and that this will impact.
The commentary of users on LWN and HN may be interesting, but not likely to be representative of those paying for RHEL on desktop/workstation. (I’m talking about sizable accounts here, not small shops that might be paying a little.)
I am no longer at Red Hat but in my experience the product marketing managers, and product managers, and account folks had a pretty good finger on the pulse of their customers.
Right but people generally do not install packages from just anywhere in corporate settings. I am sure there are a lot of places where either red hat packages the software or you don't get to use it.
Not to mention, sometimes it's a pain in the ass to install an unsupported app like a compiler or mail/ldap/web server.
And if something goes wrong and you're not using the supported version of the supported package, you don't get support. (Which is how it should be I think)
There seem to be a server version of LibreOffice, called confusingly LibreOffice Online and Collabora Office (?) somewhat interchangeably; Collabora is the #1 contributor to LibreOffice.
I cannot find a free online demo of that though, so I don't know how good it actually is.
edit: there is also some confusing thing about maximum number of users, and if you want to remove it, you need to rename the server because of trademark? I don't know. Seems confusing
It's decent enough for me to use it instead of Google Docs but it definitely has it's limitations. While Google Docs seems to render things on the client side, Collabora Online renders everything on server side, which makes this uncomfortable to use with slow internet.
While the feature set of Collabora Online is decent, there are some missing, for examples you can't insert/edit mathematical equations and there are no macros. Templates are supported but you have to create them externally and then upload them.
I think it's good enough to write a few pages of text but it's not good enough for power users who write 100-page essays or use complex formatting.
When IBM bought Red Hat this was the kind of thing I worried might happen: That Red Hat might stop supporting the Linux Desktop.
I have no idea how their announcement makes any sense. They want to improve workstation experience by... not offering an office application any more? Like, what do you even mean by workstation?
Workstation usually means a high powered system for one user (at a time) where you would run things like CAD, 3D tools, mathematics or science software etc.
So a focus on professional graphics features certainly makes sense.
A (relatively) low powered system just for productivity software and web browsing would usually be called a desktop.
At least some point there were actually different variants of RHEL for workstations and desktops.
>that's no big issue so long as the RPM and flatpak work fine. //
RH are no longer putting any effort into that, when they were doing before, so ... if RH are saving anything then LO will have more issues for RH users than it has up to now.
Exactly, one has nothing to do with the other. Or maybe people think that the Red Hat employees presently tasked with packaging LibreOffice also happened to be graphics stack specialists with the experience needed to bring HDR to Linux. That seems unlikely to me.
If by "given up", you mean still investing more (sometimes far more) into desktop Linux than practically anyone else.
Desktop is simultaneously not a large priority for Red Hat, and even less of a priority for every corporate player that isn't Red Hat.
RH is still doing a lot of work on things like Pipewire, Wayland, Flatpak, Gtk, Gnome, AMD graphics drivers (David Arlie wrote RADV), making the Nvidia graphics drivers situation suck less, Mesa, etc. They were doing nearly all of the Xorg maintenance too and nobody really picked it up after they stopped.
The only company with a comparable level of investment in desktop Linux is maybe Collabora or (to a lesser degree and with a much more restricted focus) Valve
Consumer desktop product. That's a category that nobody competes in. Apple sells hardware that incidentally includes macOS and Microsoft hasn't cared about selling Windows licenses directly to customers for years and their OEM licensing business for consumer devices (i.e. non-Pro licenses) is neat, but it couldn't sustain Windows by itself.
Those are incidental products of the big moneymakers being made up of the same parts, just like Fedora (and most other distros with the modern GNOME stack) exists because of RHEL.
That certainly aged poorly. Whoever wrote that had no clue what the next decade of Red Hat would actually be like.
When this was written, desktop Linux still looked like this https://distrowatch.com/images/screenshots/debian-lenny-gnom... and by 2018 a new set of desktop interoperability standards had been introduced and incorporated into most Linux desktops, with Red Hat as the main organization behind this.
Their desktop products are Red Hat Enterprise Linux Workstation, Red Hat Edge, and the Red Hat Universal Base Image build system. The former is used heavily in particle physics laboratories (CERN and Fermilab use a mix of RHEL, Alma, CentOS) as well as some niche graphics workstations. The latter two are used for a lot of different things, but can be used to manage automatically-updating company-assigned desktops/laptops, and the tools behind it have been extended by the community to offer consumer-grade desktops like UBlue.
They have deep involvement in a ton of different Linux desktop technologies. They also package the Red Hat Flatpak repository, which is the RH equivalent of Fedora Flatpaks. These are Flatpaks that are built by combining the RPM build process with additional flatpak-specific metadata. There is ARM support for all of this, unlike Flathub which is spotty on non-x86-64 architectures. Currently RH Flatpaks is a "tech preview" feature of RHEL9, but it will likely be more fleshed out in RHEL10.
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.
I swear, Desktop Linux has continued to regress in a downwards spiral since Mac OS X was first released, so only for about the past two decades.
I also love the “solutions” that are recommended for when this happens with basically every Flatpak out there. They’re all either 1. install this application to change your settings after your stuff is gone or invisible and remember to do it forever or 2. instead of that application simply type these 80 characters into Terminal.
They warn that it's a lot of work. It would have been interesting to know how much ... is this a sign that RH can't afford to run their business?
People are saying 'well, easy enough to install it from elsewhere' but surely the point is a major Linux company are no longer willing/able to support a principle business application. I'm assuming that support also included bug-fixes, packaging fixes, and such.
is this a sign that RH can't afford to run their business
I think the desktop team probably has limited resources. Many of their business customers don't use LibreOffice, but Google Docs etc. So they'd rather invest resources in parts of the ecosystem that benefits their customers, like bringing Wayland on par with macOS and Windows when it comes to HDR support, etc.
Seems like a very sensible decision to me.
People who want LibreOffice can always install the Flatpak.
I wouldn't be surprised if the reason has more to do with the number of users. I haven't used LO in some time, but back when I only used linux, I never found it to be a particularly pleasant experience. It definitely looks better now that I'm looking at it, but I switched to using google docs back at university. If RH find it to be a lot of work that is supporting very few users, then it doesn't have to say anything about their solvency. Just a spreadsheet cost calculation.
>> If RH find it to be a lot of work that is supporting very few users, then it doesn't have to say anything about their solvency. Just a spreadsheet cost calculation.
A Linux distribution is more than the sum of its parts. Having out-of-the-box ability to read MS office docs is a huge deal. Nobody wants to fuck around installing something extra to read a defacto standard document format.
Even the creator of the defacto standard document format doesn't ship the ability to read it out of the box. Neither does the other major desktop operating system vendor.
Having to install a Flatpak does not make Linux any less “out of the box” than MacOS or Windows. They are all going to require installing something.
If you are not going to buy Microsoft Office, LibreOffice may be your best bet on all platforms.
These days, if you ARE going to buy Office, it is likely to be a subscription to Office 365. If you are a subscriber, you can your documents in a web browser in Linux as well as you can on Windows. You can even use Edge.
Indeed, Windows has no out-of-the-box office productivity suite. But - at large companies, and most organizations with IT services setting up a machine for you, the default image installed for new users does have it.
For independent individual users, if we could somehow arrange it so that LO were installed by PC builders / laptop vendors - that would increase its user base from ~200M to 2 Billion within a few years. It would trounce MS Office.
“At large companies, and most organizations with IT services” you are increasingly likely to get an Office 365 subscription. If so, you can use your web browser to access all of this stuff including Outlook, OneDrive, and Teams.
If your company has standardized on Office 365 or Google Docs, the experience is pretty similar on all platforms ( Linux included ).
I use Outlook in a browser more than I launch it as an application ( even on Windows ). The same is true of Teams. To be honest, I do not use Word heavily much anymore ( but it works more than well enough to read any doc I might need on Windows ).
On Linux, I do tend to use LibreOffice to author presentations or spreadsheets rather than PowerPoint or Excel in the browser. Office 365 online would work fine for most of what I do though.
LibreOffice is more for people that DO NOT work large companies I think.
It's pretty much two or three clicks away with Flatpak and LibreOffice get to control the experience. People also install Microsoft Office or Apple Pages/Keynote/Sheets through the app store, and however Office is installed on Windows.
I get libreoffice is "bad" but the existence of alternatives online really drive home how it is not impossible to develop a modern office suite alternative to office. I honestly wish I could have a desktop tool again, I'm tired of giving the large IT corps more data they can train on.
It's possible with some love. Blender did it, it is quickly becoming an accepted tool in 3D graphics circles, if not the standard.
IMO one of the problems with the LibreOffice/OpenOffice projects is that they took on an impossible challenge, working with Microsoft’s semi-documented mess of a file format. An office suite might not be hard, but Word is made of hacks and kludges, matching them is nearly impossible.
How about we start writing actual content and stop fiddling with fonts and margins.
The amount of useful information being buried in “word” documents is mind boggling. Let’s start treating data as data and style as style. When you type your friggin notes on the meeting with the CFO we don’t need “Calibri” at 12px. This dumb shit is a nightmare to index and it’s all around stupid from just about every angle I can look at it. The amount of resources wasted on giving the illusion of a fancy typewriter is visible from space & multiple libraries of Congress.
It’s like designing websites in photoshop. Oh, wait..
sort of? Nobody uses OOXML Strict, including Microsoft themselves. Office defaults to its own dialect of OOXML Transitional, i.e. standard plus vendor extensions. This dialect also subtly differs between MSO versions.
i.e. Microsoft is still playing silly buggers with file formats, same as it ever was.
Excel has raced ahead with LET()/LAMBDA() functionality and a JavaScript api. It seems that Libreoffice Calc has stood still in comparison (although to be fair it does feel more stable and responsive).
It's not impossible but extremely difficult to make an office suite, it's also probably one of the most boring things to do. Libre office is one massive incomprehensible pile of ancient rotting c++ and java code dragged along over 38 years (staroffice). You can imagine how nobody with any sense of UI/UX or people who write for a living would ever touch it let alone dedicate their free time working on this mess. The self selected people left to work on it are very apparent in it's esthetics and everything, or lack thereof. What's left are FLOSS enthusiast's, but that doesn't make a competitive office suite.
Blender on the other hand has a massive community and dedicated leadership who pour every last bit of love and soul crafting this software, that gets significantly and noticeably better every few months.
I guess Fedora users are supposed to use flatpak from now on. Between this and the recent VAAPI controversy Fedora starts to lose some of that shine that made it appealing for me for many years:
I think you’re confusing packaging and maintaining. Red Hat helps maintain the Linux port, as in actually paying people to keep it supporting Linux, vs just packaging it and keeping the package up to date.
On the VAAPI thing, do you disagree with their legal analysis? Do you think they can ship patent-encumbered algorithms?
I think it sucks, but it would suck far more to see Fedora/Red Hat hit with legal challenges over it. It's also not usually a huge deal. This is the sort of thing that RPM Fusion has been great for many years.
Who can you call if you have a technical issue with LibreOffice? One possible answer used to be Red Hat if you had the entreprise version and a support contract.
It would be simple matter of having two software support licenses. One for operating system and one for application. This is how most software works today.
Red Hat knows if their customers are buying Red Hat license to get support for LibreOffice. I would assume this is a case only for very small number of customers, as Red Hat is mostly focusing on server product. And today companies can buy the same support from LibreOffice directly, so there is no point for Red Hat to compete against LibreOffice here. It's win win.
I don’t think you can buy support from the Document Foundation, can you?
Even then it would be vastly different than working with Red Hat/IBM. Most procurement offices probably wouldn’t be fine dealing with such a small partner.
The fact is with Oracle and Red Hat having withdrawn, no serious company nowadays supports OpenOffice/LibreOffice. This part of the market which was already mostly dead when serious online solutions arrived is now pretty much officially buried.
I don't know so I'm asking: does LibreOffice solidly support live collaborative multi-user online editing, the way Douglas Engelbart intended? If not, then good riddance.
I don't know if you are being cynical or asking a rhetorical question, but let me ask another question out of curiosity: are there any open source, privacy-respecting, non-data laundering, non-cloud-based, non-SaaS offerings which fit your requirements?
Following this, does it mean they'll reduce the price for RH subscription? Just because one can buy support elsewhere (yay OSS - BTW who offers enterprise support for LibreOffice on RHEL I'm curious?) doesn't mean one can't be salty to have support for a major part of their subscription go away with no compensation.
Current RHEL subs are still supported and will be until EOL, so nothing has been taken away. This is a change for future (yet unreleased) versions of RHEL
I don't really see the problem. I want the rock solid underpinnings of RHEL, and am ok with older kernels etc.., but I generally want updated apps like LibreOffice, Firefox etc..
To me it makes sense for those things to be Flatpak, and for you to just get them directly from the source. A Flatpak of LO maintained by LO, a flatpak of Firefox maintained by Firefox etc..
There is no problem with that. But it is just a simplified way of saying "Look! You can build your own software directly from the maintainers, but faster and much easier!"
Basically, a glorified Gentoo way. We're back to square one.
If I was using RH and paying for their workstation support, I will be quite upset they stop providing first class support for libre Office that is one of the main usage for a workstation.
Display color accuracy is a nice to have but I have hard time believing that it is what is the most important to their users.
Also, they will look fine when they will have color accuracy and HDR on their workstation and that all their applications are not able to use that or displaying with wrong theme and bad performance because of being flat pack apps...
The vast majority of the visual effects industry uses RHEL / Alma for compositing , color correction and many more aspects of the pipeline. I'd expect this userbase is more substantial than people using RHEL for libre office.
While this feels like just a delta in the scheme of things it sounds like it is a delta with the "wrong" sign.
For ages now it is clear that the Linux desktop community has lost the plot of how to move forward in the era of "cloud" and "AI" even while its value proposition, intrinsic advantages and cumulated achievement are immense. There is fragmentation, duplication, silos, and lack of interoperability among the vast array of available open source desktop apps.
And now there is AI knocking on the door. Of all the desktop apps Libreoffice is maybe the one that is exactly in the eye of the AI storm.
Its pretty obvious that cloud "productivity" suites will be increasingly integrating these algorithms and new functionalities will completely subsume and/or obsolesce old paradigms.
Libreoffice having access to local and sensitive data and a huge range of open source data science / ML libraries should have been at the forefront of integrating open source AI. Not only gaining a new lease of life for the next decade but enticing maybe many millions more users into FOSS platforms.
I don't understand the point you're making. Is it that Libreoffice should be training open source AI using my local sensitive data? Or that the future AI powered office suites won't be some sort of subscription based PWAs?
libreoffice should make use of locally running open source AI that (optionally) has been fine-tuned (by the user) to local data.
"AI" is just a proxy for a vast range of, e.g., Python or R or julia algorithms and libraries that libreoffice could already tap via extensions, scripting etc.
FWIW and like it or not, libreoffice is the best or only way to do some of the things it does.
I don’t actually use it directly as an office suite really ever. But I do use tools that use its libraries, like unoconv, or that depend on it for other things, like Nextcloud.
It’s a beast and a burden, but if you need to deal with Office documents of unknown provenance, programmatically, it’s a valuable and relevant set of tools.
Maybe I'm ignorant, but I don't see why Red Hat even should support LibreOffice. I still use LO sometimes to this day, particularly because it's offline-only, but it's hardly a paragon of software today. It hasn't meaningfully improved in a very long time, and it still looks clunky. I don't think it has much to do with the age of the software because Microsoft Office has always looked and felt nicer than LO and OO. At this point, someone just needs to be around to get it to compile for the latest operating systems. I can't imagine that interest in contributing to it has done anything but decline over the last decade.
Focusing on Wayland makes way more sense. I don't see why LO can't be considered "good enough" and allow the community to compile it and fix bugs or exploits.
I don't think it's a big deal, and them going all-in on flatpak for user-facing GUI applications makes sense to me. If the resources freed up by this go towards improvements to the base OS and DE I think that's a good thing in the long run.
Libreoffice has been a huge mess for years. It's unreliable garbage for anyone who is trying to work with documents from other people. It might be OK for composing stuff from scratch, that is until it crashes while you're in the middle of a document. I've never found it reliable under any OS. I don't understand what I'm doing wrong, or what people actually reliably use it for
I recently used Libre Office Writer for developing professional-grade documentation. we had Word installed on our remote desktops, so I opened the document in Word just to compare how it looks like.
I was horribly formatted and the fonts looked off. Then I saved the file in Word and opened it in LO Writer again. Even more issues.
And I'm sure there's zero chance that IBM will be releasing their own Linux office product- probably derived from LibreOffice, but with an additional support line item attached- in the very near future. Nope, no chance.
To clarify, is libreOffice a red hat project? Does this mean the project needs a new maintainer? Or is this saying that the red hat distro is no longer ensuring compatibility (in favor of a different product?)? If they're just dropping support from the distro, what are they replacing it with?
LO has a multi-vendor foundation, The Document Foundation. Red Hat has been a large contributor up to now, about as large a contributor as Collabora by commits. There are several other vendors and a lot of unaffiliated volunteer contributions.
The Flatpak (Flathub) version works just fine and it is what I switched to using on Fedora for a while now, so I don't see an issue here. I'd rather the core OS would get more improvements.
I find it likely that the majority of people who pay for
Red Hat Enterprise Linux are not using Libre Office?
(and thus IBM/Redhat no longer wants to maintain it.)
Does anyone know the ratio of "server" RHEL to "desktop" RHEL
subscribers?
"Yes, the equation editor for Linux is in our wish list but we don't have any specific date to share with you. I have forwarded this request again to our development team." --June 27th 2020[1]
I'll allow others to download and try out the package - nice Web page though.
LibreOffice is a noble yet doomed project that tries to fix the unfixable: the incredibly slow, highly complicated and unaesthetic StarOffice originally developed by Sun, that later reincarnated in OpenOffice. Fixing that suite is so monumentally effort intensive that you would be better off rewriting it from scratch or porting features to a simpler suite like Abiword/Gnumeric, etc.
FreeOffice is the free version of SoftMaker Office. A performant, visually pleasing office suite that is closer to the state of the art in office suites. Running it does not transform your computer into a heating system.
Unlike WPS Office, another popular and free office suite (developed in China by KingSoft), SoftMaker is developed in the west by someone I can actually sue in a non kangaroo court in the EU if something goes wrong.
Sure, it takes a while to start up, but after that my experience has been that it's as performant as Microsoft Office or Google Docs (ie. pretty much instant for everything I've done with it). Just start it once and keep it running, and you won't really have to worry about performance.
As for aesthetics, it looks fine to me... just like any other generic office app... besides which, aesthetics take a distant third place behind functionality and performance for me.
As for suing, what are you doing that you have to even consider suing someone?
That never even entered my mind for any software that I've ever used in my life.
It is extremely sluggish on all my machines (both Windows and Linux with large amount of memory and cores).
I don't mind the start up performance, it's fine.
But scrolling is sluggish, drag and dropping is painful, opening mid-sized spreadsheets takes forever, and on most of my machines even just typing have a noticeable delay.
Even Google Docs feels noticeably faster and it's running on 12 more layers of abstraction so I can't really explain why is LO so bad...
Note: Disabling Skia or hardware acceleration completely does help with performance on some computers.
WYSWYG office suites were a mistake. Combining the editing and the display compromises both. They seem destined to become giant unmaintainable monoliths. They solve problems that are fundamentally really hard but also incredibly boring, like making layout decisions on the fly. And finally they are just boring in a way that means nobody is really that interested in contributing.
Markdown, LaTeX, or HTML are much better options if fancy text is really necessary. Often it is better to just do plain text though.
Office suites cover quite a bit more use cases than LaTeX or markdown. Civil clerks worldwide use Word daily to create dense forms for people to fill out. That is a major pain in the ass to achieve with the tools you mentioned; you basically need a developer on call to create a template for you. Office suites enable almost untrained users to achieve that autonomously. Excel empowered hordes of complete laymen to do basic programming and perform database queries. I don't like office suits either, but credit where credit's due.
I guess users would still be able to install common desktop and productivity applications via flatpak or snap. Is there much value to using rpms for this at this point? I know it's a sensitive topic to some people who just don't like any change unless its on their terms. But I think the reality is that with so many linux distributions around the job of packaging up software for those is a rather tedious and thankless one. Or in the case of IBM/Red Hat also one without a lot of revenue/profit opportunities. So, I can see why IBM would want to reduce the number of packages they have to worry about.
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 that most people consume LibreOffice in the long term.
> Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.