Slovenska državna uprava gre na odprto kodo

Bistri007> Se ne mislim kregati, ampak Microsoft Office formati gotovo niso črna lunkja za tvoje podatke, kot bi želel prikazati Jype.

Za "moje" so, ker na mojem računalniku nobena od omenjenih reči ne deluje. Če mi država pošlje dokument v taki obliki, ga ne morem niti pregledat, ne da bi najprej plačal skoraj 250 evrov davka Microsoftu.

Kako točno si pri tem, da maš vse v odprtih, ISO certificiranih formatih, zaklenjen na karkoli? JU lahko shranjuje svoje dokumente z MS Office v odprta formata ODF in OOXML. Seveda po tistem, ko bo OOo.org nehal uporabljati svoje "razširitve" ODF standarda in siliti svojega vendor lock-ina.

Samo ker imate OpenSource pisarno, jo boste pa tudi komot popravili, da bo ustrezala obema odprtima standardoma.

Kje točno je problem?

A to je tisti odprt ISO standard, za katerega sprejetje je MS podkupoval babana republike, katerega se niti MS sam ne drži in v katerem so stvari v smislu "tu pa naredi tako kot naredi office 97?

Errr... preprosto tako, da se teh ISO standardov nihče ne drži 100%.

Razumem, torej menjujemo en kos softwara, ki se ne drži odprih ISO standardov za drug kos softwara, ki se ne drži odprtih ISO standardov in za to da bomo imeli podatke ujete v drugem nekompatibilnem standardu bomo zakurili kup denarja.

Je vsaj jasno.

Skoraj tako. Edina mičkena malenkost je samo še ta, da za OOo formate menda ni nobenih patentov, za MSO formate pa patenti so, vendar pa je MS dal besedo, da se ne bo posluževal tistih, ki pokrivajo ISO verzijo formata.

Glede na to, da tako Office 2007 kot 2010 lahko shranjujeta v ODF format, tole nekak ni lih razlika, saj se preprosto JU odloči uporabljat ODF namesto OOXML.

In če se še prav spomnim, 2010 pri prvem zagonu celo vpraša katerega izmed teh naj uporablja... Se mi zdi da bi bila cena takega "prehoda" precej nižja kot pa to kar predlagajo drugi.

Marsikaj se folku tule zdi...

Bom napisal eno zgodbico kako te "ekosistem" zajebe v praksi. V glavnem za Mavrika, trole tipa Cold1 pa prosim, da tegale ne berejo.

Torej - pred kratkim sem v eni dosti pomembni spletni aplikaciji (vsebuje precej pomembne in zelo občutljive podatke) neke ustanove odkril zanimivo varnostno ranljivost. Ko se uporabnik odjavi, cookie v brskalniku ostane in uporabnik lahko nadaljuje sejo. Torej - delam v aplikaciji, kliknem "odjavi" in če ne zaprem brskalnika, lahko nadaljujem delo v aplikaciji, saj sem ostal prijavljen. Problem je v bistvu v tem, da server nima neke tabele aktivih veljavnihsej, ki bi v primeru, da uporabnik klikne "odjavi" označila, da je seja neveljavna.

Jasno, spišem poročilo in sledi sestanek. Kjer mi začnejo pojasnjevat, da odprava te napake nikakor ni trivialna. Zelo zapletena in zelo draga bo.

Zakaj? Zato, ker aplikacija sama ne avtenticira uporabnikov, pač pa to dela nek zunanji modul. Zakaj ne? Ker so uporabniki "shranjeni" v LDAP direktoriju, aplikacija pa ne zna komunicirat z njim. Pač - firma, ki je to programirala, je tako naredila, rewrite ni možen, razen z velikimi stroški.

OK, kaj pa zunanji modul? Bi lahko on ob vsakem kliku preverjal veljavnost seje?

Pravzaprav ne. Ta modul namreč nima možnosti shranjevati seznama trenutno veljavnih sej. Namreč, uporabljajo nek IBM-ov LDAP, ki ne omogoča dodajanja več kot 5 (ali nekaj takega) atributov uporabnikom. Ker so hoteli userjem dodati več kot 5 atributov, so morali kupiti Oraclovo bazo (!). Ker če bi menjali IBM-ov LDAP, bi to potegnilo za samo cel kup drugih reči - menjava celega ekosistema stane.

Moje naslednje vprašanje je bilo - pri analizi aplikacije sem opazil, da so gesla lahko dolga max. 8 znakov. Zakaj?

Ker je to omejitev IBM-ovega strežnika. Saj bi lahko vse skupaj zamenjali - ampak menjava celega ekosistema stane. Lahko bi celo kupili nove strežnike, ki omenjeno funkcionalnost že imajo (in še 200 drugih), ampak to spet stane. Torej se bo živeli z 8-mestnimi gesli.

