Live data from Hacker News

Red Hat dropping support for LibreOffice

lwn.net

231–240 of 316 posts

Re: Red Hat dropping support for LibreOffice

#231

Earlier quoted context omitted.

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…

> 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 softw…

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 ^^

Re: Red Hat dropping support for LibreOffice

#233
post #3

I think most commenters on lwn are misunderstanding this gravely. RHEL not supporting LibreOffice doesn't mean you can still install it, right? It just means RH won't offer support for it? Also does not mean you must use Flatpak to use it, does it? Am I missing something? If it does make sense business-wise, it's their call. I'm pretty sure they know their userbase and did the math. I also prefer efforts put on Wayla…

> If it does not make sense business-wise, it's their call. I'm pretty sure they know their userbase and did the math. This assumes companies don't make mistakes. They do. A lot. And if users aren't allowed to voice concern then they will make many more mistakes.

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.

Re: Red Hat dropping support for LibreOffice

#234

Earlier quoted context omitted.

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.

Flatpaks unlike Snaps are actually sandboxed properly.

Full or no filesystem access is very, very far from proper sandboxing.

Re: Red Hat dropping support for LibreOffice

#235

Earlier quoted context omitted.

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…

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?

Re: Red Hat dropping support for LibreOffice

#236
post #201

Earlier quoted context omitted.

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 s…

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 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.

Re: Red Hat dropping support for LibreOffice

#237
post #234

Earlier quoted context omitted.

Flatpaks unlike Snaps are actually sandboxed properly.

Full or no filesystem access is very, very far from proper sandboxing.

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.

Re: Red Hat dropping support for LibreOffice

#238
post #225

Earlier quoted context omitted.

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.

What do you mean by "monitoring security spaces"? Are you frequently refreshing the bug boards of every library your applications and OS uses?

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.

Re: Red Hat dropping support for LibreOffice

#239
post #227
post #62

Earlier quoted context omitted.

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.

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 relevan…

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 just replaced X=flatpak with nix.

Re: Red Hat dropping support for LibreOffice

#240

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.

"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?

Post reply on HN