Slashdot Mirror
Why Munich Will Stick With Linux
Jason Hibbets writes: "There are many solved problems in open source. Groupware is not one of them," Georg Greve, co-founder and CEO of Kolab System starts off his post highlighting recent features of the latest release of the Kolab groupware project. He calls out a few newly elected politicians that don't like the current set-up, but says that thousands of users don't have the same experience. "Until today, the city of Munich is using the same stand-alone calendaring and email systems it had used when it was still fully operating on Windows. Updating these systems had a lower priority than the migration to LiMux then. But an upgrade is underway now. And, the solution they chose is agnostic to the desktop platform and will service LiMux and Windows alike. The primary difference made by another migration would likely be due to the perils that come with any migration, such as additional costs and delays. In other words: The very problem used to criticize the LiMux desktop is already being solved."
They should teach these people how to install linux on their home computers too. It's less confusing to have one os (all linux) than two (linux in the office, windows at home). Maybe even give them a free linux laptop for the home. They can afford that because of the license fee savings for not using windows.
no, I don't have a sig
> You can't easily exchange documents with GNU/Linux and expect it to work.
Sure you can. Or at least you can as much as you can expect this to work with random versions of office itself. This problem is so pervasive that you won't even get blamed for running a deviant word processor if there are problems.
msoffice based document interchange is so problematic that some people/industries just gave up and defected to PDF.
Like anything else, you have to focus on actual real world requirements and use cases and not the most obscure corner case that you can concoct. The same goes for "groupware". I am not convinced that this is a big problem.
Again... what people actually use versus someone's chosen bullet points.
A Pirate and a Puritan look the same on a balance sheet.
Yes but you usually don't run into this problem when using MSOffice because everyone in the office has the same Office....
Not all offices have the same version of MS Office installed throughout the office. I've been at companies that have had three different versions of MS Office installed, and they did have issues with exchanging documents. The easiest solution was just to tell everyone to "save as an old MS Office format" when a document needed to be shared.
.
Moving form office to office, I've found that LibreOffice does better than MS Office at properly importing office documents from various versions of MS Office. YMMV.
"Yes but you usually don't run into this problem when using MSOffice because everyone in the office has the same Office. "
No, no they dont.
Whereas I appreciate the beauty of OpenSource, I am yet to find a compelling MS Access equivalent in the Linux world. Yes, I know about Kexi, MariaDB, OpenOffice Base and the like.
But let's face it: There's nothing in the Linux world that can compare to MS Access. Nothing! I am not just trolling. I have developed hundreds small scale MS Access implementations for many clients.
VB, even with its quirks, does well. I would like a front-end, in which business logic can be programmed. Logic placed right there on the form...Logic and parameters that can be passed to the DB engine. Nothing friendly exists in Lunix, or should I say, "I haven't found one yet." Am I wrong?
My experience is that when new versions of Word have problems opening a file created by a previous version, the solution is to open them in OpenOffice and use OO to save to the newest MS Word format (or leave them as odt).
In that way, OpenOffice has BETTER compatibility with various types of MS Word documents than MS Word itself does.
Moving form office to office, I've found that LibreOffice does better than MS Office at properly importing office documents from various versions of MS Office. YMMV.
Yes, I totally agree that importing is rarely a problem. However LibreOffice fails in many aspects. our publishing house made the switch to LibreOffice early this year after basic testing.
For a simple example that Writer is not fit for businesses: it cannot properly handle even basic tasks such as working with templates. Without an add-on it is not possible to change the template. Yes that's right. Only documents that are created based on templates are coupled to that template. The available add-on (templatechanger ) to change this is only available for the latest version via a user that added it to a bug report (many thanks for that btw) and only works with Writer. For Calc changing templates is simply not
Another function that is sorely lacking as an editor has been in MS Office since version XP, around ~2001 I think. If you receive a document from a freelancer it often has the wrong styles in it or only a few. To change this quickly in MS Office you load the tempalte you want. Select the style that is wrong, click select all instances followed by a double click on the style you want. This way you can quickly fix documents.
I find the default colors of LO's panel dreadful. There are better colors available though, such as http://extensions.libreoffice.... Why are these not used or given as an option?
If you save a file on a NAS and select Tools/Share Document so more people can simultaneously work in it, often the formatting of the file changes randomly between saves. Old formatting often re-appears.
Calc cannot properly handle conditional formatting. This morning I created a Calc document with a cell that could have one of three colors based on the content of three other columns. I then copied the formatting to more cells in the column. After saving the document only the first cell formatting is kept, the formatting in the other column cells is lost.
For our publishing house LO mostly suffices, but there are many ways in which it has to improve for other business to even consider it.