München után Hamburg is a nyílt forráskódú szoftverekben látja a jövőt

Címkék

Nemrég jött a hír, hogy többszöri irányváltás után München újra a nyílt forrás felé fordult. A ZDNet egyik cikke szerint most a Microsoft egyik bástyájának számító Hamburg városa döntött úgy, hogy a közszolgálati feladatokat ellátó szoftvereit Microsoft gyártotta megoldásokról nyílt forrású alternatívákra váltaná. A nyilatkozat egy, a várost vezető szociáldemokraták és a zöldek közti 200 oldalas megállapodás részeként érkezett. Kedden vezették elő, ugyan még nem írták alá, de az elfogadása feltehetően nem lesz probléma, mert Hamburg és München vezetésében szociáldemokraták (is) ülnek. 

Peter Ganten, a stuttgarti székhelyű Open Source Business Alliance elnöke írta:

With this decision, Hamburg joins a growing number of German states and municipalities that have already embarked on this path, [...] The Hamburg decision is nevertheless remarkable because the city has always been more aggressively oriented towards Microsoft.

Részletek itt.

Hozzászólások

Szerkesztve: 2020. 06. 07., v - 10:35

Reméljük itt nem két évtizedes projekt lesz. Ha sikeres lesz a városi fórumokon fel lehet majd tenni a kérdést

Mi a létjogosultsága a Microsoft Office-nak?

Mert aki ezekben a városokban munka szintjén dolgozik rendszeresen Libre Office dokumentumokkal és nagy mennyiségben állítja elő ezeket a dokumentumokat, összetett formázásokkal, az tudja, hogy mennyire bosszantó tud lenni, amikor valaki nem Libre Office-szal nyúl bele valamelyikbe, hanem Microsoft Office-szal. Ilyenkor itt-ott szétesik a formázás, megmagyarázhatatlan dolgok történnek a dokumentummal és szenvedhetek a keletkezett hibák kijavításával. 

:D

Office teren a nepek segge tulsagosan ki van nyalva.

Ami dokumentumot TXT -ben nem lehet kozreadni, azt nem is erdemes. Ha az RFC -k tok jol kezelhetok clear textben, akkor a Hatarozat: Gipsz Jakab parkolohasznalataval kapcsolatban cimu dokumentum is jo ebben. Ha szetesik a formazas lesz szives szokozt hasznalni, az nem romlik el. Haha.

Az az Excel pedig ami nem konvertalhato CSV -be, az nem fontos. Szin, betutipus atmegy? Akkor mar tobbet kapott a jonep mint amit megerdemel. IMHO.

Disclaimer: Ennek a hozzaszolasnak a szerzoje ebben a temaban nem nevezheto atlagosnak, mert rossz szokasa, hogy a projekt dokumentacio lenyegi reszet bash scripttel generalja. Komolyan!

Ha az RFC -k tok jol kezelhetok clear textben, akkor a Hatarozat: Gipsz Jakab parkolohasznalataval kapcsolatban cimu dokumentum is jo ebben

Az RFC-k zöme általában kezelhető plaintextben. De én azért örülök neki, hogy ha egy szövegben szükség van egy (akár nagy és részletes) ábrára, akkor azt egy PDF-ben meg tudom nézni beágyazott PNG / JPG / GIF / bármimás formátumban, szép színesben és nagyfelbontásban. Nem pedig fekete-fehér ascii-art-ban kellene a 100-150 objektumot tartalmazó Visió architektúra diagrammokat küszködve vizuálisan dekódolni. Lehetne az RFC-ből is hardcore .TXT verzió (a ~50+ éves ascii-art csúcstechnológiás), meg egy modernebb istenbocsá' PDF amiben a bonyolultabb ábrákat esetleg a nem-aspergeresek is ki tudnák bogozni. Így 2020 derekán semmilyen más korlát nem indokolja az 50+ éves 80x25-ös karakteres terminálra optimalizált formatumot, mint a techno-elitizmus. 100+ Gbps átviteli szabványok, futtatva akkora gépeken amik 10-15 évvel ezelőtt Top10 szuperszámítógépek lettek volna, de az ezeket definiáló RFC-ben nem lehet PNG ábra!!44!!

Szerencsére a problémát mások is látják/látták:

https://www.mnot.net/blog/2018/07/31/read_rfc

It’s no secret that plain text RFCs are difficult to read bordering on ugly, but things are about to improve; the RFC Editor is wrapping up a new RFC format, with much more pleasing presentation and the option for customisation. In the meantime, if you want more usable RFCs, you can use third-party repositories for selected ones; for example, greenbytes keeps a list of WebDAV-related RFCs, and the HTTP Working Group maintains a selection of those related to HTTP.

