161–170 of 316 posts
Earlier quoted context omitted.
> Do you audit every single line of code from OSS you use? I audit some of it sometimes. I trust that other do the same. Many hands make light work.
Anyone that is mildly evolved with SecDevOps knows how much of theory that happens to be in practice.
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…
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?
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'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 tha…
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 bette…
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 b…
Haa, the fabulous "yes, this is our program, we wrote it in excel because macro because we can and do not know how to do better"
if you never met it, you are lucky for being spared
Earlier quoted context omitted.
It's just not shipping by default, I don't think they're removing it from their repositories, so you can still install it if you want
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?
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.
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.
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!
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...
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..
What's the problem with that?