Kiedy będzie polonizacja dla wersji 3.1 dla Linuksa x86_64

[Jusko]

Witam.


Zastanawiam się nad tym, kiedy zostanie spolszczony pakiet biurowy OpenOffice 3.1 dla architektury 64 bitowej. Zdziwiłem się, gdy chcąc pobrać pakiet, widziałem paczki deb po polsku tylko dla architektury 32 bitowej (którąś wersję już z rzędu). Dlaczego nikt nie zbudował debów dla 64bitowców ? Skoro ktoś może zbudować polskie deby dla x86, czemu nie może się wysilić i zbudować dla x86_64 ? Pół biedy, ponieważ na siłę idzie problem obejść. W związku z tym pytam się, kiedy na http://pl.openoffice.org/product.download.lpack.html pojawią się paczki polonizacyjne dla 3.1 ? Można wtedy poprzez --force-architecture zainstalować 32bitowe paczki językowe, spolszczając w ten sposób 64bitowy pakiet OpenOffice.org.

Dlatego mam też końcowe pytanie - dlaczego użytkownicy systemów 64bitowych traktowani są po macoszemu i nikt nie tworzy paczek dla tej architektury (spolonizowanych) ? Na chwilę obecną używam angielskiej wersji 3.1. Nie jest to dla mnie przeszkoda, jednak zastanawia mnie właśnie podejście do polskich paczek dla x86_64. Dlaczego na polskiej stronie OO.o jest taki zastój i strona nadal stoi w epoce 3.0.1 ? Skoro można spolszczyć 3.1 dla 32bitowców, czemu nie robi się tego samego dla 64bitów ?

[quest-88]

Dlaczego nikt nie zbudował debów dla 64bitowców ?

Bo nie ma opiekuna. Zachęcam do współpracy.

Dlatego mam też końcowe pytanie - dlaczego użytkownicy systemów 64bitowych traktowani są po macoszemu i nikt nie tworzy paczek dla tej architektury (spolonizowanych)

Bo to jest nisza w niszy, w następnej niszy i nie ma osoby, która podjęłaby się testów.

http://marketing.openoffice.org/marketing_bouncer.html

1 nisza. Użytkownicy Linuksa pobierający oficjalne, anglojęzyczne kompilacje to 7% z ogółu.
2 nisza. Nie wiadomo jaki jest odsetek polskojęzycznych użytkowników, korzystających z oficjalnych, spolonizowanych paczek dla Linuksa. Ogromna większość korzysta z paczek dostarczanych przez producenta.
3 nisza. Architektura x86_64 mimo zalet, jest mało popularna.

http://tools.services.openoffice.org/dashboard/

Spróbuj oszacować liczbę polskojęzycznych odbiorców, użytkowników Linuksa, z odpowiednią architekturą komputera, wiedząc, że potencjalna grupa odbiorców to 36 mln w przypadku j. polskiego. W przypadku j. angielskiego jest to 7% z 402 mln oznaczona ogólnikowo jako Linux.

Istnieją statystyki odnośnie polskich kompilacji, ale dla mnie są one niewiarygodne.

http://openoffice.bouncer.osuosl.org/logstats/?C=N;O=D

Z 2 czerwca. Liczba pobrań/system

4009 /?product=OpenOffice.org&os=win&lang=pl&version=3.1.0
3385 /?product=OpenOffice.org&os=winwjre&lang=pl&version=3.1.0
60 /?product=OpenOffice.org&os=linuxintelwjre&lang=pl&version=3.1.0
60 /?product=OpenOffice.org&os=linuxinteldeb&lang=pl&version=3.1.0
54 /?product=OpenOffice.org&os=macosxintel&lang=pl&version=3.1.0
26 /?product=OpenOffice.org&os=linuxintel&lang=pl&version=3.1.0

Jeśli powstaną DEB-y, należałoby też stworzyć RPM-y i .exe dla Windows. Zasadnicze pytanie brzmi: kto będzie z tego korzystał? Czy warto w ogóle tworzyć taką kompilację?

Dlaczego na polskiej stronie OO.o jest taki zastój i strona nadal stoi w epoce 3.0.1 ?

Czym objawia się "stanie w epoce 3.0.1"? OO.o 3.0.1 x86_64 DEB również nie posiadał spolonizowanych kompilacji ani paczek językowych.

[milek_pl]

@jusko:

jeśli podejmiesz się testowania (to zajmuje około półtorej godziny za pierwszym razem, potem krócej - proste operacje typu otwarcie pliku, zapisanie pliku, napisanie zdania itd.), to możemy zatwierdzać do dystrybucji wersje 64-bitowe. Teraz po prostu nie mamy testera.

Więcej o testowaniu jest tu:

http://wiki.services.openoffice.org/wiki/PL/TCM

Wspomniana jest stara wersja, ale wszystko poza numerem wersji się zgadza i dziś (warto przeczytać też linki angielskie).

[Jusko]

Mówiąc o zastoju na stronie miałem na myśli, że 3.1 jest już parę chwil, są polskojęzyczne deby 32bitowe, a polska strona z paczkami językowymi nadal stoi na 3.0.1. Jeśli tylko pojawią się paczki językowe dla 3.1 to nie będzie problemu - wymuszenie architektury, instalacja 32bitowych paczek, i już pakiet jest w naszym ojczystym języku, choć używa się architektury x86_64. Także brak oficjalnej polonizacji dla 64bitów to nie do końca problem - jeśli są oczywiście pliki polonizacyjne, których tymczasowo jeszcze brak. Niestety czasem wolnym dysponuję raczej nieczęsto, stąd kiepski byłby ze mnie tester/opiekun - dodatkowo nie wiadomo, na jak długo - różnie przecież bywa. Nie mam też super łącza ani komputera, więc ew. kompilacje lub ściąganie dużych plików byłoby problematyczne. Mógłbym jednak zaryzykować dla testu. Jak jednak wspomniałem - wystarczy na bieżąco być z plikami spolszczającymi i problem staje się niemal marginalny. Cały czas jednak istnieje wtedy małe oszustwo - używanie 32bitowych rzeczy choć ma się system x64.



