Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat dropping support for LibreOffice

lwn.net

Post reply on HN
Print view View original

251–260 of 316 posts

Re: Red Hat dropping support for LibreOffice

#251

Post by ghaff »

mrweasel wrote: post #235
cjmcqueen wrote: post #95

Earlier quoted context omitted.

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

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.

Re: Red Hat dropping support for LibreOffice

#252

Post by josefx »

dralley wrote: post #212
bzzzt wrote: post #91

Earlier quoted context omitted.

> 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 imagine that includes assets.

And includes none of the dependencies used.

Re: Red Hat dropping support for LibreOffice

#253

Post by ghaff »

cratermoon wrote: post #140
mrweasel wrote: post #79

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…

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…

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

Re: Red Hat dropping support for LibreOffice

#254

Post by matheusmoreira »

supportlocal4h wrote: post #124
matheusmoreira wrote: post #58

Earlier quoted context omitted.

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?

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

Re: Red Hat dropping support for LibreOffice

#255

Post by MereInterest »

torstenvl wrote: post #123
MereInterest wrote: post #105

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…

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.

Re: Red Hat dropping support for LibreOffice

#256

Post by ghaff »

eastbound wrote: post #157
ghaff wrote: post #120

Earlier quoted context omitted.

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.

> the idea of sending around point-in-time snapshots of documents feels horrifying The idea that Google has every startup’s term sheet, plans, budgets, is really strange to me. USA can so easily spy on every other country’s data. Am I the last dinosaur? Are all the other concerns dead?

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

Re: Red Hat dropping support for LibreOffice

#257

Post by phone8675309 »

thrwawy74 wrote: post #250
piaste wrote: post #225

Earlier quoted context omitted.

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

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

This sounds like a fit for NESSUS

Re: Red Hat dropping support for LibreOffice

#258

Post by Kailhus »

dang wrote: post #160
chrismorgan wrote: post #21

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…

Ok, we've changed to that from https://lwn.net/Articles/933525/ . Thanks!

You just never stop, you’re a beautiful human

Re: Red Hat dropping support for LibreOffice

#259

Post by dale_glass »

duped wrote: post #114
dale_glass wrote: post #88

Earlier quoted context omitted.

You can, the trouble is that you don't know that say, libfoo.so loads libbar.so at runtime, and so you need to also package up libbar.so. Otherwise, libbar.so won't be found in your AppImage, will get loaded from the host instead, and now it explodes but only on some distributions. In my case it was OpenSSL loading stuff at runtime.

In general a program that calls `dlopen()` must either ship with the libraries being opened (in the case of OpenSSL, which iirc only does this with libcrypto or one of its targets in some cases?) or be able to resolve them without the help of the loader via default paths. But all that said if you don't want your app to explode on different distros you always need to vendor your dependencies, including transitive depe…

Yeah, that's kinda the problem. If your dependencies are complex enough you may have a tough time figuring out when you've packaged everything.

Surprises may be lurking anywhere. It might be loading files based on something read from a config file, or concatenating tokens, so you'd have a hard time knowing you got everything for sure without reading the source for every library your application loads, and every library your direct dependencies load.

And then everything may still work until 3 distro releases later something finally becomes binary incompatible.

Re: Red Hat dropping support for LibreOffice

#260

Post by fsflover »

bandrami wrote: post #222
bandrami wrote: post #220

Earlier quoted context omitted.

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.

I'm using separate browsers in separate VMs for banking, business and personal things. And it's all with a great UX on Qubes OS.
Post reply on HN