Live data from Hacker News

Red Hat dropping support for LibreOffice

lwn.net

221–230 of 316 posts

Re: Red Hat dropping support for LibreOffice

#221

Earlier quoted context omitted.

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.

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…

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

Re: Red Hat dropping support for LibreOffice

#222

Earlier quoted context omitted.

Flatpaks unlike Snaps are actually sandboxed properly.

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.

Re: Red Hat dropping support for LibreOffice

#223

Earlier quoted context omitted.

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

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

> And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected.

Bugs discovered in older version of libraries are far more common than newly introduced ones.

Also, distros usually keep to whatever release line is deemed "stable" vs "whatever appimage author decide to put there"

Re: Red Hat dropping support for LibreOffice

#224

Earlier quoted context omitted.

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.

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

Re: Red Hat dropping support for LibreOffice

#225

Earlier quoted context omitted.

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.

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

Re: Red Hat dropping support for LibreOffice

#226

Earlier quoted context omitted.

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.

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…

“How often does Canonical need to fail with Mir, Unity, Upstart and now Snap?”

Until it gets different leadership. The drive to try to keep creating moats around Ubuntu that only benefit Canonical comes from the top.

Re: Red Hat dropping support for LibreOffice

#227
post #62

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…

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 relevant to this conversation.

Re: Red Hat dropping support for LibreOffice

#228

Earlier quoted context omitted.

How do the online suites handle word documents? 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.

> Word is made of hacks and kludges, matching them is nearly impossible. The newer OOXML formats are fine. They’re only hard to implement because the feature set of word is gigantic. PDF is much worse.

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.

Re: Red Hat dropping support for LibreOffice

#229

How much have RH been contributing to LO? 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-fix…

They're one of the larger contributors in number of commits, about equal to Collabora.

[deleted]

Re: Red Hat dropping support for LibreOffice

#230

Dumb questions: 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.
Post reply on HN