En ugy latom, hogy az informacio atadasnak van harom szintje, amit gyakran egybemosbak, vagy legalabbis nem a helyen kezelnek.

Az elso amikor csak a lenyeg szamit, a kulalak nem. Erre jo pelda ez a post, ahol mivel telefonrol irok, nem hasznalok ekezeteket. Ha izgis kep kell, eleg egy rautalo ( . ) ( . ) abra, es maris mindenki ugyanarra gondol. (Nagy szemekre, nyilvan.) :+)

Erre ellenpelda, amikor az elso munkahelyemen fejleces word doksiban ment ki mindenkinek az az egy sor, hogy a nyari szunet alatt a bufe ettol-eddig zarva lesz.

Ez ugyanis mar a masodik szint, ahol Word/Excel/Power point/Visio doksi szuletik.

Ez a masodik szint az ahol a forma is szamit, de senki nem akad ki azon, ha nem pixelhelyes. Nagyjabol jol nezzen ki, lehessen felkover es dolt, alahuzas meg betuszin, es hatterszin. Meg nyilak es dobozok, esetleg kis kepek, abrak, vonalrajzok.

Ez mar jol olvashato, informativ, cserebe az elkeszitese nagysagrendekkel tobb ido mint a TXT szovegnek. De pontosnak nem kell lennie. Ha lefenymasolod szurkearnyalatosban, akkor is jonak kell lennie. Ennyi torzulast el kell tudni viselnie a felhasznalonak. Egy hivatalos irat peldaul ilyen. Nagyjabol szep, de ha nem pont kozepen van a kozepre igazitott szoveg, az senkit nem vag a foldhoz.

A harnadik a pixelpontos kiadvany. Egy fotoalbum szoveggel, vagy egy baromi reszletes kapcsolasi rajz eseteben minden pixelnek fontos a helye es a szine, ott nem megengedheto hogy a Visioban szetesett doboz latszolag masik vonallal erintkezzen.

En a gondot ott latom, hogy sokan ezt a harmadik szintet varjak el az Offfice termekektol. Pedig az a masodik szintu feladatok ellatasara szolgal.

A collstok nem tolomerce, es a tolomerce nem mikrometer. Aki azon dramazik, hogy nem tized mm pontos a meroszalagja, az engem nem hat meg.

Abban igazad van, hogy az RFC kinotte a TXT formatumot. Egy kicsit a man oldalak is kinottek, de azert jo hogy ott vannak, es konzolbol ra lehet nezni barmelyikre anelkul, hogy el kene inditani a winword.exe -t egy grafikus felulet nelkuli linuxon. :-)

Ez szerintem is így van, nálam van a vi/emacs szint, a Word/Writer/Ppt/Impress szint, meg a kiadványszerkesztő szint. Az valóban probbléma, hogy nagyon sokan a Word/Writer szövegszerkesztőket kiadványszerkesztőnek próbálják használni, pedig arra nem igazán alkalmasak. A határ nálam ott van, hogy mit nyomtatunk saját nyomtatón, és mi megy nyomdába.

Mozgok mindhárom szinten, én ezt tenném hozzá: A Word/Writer szinten sokat használjuk a stílusozást, templátokat, pl hogy céges iratok/levelek/bemutatók egységesen nézzenek ki.

Egyébkénr a Mi a létjogosultsága vitához annyit, hogy nem látom, hogy az online szerkesztők korában mi a létjogosultsága az offline MS Officenak. Szerintem GDocs (és társai) le fogja őket nyomni idővel, hiába az Office 365 című förmedvény. 

Mi a búbánatért nyúl bele valaki egy LO állományba egy m$ Office-szal?

Jó tudom, Bill Gate$-től örökölt mentalitás miatt az m$ nem önzetlenségből nyomul az oktatási intézményeknél, hanem hogy - önző üzleti érdekből - a cég termékén nevelkedjenek a diákok, ne máson. Sajnos nem is szövegszerkesztést oktatnak az iskolákban, hanem Word adott verziójában lépéssorokat, műveleteket.

"Mi a búbánatért nyúl bele valaki egy LO állományba egy m$ Office-szal?"

- Több oka is lehet rá, pl. az van a gépére telepítve, tehát azzal fogja megnyitni. Nem tud arról, hogy ezzel milyen problémát okozhat. Nem tudja, hogy az adott dokumentum mivel készült. Nem érdekli, a törvény pedig nem tiltja.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Elvileg a docx ugyanolyan nyílt formátum, mint az odf, szóval mindkettőt mindkét szerkesztőnek (Libre Office és MS Office) azonosan kellene kezelnie. Nyilván ez az elmélet.

És mint tudjuk elméletileg az elmélet és a gyakorlat között nincs különbség, gyakorlatilag pedig van. ;)