6 ms·

What’s the load time on LibreOffice these days? Years ago on Linux it took awhile. I use Notepad and Wordpad because they load fast.

conception 3y ago
Abiword still is great.
horeszko 3y ago
I use libreoffice on linux and the load times are fine, maybe a few seconds on the splash screen. Its never been long enough that I thought it was slow
- hilbert42 3y ago
  LibO loads considerably faster on Linux than Windows but it still suffers bugs and quirks mentioned in my earlier comment.
kzrdude 3y ago
Load time is fine, less than a second.
fanatic2pope 3y ago
The flatpak version of libreoffice write loads in about a second on my 5 year old desktop.
hilbert42 3y ago
The latest version of LibO, 7.6, loads considerably faster than it used to. I now use it almost exclusively but I've MS Office 2007 still installed as there are times when I still need it. LibO's Write still has many bugs and can become incredibly slow when loading large tables (60 to 100 pages or more). To get myself out of trouble I've exported the .ODF file to .DOC and used MS Word to continue. Nothing irks me more than having to do this, I wish The Document Foundation would address this instead of adding new features. Damn it, MS Word has bugs and quirks but it's much faster and than LibO when dealing with large tables and inserted images. If LibO were fixed properly it would then be a true competitor to MSO.
- grandinj 3y ago
  95% of the patches __are__ bugfixing. New features are pretty rare. We're mostly volunteers, so people implement whatever they feel like doing :-) The essence of open-source. Come help out if you can, or sponsor some fixes with one of the LibreOffice consulting companies.
  - deleted 3y ago
    [deleted]
  - hilbert42 3y ago
    "We're mostly volunteers, so people implement whatever they feel like doing :-) The essence of open-source." I am extremely appreciative of what open-source developers do. One only has to look at the Linux ecosystem to see how much work they've contributed—and of course there's much more than just that. What you say is obvious, volunteers are unlikely do work they do not like and I'd certainly not expect them to do so. However, unfortunately, that, in my opinion, is often (but not always) the Achilles's heel of much open-source software. For example, open-source software often lacks drivers or that good drivers only arrive much later than they do for commercial software. The two mitigating reasons for this are that hardware interfaces etc. are often proprietary and the info is more likely to be released through commercial agreements leaving open-source developers to reverse engineer them which is messy and timeconsuming. But a second factor is even more important, which is that very few developers like writing drivers (I hate doing so and it's years since I've done so—so I'd not expect others to do so for free). A good illusion of this is Linux's old NTFS driver, it was a 'dog' and often corrupted files. Luckily it was fixed recently when the commercial operation Paragon donated a revamp/rewrite of their commercial NTFS code (no doubt out of vested interest, compatibility etc.). That new driver probably doesn't do much for Linux Diehards who interface with ext4, etc. (and it's likely why the old code was never properly developed), but the replacement is a godsend for mixed environments where one is trying to introduce Linux to Windows users. The problem then is how do we fill the gap between what open-source developers want to do and what users actually need? It's really a vexed problem that remains to be solved if open-source software is to become widely competitive with its commercial counterparts. For a long time my view has been that we need a middle-ground solution here. For example, large projects such as LibO should be developed under a nonprofit structure that would pay developers for their efforts. The amount developers would receive as compensation would be less than that paid by commercial interests but it'd certainly be more than a token amount. This way, only those who had a true commitment to the project would work on it and payment would also provide the incentive to get the less popular development done, thus projects wouldn't be held up. Revenue to pay developers would come from the sale of the software, which, say, for LibO could be around $20 - $30 which is only a fraction of what MS charges for MSO. Such a scheme would be criticized on grounds that the source would then have to be closed. That problem is also easily solved if the license agreement required that the source could be only be compiled on condition that the binary was only for one's own personal use—resale of the complied code would be strictly forbidden. Given its nominally low price then by far the vast majority of users would opt to buy the program already compiled. No doubt, there are many variations on such a scheme and much tweaking would take place before an optimal solution was found. Overall, with such a scheme users would be better off as development would be faster and proceed more smoothly. I can only stress again that I am in favor of open-source development and I do donate to open-source projects, also if I have to buy software then I only do so from small independent commercial developers. In fact, in recent years, I've bought no code from the Big developers except for Windows which was already installed on a machine, even then that's been strictly limited as most of my machines run Linux. What prompted my original comment about LibO was my recent bad experience, in fact it was quite horrific. It needs a separate post to provide even a reasonable outline as so many things went wrong. However, in brief, it goes thus: I'd not written long and detailed documents in either MSO or LibO for some time and by that I mean complex documents over 100 pages. LibO has been the default WP for ages but I occasionally use MSO on .doc files created by others to ensure no page format anomolies. Anyway, recently I had to produce a legal document in which some drafts were in excess of 150 pages and about 100 were in the form of a complex landscape table where some cells were split horizontally and vertically. Not only were there memory leaks, the table would take ages appear, certain operations such as deleting cells that split across pages would lock the program and it could only be killed by the task manager (this, unfortunately, was in Windows), moreover there were multiple instances of Write that had to be killed or it wouldn't reopen. Also, the LanguageTool extension (which I needed) caused Writer to cease up when certain actions were invoked, these were separate to the earlier mentioned problems which were present even if LanguageTool was disabled or not installed. Somewhere between revision 200 and 550 the file became corrupted but it was not obvious until around rev 550 when I found I couldn't delete some parts of the table. Backups didn't help as they contained the corruption from early on. I then had to cut-and-paste into a new file using plaintext to get rid of the corruption which still wasn't obvious, I thus lost almost all of my complex formatting. These problems cost me several weeks lost work, and to make matters worse I was on a court-imposed deadline that I could not alter. That's only part of the story. Moreover, I wish to hell LibO had some utility that would find corrupt parts within an .odt file and either correct them and or bring them to my attention. Finding some way to edit—or even examine—a raw indigestible and unintelligible .odt file would be extremely useful. Also, it would have been good if I could have sent the hundreds of crashes to The Document Foundation but with the sensitivity of the doc and the fact that I couldn't carefully review exactly what was to be sent back I found most annoying. That process for advising crashes isn't fit for purpose. I really do need an extended blog to fully explain what happened. I note from the changelog of ver 7.6 that one of the table code bugs has been fixed but I've yet to fully verify that, however, it still locks up when I try to correct a spelling error before the speller autocorrects it (it's so damn slow, I can beat it manually). Similarly, I also note LT has notched a single point release since my original trouble but Writer 7.6 still often fails to engage or interact with the extension, that is LT is active but no grammar or spelling correction takes place. To fix this LibO must be closed down and restarted. I don't know if this is a bug in Writer or LT, either way it's really a damn nuisance.

