25 тысяч сотрудников госпиталей Копенгагена перейдут на LibreOffice
5
Иллюстрация с сайта En.Wikipedia.Org
В течение следующего года почти все сотрудники 13 госпиталей Копенгагена (Дания) в количестве 25 тысяч человек перейдут на использование свободного офисного пакета LibreOffice.
Переход сотрудников датских госпиталей на LibreOffice с проприетарного офиса от Microsoft на LibreOffice обусловлен экономическими соображениями. Проблема существенных финансовых затрат всплыла после принятия решения о внедрении виртуальных рабочих столов и тонких клиентов. Лицензионная политика Microsoft привела авторов инициативы к мнению, что затраты на лицензии на проприетарный офисный пакет окажутся неоправданно высокими.
Сообщается, что более года велись переговоры с Microsoft по этому поводу, однако никаких результатов это не принесло. Поэтому было принято решение осуществить постепенную миграцию на свободное решение — LibreOffice. Нынешние лицензии на Microsoft Office (в количестве 10 тысяч) будут использоваться до истечения их срока действия. Затем на LibreOffice перейдут все сотрудники за исключением небольшого числа ответственных «за работу со сложными электронными таблицами».
На данный момент в госпиталях запущено около 2500 виртуальных десктопов, в которых сотрудники уже начали знакомиться с LibreOffice. Персонал проходит специальное обучение работе в LibreOffice для того, чтобы адаптация в новой офисной среде проходила быстрее и мягче.
Отмечается, что это третий по масштабам проект миграции государственных организаций на свободный офис в Европе. Крупнее были только проекты во Франции: переход жандармерии (80 тысяч пользователей) и Национальное агентство по выплате семейных пособий CNAF (36 тысяч десктопов) на OpenOffice.org. На четвертом месте этого своеобразного рейтинга Финляндия с миграцией на OpenOffice.org десяти тысяч сотрудников Министерства юстиции.
Постоянная ссылка к новости: http://www.nixp.ru/news/11349.html. Дмитрий Шурупов по материалам osor.eu.
- Итальянские военные переводят 150 тысяч рабочих мест на LibreOffice и формат ODF 6 16 сентября 2015 г.
- Французский город Нант завершает миграцию на LibreOffice 7 2 25 марта 2016 г.
Прощание с LiMux: Полный возврат Мюнхена с Linux на Windows обойдётся почти в 50 миллионов евро
3 19
В LibreOffice Calc добавили начальную поддержку многопоточных вычислений
Французский город Нант завершает миграцию на LibreOffice
7 2
Итальянские военные переводят 150 тысяч рабочих мест на LibreOffice и формат ODF 6
The Document Foundation объявила место и время проведения конференции LibreOffice 2015 года 1 4
Переход на OpenDocument дорого обойдется Дании
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Интересно, а почему бы не на OOo? Его же так сказать реабилитировали.
Нууу… Передачу в Apache Incubator я бы не назвал реабилитацией. К тому-же ребята из libreoffice довольно большие куски, написанные на Java, переписывают на С++. Это дает +1000 к карме :D и буст по производительности и уменьшение использующейся памяти. Как минимум. Потом у libreoffice комьюнити уже больше чем у OOo. Взять хотя-бы переход повального количества дистров на Libre.
Мне честно говоря показался этот переход именно реакцией на то, что OOo может стать закрытым Oracle’овским продуктом. Не знаю уж что они там на C++ переписывают, но было бы хорошо это все объединить и да, переписать на C++.
Все не перепишут. Иначе он не запустится на Windows PC
От чего-же? QT написана на С++? Написана. Что не мешает компилить проги на множество аппаратных и программных платформ. да, уровень совместимости придется вводить и переписывать для каждй платформы — типа реализовать java для бедных. Но реализовать оочень небольшой кусочек. Оно того стоит.
Да один хрен, что C++ что жаба. C++ заметно быстрее и меньше на относительно небольших проектах, к которым Open/Libre не имеет никакого отношения. Но на больших, если C++ и опережает по скорости, то по памяти, один член, идёт ноздря в ноздрю с жабой.
Ситуация ещё усугубляется тем, что C++ не предназначен для переписывания кода. На C++ можно написать программу, и потом использовать её. Но изменять C++ код — хуже не придумаешь. Так что лучше не будет. Вот если бы они выкинули существующую базу кода, и начали бы писать с нуля, то могло бы получиться лучше. Лет через пять, через десять.
Ой-вей, да что ви говорите… «C++ не предназначен для переписывания кода.» — А кто предназначен?
«Но на больших, если C++ и опережает по скорости, то по памяти, один член, идёт ноздря в ноздрю с жабой.» — как-то странно получается. При чем здесь «размер проекта»? Я понимаю, что физик на любом языке напишет на Фортране (С), но по рукам за такое бить очень больно надо. Туда-же и жабописцев.
«Вот если бы они выкинули существующую базу кода, и начали бы писать с нуля» — Собственно то и происходит. Вычленяют жабу как только можно по причине независимости от Oracle. И вообще, мое мнение относительно фразы «Ой ё, да лучше переписать с нуля нежели что-то изменить» ну очень… нехорошее (чтобы оставаться в рамках приличия). Очень осторожно надо 1) произносить такое 2) относиться к произнесенному.
Факт остается фактом — для равносильных структур данных жабе требуется больше памяти. И больше времени процессорного по управлению памятью. Хотя да — реализация на С++ иногда намного тяжелее. Ну дык мы не ищем простых путей :D
> Ой-вей, да что ви говорите… «C++ не предназначен для переписывания кода.» — А кто предназначен?
Например C. Код на C поддаётся рефакторингу, и более того архитектурному рефакторингу. Но C не единственный такой язык. C++ же, из известных мне языков, менее всего предназначен для переписывания частей программы. В C++ архитектура программы забивается на этапе проектирования, раз и навсегда. Как только фаза проектирования закончена изменить что-либо уже не представляется возможным. И все ошибки проектирования программы на C++ будут жить столько же, сколько и сама программа.
> При чем здесь «размер проекта»?
java тянет за собой огромный рантайм. И 99.99% ресурсов потребляемых программой хеллоу-ворлд написанной на жабе, будут потреблятся этим самым рантаймом. Но по-мере роста проекта, мало того, что рост программы будет уменьшать эти 99.99%, так всё меньшее и меньшее количество из этих 99.99% будет являться бесполезным грузом для проекта. Всё большее и большее количество кода этого рантайма будет оказываться полезным для проекта.
Если же рассмотреть «рост» C++ проекта, то на этапе хеллоу-ворлд, будет больший процент полезной нагрузки, но по-мере роста, всё больше и больше всякого хлама будет подключатся. И когда проекты дорастут до размеров OO, они если не сравняются по потреблению памяти, то во-всяком случае будут настолько близки, что обращать внимание на это не будет смысла.
> «Вот если бы они выкинули существующую базу кода, и начали бы писать с нуля» — Собственно то и происходит.
Нет. Не так. Они меняют кусочками, оставляя те же связи между кусочками, которые были раньше. Они избегают сложных архитектурных изменений. Что естественно, поскольку программа написана на C++.
> И вообще, мое мнение относительно фразы «Ой ё, да лучше переписать с нуля нежели что-то изменить» ну очень… нехорошее (чтобы оставаться в рамках приличия). Очень осторожно надо 1) произносить такое 2) относиться к произнесенному.
А я между прочим и произнёс это «очень осторожно». Я не предлагал переписывать всё. Я лишь сказал, что действительно измениться что-то может, лишь в результате переписывания всего кода.
> Факт остается фактом — для равносильных структур данных жабе требуется больше памяти. И больше времени процессорного по управлению памятью.
На сколько больше памяти требуется? На 5%? Эти 5% — если и скажутся на потреблении ресурсов, то никто этого не заметит без проведения специальных тестов.
Java медленнее — это да, от этого никуда не денешься. Но большие и сложные программы на C++, почему-то, любят потормозить так, что иногда даже задумываешься: а не было бы быстрее на жабе? Наверное не было бы. Но и тем не менее, я весьма и весьма сомневаюсь, что LibreOffice станет быстрее от переписывания на C++. Мне кажется, что скорость OO определяется исключительно скоростью рандомного доступа к оперативке, отравленного постоянными промахами по кешу. А в такой ситуации плевать жаба или C++, оно будет тормозить однопенисно. Правда тестов я не проводил, и утверждать точно не могу. Но и тем не менее, это моё мнение.
> Хотя да — реализация на С++ иногда намного тяжелее. Ну дык мы не ищем простых путей :D
И зря. Какие же вы к чёрту юниксойды, если вы не ищете простых путей? Юникс родился на идее KISS, и добился успеха благодаря упёртому следованию этой идее.
> Например C. Код на C поддаётся рефакторингу, и более того архитектурному рефакторингу. Но C не единственный такой язык. C++ же, из известных мне языков, менее всего предназначен для переписывания частей программы.
Очень громкое и неправдоподобное заявление. Чем лучше себя тут может показать та-же жаба. И не надо про C — рефакторинг C-кода намного тяжелее. Особенно если это делают люди, которые не являются изначальными авторами кода. Попробовали бы вы разгрести как работает тот-же gphoto2 — уродистость по которой рефакторинг плачет. И для примера — влезть унутря QT посмотреть как работает с целью cGPL-ить что-то…
> так всё меньшее и меньшее количество из этих 99.99% будет являться бесполезным грузом для проекта. Всё большее и большее количество кода этого рантайма будет оказываться полезным для проекта.
Ну да. А управление памятью и собственно аллокаторы референс-каунтеры и прочая лабудень для такой структуры, как дерево — они наверное куда-то деваются. А чем манипулирует офис? — довольно большое и насыщенное свойствами дерево.
> Если же рассмотреть «рост» C++ проекта, то на этапе хеллоу-ворлд, будет больший процент полезной нагрузки, но по-мере роста, всё больше и больше всякого хлама будет подключатся.
Какой-такой хлам? Поконкретнее на примерах, пожалуйста. Я вот тоже могу сказать — у java проги очень много хлама. И что от этого?
> На сколько больше памяти требуется? На 5%? Эти 5% — если и скажутся на потреблении ресурсов, то никто этого не заметит без проведения специальных тестов.
Ну да. Вот у меня на серваке терминальном крутятся 150 юзеров. С каждого открытого документа по 5% — это уже прилично. И 5% — это самые пессимистические оценки.
> Мне кажется, что скорость OO определяется исключительно скоростью рандомного доступа к оперативке
У java-программы эти показатели заметно хуже чем у с/c++. И Причем тут рандомный доступ? Дерево — довольно компактная струкрура данных. Используя низкоуровневость С++ можно немного повлиять как будет храниться в памяти структура. java — решает это сама. И частенько не самым лучшим способом.
> Но большие и сложные программы на C++, почему-то, любят потормозить так, что иногда даже задумываешься: а не было бы быстрее на жабе?
ТОгда зачем этот долбанный гугл морочит себе мозг с NDK для Android и c NACL — на Java ведь быстрее!!! Ох… Как по мне это выражение связано с личным опытом и с используемыми Вами программами. Но повторюсь — каждый физик на любом языке напишет на Фортране. С другой стороны, известна фраза что «потоки нужны людям не умеющим программировать.» Все-же можно представить в виде упрощенного конечного автомата! А то, сколько времени на это уйдет никто не уточняет. Так и с любым языком. С++ хорош для массивных вычислений.И при большом количестве выделение-изменение-доступ-удаление кусков памяти оказывается Намного быстрее чем java. Если упор идет на время разработки — на java быстрее разрабатывать (потому что не надо беспокоится о некоторых вещах). Каких-либо конструктивных моментов языка, улучшающих рефакторинг… Нету по сравнению с С++. Но это OS и никто не подгоняет — значит можно вдумчиво сесть и сделать конфетку.
> «можно вдумчиво сесть и сделать конфетку.»
Главное верить. Верьте!
То-же самое можно сказать и вам — думаете что получится Г… — Верьте и убеждайте себя в том, что прога написанная на Java — по умолчанию попадает в Валгаллу. Самая короткая дорога — та, которую хорошо знаешь. Ну или язык, которым владеешь лучше всего.
Я далек в этих тонкостях. Хотел спросить:
1. Для каких целей использование Java обосновано?
2. Ответ на первых вопрос не должен быть ответом на Ваш спор?
> 1. Для каких целей использование Java обосновано?
Ни для каких. Точнее так будет лишь если закрыть глаза на распространённость джавы, которая всё же вносит свои коррективы в выбор языка. Жаба, вроде как, для прикладного программирования предназначена, но всё что в ней есть хорошего для прикладного программирования — это ООП и сборка мусора. Ещё, конечно же, неплохо что своя графическая библиотека — кроссплатформенно, — но есть кроссплатформенный gtk который благодаря C’шному ABI несложно привязать к любому языку. При некотором желании и терпении можно и qt привязать. Так что это не считается.
Но можно ведь найти язык со всеми возможностями жабы, который компилируется в native код. Причём можно выбрать даже язык с привычным синтаксисом, не обязательно выбирать Lisp или Haskell. И это ставит большой вопрос на осмысленности выбора в пользу жабы. Если выбирать между C++ и жабой — то тут действительно сложно выбрать. Две кучи дерьма, у каждой свой список недостатков, но они друг-друга стоят. Если же не ограничивать себя популярными языками, то тогда действительно появляется выбор, причём уже выбирать не «наименьшее из зол», но из хороших лучшее.
Во всех других случаях использование С++ более предпочтительно, пока не доделают D =)
Ага — по этому поводу есть шутка: compile once — debug everywere :)
Байткод — это может быть хорошо, если сорцы спрятаны от общественности: не надо собирать по релизу каждому идиоту с его линуксом стоящем на непонятном процессоре и со странными версиями библиотек. Если же сорцы доступны, тогда проблемы компиляции под нужную платформу можно оставить этому идиоту. Именно на таком принципе, между прочим, GNU/Linux умудряется работать как на x86, так и на x86_64, на ARM, на MIPS, на AVR32 и на ряде других платформ. Не привлекая, замечу, никакого байткода. Байткод это хорошо для python’а, ruby и тому подобных языков, которые не претендуют на то, что их будут использовать для написания OO. Ограничиваются мелкими приложениями типа bittorrent-клиента, редактора конфигов, или чего-нибудь типа emacs’а. Да и то, emacs хоть и написан на elisp, но, всё же, основные структуры данных реализованы на C как неотъемлимая часть elisp.
> Во всех других случаях использование С++ более предпочтительно, пока не доделают D =)
Спасибо, я… Я лучше пешком постою. Множество языков программирования не ограничено тремя — C++, Java и D. Существуют и другие, и мне есть из чего выбрать.
Java и C++ выбирают потому, что они популярны. Это примерно та же история что с вендой на десктопе, которую ставят везде, потому что она везде стоит. Но я не ставлю венду, и не выбираю Java и C++.
А вообще, выбор между C++ и Java, может быть сделан в пользу Java, ещё и потому, что Java более простой язык. C++ программисты со стажем, подчастую чванятся, что мол C++ — это язык не для всех, и надо иметь много мозга и трудолюбия чтобы научится на нём писать. Но многие считают это не преимуществом языка, а недостатком. Тем же кто сомневается, я могу порекомендовать взять сорцы libstdc++ и попытаться читая их (и только их) разобраться как же они работают. Или даже не разобраться в их работе, а просто выяснить как надо использовать STL. Поверьте мне, быстрее изучить ассемблер, отдизассемблировать libstdc++.so и разобраться в дизассемблерном листинге, чем в сорцах на C++. Хотя, может быть огромный опыт разработки на C++ может существенно облегчить задачу, но приобрести этот опыт, по-любому дольше чем разобраться при помощи дизассемблера.
Человек не умеет писать большие программы. Это признают все специалисты: нет таких методик разработки, которые позволяют создавать столь сложные системы. Поэтому программы не просто пишут, их постоянно меняют. Вносят изменения то туда, то сюда. И есть языки которые способствуют тому, чтобы легко было бы разобраться в том, где именно нужно внести изменение, чтобы добиться результата, языки которые способствуют тому, чтобы легко можно было бы проверить корректность изменения. А есть C++, в коде программ на котором сам чёрт ногу сломит, и патчи к этим программам невозможно осознать без использования ряда утилит предназначенных для исследования кода.
Кстати на эту тему, Торвальс как-то троллил C++ программистов. Вот линк: http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2
> Байткод — это может быть хорошо, если сорцы спрятаны от общественности
Про копирайтеров речь не идет. Ну совсем. К тому-же никто не мешает распространять бинарный блоб с обвязкой для архитектуры.
>Байткод это хорошо для python’а, ruby и тому подобных языков
не знаю как Ruby, но Python ВООБЩЕ не компилируемый язык. Подготовку какую-то можно сделать а вот нативный код — нет.
> Тем же кто сомневается, я могу порекомендовать взять сорцы libstdc++ и попытаться читая их (и только их) разобраться как же они работают. Или даже не разобраться в их работе, а просто выяснить как надо использовать STL. Поверьте мне, быстрее изучить ассемблер, отдизассемблировать libstdc++.so и разобраться в дизассемблерном листинге, чем в сорцах на C++. Хотя, может быть огромный опыт разработки на C++ может существенно облегчить задачу, но приобрести этот опыт, по-любому дольше чем разобраться при помощи дизассемблера.
То-же можно сказать про любую стандартную библиотеку. Вы на Java-ские поглядите. А по поводу ассемблера — да Вы, батенька, мощны, раз ассемблер быстрее разгребаете чем С++ (ага с исключениями код например :D) и по асму понимаете как надо пользоваться библиотекой.
> И есть языки которые способствуют тому, чтобы легко было бы разобраться в том, где именно нужно внести изменение, чтобы добиться результата, языки которые способствуют тому, чтобы легко можно было бы проверить корректность изменения. А есть C++, в коде программ на котором сам чёрт ногу сломит, и патчи к этим программам невозможно осознать без использования ряда утилит предназначенных для исследования кода.
Например?.. Perl :D? или Python? или… ???
> Кстати на эту тему, Торвальс как-то троллил C++ программистов. Вот
Ой, да он много по какому поводу тролит. Вернее по каждому, когда ему что-то не нравится. О случае микроядер вообще легенды ходят. Да и как-то OO язык для разработки ядер не сосбо… Вы прикиньте сколько компилиться будет :D Вот и тролит потихоньку.
> Например?.. Perl :D? или Python? или… ???
Например C. Вы загляните в код ядра, его читать легко и приятно. Например lisp — он тоже позволяет писать программы так, чтобы их потом можно было читать. Дело доходит до того, что разработчики библиотек пишут весьма скудную документацию, и отправляют в сорцы выяснять всё остальное.
Да, кстати и Python тоже. Я сталкивался с программами на нём, читал сорцы и не видел никаких проблем с тем, что и изучаемый кусок кода работал не так как выглядел.
> Да и как-то OO язык для разработки ядер не сосбо…
Вы бы почитали сначала, а потом рот разевали. Торвальдс если и троллит, то троллит по делу. Иначе бы я тут ссылку не оставлял. ООП, между прочим, он уважает и в ядре использует направо и налево (вспомнить, хотя бы, kobject), так почему же по вашему мнению ООП язык не подходит для ядра?
> Вы бы почитали сначала, а потом рот разевали. Торвальдс если и троллит, то троллит по делу. Иначе бы я тут ссылку не оставлял. ООП
Все-таки есть различия между понятиями Объектно-ориентированного программирования и Объектно-ориентированного языка, не так ли? Так вот — опыт использования последних при написании ядер очень уж плачевен. А ООП в ядре линуховом — да везде куда ни плюнь, эт точно. Особо яркий пример — VFS.
> Да, кстати и Python тоже. Я сталкивался с программами на нём, читал сорцы и не видел никаких проблем с тем, что и изучаемый кусок кода работал не так как выглядел.
В том то и дело — что сталкивались с хорошо написанным кодом. Не важно на каком языке, хоть на COBOL-е. И, кстати, я попытался пошутить, поставив cначала Perl и в противоположность Python (есть такая фраза — Neo, is this The Matrix? — No, no! This is my new perl script, that I’m working on! ). Каламбурчик не удался…
> В том то и дело — что сталкивались с хорошо написанным кодом. Не важно на каком языке, хоть на COBOL-е.
Я сталкивался с разными программами. Собственно первая программа в чьих сорцах я ковырялся (не считая своих) была написана крайне криво. Причём она была написана криво на паскале, потом криво дописана, затем при помощи p2c скомпилирована в C, и после этого претерпела ещё ряд «апдейтов». Но как бы криво она не была написана, я в ней разобрался. И успешно вносил в неё те изменения, которые мне хотелось. И со скриптами на perl’е я разбирался — уж не помню зачем, но я ковырялся в latex2html. И ведь разобрался, даже несмотря на то, что перла я не знал. И до сих пор не знаю.
Я знаю, что на любом языке можно написать нечитаемую пургу. Но если вы считаете, что libstd++ просто написана убого, то приведите мне пример как она может быть написана лучше, так чтобы можно было бы прочитать её хедеры не свернув себе мозг. Я уверен, что это невозможно. А STL, между прочим, вроде как первый и основной пример использования C++, которому должны подражать все.
> Так вот — опыт использования последних при написании ядер очень уж плачевен.
Я тоже считаю что ни Java, ни C++ не подходят для этого дела. Но зачем тогда вы завели разговор о системном программировании?
> Я тоже считаю что ни Java, ни C++ не подходят для этого дела. Но зачем тогда вы завели разговор о системном программировании?
Помойму Линуса сюда Вы как раз и приплели. А его слушать можно только в отношении разработки ядер, таких как линуховое. У него уже мозг на это повернут. И у меня не было фразы — не подходит. Опыт разработки плачевен, например L4 до сих пор из alpha не вышло. Но почитайте — какие там у ребят проблемы если будет свободное время…
> Но если вы считаете, что libstd++ просто написана убого, то приведите мне пример как она может быть написана лучше, так чтобы можно было бы прочитать её хедеры не свернув себе мозг
Вы видели код универсальной библиотеки? Которая компилится на N платформ? Притом как аппаратных так и программных. Потому так и получается — взрыв мозга. Тем-более, что это основная библиотека. И как по мне — преспокойно можно прочитать. В общем — плохой пример.
> Про копирайтеров речь не идет. Ну совсем. К тому-же никто не мешает распространять бинарный блоб с обвязкой для архитектуры.
Бинарный блоб будет работать на одном процессоре. Если он скомпилирован под amd64, то на arm он уже работать не будет. Байткоду же плевать, он выполняется на виртуальном процессоре, который можно написать для любого реального процессора.
Ну будет или не будет работать — еще вопрос. Как правило приходится на каждой платформе проверять и тратить на это довольно приличное время. Так что можно и блоб скомпилять. :D
По поводу Java / C++, согласен с rgo: проектам размером с ОО переписывание с Java на C++ — что мёртвому припарки.