[HN Gopher] Red Hat dropping support for LibreOffice
___________________________________________________________________
Red Hat dropping support for LibreOffice
Author : 5e92cb50239222b
Score : 333 points
Date : 2023-06-03 08:30 UTC (14 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| greatgib wrote:
| 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...
| GlacierFox wrote:
| 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.
| wheelerof4te wrote:
| How about this?
|
| RH will provide just the bare minimum of base OS and a bunch of
| devel-libraries to enable users who want to build their own
| software!
|
| It would be more in line with the intended audience, at least.
| bipson wrote:
| 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 Wayland improvements, much closer to
| the OS itself and relevant to several use cases.
| psychphysic wrote:
| > 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.
| creatonez wrote:
| > 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)
| pmoriarty wrote:
| So there was some kind of referendum of RedHat users that
| asked them what features of the Linux operating system they
| wanted systemd to absorb?
| einpoklum wrote:
| > They are extremely loyal to their user base.
|
| Are you sure it's not the other way around? :-(
| creatonez wrote:
| 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.
| supportlocal4h wrote:
| 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.
| jzb wrote:
| 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.
| bipson wrote:
| No, it doesn't.
|
| Something "making sense" does not mean mistakes are not
| possible.
|
| Assuming only idiots make mistakes is rather black-and-white.
| rc_mob wrote:
| then its a badly written headline
| kbumsik wrote:
| Well I think it still is a correct headline.
|
| In a linux distro, when it "support" a package means that you
| can contact its maintainers for help (bugs and etc) on the
| package.
|
| So the headline means that RHEL won't help you to install
| LibreOffice. There are always other way to install it though.
| dizhn wrote:
| 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)
| steve1977 wrote:
| It does mean that it won't be in RHEL's package repositories
| anymore, as far as I understand.
| [deleted]
| pbhjpbhj wrote:
| 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-fixes, packaging
| fixes, and such.
| blihp wrote:
| > is this a sign that RH can't afford to run their business?
|
| Afford has nothing to do with it... IBM will continue
| tightening things up with/at RH to get their ROI.
| [deleted]
| danieldk wrote:
| _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.
| davidgerard wrote:
| They're one of the larger contributors in number of commits,
| about equal to Collabora.
| [deleted]
| inefficient wrote:
| 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.
| LeFantome wrote:
| Frankly, LibreOffice is amazing these days.
| phkahler wrote:
| >> 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.
| LeFantome wrote:
| 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.
| einpoklum wrote:
| 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.
| LeFantome wrote:
| "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.
| danieldk wrote:
| 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.
| tssva wrote:
| 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.
| glowingly wrote:
| Wordpad has read docx files for a while now.
|
| edit: I just checked my Win11 VM, and Wordpad is included
| by default. It also reads and writes docx and odt.
| tssva wrote:
| WordPad only supports limited capabilities of the docx
| format.
| barbariangrunge wrote:
| 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?
| davidgerard wrote:
| 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.
| FeistySkink wrote:
| 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.
| ekianjo wrote:
| Flathub is a single point of failure and flatpaks can also have
| security issues that go unfixed. Its not some kind of miracle
| from God or something
| awill wrote:
| 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..
|
| What's the problem with that?
| wheelerof4te wrote:
| 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.
| awill wrote:
| It's not really building anything. You would just download a
| few apps from flathub.org
| wheelerof4te wrote:
| I know, I was just being hyperbolic.
| hannob wrote:
| 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?
| steve1977 wrote:
| 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.
|
| https://access.redhat.com/discussions/3772571
| psychphysic wrote:
| They are pivoting the work they do for workstations away from
| applications to HDR etc.
|
| That 'for' doesn't mean they are pivoting to Workstations.
|
| Guess it's a bit ambiguous, but anyways so libre office won't
| be a package on RHEL that's no big issue so long as the RPM and
| flatpak work fine.
| ekianjo wrote:
| HDR sounds like a nice excuse rather than a genuine reason...
| George83728 wrote:
| 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.
| pbhjpbhj wrote:
| >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.
| pjmlp wrote:
| Red-Hat has officially given up on the Linux Desktop about 15
| years ago.
|
| There are enough places to read that announcement and related
| reactions.
| creatonez wrote:
| Red Hat has not given up on desktop Linux. Not in the
| slightest.
| pjmlp wrote:
| Greetings from 2008,
|
| https://www.slashdot.org/story/100116
| creatonez wrote:
| 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.
| pjmlp wrote:
| Where is the desktop product?
|
| https://www.redhat.com/en/technologies/all-products
|
| I see cloud, OpenShift, SAP, embedded, servers, desktop
| not really.
| creatonez wrote:
| 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.
|
| https://www.redhat.com/en/technologies/linux-
| platforms/enter...
|
| https://www.redhat.com/en/products/edge
|
| https://redhat-connect.gitbook.io/partner-guide-for-red-
| hat-...
|
| (Not a Red Hat project) https://ublue.it/
|
| https://catalog.redhat.com/software/containers/rhel9/inks
| cap...
| pjmlp wrote:
| CERN researchers mostly use Windows and macOS, even if
| the LHC cluster is powered by Linux.
|
| Back in 2003 - 2004, I was one of the few in my group,
| ATLAS/TDAQ, that bothered to have a laptop with
| Scientific Linux, and I doubt it has changed.
|
| All of those projects are a by product that Red-Hat
| Enterprise Linux also needs a graphical user interface,
| not a desktop product on its own.
| rowanG077 wrote:
| 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.
| dralley wrote:
| 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
| pjmlp wrote:
| To the extent required by Red-Hat Enterprise _paying_
| customers.
|
| If anything, it shows how much everyone still cares.
|
| Greetings from 2008 Slashdot,
|
| https://www.slashdot.org/story/100116
| asmor wrote:
| _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.
| pjmlp wrote:
| The shopping mall down the street certainly has Windows
| Home DVDs, as does Microsoft online store.
|
| Try to find value added _enterprise_ desktop.
|
| https://www.redhat.com/en/technologies/all-products
| asmor wrote:
| 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.
| rurban wrote:
| They do control the desktop. Nobody else is close to them
| pk-protect-ai wrote:
| LibreOffice comes with its own support these days... RPMs are
| provided out of the box too. So it makes sense.
| WastingMyTime89 wrote:
| That's not what support means.
|
| 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.
| miohtama wrote:
| 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.
| touisteur wrote:
| 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.
| freedomben wrote:
| 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
| WastingMyTime89 wrote:
| 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.
| godzillabrennus wrote:
| It's telling how good the browser based productivity
| suites are if Redhat customers aren't relying on
| LinreOffice anymore.
| DonHopkins wrote:
| 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.
| acka wrote:
| 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?
| wheelerof4te wrote:
| That is actually a very good point.
| bee_rider wrote:
| 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.
| mr_mitm wrote:
| 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.
| JackSlateur wrote:
| And that hordes of laymen, empowered by excel, flowed the
| world like a plague
|
| 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
| wheelerof4te wrote:
| I worked with a Office layman who couldn't (and did not
| care to learn how to) open RAR files.
|
| Yeah.
| bee_rider wrote:
| I think spreadsheets are great, I hadn't thought to include
| them in with office suites, I mostly use GNUmeric.
| chrismorgan wrote:
| 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 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._
| gigatexal wrote:
| Why don't the libreoffice devs package a flatpak as a first
| party thing?
| dang wrote:
| Ok, we've changed to that from
| https://lwn.net/Articles/933525/. Thanks!
| Kailhus wrote:
| You just never stop, you're a beautiful human
| tlamponi wrote:
| 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?
| bonzini wrote:
| 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.
| tlamponi wrote:
| > Fedora has a Flatpak repository that is separate from
| FlatHub.
|
| Yeah, it sounded a bit like this, but with all those
| comments here and LWN I started to get confused myself.
|
| And I definitively could have just looked it up so
| appreciate it all the more that you cleared it up to me,
| many thanks!
| chrismorgan wrote:
| 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".
| tlamponi wrote:
| Yes indeed, seems like I got a bit confused myself here,
| thanks!
| Gigachad wrote:
| 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.
| bandrami wrote:
| 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.
| dralley wrote:
| Flatpaks unlike Snaps are actually sandboxed properly.
| seabass-labrax wrote:
| 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.
| lvass wrote:
| Full or no filesystem access is very, very far from
| proper sandboxing.
| nerdponx wrote:
| 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.
| bandrami wrote:
| 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.
| bandrami wrote:
| 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.
| fsflover wrote:
| 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.
| piaste wrote:
| What do you mean by "monitoring security spaces"? Are you
| frequently refreshing the bug boards of every library your
| applications and OS uses?
| rowanG077 wrote:
| 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.
| nikodunk wrote:
| We do not :)
| Teknoman117 wrote:
| I would definitely like to say I do but I definitely do
| not.
| thrwawy74 wrote:
| 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?
| phone8675309 wrote:
| This sounds like a fit for NESSUS
| ho_schi wrote:
| 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?
| ilyt wrote:
| > 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.
| George83728 wrote:
| > _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.
| ho_schi wrote:
| 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 ^^
| jzb wrote:
| "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.
| wheelerof4te wrote:
| "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?
| Gigachad wrote:
| It isn't that hard, that's exactly what flatpak is doing.
| wheelerof4te wrote:
| Flatpak requires runtimes, not libraries. Most devel
| libraries don't take up GBs of disk space as Flatpak
| runtimes do.
|
| Also, Flatpak apps are containerized. That usually means
| they aren't bare metal.
| creatonez wrote:
| > 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.
| Conan_Kudo wrote:
| New maintainers picked up LibreOffice, so that will still
| happen, since LibreOffice wasn't retired from Fedora.
| ekianjo wrote:
| Works everywhere is a stretch. Flatpaked applications have
| multiple issues
| qbasic_forever wrote:
| Bespoke RPMs that have to be patched and modified for
| distros by a small group of maintainers have issues too.
| bbarnett wrote:
| Redhat is just falling.
|
| It was a pain doing packages 25 years ago, comparatively
| it is _simple_ now.
|
| Frankly, the flatpak will have issues as well, but those
| will be outside of Redhat's direct control.
|
| Which means the end game, will be a redhat flatpak.
| contrarian1234 wrote:
| You're talking about AppImages right?
|
| 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
| dale_glass wrote:
| 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.
| MereInterest wrote:
| 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.
| torstenvl wrote:
| 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.
| MereInterest wrote:
| 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.
| kpw94 wrote:
| > 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.
| ZiiS wrote:
| 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.
| ilyt wrote:
| > 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"
| duped wrote:
| 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?
| dale_glass wrote:
| 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.
| duped wrote:
| 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.
| dale_glass wrote:
| 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.
| Laaas wrote:
| Flatpak is quite simple under the hood, it's just a wrapper
| around bubblewrap [0]. I'm not sure what you mean with
| integrating it with a CMake build.
|
| [0]: https://github.com/containers/bubblewrap
| xvilka wrote:
| Time to ditch Fedora and migrate to Arch, I guess.
| jrm4 wrote:
| On one hand, this is awfully clickbaity, it would be more fair to
| highlight the Wayland work.
|
| On the other; Wayland work? Also not impressive to flex stuff
| that should have worked a decade ago.
| davidgerard wrote:
| Caolan McNamara was one of the largest LO contributors at Red
| Hat, he's now moved to Collabora to keep doing the same stuff.
| https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html
| quink wrote:
| Flatpaks continue to horrify me because of fundamental stuff like
| this that keeps getting completely ignored:
| https://github.com/flathub/org.libreoffice.LibreOffice/issue...
|
| 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.
|
| Linux Desktop is a parody of itself.
| schmorptron wrote:
| 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.
| nologic01 wrote:
| 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.
| nazgulsenpai wrote:
| 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?
| nologic01 wrote:
| 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.
| wmf wrote:
| Related blog post that's worth reading:
| https://news.ycombinator.com/item?id=36175655
| jillesvangurp wrote:
| 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.
| ThinkBeat wrote:
| 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?
| ac2023 wrote:
| Hardly related as this is more server-side, but it seems CentOS
| is getting a lot of traction with cloud companies these days.
|
| Microsoft also apparently going large scale with CentOS-based
| Azure Linux.
|
| The question is: What is the best solution going forward for
| desktop productivity software on Linux?
| chriscappuccio wrote:
| 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
| wheelerof4te wrote:
| 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.
| 29athrowaway wrote:
| FreeOffice is a superior alternative. Just not open source.
| louky wrote:
| Thanks for that, I've haven't looked beyond Libre in years.
| Trying it out on Debian11 now.
| 29athrowaway wrote:
| Make sure to enable the HiDPI mode which is not the default
| for some reason.
| pmoriarty wrote:
| In what ways it it superior?
| 29athrowaway wrote:
| 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.
| pmoriarty wrote:
| Is LibreOffice really that slow?
|
| 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.
| 29athrowaway wrote:
| In modern hardware you may not perceive the difference
| but in older hardware the difference is more noticeable.
| 2b3a51 wrote:
| _" 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.
|
| [1] https://forum.softmaker.com/viewtopic.php?f=389&t=20201
| thesuperbigfrog wrote:
| 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://access.redhat.com/documentation/en-us/red_hat_enterp...
|
| 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.
| ezst wrote:
| 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.
| oneshtein wrote:
| 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.
| kaba0 wrote:
| 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.
| jzb wrote:
| 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.
| kaba0 wrote:
| 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.
| pmoriarty wrote:
| Agreed, though I'd much rather see this done with Guix.
| jahewson wrote:
| Nix is great conceptually but after 20 years of boiling the
| ocean, I would call the experience difficult and erratic, not
| "splendid".
| aseipp wrote:
| 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.
| whateveracct wrote:
| 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!
| oneshtein wrote:
| It's easier to run LibreOffice using Wine than Flatpak.
| bbarnett wrote:
| _It lets them focus on more enterprise-y features and improve
| overall security._
|
| Such a minor amount of work saved, if any, and it's all for
| cost savings, with a reduced user experience.
|
| Yup. Redhat as IBM.
|
| Modern IBM has fallen so far, and could never, ever create or
| originate something like redhat.
|
| So buy it, they did, and now legions of managers preen, and
| describe how to "improve" redhat, each cutting, shaving cost,
| impressed with themselves.
|
| And don't believe the "hands off" junk, they still have purse
| string control.
| criddell wrote:
| 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.
| bonzini wrote:
| > 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.
| redprince wrote:
| > 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.
| bzzzt wrote:
| > 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.
| redprince wrote:
| > Compressed source code archive is over 300Mb.
|
| Much of it not interesting security wise.
|
| > That's not a manageable amount for one individual, so I
| wouldn't expect it to be systemetically reviewed.
|
| I settle for people thinking like attackers and going for
| the attack surfaces.
| dralley wrote:
| I imagine that includes assets.
| josefx wrote:
| And includes none of the dependencies used.
| [deleted]
| rajamaka wrote:
| I always find this take so weird. Do you audit every single
| line of code from OSS you use?
| matheusmoreira wrote:
| 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.
| supportlocal4h wrote:
| 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?
| matheusmoreira wrote:
| > 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.
| oneshtein wrote:
| So only people capable of auditing source code and build
| scripts are able to be maintainers of opensource packages
| for others.
| supportlocal4h wrote:
| 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?
| redprince wrote:
| > 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.
| pjmlp wrote:
| Anyone that is mildly evolved with SecDevOps knows how
| much of theory that happens to be in practice.
| htag wrote:
| 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.
| pjmlp wrote:
| Pentesting is also part of it.
| danieldk wrote:
| _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.
| redprince wrote:
| > 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.
| kaba0 wrote:
| You don't need malicious app to cause harm without a
| sandbox. Malicious _data_ with a bug is enough.
|
| Sandboxes should be the must in this century and mobile OSs
| are much more ahead here.
| blablabla123 wrote:
| 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.
| hulitu wrote:
| > If I install LibreOffice, I want to be asked for permission
| before it tries to access my microphone or location or other
| sensitive resources.
|
| Why would LibreOffice need access to microfone or location ?
| Asking for a friend.
| bombcar wrote:
| PowerPoint let's you record audio and video for slide
| presentations- I could see libreoffice having something
| similar.
| jolux wrote:
| It shouldn't, that's the point.
| hakfoo wrote:
| 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.
| bonzini wrote:
| > 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.
| clever-leap wrote:
| LibreOffice is such a bloatware that I migrated to SoftMaker
| office two years ago and never looked back.
| shp0ngle wrote:
| People mention Google Docs a lot in this thread.
|
| 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
|
| https://www.libreoffice.org/download/libreoffice-online/
| nr11_bullseye wrote:
| 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.
| ape4 wrote:
| Maybe this is a way of Red Hat promoting Flatpak?
| tkuraku wrote:
| I usually uninstall libreoffice and install the up to date
| flatpak anyway. This seems like the smart thing to do.
| wheelerof4te wrote:
| LO in fedora is usually up-to-date version.
|
| I don't know the situation with RHEL.
| trop wrote:
| 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.
|
| [0]: https://lwn.net/ml/fedora-
| devel/20230601183054.12057.45907@m... [1]:
| https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
| pmoriarty wrote:
| What's more important for most users, document editing or
| image/video editing?
| GlacierFox wrote:
| 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.
| joao_lopes wrote:
| 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).
| dmix wrote:
| 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?
| jdiff wrote:
| 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.
| COGlory wrote:
| 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.
| somenewaccount1 wrote:
| In 2023? I would argue image/video editing for sure.
| raverbashing wrote:
| 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
| dralley wrote:
| 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.
| supportlocal4h wrote:
| 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.
| dralley wrote:
| Nobody is getting rid of LibreOffice, it's only a
| question of whether it is supported directly by Red Hat
| as part of the base install and repos.
| mrweasel wrote:
| 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.
| martinpw wrote:
| 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.
| cripblip wrote:
| Could you expand on the Google docs comment?
| cjmcqueen wrote:
| 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?
| cripblip wrote:
| +1 the collaboration features of Google docs are so good,
| does not have feature parity with say MS Word, but I have
| not missed local apps
| mrweasel wrote:
| 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?
| ghaff wrote:
| 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.
| jahewson wrote:
| Line wrapping is often different between different
| browsers, so things end up on different pages for
| different users.
| cratermoon wrote:
| 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.
| ghaff wrote:
| >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.
| trop wrote:
| 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.
| pengaru wrote:
| What's more important for RH's _paying_ _customers_?
| Apparently their movie industry contracts are the ones
| keeping the lights on for the desktop group...
| mumblemumble wrote:
| 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.
| ajross wrote:
| 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.
| ghaff wrote:
| 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.
| eastbound wrote:
| > 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?
| lstodd wrote:
| No, you are not. This is truely strange.
|
| I can understand giving away grocery lists to the world,
| but not this.
| jahewson wrote:
| I mean, at Google scale the investors in global capital
| all know each other and invest in each other's funds
| anyway.
| ghaff wrote:
| 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).
| Tagbert wrote:
| 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.
| twangist wrote:
| 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.
| lyu07282 wrote:
| 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
| water-your-self wrote:
| Cool which one of those is libre?
| htag wrote:
| 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.
| seabass-labrax wrote:
| 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!
| makeitdouble wrote:
| 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.
| galkk wrote:
| 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
| packetlost wrote:
| 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
| loeg wrote:
| 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?
| packetlost wrote:
| The LibreOffice project themselves package up .rpms for
| their project and distribute them.
| UncleEntity wrote:
| The volunteers who maintain thousands of other packages?
| jahewson wrote:
| Gamers want HDR too.
| pnpnp wrote:
| My vote would be replacing the dumpster fire that X currently
| is. Everyone would benefit from that.
| einpoklum wrote:
| 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.
| 5e92cb50239222b wrote:
| 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:
|
| https://www.phoronix.com/news/Fedora-Disable-Bad-VA-API
|
| I wonder why way smaller distributions are fine with maintaining
| LibreOffice, but Red Hat supposedly doesn't have enough resources
| to keep it going.
| PlutoIsAPlanet wrote:
| 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.
| freedomben wrote:
| 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.
| dralley wrote:
| SUSE also followed suit with VAAPI, so apparently their legal
| team doesn't disagree.
| ravenstine wrote:
| 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.
| noobermin wrote:
| 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.
| einpoklum wrote:
| It's the exact opposite of what you describe:
|
| * LibreOffice is "good", not "bad". Writer is really good, Calc
| is pretty good, Impress is meh/not-so-good, Draw is ok, Base I
| haven't used.
|
| * There is no alternative online to office productivity suites.
| What you might think of as alternatives only offer some of the
| functionality.
|
| * bugs.documentfoundation.org - if something bugs you, file it
| :-)
| lyu07282 wrote:
| 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.
| pmoriarty wrote:
| How is Libre Office bad exactly?
|
| It has always seemed like an excellent alternative to Microsoft
| Office to me.
|
| What don't you like about it?
| kwhitefoot wrote:
| Writing macros or whatever they are called is painful.
|
| Writing an application or macro in VBA is much simpler.
| gmiller123456 wrote:
| What makes it bad?
| bee_rider wrote:
| 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.
| SanderNL wrote:
| 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..
|
| I'll let myself out.
| jahewson wrote:
| > 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.
| davidgerard wrote:
| 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.
| boredemployee wrote:
| [flagged]
| tompandolfi wrote:
| was this written by chatGPT ?
| [deleted]
| sysstemlord wrote:
| Yes, and with a bad prompt also. It misses the point as if
| it's not possible to run Libre Office on RedHat anymore.
| tentacleuno wrote:
| Thanks for being honest.
| sysstemlord wrote:
| You're welcome but it makes me think that you think I'm
| the one who wrote it
| jmbwell wrote:
| 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.
___________________________________________________________________
(page generated 2023-06-03 23:00 UTC)