conception 3y ago

Abiword still is great.

horeszko 3y ago

I use libreoffice on linux and the load times are fine, maybe a few seconds on the splash screen. Its never been long enough that I thought it was slow

hilbert42 3y ago
LibO loads considerably faster on Linux than Windows but it still suffers bugs and quirks mentioned in my earlier comment.

kzrdude 3y ago

Load time is fine, less than a second.

fanatic2pope 3y ago

The flatpak version of libreoffice write loads in about a second on my 5 year old desktop.

hilbert42 3y ago

The latest version of LibO, 7.6, loads considerably faster than it used to. I now use it almost exclusively but I've MS Office 2007 still installed as there are times when I still need it. LibO's Write still has many bugs and can become incredibly slow when loading large tables (60 to 100 pages or more). To get myself out of trouble I've exported the .ODF file to .DOC and used MS Word to continue. Nothing irks me more than having to do this, I wish The Document Foundation would address this instead of adding new features. Damn it, MS Word has bugs and quirks but it's much faster and than LibO when dealing with large tables and inserted images. If LibO were fixed properly it would then be a true competitor to MSO.

grandinj 3y ago
95% of the patches __are__ bugfixing. New features are pretty rare. We're mostly volunteers, so people implement whatever they feel like doing :-) The essence of open-source. Come help out if you can, or sponsor some fixes with one of the LibreOffice consulting companies.
- deleted 3y ago
  [deleted]
