Re: Just upgraded on my work laptop OpenSUSE 12.2
No but Microsoft not being able to produce compliant ODF files is.
The Document Foundation has announced LibreOffice 4.0, the latest version of the free software competitor to Microsoft Office that spun off from the OpenOffice.org effort in 2010, describing it as nothing less than "the free office suite the community has been dreaming of since 2001." "LibreOffice 4.0 is the first release that …
No but Microsoft not being able to produce compliant ODF files is.
For most of our users, Outlook is the key component of Office. Word and Excel are important of course, but many of our users spend 50% of their day using web-based in-house apps, 10% on Excel+Word, and 40% in Outlook - and they don't like web-based Outlook / OWA. So to them, Outlook is the most important component, something LibreOffice seems to completely ignore.
We would love to break free from the MS Office stranglehold, but can't due to Outlook (with Exchange).
I use OWA in preference and so do several of my colleagues because actual Outlook (2010) takes about 5 minutes from startup to become usable (i.e. you can actually click on something and it responds) and frequently slows down throughout the day. Might just be our setup but it's a dog. If we didn't use the group calendaring functions it would be completely pointless and any old mail client would do anyway. OWA 2010 is actually reasonable, and a lot quicker (for us) than the fat client.
It Outlook takes 5min to start up, the problem is your sysadmins. I work remotely on a VM and it takes ~2s - and this isn't a tiny setup either, it's been ongoing for 10+ years so the dataset on the server must be pretty horrific!
Outlook (2010) takes about 5 minutes from startup to become usable
I am willing to bet you have data stored on network drives. Outlook seems to be extremely inefficient with file access, and by using a network mounted drive for storage you *seriously* multiply that problem.
If we didn't use the group calendaring functions it would be completely pointless
There are other ways to give you corporate group calendaring which would free you from the clutches of Microsoft (and, as a consequence, enable email and shared calendaring on any electronic device you care to use), but even sticking with Exchange you guys *really* need to stop using network drives for a local cache - it's the only thing that can explain this. Outlook may suck, but it doesn't suck *that* much :)
The reason OWA works quicker is because you then have all the file access done on the Exchange server (i.e. local to the software doing the work), with OWA only giving you an interface to it. That is also why a VM desktop works quicker: the files stay local, you only export the display.
How the heck do you get it to open up embedded visio files using visio? Currently clicking on a visio just brings it up as a picture instead of the embedded object it really is...
we use embedded visios and Jude diagrams a lot in our software documentation...
Works just fine with Word & Visio 2007 installed.
However, you need to check how the Visio objects are being copied and pasted into your document.
For technical documentation that is to be released to third-parties, I've tended to paste 'esoteric' objects such as Visio and Organisation Charts as pictures so that I can be sure others can read what I intended, it also helps to reduce the size of the Word document being sent to all and sundry (I complain when others email me a large file and I'm in a hotel room with only a dial-up connection...).
Do you know what would happen if I suggested some of our customers switched to LO from MO? They'd look puzzled and ask why. I'd tell them the cost benefits. They'd say that they have to retrain users. Business fears change and some of them would rather piss away money on Microsoft's evil licencing than make a change for the better...
Nobody ever got fired for buying Microsoft Office... :-(
Please define better? And also list your credentials as a UX expert.
You can't really list "open source" as a reason it's better, because that opens up the whole argument if OSS is better. To the average user it makes not an iota of difference.
"LibreOffice 4.0 also supports importing Microsoft Publisher documents for the first time"
^^ That'll help - Publisher has been the fly in the ointment because nothing supported it.
A long while back (decades) when PagePlus was a baby in v1 or 2 guise, Serif tried to cross-license the necessary formats to work with Publisher files. MS took the line that they would wipe the floor with PP, which at the time was a bold move as they were basically nowhere in the home market in particular. PagePlus still kicks Publisher around the park for anything more than making posters or cards.
However, because MS made early versions of Word so poor at handling graphics, to the point where adding a 5th or 6th picture would throw everything off the page, and then bundling Publisher with Office (or at least only a couple of quid per PC to add it to a volume licence fee) they weened a lot of folk into the Publisher cul-de-sac. Gradually newer versions of Publisher started to export to other formats, which meant limited cross-over working could be used, but inertia took hold ;-)
Schools have been getting used to using other MS products though, like Outlook, Sharepoint and Exchange (many LEA-provided VLEs are Sharepoint-based) - MS is good at levering the whole suite in on the back of dependencies like that. We tried Zimbra for email for a while (3 years), but went back to Exchange because it was less of a hassle in the end.
It'll need a determined effort to move away from so many hooks such as Office has, but this will definitely be helped by the ability to move away from Publisher without binning loads of work, or keeping odd copies of Publisher hanging around (which defeats the object of moving away from Office really).
"You can't really list "open source" as a reason it's better, because that opens up the whole argument if OSS is better. To the average user it makes not an iota of difference."
It's a flaw in his and others' logic. In my view it's undeniable that open source is a better development process. Where some people trip over is confusing the open source process and open source software. You can't say as an absolute that open source software is better per se because there's no guarantee that's the case. It should lead to better software but that should be evaluated on a per-package basis, rather than assuming being open source is a requirement for quality and that closed source can't be good.
It all comes down to cost versus experience. All things being equal, ie both free, I'd use Microsoft office as its the slicker experience in my view.
If I had to pay full price for ms office as a personal user, I'd use libre office without batting an eyelid. As it currently stands, I am lucky enough to work for a company with a hup licence, so got ms office professional plus 2010 & 2013 for £8.95 each. For that sum, ms office wins out easily!
I don't think schools pay very much for ms office licences, so I can't blame them for taking the same choice that I have.
And also list your credentials as a UX expert.
"Schools should be using LibreOffice " - if they want their pupils no have no experience with what is actually used in the real world.
LibreOffice might be free to buy - but it will cost you in support, functionality, compatibility, and user training - which is a much larger percentage of TCO than the licensing fee.
How do you define "better". For instance recent Microsoft code has a much lower known security vulnerability count over time that the average for Open Source code per line written.
it will cost you in support, functionality, compatibility, and user training - which is a much larger percentage of TCO than the licensing fee.
Yeah, right. This is where facts differ from fiction, provided you look long term.
support costs: you have ONE product to support, and one version which remains consistent in functions and file formats throughout its life span. This mean lower support costs, also because you can afford to upgrade when a new version comes along because you don't have the risk of incompatible file formats to fight with, nor a different modus operandi in the way the thing works.
Summary: cheaper to support - and a set up support scripts you only have to write once as the UI rarely changes (compared with the MS Office UI which changes every single time). In addition, you can actually afford more support: just use the licence fees you just saved yourself. You may also use those to translate any macros.
compatibility: you could default OOo/LOo to using the ".doc" and ".xls" file format. This results in internal consistency, won't immediately cause major havoc with intercompany document exchange and avoids the disaster of the allegedly cough "open" cough OOXML formats. The result is stability, because you will not be fighting the older/newer file formats battle that has accompanied MS Office from about version 2. Even better if you stick to a true open standard like ODF, but that may cause problems when data travels out of the door. Depends how big you are, a setup like Reuters could force others to adapt.
user training: ah, THE big lie of MS Office resellers. So far, every single release of MS Office has required user retraining and has *always* negatively impacted productivity as users have to embark on a "where the f*ck did MS stick function xyz this time" search, not exactly helped by the move away from locally installed help files - the "look it up on the Internet" help files are not only slower, they are also about as useless as Google would be with a random ranking of results. Actually, it is probably *Bing* with a random results ranking..
OOo/LOo, on the other hand, have remained pretty consistent with their user interfaces so a change from MS Office to OOo and LOo would entail only *one more* training exercise. And you can keep re-using those training materials for new people. Translated: changing from MS Office to Open/LibreOffice needs the same amount of training, but due to the stability of the UI it would be the last training you'd have to give. The result would be a stability in productivity you simply won't get with Microsoft Office products.
Of course, proposing Open Office deployment means you will immediately get into a political fight as it would cut down your staffing and support needs, and that means a budget and staffing reduction for those who make their living out of the deficiencies of the Microsoft platform, not to mention the possible invasion of MS sales staff taking the important people out for dinner or golfing and feeding them the usual bullshit - after all, going for Open Office and derivatives is basically the first step to booting out Microsoft altogether. Ditto for Exchange - if there was an alternative for Outlook there would be no reason left whatsoever not to switch to one of the many Open Source groupware packages out there. Here too, there would be less need to use a Windows core platform to start with - going for Open Standards means you could use Macs for the marketing and design departments, Linux for the number crunchers and whatever you felt like for desktop, you could buy kit suitable to your business needs rather than what was dictated by your vendors.
But hey, that would be *logical*, based on *facts*. The moment corporate IT is decided on those factors I suspect Hell will start selling ice cream..
"For instance recent Microsoft code has a much lower known security vulnerability count "
(Yawn) Evening RICHTO !
"For instance recent Microsoft code has a much lower known security vulnerability count "
@AC aka RICHTO/TheVogon
Please stop making it so easy to spot you. Your turn of phrase is a dead giveaway. The only interesting part about your posts is trying to guess if it's you so come on make some sort of effort.
Support Costs: But you don't have one product to support as power users or those that need to be able to exchange documents in any reliable fashion with other entities will still require MS Office. Also MSO can be fully managed via GPOs.
Compatibility - well you could use that file format - but it will limit you to only the functionality of Office 2003.
User training -- this has always been optional during several very large Microsoft Office update roll outs I have been involved in and the number of users that actually use / require it is tiny. Migrating to a completely different product however is very different and traning would in most cases be a significant transition cost.
Not sure how you think that a product that lacks many of the enterprise management features of MSO is going to be in some way cheaper to support or require fewer resources? In a very small company it might be if the product is more stable or has fewer issues (I find that unlikely, but i guess it's possible) but in an enterprise it is going to be far more expensive to support, configure and manage such a product.
Yes you could choose a big and wide selection of different products to do slightly different things, but many studies have demonstrated that in the vast majority of business cases, this costs more in terms of the TCO. This is why companies tend to standardise where possible on the most capable and versatile product - which on 90%+ of desktops and 50%+ of servers means Windows.. .
A school my children all went to when they were younger switched many years ago, kids, teachers and admin staff, on laptops, desktops, the whole lot. That's Warrington school in NZ, they say it was better in many respects, maintain it themselves with little effort, saving on support costs. Saving money wasn' t their objective, it was about being able to do what they want to do. They're using Ubuntu. I think they got the Ministry of Education to do an open tender and worked out that the NZ govt was paying $30,000,000 a year or something for Windows, but they didn't have any success getting the $thousands back for "their" school for useful things, not yet anyway. $30,000,000 is a lot of money to be wasting for a small place like NZ.
Just a quick question as 2007 to 2003 is terrible (even with the "compatability" added) - if you want an example try just changing the cell colours in excel and opening in a different one. I have Libre office at home (and MS office 2003) and will be trying the new version later (and reporting any bugs I find - only thing I have time for at the moment - to give a little back) . As to the ribbon interface - just hide mine at work and use it like a horizontal menu system.
LibreOffice is great but it looks fugly and feels ungainly. A drab, 1993 style UI spangled with random icons like a badly decorated Christmas tree. It won't do. Managers today like things to be shiny, snappy and above all slick, so give them what they want. LO should divert all coding efforts from the engine and into the UI. Heck, give them a ribbon if that's what they want, or a menu that spins around, just make sure it is smooth and fast.
"LO should divert all coding efforts from the engine and into the UI"
Oh yes, style over substance every time </sarcasm>
Alas my post was taken seriously by some. It was humour.
Personally, I also like the LO GUI, but then I am an IT professional like you, and an open source enthusiast. My point is that LO is more likely to garner mass appeal by looking impressive to the layman, or regular office worker, as Word does. Yes it is shallow but appearances influence decisions.
"Alas my post was taken seriously by some. It was humour."
Sorry if I upset you - it's just one of my things. I don't care what a program looks like as long as it has the performance/stability/etc.
In my case being totally Linux only I use LO as I don't have much choice anyway.
Alas my post was taken seriously by some. It was humour.
That was my guess, but if the Internet has taught us anything, it's that people can't see the color of your bits. If you want readers to understand your intent, you'll generally have to indicate it in some fashion. I'm not fond of the Reg's "Joke Alert" icon (so unsubtle; it's the visual equivalent of a rim shot), but that's what it's there for...
So you are suggesting to polish the turd?
@Jim A few months ago the LibO user menus were detidied up, looks so much better, staff at my workplace like it. It's a tool, does the job fast, smoothly and reliably.
When will we LibreOffice 64-bit for Windows. It's available for Linux variants, but not Windows yet. Why the hold up?
But near zero people use Linux on the desktop.
I would suggest the real reason is that 64 bit is not really needed on Windows as a 4GB filesize limit is more than adequate for those using a toy version of Office like this.
I've just downloaded the Source Code, and am now working my way through installing the heap of -dev packages I need to build it.
If there's anyone from Canonical listening, the one feature I would really, really, really like in Ubuntu 13.10 -- and the one that might finally get me off Debian -- would be to merge all -dev packages in with the respective main package. Separating them out made sense 10 years ago, when drive space was measured in gigabytes, processor speed in megahertz and everyone was expected to know exactly what they were doing. Today, -dev packages are a PITA. If somebody really doesn't need the development files, they can delete them; but HDD space is not really a valid concern anymore, compared to not making it needlessly complicated to build packages from Source Code.
I;ve never really thought of Ubuntu being aimed at people who want to build stuff from source - more at people who don't. Not sure they'd want to drop a load of extra packages into an install that their target demographic is unlikely to want. If I'm reading what you're saying correctly that is; I have to add in dev packages in Debian too so I might have missed your point.
For clarification, I'm currently running Debian on most of my boxen (including servers and desktops); but after trying Ubuntu on a laptop, I quite like it. It's not dumbed-down; I can still edit files in /etc/ with nano -- or even gedit with sudo --if I choose to do it that way, and it won't confuse the GUI configuration tools. (And I really love the Unity interface on a widescreen display, with its vertical launcher down the left-hand side; but I can see why classic GNOME 2.x users might find it different.)
It's simply wrong to imagine that compiling software from Source Code should be beyond "normal" users. Precompiled binaries are a legacy of Windows, not the traditional way complex software has been distributed. Actually, assuming that users are stupid -- as opposed to merely ignorant, but capable and ready to learn -- is a legacy of Windows.
Separate -dev packages make it harder for "normal" users to make the "leap" to building from Source Code, by putting that gap there in the first place -- by assuming that users will not, by default, want to build from Source Code. Disk space and bandwidth are cheap nowadays.
One alternative to "forcing additional stuff onto users" (most of whom, I'm sure, wouldn't even notice it till they double-clicked a .tar.gz file and it just installed itself) would be to extend dpkg to include, besides "depends", "recommends", "suggests" and "conflicts", a "dev-depends" category. With a simple configuration setting, installing a package could automatically install its -dev files or not; a database of -dev packages already required / installed would make it even easier to switch routes, by suddenly requiring or de-requiring a bunch of packages which will then get installed or uninstalled automatically at the next upgrade.
Another idea would be creative misuse of "suggests": optionally automatically install anything from "suggests" that has -dev in its name, and make every package suggest its own -dev. But this is not really the right solution, as it will involve just as much upheaval again if and when a "dev-depends" category is created.
"It's simply wrong to imagine that compiling software from Source Code should be beyond "normal" users."
I've never thought or claimed that. It does seem that Ubuntu, with the goal of getting people into Linux, tried to remove/minimise the need. For what seemed to be their target audience. As I recall Ubuntu was met with a lot of derision by Linux diehards when it came out. Remember the old "Ubuntu means too stupid to install Debian" jokes?
"Actually, assuming that users are stupid -- as opposed to merely ignorant, but capable and ready to learn -- is a legacy of Windows."
You seem to have misunderstood what I said. As I see it, Ubuntu's target audience has been people who want it to "just work" (sorry for trite phrase,) ideally out of the box. Which would imply no compilation. The assumption that users are stupid is not a legacy of Windows at all - it's the prevailing opinion of the IT community, and one I've railed against before on these forums given how often it's voiced. Glad to see someone recognising the difference between ignorance and stupidity; I hope others here will take note.
"Separate -dev packages make it harder for "normal" users to make the "leap" to building from Source Code, by putting that gap there in the first place -- by assuming that users will not, by default, want to build from Source Code."
To be honest, it looks like you're asking for your personal preference to be made the default. Essentially making the reverse assumption. If you make neither, it seems more sensible to me to go for a more minimal install - avoiding "bloat", to use another trite phrase. I don't agree that stuff should be put on someone's hard disk "in case they decide to use it in the future". They shouldn't have to decide to remove stuff they haven't asked for - another argument generally used against Windows. It's not mitigated by Linux letting you remove things more easily (or at all,) compared to Windows; it seems like a violation of the ideals.
"Disk space and bandwidth are cheap nowadays."
That's a matter of circumstance, really. Throwing silicon/money (even if the latter cost is comparatively small to you,) at a problem is inelegant. And *definitely* not for you to decide on others' behalf. I'm sorry to say that smacks of arrogance - "Eventually everyone will want to do it my way, because they're not stupid." Isn't that the "No True Scotsman" fallacy or something?
One alternative to "forcing additional stuff onto users"
Putting it in quotes doesn't negate that you're suggesting it.
(most of whom, I'm sure, wouldn't even notice it till they double-clicked a .tar.gz file and it just installed itself)
I don't see how that ties in with having the dev libraries automatically installed.
"would be to extend dpkg to include, besides "depends", "recommends", "suggests" and "conflicts", a "dev-depends" category. With a simple configuration setting, installing a package could automatically install its -dev files or not; a database of -dev packages already required / installed would make it even easier to switch routes, by suddenly requiring or de-requiring a bunch of packages which will then get installed or uninstalled automatically at the next upgrade."
Now that sounds eminently sensible to me. I'd get behind that.
"As I see it, Ubuntu's target audience has been people who want it to 'just work' (sorry for trite phrase,) ideally out of the box. Which would imply no compilation."
No apology required. I get exactly what you mean. The problem as I see it is, compiling software from Source Code doesn't "Just Work, out of the box". When you find out about some obscure package foo that your distribution's maintainers haven't thought to package, so you download the Source Code foo.tar.gz and it says you need to have package bar installed, and you know you have got bar installed, that's as confusing as hell -- and it sends a wrong message. What it actually means is that you need some file that would have been "left behind" if you had built bar yourself from Source Code, but you don't actually need for day to day use of bar. And your distribution's maintainers have helpfully separated those files out into a different package just for developers: bar-dev. But this is not obvious. And from the point of view of the user -- who really doesn't think of themself as a developer -- it ends up looking as though compiling software from Source Code is some sort of black art, some arcane magic, something they aren't meant to understand. It reinforces a view of "them and us". And it should not be like that, because everybody has something to give to the Free and Open Source Software movement -- unless they get so deterred by one bad experience that they defect to Windows. And what's that done for the hapless developers of package foo? Somebody wanted it so badly, but now they've been dissuaded from trying to install it.
My point is that, once upon a time, separating out developer files was beneficial to the "normal" user; including the developers' files in the main package would have done them a greater disservice than omitting them did the potential developer. I am no longer sure that this is the case: the inconvenience to users wishing to compile packages from Source Code as a result of separating out the developers' files now exceeds the inconvenience to other users that would result from including them.
Some users certainly will make the effort to learn about developers' packages, or even learn the hard way -- I ended up reinstalling a whole bunch of libs from Source Code one one box, once in my younger days, just because I didn't know about developers' packages. And that experience has informed the position from which I argue. If you'll allow me to use a cliché of my own, I just don't want anyone else to have to go through that.
Compiling a package from Source Code really needn't be any harder than double-clicking on a tar.gz file to start the configuration (./configure) and compilation (make) process, then supplying a password to allow installation to system-wide folders (sudo make install). And if it barfs for want of a dependency, then it isn't unreasonable to assume that installing the named package from repository ought to be enough to satisfy that dependency. Now, if the file manager (or its archive plugin) is really smart, it could detect that this is the first time you've ever double-clicked on a Source Code file, and turn on (if my hypothetical dev-depends: existed) automatic installation of developer packages. A smart "installable Source Code archive" plugin could even parse the error log and suggest a fix. Result: Compiling a package from Source Code is now as easy as (even although it will take a bit longer than) installing a pre-compiled binary package, for the casual user who -- for whatever reason, of their own business -- would like to install something that has not yet been packaged for their distribution.
Anyway, you've convinced me to put my money where my mouth is. I'm going to take a look at dpkg and see if I'm up to the task of adding the needed feature myself; and if I should bottle it, then I will at least suggest it to the developers. Either way, I plan to offer my bunch of patches or humble feature suggestion to Ubuntu first, because I think they do try hardest to have "everyone" as their target demographic. To prove I'm not as bitter as I may have sounded, I'm going to say this: Be my guest and suggest the dev-depends: idea to Debian -- or even Fedora; I'm sure they'd love an advantage over dpkg and apt-get. This is not a zero-sum game; we'll all come out winners if it's adopted, whoever is first.
Tell me they've fixed that in LO 4+
Roll it out with a GP startup script, upgrades in the background, not had a problem with this yet even on the older computers.
Looks like the MS staff are out in full force today.
Looks like it, they're crapping themselves!
"The Document Foundation has announced LibreOffice 4.0, the latest version of the free software competitor to Microsoft Office that spun off from the OpenOffice.org effort in 2010, describing it as nothing less than "the free office suite the community has been dreaming of since 2001."
In the other Office / Excel threads comments were sparse from those who had successfully migrated users off their Office addiction and onto LO! Until there's deep support for Macros & VBA legacy spreadsheets LO is not a serious competitor to MS-Office IMHO!
There are comments on here as if Excel macros are limited to the financial community solely. I've personally witnessed a huge number of small business with macro based spreadsheets and even some medium sized restaurant chains too relying on them. Excel and its macros are far more pervasive that some imagine.
But when it can't open spreadsheets* that have total wank in them such as:
Application.CommandBars("Task Pane").Visible = False
then it forces the user to pony up the £200 and buy the full MS Office suite. If LibreOffice aims for compatibility with the MS Office suite, then at the very least it should handle gracefully this sort of shit which attempts to disable an Excel toolbar that doesn't exist in LibreOffice.
* A client, using a custom written and password locked spreadsheet, wanted 8 new PCs without the cost of MS Office... I had hoped LibreOffice would do the job but even the latest 188.8.131.52 version I just installed falls at this first and most basic (no pun intended) of hurdles. Shame, as it's 8 more client licences for Microsoft.
"Shame, as it's 8 more client licences for Microsoft."
Except in a lot of cases it isn't (volume licensing).
Feel free to send the invoice to whoever supplied the s/sheet.
With a copy of the requirements doc highlighting the bit showing why the spreadsheet author shouldn't have used that call and is therefore liable, of course.
Biting the hand that feeds IT © 1998–2017