In pol razmišljam. Pred 10, 15 leti je bila ta tehnologija industry standard. Danes pa je obsolete. Ampak sistem je pa že postavljen. Rewrite celega sistema je nepopisen strošek. Torej jim ostane le, da čakajo kdaj bo neko funkcionalnost ponudil tudi njihov ponudnik ekosistema (če jo bo) in upajo, da bo cena čim nižja.

Bo pa vsekakor vedno nižja kot bi bila menjava ekosistema! (Stroškov vseh nadgradenj pa ne bomo seštevali. In stroškov izgubljenih priložnosti ne ocenili. Konec koncev - a je to da leta 2011 ne moreš imeti več kot 8 mestno geslo sploh strošek?)

Bistri007> Če je res tako, kot praviš, potem so res loleki tisti, ki vzdržujejo to aplikacijo.



Loleki, eh?

4. Po tihem zamenjati ekosistem in ko glavni crkne samo preusmeriti zadevo
5. Odprava celotne neumne veje uprave (is that possible?)

Koga briga, če backend nima veze? Če tega ne moreš spremeniti, ker si se zajebal pri ponudniku, zdaj ga pa ne moreš zamenjati, ker si nanj privezan z zelo drago migracijo, potem si očitno nekaj naredil narobe, ne?

In ker v MSO ne moreš določati, kaj vse se pri shranjevanju zapisuje v datoteke, bi bilo zelo dobro, če bi ponudnika zamenjali, pa nočejo, ker to stane skoraj toliko, kot nadgradnja.

Bistri007 je 28. mar 2011 ob 08:19 izjavil:

Spletna aplikacija mora cookie označiti kot potekel.

Nerelevantno. Ne moreš namreč zaupati client sideu. TI (se pravi server) MORAŠ vedeti kateri cookije je valid in kateri ne.

Bistri007 je 28. mar 2011 ob 08:19 izjavil:

Za primer, da bi kdo "ukradel" cookie, pa lahko narediš tabelo veljavnih sej s povezavo na čisto drugo podatkovno bazo, npr. Express verzijo DB2 ali MySQL.

Točno to sem predlagal. Ampak aplikacija je lastniška, pisana za specifičen ekosistem in bo vse skupaj drago.

Pyr0Beast je 28. mar 2011 ob 07:46 izjavil:

4. Po tihem zamenjati ekosistem in ko glavni crkne samo preusmeriti zadevo

Ja, samo to ni opcija, zaradi stroškov - pa verjetno tudi zato, ker bi se s tem priznalo zgrešenost preteklih odločitev.

Pyr0Beast je 28. mar 2011 ob 07:46 izjavil:

5. Odprava celotne neumne veje uprave (is that possible?)

Itak da ne.

Ja, samo eni tle pravijo, da ne moreš ekosistema menjat, ki je že utečen. Jaz pa dokazujem, da ti vztrajanje na zaprtem ekosistemu lahko prinaša hude stroške.

Ja, ocenjenih. Če pa govorimo o varnosti pa - eh, saj tega stroška se ne vidi, kajne?

Ja, gre za ene najbolj možnih občutljivih podatkov.

Če bi bil nov sistem bi jaz naredil reklamacijo. Pač nestrokovna izvedba sistema.

kitaj je 28. mar 2011 ob 08:58 izjavil:

BlueRunner je 27. mar 2011 ob 18:48 izjavil:

Ne. To je ISO standard za katerega je MS izkoristil ISO fast-track proces (kar ni nič posebnega) in ne vsebuje stvari v smislu "tu pa naredi tako, kot naredi Office XXXX". Je pa res, da se ga niti sam MS (še vedno) ne drži čisto oziroma je do neke mere proces tudi izigral.

Je pa v MSO 2010 kompatibilnost že zelo visoka.

Analiza Microsoftovega stila "tu pa naredi tako, kot naredi Office XXXX"
http://www.robweir.com/blog/2009/10/fin...

Mislim, da si tole povedal malo izven konteksta.

Celoten kontekst je, da imaš "transitional" in "strict" shemo, pri čemer se je iz strani vseh, razen is strani Microsofta pričakovalo, da bo "transitional" shema opuščena in bo kot merodajna ostala samo "strict". Transitional pa dejansko služi prehodu iz dejanske MSO imeplementacije v strikten ISO format. Proces sprejemanja zunanjih standardov v ISO nomenklaturo, kjer se je to na mala vrata vrinilo notri, pa je tisto, kar opisuje moja izjava, da je Microsoft "proces do neke mere izigral".

Na koncu tudi zato, ker se je odpovedal "strict" shemi in želi uporabljati samo še "transitional".

E pa sad...