- hilbert42 3y ago
  "We're mostly volunteers, so people implement whatever they feel like doing :-) The essence of open-source." I am extremely appreciative of what open-source developers do. One only has to look at the Linux ecosystem to see how much work they've contributed—and of course there's much more than just that. What you say is obvious, volunteers are unlikely do work they do not like and I'd certainly not expect them to do so. However, unfortunately, that, in my opinion, is often (but not always) the Achilles's heel of much open-source software. For example, open-source software often lacks drivers or that good drivers only arrive much later than they do for commercial software. The two mitigating reasons for this are that hardware interfaces etc. are often proprietary and the info is more likely to be released through commercial agreements leaving open-source developers to reverse engineer them which is messy and timeconsuming. But a second factor is even more important, which is that very few developers like writing drivers (I hate doing so and it's years since I've done so—so I'd not expect others to do so for free). A good illusion of this is Linux's old NTFS driver, it was a 'dog' and often corrupted files. Luckily it was fixed recently when the commercial operation Paragon donated a revamp/rewrite of their commercial NTFS code (no doubt out of vested interest, compatibility etc.). That new driver probably doesn't do much for Linux Diehards who interface with ext4, etc. (and it's likely why the old code was never properly developed), but the replacement is a godsend for mixed environments where one is trying to introduce Linux to Windows users. The problem then is how do we fill the gap between what open-source developers want to do and what users actually need? It's really a vexed problem that remains to be solved if open-source software is to become widely competitive with its commercial counterparts. For a long time my view has been that we need a middle-ground solution here. For example, large projects such as LibO should be developed under a nonprofit structure that would pay developers for their efforts. The amount developers would receive as compensation would be less than that paid by commercial interests but it'd certainly be more than a token amount. This way, only those who had a true commitment to the project would work on it and payment would also provide the incentive to get the less popular development done, thus projects wouldn't be held up. Revenue to pay developers would come from the sale of the software, which, say, for LibO could be around $20 - $30 which is only a fraction of what MS charges for MSO. Such a scheme would be criticized on grounds that the source would then have to be closed. That problem is also easily solved if the license agreement required that the source could be only be compiled on condition that the binary was only for one's own personal use—resale of the complied code would be strictly forbidden. Given its nominally low price then by far the vast majority of users would opt to buy the program already compiled. No doubt, there are many variations on such a scheme and much tweaking would take place before an optimal solution was found. Overall, with such a scheme users would be better off as development would be faster and proceed more smoothly. I can only stress again that I am in favor of open-source development and I do donate to open-source projects, also if I have to buy software then I only do so from small independent commercial developers. In fact, in recent years, I've bought no code from the Big developers except for Windows which was already installed on a machine, even then that's been strictly limited as most of my machines run Linux. What prompted my original comment about LibO was my recent bad experience, in fact it was quite horrific. It needs a separate post to provide even a reasonable outline as so many things went wrong. However, in brief, it goes thus: I'd not written long and detailed documents in either MSO or LibO for some time and by that I mean complex documents over 100 pages. LibO has been the default WP for ages but I occasionally use MSO on .doc files created by others to ensure no page format anomolies. Anyway, recently I had to produce a legal document in which some drafts were in excess of 150 pages and about 100 were in the form of a complex landscape table where some cells were split horizontally and vertically. Not only were there memory leaks, the table would take ages appear, certain operations such as deleting cells that split across pages would lock the program and it could only be killed by the task manager (this, unfortunately, was in Windows), moreover there were multiple instances of Write that had to be killed or it wouldn't reopen. Also, the LanguageTool extension (which I needed) caused Writer to cease up when certain actions were invoked, these were separate to the earlier mentioned problems which were present even if LanguageTool was disabled or not installed. Somewhere between revision 200 and 550 the file became corrupted but it was not obvious until around rev 550 when I found I couldn't delete some parts of the table. Backups didn't help as they contained the corruption from early on. I then had to cut-and-paste into a new file using plaintext to get rid of the corruption which still wasn't obvious, I thus lost almost all of my complex formatting. These problems cost me several weeks lost work, and to make matters worse I was on a court-imposed deadline that I could not alter. That's only part of the story. Moreover, I wish to hell LibO had some utility that would find corrupt parts within an .odt file and either correct them and or bring them to my attention. Finding some way to edit—or even examine—a raw indigestible and unintelligible .odt file would be extremely useful. Also, it would have been good if I could have sent the hundreds of crashes to The Document Foundation but with the sensitivity of the doc and the fact that I couldn't carefully review exactly what was to be sent back I found most annoying. That process for advising crashes isn't fit for purpose. I really do need an extended blog to fully explain what happened. I note from the changelog of ver 7.6 that one of the table code bugs has been fixed but I've yet to fully verify that, however, it still locks up when I try to correct a spelling error before the speller autocorrects it (it's so damn slow, I can beat it manually). Similarly, I also note LT has notched a single point release since my original trouble but Writer 7.6 still often fails to engage or interact with the extension, that is LT is active but no grammar or spelling correction takes place. To fix this LibO must be closed down and restarted. I don't know if this is a bug in Writer or LT, either way it's really a damn nuisance.