p.s : Liczba użytkowników OO.o pod GNU\Linux może być/ jest większa. Jak wiedzą użytkownicy tego systemu, często pakiet jest rzucany już na starcie jako preinstalowana w systemie aplikacja, także odpada konieczność ściągania ze strony. Dlatego statystyki też nie są do końca prawdziwe jeśli chodzi o systemy spod znaku pingwina.

[mellonedain]

Ad Ps. : Rzekłbym nawet, że jeżeli ktoś używa Linuksa to korzysta z paczek przygotowanych dla jego dystrybucji. A to daje naprawdę ogromną liczbę użytkowników pakietu, których nie ma i nigdy nie było w statystykach.

[milek_pl]

@jusko - prosisz, masz. Zapomniałem zaktualizować tę stronę, bo przygotowywaliśmy nową pobieralnię... Teraz jest już 3.1.0 w postaci paczek lokalizacyjnych.

Co do testowania - to napisz na mojego maila (milek_pl małpa openoffice.org). bo muszę znać Twojego, aby dać Ci uprawnienia w TCM. To nie jest nic bardzo trudnego, ale jednak dobre łącze by się przydało, bo te pliki są dosyć duże...

[Jusko]

Ok - napisałem e-mail. Cóż - teoretycznie łącze mam 3Mb/s. W praktyce jednak bywa ostatnio różnie,nawet bardzo różnie. Wiele zależy od serwera, z którego się ściąga. Mnie osobiście nie trafił się serwer przy ściąganiu OO.o, na którym miałbym więcej niż ~128KB/s Dziękuję za zaktualizowanie plików polonizacyjnych. Wymusiłem instalacje pomimo architektury i mam już OpenOffice.org po polsku pomimo posiadanej architektury.

Pozdrawiam.

p.s : dostaję zwrot z mailer daemona - czy adres e-mail jest na pewno poprawny ?

[KLAPEK]

A ja chciałem przy okazji się spytać, czemu nie ma już wersji instalacyjnych OOo dla Linuksa, tylko deby i rpmy?
Ja np używam Slackware i szlag mnie trafia z tymi nastoma pakietami deb/rpm ;/
Mogę sobie co prawda zrobić rpm2tgz, ale to nie Debian, gdzie każda paczka musi być podzielona na kilkanaście by szybciej stracić orientację
A dystrybucyjne nie zawsze są od razu (nie mówiąc o wersji polskiej), a ponadto w pracy mam kilka stacji ze starszymi wersjami Slacka, na które nie ma już paczek...
Zdecydowanie bardziej odpowiadała mi poprzednia wersja paczkowania.
Wystarczała wtedy zresztą tylko jedna dla Linuksa, teraz muszą być dwie (rpm/deb).
Może wiecie dlaczego tak to wygląda?

[quest-88]

Faktycznie! Był kiedyś projekt mający na celu stworzenie uniwersalnego instalatora na Uniksa/Linuksa. Najpierw obejmował on paczki RPM i archiwa dla Solarisa (OO.o 2.3), a w następnym wydaniu (2.4) miał zawierać DEB-y. Instalacja OO.o nie wymagała praw roota. Program instalował się w folderze lokalnym.

http://blogs.sun.com/GullFOSS/entry/jav ... wizard_for
http://installation.openoffice.org/Java ... taller.odt

http://installation.openoffice.org/

Nie mam pojęcia, dlatego zaprzestali rozwijać ten projekt. Najprościej będzie, jak zapytasz samego autora - Ingo Schmidt-Rosbiegala (ingo.schmidt#sun.com)

[Jusko]

Cóż - zawsze można zrobić jedno archiwum np. run lub zrobić paczkę w autopackage lub Nixstaller (polecam) i sprawa dystrybucji byłaby generalnie załatwiona - bez rozdrabniania się na systemy paczek. Wątpię jednak, by coś z tego wyszło - trzeba by znaleźć osobę znającą się na tym, a po drugie to OO.o ma już pewnie swoje ustalone kanony i nie zmieni ich tylko dlatego, że mamy taki kaprys. Fakt - jeden a do tego uniwersalny instalator dla każdej dystrybucji byłby wspaniałą rzeczą, ale raczej nierealną.

[mellonedain]

Kanony szczególnie te niesprawdzone są do zmiany. Trzeba zauważyć, że najlepszym rozwiązaniem tego zagadnienia byłby dobry system paczek (które poniekąd są prostymi instalatorami). Mają wiele plusów szczególnie jeżeli chodzi o różnice w wydaniach, wersja, optymalizacjach itd. W Windowsie nie ucieszysz się z optymalizacji pod architekturę Twojego procesora, ustalone przez Ciebie lub twórców Twojej dystrybucji podstawowe lokalizacje zasobów takich jak programy, pliki użytkownika itp. itd., Można by wymieniać godzinami. Moim zdaniem najlepszą rzeczą w systemie paczek są zależności, które dają ogromną możliwość ułatwienia życia Użytkownikom, nawet tym, którzy "nie znają się" na systemie operacyjnym, bibliotekach i innych technicznych aspektach pracy systemu i oprogramowania.

Każde rozwiązanie ma swoje plusy. Nixstallera nie znam. Nazwa brzmi Ciekawie. Może w końcu komuś uda się połączyć prosty interfejs z zaawansowanymi możliwościami oprogramowania.