A KDE és a The Document Foundation München esetleges visszaváltásáról

 ( trey | 2017. február 15., szerda - 8:32 )

Ma szavaznak a Münchenben arról az indítványról, amely leegyszerűsítve arra tesz javaslatot, hogy a város a munkaállomásain 2020-ig bezárólag váltson vissza Linuxról Windows 10-re. A nyílt forrású projektek közül a KDE és a The Document Foundation is állásfoglalást adott ki a tervezett szavazással kapcsolatban.

KDE projekt:

Idézet:
Specifically the move away from Free Software will

  • not actually fix the issues identified in the report by Accenture
  • remove vendor-independence which was one of the core arguments for moving to Free Software in the first place
  • incur estimated costs of €90 Million to be paid by tax-payer money. Another €15 Million are expected to be spent on replacing or upgrading hardware that cannot cope with the requirements of Windows 10 but runs fine with Linux.

A KDE projekt szerint a váltás szabad szoftverekről nem szünteti meg, javítja ki az Accenture jelentésben leírt problémákat, viszont megszünteti a gyártófüggetlenséget és közel 100 millió eurós költséget jelent majd az adófizetőknek.

The Document Foundation:

Idézet:
In spite of the suggestions, on Wednesday, February 15, Munich City Council will discuss a proposal – filed by a minority of city councillors – to install Windows 10 and MS Office 2016 on all workstations by 2020. This would cost taxpayers close to 90 million euro over the next six years, with a 35% aggravation over the 66 million euro figure suggested by Accenture.

In addition, according to estimates provided by Green Party councillors, another 15 million euros should be spent to replace or upgrade PCs which are perfect for a small footprint operating system such as Linux, but cannot support even a Windows 10 basic configuration. Last, but not least, most expenditures related to the purchase of Microsoft licenses will contribute to the GDP of Ireland (where all Microsoft products sold in Europe are sourced from) rather than to local enterprises who support the open source solutions deployed today. [...] Apart from the cost aggravation, the proposal under discussion ignores the main reason behind the decision to migrate from proprietary to open source software by the City of Munich, i.e. independence from a single software vendor and the move from proprietary to standard document formats.

A The Document Foundation szintén kiemeli a váltás költségeit, megjegyzi, hogy a kifizetett pénz Írország GDP-jét növeli, ahelyett, hogy a helyi (német), nyílt forrással foglalkozó vállalkozásokat látná el munkával. A TDF emellett szintén megemlíti a vendor lock-in és a szabványos dokumentumformátumokról proprietary formátumokra váltás problémáját.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

No Martini, no Party.

--
zrubi.hu

Van egy varázsige, ami minden jogos érvelést felülír: korrupció

--
robyboy

"filed by a minority of city councillors"

Reméljük, hogy a végén is kisebbségben maradnak.

--
trey @ gépház

A KDE és a TDF véletlenül azt hitték, hogy technikai érvek játszanak közre

yepp

--
robyboy

Az mikor vendor-independence, amikor függnek a Canonicaltol és a Libreoffice Foundationtől?

Azt az OSS huszárok mindig elfelejtik, hogy az is vendor lock-in, ha az egyik vendorról egy másik vendorra áll át az ember.

Nem "LibreOffice Foundation"-re váltottak, hanem egy nyílt dokumentumformátumra.

--
trey @ gépház

Ennyi erovel az OpenXML is nyilt formatum.

----------------------
while (!sleep) sheep++;

És még nyílt implementációja is van.

Rules and conditions may apply... (always in motion transition is the future :))

"Autospace like Word 95"

A szabvány 4-es részének (Transitional Migration Features) 14.8.3.4 autoSpaceLikeWord95 (Incorrectly Adjust Text Spacing for Specific Unicode
Ranges) fejezetében le van írva, hogy mit jelent ez pontosan.
Meg ebben a részben le van írva minden ilyen fogalom pontos definíciója.

A nyílt szabvány és specifikáció között tudtommal az a különbség, hogy az egyik esetén a szabvány következő verziójába több gyártónak is van beleszólása (ilyen az ODF), míg a specifikáció inkább leírja, hogy egy cég mit csinált (ilyen az OOXML). A feladat bonyolultságához képest valóban szép munkát végeztek az OOXML-es srácok, de ettől még nyílt szabványnak hívni az elkészült papírt tévedés.

Nektek se jo soha semmi. Visszasirod a .doc -ot, amirol kb. semmit nem lehetett tudni? #irony
--
Blog | @hron84
Üzemeltető macik

- never mind -

Nem neked szolt a dolog, vmiklos erti a celzast.
--
Blog | @hron84
Üzemeltető macik

Jaja, emlékszem, újabb csontváz a szekrényből, amivel kapcsolatban a Microsoft és a bribery szavakat gyakran emlegették együtt. :D

--
trey @ gépház

A LibreOfficeról MSO-ra váltást még nehezebb megindokolni. Tekintve, hogy számtalan európai kormányzati szervezet használ évek óta LO-t, igaz általában Windowson.

Igazabol nem. Egyetlen dologgal meg lehet indokolni: SharePoint/O365 integracio. Ez az, amit a LO jelenleg nem tud, es a kozeljovoben nem is fog tudni.
--
Blog | @hron84
Üzemeltető macik

Hát a helyes indok így szól: "MS technológiákat akarunk használni." Már sokszor és sok helyen kifejtettem, hogy két értékelhető út van: vagy MS technológiákat akarsz használni, vagy nem. Ha igen, akkor lehetőség szerint mindenből MS-t akarsz használni, mégpedig a MS által kijelölt úton maradva (azt, olyan beállításokkal/feature-ökkel, akkor és úgy upgradelve, ahogy ők mondják), különben szopsz. Ha nem, akkor viszont minimalizálnod _kell_ az MS cuccok használatát, mert ha nem teszed, leránt az örvény a mélybe. A kettő utat nem lehet keverni, az maga a tömény szopás. Ergó vagy MS-világot építesz, és akkor lehet SharePoint/O365, akkor MS Office-t akarsz, meg Exchange-et, meg Outlookot. Vagy nem MS-világot akarsz, és akkor menekülj az Exchange-től, Outlooktól, SharePointtól, de igazából az MS Office is az ellenséged. Köztes út nincs, szándékosan lehetetlenné teszik, hogy ott botladozzál középen, állást kell foglalnod.

"két értékelhető út van: vagy MS technológiákat akarsz használni, vagy nem"

Azért 2017-ben már legalább három út van:

1. Google. Windows notebook: OK, vagy gazdaságos Chromebook: OK. Tablet: OK. Mobil: OK.

2. Apple. MacBook: OK. iPad: OK. iPhone: OK. Lényeg, hogy csak Apple hardvert vásárolj és nem lesz gond.

3. Microsoft. Windows notebook: OK. Tablet: kicsit problémás lehet. Mobil: armageddon.

És végül

4. Saját szoftveres környezet felhőben. Windows/Linux/ChromeOS notebook: OK ha arra vagy böngészőre fejlesztettél. Tablet: OK ha fejlesztettél rá. Mobil: OK ha csináltál jó mobil appot.
Természetesen a negyedik úthoz kellő szoftveres kompetencia kell házon belül vagy egy jó partner. Münchenben szemmel láthatóan hiányzott a megfelelő kompetencia.
Én már 10 év után kétségeimnek adtam hangot. Miféle giga projekt az, amit 10 év alatt képtelenek befejezni?! Még szocializmus is csak 5 éves tervekben gondolkodott. Mikor is kezdődött München Linuxos projektje?!
Azóta a Google Linuxszal meghódította a mobil és tablet piacot, amikből vagy ötször annyit adnak el évente mint Windows pc-ből. Google mellett Amazon, és csillió OpenStack cég felhője kiváltotta a régi szerveres infrastruktúra legalább felét, szintén Linux alapokon. Már önvezető autók jönnek ki Linuxszal, a németek meg még mindig a nyomtatókkal meg dokumentumokkal szopnak. Szégyen!

Ritka, hogy egyetértünk, de a müncheni kompetenciák kérdésében ez a helyzet.
Viszont a 3. pontban sajna nem: a Microsoft megoldásai iOS-en és Androidon is jól (néha jobban...) működnek. A problémás, sőt az armageddon minősítést ezért nem értem.

Üdv,
Marci

A saját tabletes és Windows mobile eszközökre utaltam. Mint Windows ökoszisztéma ide kiterjesztett részei.
Android és iOS eszközöknél egyet értek veled. Már ami a MS Productivity appok nagy részét illeti és többnyire elérhetőek ezekre a platformokra.

Oke, meseld el nekem, hogy a LibreOffice milyen workgroup megoldassal integralodik, ideertve mondjuk egy felhos tarhelyre valo direkt mentest (Dropbox, Google Drive, OneDrive, iCloud, engem igazabol nem erdekel, melyik), barmilyen workgroup megoldast mondhatsz (es nem, nem erdekel az, hogy kulso alkalmazassal ez hogyan oldhato meg. A tetves Word beepitetten tudja, ezt kell uberelni.). Illetve erdekelne egy olyan, szabadszoftveres levelezoszoftver szerver-kliens paros, ami legalabb azt a funkcionalitast nyujtja, mint az Exchange-Outlook kombinacio, legalabb olyan konnyu uzembe allithatosaggal es hasznalhatosaggal, es pont olyan osszecsiszolt rendszerben, mint az MS alkotta paros.

Felreertes ne essek, en is verbeli szabad szoftveres harcos vagyok, es ahol lehetseges es ertelme van, igyekszem ingyenes, nyilt forrasu szoftverekkel problemakat megoldani. De sajnos latom a szabadszoftveres vilag hibait is. Ahhoz, hogy egy Exchange szintu levelezoszoftver osszerakasra keruljon, vagy iszonyu sok szopas kell, vagy valamelyik opensource Exchange imitaciot kell hasznalatba venni (Zentyal, OpenXchange, Zimbra, stb), amiknek mind-mind mas drawbackjei vannak, mas-mas szopasokkal. Kliensoldalon ennel meg sokkal durvabb a helyzet, a TB egy fos, es mar nem fejlesztik, alternativa (plane crossplatformos) nemigen van (az ilyen Opera Mail meg hasonlo borzalmaktol legyszi kimelj meg), a Linuxos appok meg... hat... mind a KMail mind pedig az Evolution - bar rengeteget kuzdenek veluk, de - meg messze van az Outlook minosegetol es feature-setjetol. Foleg ugy, hogy a KDE-sek epp megint ujrairnak mindent, mert az fun. Nekik.

De ugyanigy szo van az ActiveDirectory levaltasarol is. A Samba 4 mar rengeteg josagot hozott e tekintetben, de meg mindig instabil kepzodmenyrol van szo, az AD funkcionalitasat es integraltsagat hozo, de nem feltetlen SMB kompatibilis rendszerek meg eroteljesen gyerekcipoben jarnak (pusztan az alacsony penetreacio miatt), es valtozatos hibaktol kuzdenek. Ha meg nullarol akarsz ilyen rendszert epiteni, az megint csak rengeteg ido es szopas, amit ha beszorzol, jobban jossz ki egy Windows Server 2012 licenccel.

Szoval, en nagyon szeretnek nem-MS vilagot, de a szabadszoftveres vilag nagyon nem segit ebben. Szerverfeladatokra, web stackekre, clusterre, adattarolasra a szabad szoftveres vilag kismillio alternativat nyujt, de irodai felhasznalasra, csoportmunkatamogatasra nagyon-nagyon keves az olyan, batran ajanlhato szoftverkeszlet, amivel utana nincs lenyegesen tobb support munka, mint egy O365 kiajanlasa utan.
--
Blog | @hron84
Üzemeltető macik

LibreOfficeból még máig hiányzik a használható mobil app. Eddig tudtommal csak egy problémás Viewer van. Ebben egyet értünk.

Exchange-Outlook kombinació. Hát erre már ott a remek Google-Gmail vagy Inbox kombináció. A saját email szerver egyre inkább olyan luxus amit csak azok engednek meg maguknak akiknek:
- ez a hobbijuk.
- belefér pár évente egy egy szerverösszeomlás a korábbi levelek elvesztésével
- már úgyis a facebookot használják és csak ritkán emaileznek :)

Elég sok Exchange szervert láttam már összeomlani. Sajnos semmivel sem kevésbé problémás mint egy Linuxos email szerver. Ami a kliens oldalt illeti, számtalan okból kifolyólag web interface. Még Exchange szerver esetében is. Mobilon meg mondjuk K9 Mail.

Persze az Apple iCloud szintén remek megoldás, ha egyébként is Apple hardver van mindenre.

Ugyanez igaz a Samba, azaz közös tárhely megoldásokra. A felhős szolgáltatások a mai árai mellett már nem versenyképes alternatíva a saját szerveres megoldás.

"Elég sok Exchange szervert láttam már összeomlani. Sajnos semmivel sem kevésbé problémás mint egy Linuxos email szerver. "

Az összehasonlításról nem tudok nyilatkozni, mert nem üzemeltettem még Linuxos e-mail szervert.
Az Általad látott összeomlások okairól sem tudok mit mondani, hisz ezeket nem láttam közelről.
A tapasztalatom az, hogy az Exchange nem "problémás", hanem "komplex megoldás és ezért sokrétűen képzett, tapasztalt üzemeltetőt igényel".
Persze sejtem, hogy most jöhet, hogy a "problémás" az ugyanez meg én finomkodóan fogalmazok, de sebaj.
Akit érdekel a véleményem, megszívleli.
Amúgy láttam én már junior szerverüzemeltetőt komoly Exchange környezetért felelni. Az Exchange-nek nem is volt soha semmi baja, de az illető sajnos nagyon megküzdött ezért: túl gyorsan kellett felnőnie a feladathoz.

Üdv,
Marci

Ja, hát kicsi quotákba és ezáltal folyamatos email törlésekbe kényszerített userekkel üzembiztos egy Exchange szerver is. De pont ugyanez mondható el a Linuxos email szerverekről is. Ezúttal nem kell védelmedbe venned cégedet. Nem a MS szoftverében vagy a Linux+opensource megoldásokban van hiba. Egy idő után a hardver nem bír a folyamatosan növekedő adatmennyiséggel.
Most őszintén, 2017-ben versenyképes alternatívának tekinted a saját céges szervert GMail, iCloud.. stb nagy felhős szolgáltatók mellett??

Ha jol meg van csinalva, es jol ossze vannak rakva a kvotak, igen. Raadasul nem akarok az Exchange szoszolojanak tunni, de Linuxos rendszeren nemigen lehet ganyolas nelkul megcsinalni azt, hogy a felhasznaloi postafiokok tobb gepen teruljenek el.
--
Blog | @hron84
Üzemeltető macik

Linuxon lehet csak igazán megcsinálni ennek a szolgáltatásnak (is) a clusterezését.
Ami pedig a user quotakat illeti, egyre inkább az az igény, hogy quota ne legyen.

Hogyan? Marmint, nem nagyon van olyan imap/pop3 proxy, ami clusterkepes lenne.
--
Blog | @hron84
Üzemeltető macik

Hm? Mi a bajod a dovecot-tal?

Hogy osztod el a mailboxokat tobb gep kozott? Az NFS nem jatszik.

Fenntartom, hogy van valami uj fejleszted a Dovecotban, amirol nem tudok, de kisse nehezen tudom elkepzelni ezt rola.
--
Blog | @hron84
Üzemeltető macik

Nálam az "elosztani" azt jelenti, hogy az egyiket ide rakom, a másikat oda. Ezt LDAP user adatbázissal nevetve tudja a dovecot.
Elöl van egy gateway, ami az LDAP-ból authentikálja a usert, majd proxyzza az adott userhez tartozó backend szerverre a forgalmat. A gateway réteg állapotmentes, ergó lehet belőle több is, simán lehet közöttük round-robin vagy per source IP terhelést elosztani. A backendből nyilván per user egy darab lehet, ha rendundanciát akarsz, akkor kell alája valami failover cluster megoldás.

A gateway resze erdekel, azt hogy oldod meg Dovecottal?
--
Blog | @hron84
Üzemeltető macik

Authentikál LDAP-ból, kiolvassa, hogy hol a backend, és proxyzza a kérést.
Nálam csak egy backend van, de a seamless per-user migrációhoz ez tökéletesen használható (ugye ezzel egyesével tudom a felhasználókat mozgatni), ezért összeraktam és utána így maradt. Minimális extra terhelést jelent.

http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy

hosts = 127.0.0.1
base = ou=Mailboxes,dc=domain,dc=hu
auth_bind = yes
pass_attrs = =user=%{ldap:mailLocalAddress},=host=%{ldap:mailHost},=proxy=y
pass_filter = (&(objectClass=inetMailbox)(mailLocalAddress=%u))

Hmm... ez 2.x.y feature, akkor ezert szamit nalam ujnak, Dovecot 2-vel sajnalatos modon nagyon keves rendszert implementaltam meg, amiket meg uzemeltetek, az 1.x.

De nem bypassolja az authentikaciot a backendeken ugye? Tehat ugyanugy be kell konfiguralni a central authentication source-t a backendeken is, mint a frontenden, es a frontend csak papagajkodik az authentikacios paranccsal?

A doveadm mennyire tamogatja ezt az egeszet? Migralni manualisan szoktal?

elnezest, hogy ezt a szalat elviszem erre, de van egy tervem, amihez ez a rendszer nagyon passzolna
--
Blog | @hron84
Üzemeltető macik

Hát, a 2.x nem mai gyerek pedig már... én szerintem évek óta azt használom.

Nálam semmit nem bypassol (azaz mindkét réteg ellenőriz), minimális a konfig különbség a gateway meg a backend között (a backend LDAP filterében benne van a saját neve, így aki nem nála lakik az LDAP szerint, azt be sem engedi).
Azt biztosan meg lehetne csinálni, hogy a frontend semmit ne ellenőrizzen, csak kiolvassa a user entryt az LDAP-ból, aztán pöttyintse is tovább egy-az-egyben, ha van hová.

A doveadmot nem használom, bár néha észre szoktam venni, hogy mennyi mindent tud. A migrálás teljesen manuális volt, scriptből, rsync-kel.

1) Hat, nekem meg evek ota nem volt uj implementalasom, hogy utana nezzek az uj feature-knek.

2) Ez jo otlet, lopom :D Bar nekem SQL-bol jonnek majd a parasztok, kerdes, hogy ott meg fogom-e tudni csinalni...

3) Nekem izgatja a fantaziamat, bar en leginkabb csak a quotazashoz es a kukazashoz hasznalom, meg neha mailbox infokhoz.
--
Blog | @hron84
Üzemeltető macik

:) megnéztem, 2011 júniusában váltottam 2.0.13-ra (ami akkor már "stable" keywordű volt, nyilván már egy ideje megvolt akkor a 2.x-es széria).

Nekem volt egy implementaciom valamikor '13 kornyeken, akkor szembejott a 2-es, de oda egy teljesen alap rendszer kellett (visszapattanokezeles miatt kellett egy IMAP/POP szerver, tettem bele kvotat, de ennyi). Azon felul csak mar kesz, atvett rendszereket uzemeltettem. '15 kornyeken volt egy kiserletem, hogy na akkor most kitapasztalom a kettest, mert lett volna egy bonyolultabbnak kinezo hosting projekt, de vegul abbol is egy majdnem default setup lett, kvotazas kellett meg kuka kezeles, de a tobbszerveres setupbol vegul anyagi okok miatt (as usual) nem lett semmise. Nekem meg oszinten szolva elvette a motivaciomat a sok kavaras a projekt korul, szoval a vegen meg az LDAP-ot se neztem meg, valami tutorialbol odavagtam egy SQL-es authentikaciot, meg lett ele egy postfixadmin oszt' jovan.

Azota meg nem voltam komplexebb projekt kozeleben, pedig imadok levelezessel szorakozni.
--
Blog | @hron84
Üzemeltető macik

Van postfix varazslo is. Megkerdezi milyen mailszervert akarsz oszt enter. Egyablakos ugyintezes, na!

> Hogy osztod el a mailboxokat tobb gep kozott? Az NFS nem jatszik.

Miért nem játszik? (Mit adtak nekünk a rómaiak?)

Egy másik opció a shared filesystem-eken kívül a Replication with dsync.

Interview with Timo Sirainen Dovecot's way of scaling to millions of users

Részlet:

 Q: What is the biggest Dovecot installation you know of (in terms of the number of users)?

 That’s Deutsche Telekom with 26 million users.

Dovecot's way of scaling to millions of users (video)

Az NFS-t inkabb hanyagolnam levelezesre. Van mar vele tapasztalatom, es nem. Nagyon-nagyon nem.

--
Blog | @hron84
Üzemeltető macik

Más network filesystem se jöhet szóba, pl. GlusterFS?

Azon lehet, hogy elgondolkodnek. Tests required. NFS and DRBD are banned.
--
Blog | @hron84
Üzemeltető macik

Azért a Google például elég jól megoldottal globális méretben Linux serverekkel.
Ami saját email clustert illeti, az adatbázisnál érdemes elindulni aminek a clusterezése gondolom neked is ismerős. Adatbázis kapcsolatra pedig mondjuk http://dbmail.org/

"Azért a Google például elég jól megoldottal globális méretben Linux serverekkel. "
Jaja, saját, proprietary mailserverrel.

Esetleg tovább juthatnál az első mondatnál.

Pedig ez jo meglatas volt a kollega reszerol tekintve, hogy mi is valojaban a tema.
--
Blog | @hron84
Üzemeltető macik

Hát neked sem sikerült túl jutni az első mondaton. Néha komolyan megdöbbentő az informatikusok bénasága. :)

De, kicsit lejjebb tuljutottam az elso mondaton, ettol meg valid a felvetes.
--
Blog | @hron84
Üzemeltető macik

enpassant fentebb azóta részletezte a cluster fájlrendszeres megoldást. GlusterFS szerintem is jó. Vagy a MooseFS szintén jó választás.
Clusteres SQL backendhez pedig linkeltem a dbmail oldalát korábban.

Erdekelne, hogy hany ilyen projekten vagy tul. De komolyan.

Egy email rendszer osszerakasa nem pusztan annyi, hogy keritunk valami db-t/fs-t ratoszunk egy POP/IMAP szervert es mindenki happy. Eleve, POP/IMAP szerverek kozott is szimfonianyi kulonbsegek vannak (vo.: "ha zongorazni lehetne a kulonbseget, szimfonia kerekedne belole"), az ilyen "taroljunk adatbazisban leveleket" cimu szosszenetek pedig tobb kerdest vetnek fel, mint amennyit megvalaszolnak.

Eleve clusterezni is nyugos egy ilyet (hatalmas blobokat tarolunk db-ben), aztan kerdes, hogy a kereseshez kepes-e az IMAP szerver valami ertelmes keresomegoldassal operalni (pl. ES), vagy az RDBMS motorra van az egesz bizva.

Aztan kerdes a kompatibilitas, Outlook, OperaMail, TB, RoundCube - csak par az ilyen vagy olyan szempontbol problemas kliensek kozul.

Aztan a csoportmunka sem csak leveledzesbol all, calendar, nevjegyek, targyalokezeles, stb. Mindenre van megoldas, de mindent meg kell egyesevel valositani, kezdve a workflow-val. Ellenpontkent meg ugye ott van az, hogy a felhoben workflow-val egyutt minden keszen all, az egyetlen realizalando kerdes a best practice lista, meg a konkret munkavegzes dokumentacioja, that's all.
--
Blog | @hron84
Üzemeltető macik

Ha apt-get install cluster-email-servert típusú megoldást keresel nem fog összejönni.
Bonyolult egy email szerver összerakása? Hát nem mondtál újdonságot. Clusterezésre írtam neked, hogy az adatbázist érdemes clusterezni. Ugyanúgy FooSQL-be rakja a leveleket, csak azok mögött nem egyetlen fizikai szerver áll adatbázissal hanem egy cluster.

De mondok egyszerűbbet. Próbálkozz csak fájlrendszer clusterrel. A problémát először a háttértár lassúsága jelenti a növekvő adatok mellett. Nem annyira hatékony mint az adatbázis cluster, kezdetnek megteszi.

"Outlook, OperaMail, TB, RoundCube"

Ha neked máig ezek jelentik a kliens oldalt, az elég szomorú. Roundcubenál vannak már sokkal jobb webmailek, amik mellett nem is kell natív kliens PC-re.

"Ha neked máig ezek jelentik a kliens oldalt, az elég szomorú. "
Nem csak te létezel a világon, hanem az ügyfelek is. És mindenki azzal kezeli a leveleit, amivel neki tetszik.

"És mindenki azzal kezeli a leveleit, amivel neki tetszik." Persze! Csak akkor nem kell panaszkodni ha az elavult natív kliens miatt problémák vannak.
A világ usereinek túlnyomó része az elmúlt években webmailre váltott. Még a hup népénél is webmail az első, pedig ez egy átlagtól alaposan elütő társaság informatikai igényekben.

Roundcubenál vannak már sokkal jobb webmailek

Na, mesélj! Én tuti le vagyok maradva, de eddig még csak a RC-nál szarabbakat láttam. Ha van nála jobb, sőt, több is, na az örvendetes.

Zarafa, SOGo.

"apt-get install cluster-email-servert típusú megoldást keresel nem fog összejönni."

Ehhez kepest az Exchange szerver az kb. apt-get install cluster-email-server modszerrel mukodik, legalabbis nem 4-5-6 kulonbozo, egymassal csak erintolegesen kompatibilis szoftvert kell osszecsiszolni.
--
Blog | @hron84
Üzemeltető macik

Mennyié'????

Lehet, hogy nem kell annyit összecsiszolni, de pont ugyanúgy hazugság az, hogy 2 óra alatt a 70-es IQ-jú takinéni is telepíti és bekonfigurálja, ahogy a Windowsnál is pont ugyanúgy hazugság ez.
Egy mai mail rendszer komplex, nem lehet megúszni a hozzáértést. Az elején sem, pláne nem később, az üzemeltetés során.

Nem a hozzaertest lehet meguszni, hanem a szopast a telepites mechanikus reszeben. Lehet kopkodni a Microsoftot annyit, amennyit akarjuk, de azert ez a varazslos megoldas minden hibajaval egyutt elegge ott van.
--
Blog | @hron84
Üzemeltető macik

"Ja, hát kicsi quotákba és ezáltal folyamatos email törlésekbe kényszerített userekkel üzembiztos egy Exchange szerver is."

Az Office 365 szolgáltatást Exchange szervereken nyújtja a Microsoft, 50GB és 100GB operatív mailbox-mérettel, számos csomagban korlátlan archívummal. És még a hardver is bírja. :)
Ezek alapján nagyon érdekelne, mire alapoztad az állításodat...

"Most őszintén, 2017-ben versenyképes alternatívának tekinted a saját céges szervert GMail, iCloud.. stb nagy felhős szolgáltatók mellett??"

Most őszintén:
-nagyon régóta foglalkozom e-mail SaaS-el.
-sokszor elmondtam, hogy a legtöbb ügyfélnek alighanem jobb választás egy felhős megoldás.
-általánosságban nem negligálnám a helyi környezetet mindezek ellenére. Ugyanis nem mindig a versenyképesség az elsődleges. Előfordul az is, hogy olyan törvényi/szabályozói/belső elvárás van, aminek a felhős megoldás nem felel meg.
Egy nagyvállalat pedig bír bonyolult is lenni, így cseppet sem hátrány, ha hibrid kialakításra könnyen van mód és az Ügyfél kezében a potméter, hogy mennyi legyen éppen felhőben vagy a saját géptermében.

Üdv,
Marci

Szóval szerinted is felhő. Én is így gondolom. Az extra igények és hibrid megoldások kiválóak, ha így nagyobb pénzmagot lehet lefejni a szervezetről, amelynek különben semmi szüksége nem lenne rá. Semmi jó elrontója nem vagyok. :) De a realitás az, hogy a felhős szolgáltatások mellett emailben is egyre kevésbé maradnak versenyképesek a saját céges megoldások. Akinek ez kell, egyre mélyebben a zsebébe kell nyúlnia. Vagy kompromisszumokat kell kötnie.

Már majdnem egyetértünk ebben-abban, erre tessék, belepancsolok: ezt mire alapoztad, ha egy egész Office 365 szól ellene: "Ja, hát kicsi quotákba és ezáltal folyamatos email törlésekbe kényszerített userekkel üzembiztos egy Exchange szerver is."?

Üdv,
Marci

Még mindig kizárólag saját hardveren működő szerverről van szó.

Miért lenne különbség műszakilag? Ugyanaz az Exchange mitől lenne csak kicsi kvótákkal üzembiztos és miért nem bírja a hardver a növekvő adatmennyiséget attól, hogy saját gépteremben futtatom?

Üdv,
Marci

Ez a kör már megvolt. Nem a MS szoftverében vagy a Linux+opensource megoldásokban van hiba.
Mindegy, hogy Exchange, vagy valamelyik Linuxos email megoldás. Sok email után egyre lassabb lesz a millió levél beolvasása. Ramot sem lehet a végtelenségig növelni, a háttértár io pláne korlátos. A levelek számának növekedésével egyre lassabb lesz a keresés, megnyitás stb.

20 giga levelet tartalmazó mailboxomon lassulásnak soha semmi tünetét nem tapasztaltam.
Exchange esetében nem tényszerű, amit írsz.
Adós maradtál annak megmagyarázásával, miért nem megy az Exchange-nek saját gépteremben, ami az Office 365-ben igen.

Üdv,
Marci

Office 365 szolgáltatás alatt egy nagy cluster dolgozik. Ezt saját gépteremmel nem fogod megközelíteni.

Szerintem érdemes lenne jobban megismerkedned ezzel a technológiával, mielőtt ilyen határozott kijelentéseket teszel.

Üdv,
Marci

Aha, voltak tapasztalataim. Pár éve egy munka kapcsán céges email használatával, ami mögött exchanges szerver állt. Kín volt használni Gmailhez képest, csak sajnos kötelező volt. Neves cég szervere volt, nem kezdő rendszergazdákkal.

TBH az O365 se jobb, bar az joreszt inkabb a frontend szegyene.
--
Blog | @hron84
Üzemeltető macik

Amikor átállhatsz alacsony tranzakciós költséggel egy másik, gyakorlatilag független vendorra ami ugyanazt a terméket/szolgáltatást adja az nem lock-in.

Ha gondod van OSS Ubuntu/Debian csomagokkal azt egy csomó
konzultáns is meg tudja oldani [1], míg a zárt forráskód természetes monopóliumot és ezáltal vendor lock-int teremt.

[1] https://www.debian.org/consultants/
--
http://balintreczey.hu/blog

#define "független vendor"
#define "ugyanazt a terméket/szolgáltatást"

Ez a konzultansi szolgaltatas baromi jo, Magyarorszagon van komoly ketto darab(!). Segitek, Microsoftos tamogato emberkebol igy masfel nagysagrenddel tobb van. Menj mar. Nemetorszagban van 62. Es nincs garancia, hogy barmelyik elerheto, plane azonnal. Ez egy kalap lotragya, de legalabbis semmikeppen sem olyasmi, amire egy komplett varos uzemelteteset ra lehet bizni.
--
Blog | @hron84
Üzemeltető macik

Egyik vendorról vándorol a másik vendorra?

--
robyboy

Lényeges különbség, hogy ha bugot találnak, akkor nem egyetlen beszállító javíthatja jogi értelemben (és forráskód híján technikai értelemben is), hanem tulajdonképpen akárki, akinek a tudása megvan hozzá.

Tehát:

Zárt szoftver: egy cég javíthatja, aki önkényesen megszabhatja az árat, vagy úgy is dönthet, hogy nem javít. Ez a vendor lock-in.

Nyílt szoftver: bármely kompetens cég javíthatja, ezért jobban érvényesül az árverseny. Ha úgy dönt valaki, hogy nem javítja a hibát, akkor megbíznak mást. Ebben hol van vendor lock-in?

"Ha úgy dönt valaki, hogy nem javítja a hibát, akkor megbíznak mást. Ebben hol van vendor lock-in?"
Ha ez így lenne, akkor nem fordulnának elő hibák opensource szoftverekben. Mégis tele vannak hibával. Mert általában nincs kompetens fejlesztő, aki ki tudná javítani a hibát. Nézd meg, a LibreOffice-t is a kommiterek halmaza javítja, senki más. Nem fog egy cég arra várni (és kifizetni), hogy RandomJózsi majd jól beletanul a LibreOffice szoftver architektúrájába, kiismeri magát, kidebugolja a hibát, majd kijavítja, majd megvárják, hogy a következő update-ben mikor lesz benne (vagy megvárják, míg RandomJózsi megtanulja buildelni a dolgot).
Ugyanaz folyik, mint a zárt kódnál: "hiba bejelentve, meg kell várni a release-t, mire kijavul".

A szövegértéssel komoly gondok vannak. Vagy pedig széndékos csúsztatásról van szó.

A forráskód elérhetősége és felhasználhatósága nem a hibamentességet garantálja, hanem a javítás lehetőségét / szabadságát.

Külön röhelyes ilyen baromságot felhoznod egy olyan szoftverről, amelynek történetének egyik kulcseleme az, hogy olcsóbb volt megvenni az eredeti feljesztőcéget és ingyenessé, nyílttá tenni a programot, mint fizetni egy vagon pénzt az MS-nek az ő szoftvereik licenszelésére.

Láthatóan arról sincsen semmi fogalmad, hogy a nyílt forrású szofverek fejlesztésébe is sok nagy cég beszáll, pont az előbb is említett okból. Esetleg valamilyen alapítványon keresztül pénzzel, de inkább úgy hogy saját maguk foglalkoztatnak fejelsztőket, hogy a számukra fontos funkciókat és javításokat előrébb vigyék:

https://wiki.documentfoundation.org/Development/Developers

Cégek: Canonical, CIB, CloudOn, CodeWeavers, Collabora, Credativ, Igalia, ITOMIG GmbH, Lanedo, Linagora, Mandriva, MultiCoreWare, Openismus, Planamesa, Red Hat, Inc., Sonicle, SUSE / Novell, Synerzip, Xamarin

Lathatoan fogalmad sincs arrol, hogyan dolgoznak azok a cegek, amelyeknek 20-nal tobb ugyfeluk van. Megsugom: senki nem fogja a te egyedi hibadat azonnal kijavitani, hanem szepen beleteszik a kovetkezo frissitesbe vagy release-be. Illetve hadd pontositsak: lehet olyan tamogatast venni, amelyben egyedi fixeket csinalnak, de ehhez meg Munchen penze sem eleg. Been there, done that.

--
L

szerk: á közben megértettem hogy persicsb release várásán lovagolsz. Először nem értettem, hogy mi köze a kommentednek a vendor lock-in félrehazudásához vagy a javítás lehetőségéhez. De aztán rájöttem, hogy ahhoz semmi, hanem csak zárt rendszeres logikát akartok ráhúzni egy nyílt rendszerre.

Ha a cégem számára szükséges egy javítás, akkor nyílt szoftvernél:
a) bejelentem és várhatom a megoldást ölbetett kézzel
b) fizethetek cégnek, hogy javítsa meg és a közös kódbázisba küldje is be*
c) lehet alkalmazottam, akit azért fizetek, hogy a számomra fontos részeken dolgozzon és a közös kódbázisba küldje is be

release kapcsán
a) várhatom a megoldást tartalmazó hivatalos kiadást
b) használhatok bármilyen release közti verziót*
c) patchel javított hotfix verziót készíthetek, míg a hivatalosba be nem kerül*

(*: a munkám során voltak ilyen megbízásaink, de sima linux repóknál is gyakoriak a pachelt csomagok)

Ms esetében pedig:

- Várhatsz a csodára
- kínálhatsz egy valag pénzt, hogy javítást csináljanak és hotfixként kiküldjék
bárhogy is, vagy megcsinálják vagy nem.

Csak akkor biztos a javítás, ha a teljes ms-t megveszed és te mondhatod meg mivel foglalkozzanak.

Ha a cégem számára szükséges egy javítás, akkor zárt szoftvernél:

a) bejelentem és várhatom a megoldást ölbetett kézzel
b) fizethetek cégnek, hogy javítsa meg és a közös kódbázisba küldje is be*

(* illetőleg, ez automatikusan megtörténik, ezért külön nem kell fizetnem)

Idézet:
release kapcsán
a) várhatom a megoldást tartalmazó hivatalos kiadást
b) használhatok bármilyen release közti verziót*
c) patchel javított hotfix verziót készíthetek, míg a hivatalosba be nem kerül

A b) es c) az egyik leggyakoribb hiba, amit elkövetnek a rendszergazdák. Azt felejti el mindenki, hogy ha a javításod mégsem kerül be a közös kódbázisba (ez reális kockázat, mert ez nem feltétlen kizárólagosan pénzkérdés), akkor a cég üzemeltetésének kutya kötelessége magára vállalni a szoftver naprakészen tartásását, és a custom patchek az aktuális kódbázishoz igazítását. Ez mindent összevetve (kiesések, mérnökórák, betanulás, a manyeyeballs hiánya, a tesztelés költsége stb). lényegesen drágább, mint supportot venni egy zárt forrású szoftvergyártól.

Egyébként ha prémium supportot fizetsz az MS-nek, és hotfixet igénylő hibád van, zokszó nélkül megcsinálják, szállítják. Nincs olyan, hogy nem csinálják meg, mert az szerződésszegés. Míg egy opensource fejlesztőt sosem fogsz tudni felelősségre vonni azért, mert nem javította ki a hibát, vagy nem olvasztotta be a patchedet a fő forrásfába.
--
Blog | @hron84
Üzemeltető macik

LOL!

Te ezt a bullshit komolyan elhiszed, amit leírtál?

Még előző munkahelyemen volt egy ügyfelünk. Nagy bank. Úgy értem nemzetközi méretekben. Ha bankot kell mondani, ami nemzetközi szinten ismert, lehet te is az ő nevüket nyögnéd be. Igen, UK-ból való bank.
Noss, náluk sikerült belebotolni olyan problémába, hogy bekapcsoltak egy csomó debug log üzenet küldését a windows szerverükön.
Ott egyszerű agent az eventlogból simán felolvasta a logokat, és valamelyik syslog protokollon beküldte központi logszerverbe.
Beküldte volna.
Ti. időnként, teljesen véletlenszerűen az eventlog csak szemetet tartalmazott, és amikor az API-ján keresztül megpróbáltad felolvasni, csak széttárt kezekkel pislogott.
Mi meg lelogoltuk, hogy hoppá, gebasz van, az eventlog az X ID-jű entryje, memóriaszemét, kb. ezt látjuk, gebasz,..
Sikerült megértetni velük (mikor az eventlog konténerben megtaláltuk a szemét, és még a saját eventlog browsere vagy mi a nyavaja sem tudta az adott entryt megmutatni), hogy itt a probléma az OS / eventlog körül van.
Sebaj, sokat fizetnek (NB.: r..t nagy bank!) a MS-nek, kommunikáljuk le velük a problémát.
Pár kör indai után eljutottam uk-beli MS mérnökökhöz (bár nekem még az ő nevük is indiainak tűnt), akik további pár hónap után csak annyit tudtak mondani, hogy... hát, ezt rohadt nehéz reprodukálni, nem tudják hogy kellene megoldani.

Szóval, az hogy tonnaszámra lapátolsz pénzt a MS-nek, SEM feltétlenül garancia arra, hogy neked ki fogják javítani a problémát.
És amikor ilyen fontos dologról van szó (valószínűleg memória corrupciós hiba a naplózás körül!), akkor csak pislognak.

De... örülök, hogy te hiszel az álomvilágodban! Biztosan megnyugtató érzés! /o\

Mondjuk lehet segített volna, ha az a bizonyos rohadt nagy bank nem a beszállítójával próbálja megoldatni random support csatornán keresztül, hanem előveszi a nevesített kontaktját (csodálkoznék, ha az ms nem adna ilyet), aki tudja, hogy kit kell belül elővenni ahhoz, hogy az igényed rendesen megnézzék.

Hat, en ugy tudom, hogy nevesitett kontakt nem nagyon van (az MS k. nagy ceg, eleg komoly fluktuacioval), cserebe a premium supportnal en ugy tudom, nem indiaiakon kell keresztulvergodni, hanem egy online hibareport egybol mernokok veszik fel a kapcsolatot veled. De majd mrceeka vagy gelei kijavit.

Sajnos a MS non-premium customer-facing supportja ritkan van a helyzet magaslatan, alultajekoztatottak, rettenetesen szettagoltak, alig vagy egyaltalan nem latnak ra mas support reszlegek munkajara, es sokszor ostoban van megallapitva a jogosultsagi szintjuk. Rendszeres a korbekuldozgetes (vagy a meg rosszabb: "varj, megkerdezem az XY termekkel foglalkozo kollegakat, lattak-e mar olyan embert, aki hallott mar ilyenrol), a tippelgetes, es a vakszerencsere kell biznod magad, hogy az, akivel epp beszelgetsz, egyaltalan latta-e mar mukodni azt a funkciot az adott termekben, amivel neked epp bajod van. Ez kivaltkepp erinti a 2-MSINFO munkatarsait, de gondolom a tobbi orszagban se jobb a helyzet.

Ezzel egyutt, ha sikerul a megfelelo support vonalon elindulni, es mernokhoz kerulni, egesz jok az eselyeid.

Nekem eddig 4 v 5 alkalommal volt szuksegem az MS supportra, es akkor oldodtak meg a problemaim, amikor mernokhoz kerultek. Addig csak a kodpiszkalas ment, meg a "probalta mar ujrainditani?". Persze mindig magyar cegeknek dolgoztam, olyan, hogy premium support, szoba se jott.
--
Blog | @hron84
Üzemeltető macik

Nem tudom, hogy sikerült félreérteni amit írtam.
Nekifutok még egyszer:

Mi voltunk neki a beszállító a saját termékeinket illetően.
A MS volt neki közvetlenül a beszállító a saját dolgaikat illetően.
Innentől direktben voltam MS mérnökökkel összekötve, és már nem volt olyan facepalm ikon a neten, ami le tudta volna írni akkoriban az érzéseimet a MS mérnökeinek inkompetenciáját illetően, annyira szájbarágósan kellett elmagyarázni nekik mindent.

"Pár kör indai után eljutottam uk-beli MS mérnökökhöz (bár nekem még az ő nevük is indiainak tűnt)"

Értem én a szitut, csak kissé meglepő, hogy a bazinagy banknak nem volt olyan kontaktja, aki megspórolta volna a pár kör indiai mérnököt. Más cégek ebben a méretben adnak olyan contactot, akit ilyenkor be lehet találni, valamennyire képben van azzal, hogy ki vagy, azzal meg biztosan, hogy viszonylag fontos ügyfél vagy, és képes olyan belül olyanhoz irányítani, aki azt se érti, mit kérdezel. Általában még azzal is szoktak tudni mit kezdeni, ha aki kezeli, az nekiáll pingvinezni (ha más nem, megmondják mennyibe fáj, hogy értelmes ránézzen). Lehet, hogy ennyire fos az MS supportja, de felmerült bennem, hogy az ügyfeletek beszopatott titeket :) Sóherek voltak, és nem volt rendes supportjuk, mert értünkmihozzá, és/vagy hadd szopjon vele a másik szállító, neki az nem drága.

Őszintén szólva én lesz...om, azt is ha csak az indiai mérnök tartja velem a kapcsolatot, meg rajta keresztül proxyznak.
Engem egy dolog érdekelt volna: Javítsák ki.

Azt meg kevéssé hiszem, hogy beszopattak volna, vagy sóherek lettek volna.
Találkoztunk sóher ügyféllel. Messziről szaglottak. Velük volt a legtöbb probléma, nyitotta a ticketeket észnélkül, fikázott észnélkül, doksit olvasni derogál, még úgy a "szakmához" se volt fingja se, de valami kis garázsnál nagyobb cégben valahogy két kenguru helyett őt sikerült megtalálják it-vezetőnek, és a legkisebb fos csomagot vették
f99-style inlet: talán valami évi 2k dollár körül ha hagytak a kasszában. Már majdnem gyűjtést kezdtünk a supporton, hogy összedobjuk neki a pénzt, odaadjuk a sales-nek, hogy lesznek szívesek visszaküldeni neki, csak többet ne halljunk felőle
, ahol SLA szerint 1 hónap van reagálni az olyan típusú picsogásokra, mint amikkel ő jött, de kb. gyorsabb reakcióidőt várt volna el, mint a leg-prémiumabb csomagot kazalszámra eladó partnerek, és még lehetne hosszan a sirámokat sorolni.

De NEM erről volt szó ebben az esetben! Ez egy jó nevű Angol bank (vagy talán a legnagyobb / legjobb nevű).
Egy rossz szót nem tudok felhozni rájuk. Korrekt szakértelemmel, mindennel. Velük, ha bármi problémájuk volt, kifejezetten szerettem dolgozni. Megesett velük, hogy elb..ták a tervezést, és megcsúsztak a határidővel, de olyankor szépen kezet tördelve kezdték a ticket, hogy bocsi, de ez most kb. sürgősbe kéne. És még a sürgősbe is kb. annyi volt, hogy na jó, kb. tervezhető legyen, és legalább ha hétfőn nyitották a ticket, akkor kb. Péntekre legalább tudjuk megmondani mi a probléma, és legyen akcióterv, hogy lehet-e workaroundolni átmenetileg, tudjuk pontosan mekkora az impakt, lehet-e mitigálni, ill. hogy ezek ismeretében sürgős jeligére generáljunk nekik egy bugfix release-t, vagy ráérnek kivárni a következő maintenance release-t, aminek a changelogjában az XY hibajegyre való hivatkozást kell majd keressék. Szóval kb. a Köcsög József típusú üf. szöges ellentéte.

Szóval visszatérve a dolgora: Már első körtől kezdve mérnökkel voltam összekötve. Az, hogy belül mit hogy szerveznek, számomra irreleváns. Nem érdekel. És azt gondolom, akkor van jól szervezve, ha nem is kell tudjak róla. Nekem "1 darab interfész" kell. Pont. Bár nem én voltam az üf-ük, hanem a fent említett bank. De kb. az üf-ek is azt szeretik általában, ha kb. '1-kapus rendszer' van.
A "témakört" tudtuk, hogy eventlogról van szó. Nyilván nem office fejlesztőkkel fognak összekötni. (Gondolom, ennyire azért még a MS-nél sem kukák.)
De a válasz kb. stílusa, meg hogy meg merik engedni maguknak, hogy ott egy hiba. Ami ráadásul memóriakorrupcióra enged utalni.
És le se szarják, mert "nehéz" precízen reprodukálni, mert csak "saccolni" lehet, hogy kb. egy héten belül meg fog történni...
Noss, az nekem elég gyenge kifogás.

Én hiszek neked, tényleg csak a leírásból úgy tűnt, az a baj, hogy nem találtok el a megfelelően kompetensig, miközben kellett volna legyen egy viszonylag rövid útnak oda.

"Nekem "1 darab interfész" kell. Pont. Bár nem én voltam az üf-ük, hanem a fent említett bank. De kb. az üf-ek is azt szeretik általában, ha kb. '1-kapus rendszer' van."
Kb. Baj akkor van, mikor az 1 darab interface a foglamatlan support. Ugyanis a supportnak nem feltétlen az a dolga, hogy bonyolult problémákat oldjon meg. Ezért szokott lenni lehetőség valami értelmes kontaktra, aki tudja ki vagy, ismeri, hogy kb mi van nálad, illetve felfogja, hogy itt most nem supportos ügy van, hanem adott esetben pl egyedi fejlesztést kellene csinálni, be kéne vonni az integrációt, vagy ki kéne küldeni egy értelmes mérnököt helybe.

És értem én, hogy az MS nagy, de nekem furcsa, hogy egy ilyen eseben ez nem jut el addig, mert nem nézem ki belőlük, hogy nagy ügyfelet a saját szoftverük bugjával azzal hajtanának el, hogy "bonyi kideríteni mi van". Olyat igen, hogy "hát, leszarom ezzel élj együtt" de nem a probléma kiderítése előtt.

> e kéne vonni az integrációt, vagy ki kéne küldeni egy értelmes mérnököt helybe.

Az az eset fel se merulet,
hogy az ms-nel nincs egyetlenegy ember se aki kepes lenne kidebugolni és kijavitani? :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

De természetesen felmerülhet. Úgy lettek a világ talán legnagyobb szoftvercége, hogy kizárólag balfaszokat alkalmaznak.

Akkor egyre gondolunk:))

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Akkor egyre gondolunk:))

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

;-)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Egyébként ha prémium supportot fizetsz az MS-nek, és hotfixet igénylő hibád van, zokszó nélkül megcsinálják, szállítják. Nincs olyan, hogy nem csinálják meg, mert az szerződésszegés.

Meg a lónak a faszát. Ha a "hiba" csak szerinted hiba, a gyártó szerint meg feature, mert ő _pontosan_ úgy akarja (te meg nem), akkor a büdös életben nem fogják kijavítani, kivéve persze ha megveszed az egész céget, és kirúgod a főnököt. Természetesen ez nem lesz szerződésszegés, mert az úgy van megírva, hogy ha szerinte nem hiba, akkor arra pont nem vonatkozik...

És minden olyan szituációban, ahol kőkemény anyagi érdekét érinti a gyártónak a feature, zokszó nélkül szarja le, hogy "mit szeretne a magyar nemzet", az lesz, amit ők akarnak, te meg tehetsz egy szívességet.

"Ha a "hiba" csak szerinted hiba, a gyártó szerint meg feature"

Ez ennél jóval objektívebb az én tapasztalatom szerint.
Hiba az, amikor egy támogatott termék nem a dokumentált működést produkálja.

Értem én, hogy nem fekete-fehér minden, de elég sok Premier esetet láttam, ami alapján túlzónak érzem az állításaidat.

Üdv,
Marci
A Microsoftnál dolgozom.

Ha mar itt vagy, tegyel mar helyre valamit: ha vki fizet Premium supportot, akkor jar hozza nevesitett dedikalt kontakt vagy sem? Engem ez komolyan erdekel.
--
Blog | @hron84
Üzemeltető macik

Jár.

Köszönöm.
--
Blog | @hron84
Üzemeltető macik

Nagyszerű. De ha ez a probléma és nincs vendor lockin, akkor alkalmazz olyan céget, amelyiknek <20 ügyfele van.

Az, hogy van egy viszonylag zárt maintainer kör azt jelenti, hogy a piac törvényei szerint normális áron és minőségben dolgoznak. Ha nem így lenne, akkor nem használná senki a terméküket, vagy pedig beindítana más is szupport tevékenységet (és ezáltal kommitterré is válna, vagy forkolna).

Ehh hanyszor lattam ezt kozigazgatasban. :D
Ott bezony a korrupcios rata a 100%-ot verdesi. Aki nem akar korrumpalodni, az nem sokaig marad ott, hamarost kipenderitik. Okot azt mindig fognak talalni. :D
Az van, hogy a sok kis ehes kismalac kiturja a csocsok elol.

Persze az alsobb szinteken mar semmi sem latszik a korrupcio "jotekony" hatasaibol. Ott csak a szopas van miatta. :D

Na mindjárt jönnek az M$ huszárok...

Az még a jobbik eset. Csak közös képviselők ne jöjjenek! :D

--
trey @ gépház

> vendor lock-in

Hogy sikerült eredetileg Linuxra és LibreOffice-ra váltani, hogyha vendor lock-in van?

Hogy a jelentését a Microsoftnál nem értik, azt mindig is tudtuk. ;)

--
trey @ gépház

Lehet nincs jogosultsága az archívumhoz. ;)
(ha a normális 3rd party böngésző renderelés az egyik legmegsemmisítőbb veszély volt a cégre nézve, elképzelni se tudom egy kompatibilis 3rd party Office minek számíthat(ott) :D)

Igazi gyöngyszem! :D

--
trey @ gépház

Igen, rendkívül releváns. :)

Összehasonlításuk, amikor ez az email született,...
- az emberek még féltek az Y2K-tól
- Magyarország még nem volt tagja a NATO-nak
- még nem lőtték halomra a diákokat a columbine-i iskolában
- még nem voltak KFOR erők Koszovóban
- még nem volt aláírva a Bologna-i Nyilatkozat
- még nem oszlott fel teljesen Jugoszlávia
- még volt 50 filléres pénzérme
- a Hortobágyi Nemzeti Park még nem volt a világörökség része
- még Jelcin volt az orosz elnök

Relevanciáról nem tettem említést. Viszont arra jó volt, hogy megállapítsam, Gates g*cibb mint amilyennek a fizimiskája alapján kinéz.

--
trey @ gépház

Ö sem g*cibb semmivel másoknál. Ez a konkurenciaharc egyik jellemzö eleme, nem több. Ki így, ki úgy, de ahhoz, hogy talpon maradj, ne adj isten a világ leggazdagabb embere légy, be kell vetni mindent, különben a többi g*ci tapos le ugyanezzel a módszerrel.

Szépen kinyírták amúgy az OS/2-t is, az nagyobb pofon volt szerintem, így a történelem távlatából, mint az Office.

--
robyboy

Persze! Volt neki barátja is :)

--
trey @ gépház

:D

--
robyboy

:D

Azert a szamitasok szerint kb. szazmillio gyerek eletet sikerult idaig megmentenie azzal, hogy a fokent cegektol elszedett penzt atcsatornazta a kutatasba (meg a harmadik vilagba, ugy egyaltalan).

Szoval azert nagy batorsag kell legecizni azt az embert, aki a tortenelem egyik legjelentosebb filantropja. :)

----------------------
while (!sleep) sheep++;

Gondolom a megfelelő helyen és megfelelő köröktől a filantróp dolgaiért megkapta az elvárt elismerést, bejut majd a paradicsomba/mennyországba stb. Az, hogy engem mennyire hagy hidegen, hogy az alapítványa angol wc-t szállít Afrikába, az egy másik kérdés.

Attól még, amiért jár a faszkorbács, azért jár.

--
trey @ gépház

OMG. Es azt kiszamoltad mar, hogy hany millo gyerektol mit sikerult elvenni azaltal, hogy a kormanyok, kozhivatalok, intezemenyek, iskolak, stb. az adobevetelt foloslegesen draga licencekre koltottek?
Talan jutott volna Microsoft es Bill Gates nelkul is kutatasra.

Lopott (bocsanat, ahogy te foglamaztal: elszedett) penzbol szeretnek en is majd filantrop lenni.

... ebből pedig 99 millió fog nyomorban élni :-(

és arra gondoltál már, hogy ha nem adná a max 20 dolcsi értékű windows enterpise-t 200 dolcsiért, mennyit spórolhattak volna a cégek, és mennyivel többet költhettek volna fizetésekre a szegény gyerekek szülei számára?

többet mint amit gates jótékonykodik..

Erről a nagy filantrópságról az a sztori jut eszembe, ami kb. 2000 körül történhetett, már nem is emlékszem melyik országban... Legyen mondjuk India.
Ahol valami árvaháznak, vagy már... a jótékonysági intézmény formájára sem emlékszem... adományoztak számítógépeket.
OEM windowsokkal.

Majd megb..ták őket, mert az OEM nem jogosította fel az adományozókat a továbbadásra, az csak használatra jogosít, így az árvaháznak be kellett volna fizetnie egy vagon pénzt a legális használathoz.
Persze lehet, hogy a közfelháborodás után az lett a sztori vége, hogy ajándékba végül azt mondták, hogy akkor legyen nekik grátisz, de... akkori MS hozzáállásból kiindulva, ezt erősen kétlem.

Emlékszik valaki konkrét részletekre?

> Igen, rendkívül releváns. :)

Például rögtön kiderül mi a f*szért nem támogatja az Outlook (80k/felhasználó) program a CalDAV (naptár) és Carddav (névjegyek) szabványokat. Mindezt úgy, hogy egy iphone/ipad alapban(!) tudja.

"Likewise this love of DAV in Office/Exchange is huge problem."

És igen, 2017-ben is ez a helyzet. Lehet kenni a sz*rt, de attól még nem lesz csoki.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ez engem is zavar, mert CalDavot pl. használnék.

Tehat, ha mindez igaz volt a level keltezesekor, akkor a vendor lock-in nem is letezett, illetve nem is relevans, hogy letezett-e. Hiszen, ami (a te fogalmaid szerint) regen volt az igazabol nem is volt, meg jaj ugyan mar.
Kristalytiszta logikanak tunik.

goto 0

ha tényleg van vendor lock-in, akkor hogy sikerült leváltani a vendort?

Akkor pl. Koreában sincs diktatúra, mert ha elég nagy tömeg elég sok veszteség árán elég sokáig próbálkozik, akár még esélyes is, hogy el tudnak ellene követni egy merényletet?

Szerk.: Mármint a Kedves Vezető ellen, nem Korea ellen. Vagy a diktatúra ellen. Vagy akármelyik másik szó ellen a fenti mondatban, amire hivatkozhatott volna az ellen.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Jaj.

?

Úgyérted, szerinted nem stimmel a hasonlat? Ha igen, miért? Valószínűleg 10 éves folyamattal és hatalmas költséggel a KV-t is el lehetne távolítani, akkor a lehetséges utódjától elfogadnád érvként, hogy "de látjátok, őt is el tudtátok tüntetni"?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Munchen peldaja jol mutatja a vendor lock-in mukodeset, de ugye nem akarod tettetni, hogy ezt te magadtol nem erted, es el kell magyarazni? A valtas pont azert tartott ilyen hosszu ideig, ezert emesztett fel elg sok forrast es nem is volt teljes koru, mert rengeteg muszaki kenyszert jelentenek a zart, nem szabvanyos adatformatumok, a nem szabvanyos protokollok (pl. IE onlyra megirt oldalak), a nem multiplatformos alkalmazasok, amik vendor only technologiakra epulnek, es igy tovabb.

Senki nem allitotta (rajtad kivul), hogy a vendor lock-in lehetetlenne teszi a valtast. Valtani lehet, de a koltsegek es a problemak megsokszorozodnak.

Árulj el nekem egy dolgot. Ha jól értem, most épp nincs vendor lock-in Münchenben, mert sok erőfeszítéssel megszabadultak tőle. Mint írod, ekkor a váltás költségei alacsonyabbak és problémából is csak törtannyi van. Akkor a mostani állapot fennmaradása mellett érvelők miért mondják, hogy sokba kerülne a váltás (a licencen túl) és hogy nem reális ilyen rövid idő (4 év, LOL) alatt véghezvinni?

(Roth pointed out that the four-year timetable for switching to Windows wasn't realistic, pointing out that the LiMux migration and wider IT restructure had taken nine years)

Üdv,
Marci

Mert a ket kornyezet nem kompatibilis. Ld. fentebb.

Ha mondjuk OpenOffice-rol kell LibreOffice-ra valtani, vagy mondjuk ket UNIX vendor kozott, vagy UNIX-rol Linuxra, stb., akkor nyilvan ezek a problemak keveseb elesek. A szabvanyok megkonnyitik az atjarast.

Szabványok? Hogy mi?
--
ne terelj

"a ket kornyezet nem kompatibilis"
A szabványos ODF-et az Office szépen kezeli, de ha kell (pl. esetleg nem szabványos...), fel lehet tenni egy LibreOffice/OpenOffice-t. A webes szabványok terén az Edge elég jól muzsikál, de ha kell, fel lehet tenni más böngésző(ke)t.

Mi nem kompatibilis?

Üdv,
Marci

Ez kicsit sci-finek hangzott ezért kipróbáltam:

Üres LibreOffice doksi, űrlaptervező megnyit, nyomógomb letesz, nyomógombhoz hozzárendel MsgBox Hello World!, test.odt lement.

MS Office 2016 test.odt megnyit üres dokumentum, gomb sehol, makró figyelmeztetés sehol. (mintha egy az egyben hiányzana a űrlap/makró támogatás vagy csak az ennyire komplexet nem szereti :))

A másik irányba legalább némi kompatiblitás van. Mondjuk az is igaz, hogy a Libreoffice mellé telepítsünk MS Officet csak, hogy egy nyomorult formot ki tudjuk tölteni drágább megoldás. :)

Innen indultunk: "A szabványos ODF-et az Office szépen kezeli"
A LibreOffice-t feltettem, az Általad leírt dokumentumot elkészítettem, a jelenséget sikeresen reprodukáltam Word 2016-ossal való megnyitáskor.
A dokumentumot .zip-re átneveztem, kicsomagoltam, megvizsgáltam a content.xml-t. Kinyitottam mellé az ODF 1.2 szabványt is.

Ez van a content.xml-ben:
<script:event-listener script:language="ooo:script" script:event-name="form:performaction" xlink:href="vnd.sun.star.script:Standard.Module1.ExampleMsgBox?language=Basic&amp;location=application" xlink:type="simple"/>

A szabvány szerint:
The attribute script:language specifies the name of a script. Script language names are implementation-dependent. The names identifying script languages should begin with by a namespace prefix, followed by a ":" (U+003A, COLON) separator. If a namespace prefix is present, the local name of the attribute value is considered to be a name in the XML namespace bound to the namespace prefix.

Hogyan kellett volna ez alapján jobban implementálnia a Microsoftnak a script:language="ooo:script"-el jelzett scriptet, ha a szabványban az "ooo" string nem szerepel?

Ez van a content.xml-ben:
<form:button form:name="Push Button 1" form:control-implementation="ooo:com.sun.star.form.component.CommandButton" xml:id="control1" form:id="control1" form:label="Push Button" office:target-frame="" xlink:href="" form:image-data="" form:delay-for-repeat="PT0.050000000S" form:image-position="center">

A szabvány szerint:
The form:control-implementation attribute specifies a \rendition or implementation of a control that should be created. If the consumer supports the form element this attribute is used with, but does not support the specific concrete rendition or implementation, the consumer shall ignore the form:control-implementation attribute and use its own rendition of the form element.

Hogyan kellett volna ez alapján jobban implementálnia a Microsoftnak a form:control-implementation="ooo:com.sun.star.form.component.CommandButton"-al jelzett nyomógombot?

Nézzük szabvány szerint hogy néz ki, egy program, ami ODF fileokat értelmez:
2.4 Consumer
An OpenDocument consumer is a program that can parse and interpret OpenDocument documents according to the semantics defined by this specification, and that meets the following additional requirements:
A) It shall be able to parse and interpret OpenDocument documents of one or more of the document types defined by this specification (see 3.3) any of which are represented in packages, but it need not interpret the semantics of all elements, attributes and attribute values.

Megfelel-e Szerinted ennek a Word 2016? :)

Üdv,
Marci

Értem én, hogy gőzgép, de Mancikát meg a főnökét nem fogja ám meghatni, hogy ami eddig ment most már nem megy. :)

Amúgy:

Idézet:
the consumer shall ignore the form:control-implementation attribute and use its own rendition of the form element.

Ebből nekem az jön le, hogy csak ki kellett volna rajzolni azt a gombot. ;)

Arról nem beszélve, hogy nálatok is hasonló/sőt rosszabb lehet a helyzet (csak abból, hogy ugye a szabványosított OOXML Strict, meg a Transitional amibe mentetek ;))

"Ebből nekem az jön le, hogy csak ki kellett volna rajzolni azt a gombot. ;)"

Aztán nevezett Mancika a migráció után kutyafuttában ránéz és ragyogó arccal mondhatja, "minden OK". Eközben semmi sem működik, csak kinézetre jó.
Itt egyértelmű, hogy jobb döntés volt a szabványnak megfelelően hibátlanul parse-olni és nem implementálni.

Üdv,
Marci

Idézet:
Itt egyértelmű, hogy jobb döntés volt a szabványnak megfelelően hibátlanul parse-olni és nem implementálni.

Tegyük fel, hogy a gomb mögött nincs script, akkor se kell? :)

Ha legközelebb küldenek egy VBA-s szemetet nyugodtan visszaküldhetem, hogy ugyan ez OOXML meg szabvány meg miegymás de a szabványba sehol nem volt említve, hogyan kell kezelni. (igazából hiába kerestem a szabványban a vbaproject.bin-re még csak referenciát se találtam rá (pedig a .bin olyan nyíltnak hangzik :)))

Sajna az élet nem ilyen egyszerű :(

Ugye nem a funkció nélküli nyomógombok kompatibilitási kérdéseiről fogunk beszélgetni?
Ezt már régebben kitalálták: Ha a só ízét veszti, ugyan mivel sózzák meg? Nem való egyébre, mint hogy kidobják, s az emberek eltapossák.

Üdv,
Marci

Már volt szerencsém checkbox/radiobutton-os (töltsd ki küld vissza) "megoldáshoz" ami így működött (értsd nem volt mögötte egy sor kód se), igaz a Ti terméketekkel készült. (akkor se volt természetes a mosolyom :))

"Itt egyértelmű, hogy jobb döntés volt a szabványnak megfelelően hibátlanul parse-olni és nem implementálni."

Aham. Akkor most ezt magyarazd el Mancikanak is.
--
Blog | @hron84
Üzemeltető macik

Mancika ezért nem fog életében ODT-t használni, mert hiába platformfüggetlen nyílt szabvány, ha nincs (és a szabvány miatt nem is lehet) két teljesen kompatibilis implementációja.
Ha ODT-t akarsz, akkor használj LibreOffice-t. Aminek meg fos a UI-a, és lassú, mint egy lajhár.
Aztán csodálkoznak a népek, hogy nem terjed az ODT.

És az OOXML-nek van két teljesen kompatibilis implementációja? :D

Nincs, de lehetne. De az meg nem a MS-től függ, hogy mások implementálják-e a szabványt vagy nem.
A LibreOffice/KOffice/Calligra Suite ha akarná, implementálhatná, de nem teszi.

ODT esetén a lehetőség sincs meg.

Most a szabványon azt a transitional verziót értjük amit az Office még mindig alapértelmezettként használ, vagy a szabvány szabványt? :)

Mennyivel is jobb egy semmit sem csináló gomb?

Üdv,
Marci

"ket UNIX vendor kozott"

Azért láttam én már karón varjút Java alkalmazás-szerver konszolidáció projektben... :)

Üdv,
Marci

Itt a helyes megjegyzés - sajnos - az lett volna, hogy lassan már két UNIX vendor se nagyon akad...

Látod, megöregedtem: csak az emlékeimben élek :)

Üdv,
Marci

Még mindig érdekel, hogy mi nem kompatibilis?

Üdv,
Marci

Szerintem egyszerubb lenne felsorolni, hogy mi kompatibilis.
Ami nem (feltetlenul) kompatibilis:
- adatformatumok
- file rendszerek
- API-k
- shell
- halozati hozzaferesek
- stb.

Millio dolgot lehetne irni, de remelem ezzel nem mondtam ujat.
Persze mindenre lehet peldat hozni errol es arrol az oldarol is, es a vita kedveert meg sokaig lehet gyurni ezt a szalat.

Egy szoftver migracioja is sok kerdest tud felvetni, nem hogy komplex es heterogen sok gepen futo szoftverkornyezete. Volt szerencsem a kozelmultban pl. verziokezelo rendszer migraciojahaoz (elvielg felhasznaloi oldalrol, gyakorlatilag alaposan bele kellett a migracioba nyulni), kifejezetten nagy szivas tud lenni pl. a windows file nev kezelesebol. Es ez csak egy aprosag...

Ha jól értem, akkor ezzel megcáfoltad a saját állításodat: "A valtas pont azert tartott ilyen hosszu ideig, ezert emesztett fel el sok forrast es nem is volt teljes koru, mert rengeteg muszaki kenyszert jelentenek a zart, nem szabvanyos adatformatumok, a nem szabvanyos protokollok (pl. IE onlyra megirt oldalak), a nem multiplatformos alkalmazasok"

Ha a fenti inkompatibilitások az általuk létrehozott környezeten fennállnak, akkor pontosan mit is értek el verejtékes munkával? Ha most szabványosak az adatformátumok, szabványosak a protokollok, multiplatformosak az alkalmazások, akkor miért okoz nehézséget a platformcsere?

Üdv,
Marci

Nem cafoltam meg az allitasomat. Olvasd el, amit irtam.

Légy erős, elolvastam. Akkor legyen úgy: Szerinted inkompatibilis a Windows-zal, amit létrehoztak, ezért nehéz váltani. És ezt Te a vendor lock-in felszámolásának tartod...
Kibogoznád nekem ezt az ellentmondást? Hisz a vendor lock-in hiánya számomra azt jelenti, hogy relatíve könnyű másik vendorra váltani. Te meg amellett érvelsz, hogy nehéz.

Üdv,
Marci

A vendor lock-in hiánya nem azt jelenti, hogy tetszőleges vendor-ra lehet váltani, hanem azt, hogy könnyen lehet több közül választani és váltani.
A vendor lock-in meg azt jelenti, hogy nem lehet könnyen másikra váltani.

Természetesen a jelenlegi helyzet sem rózsás, mert még mindig sok a vendor lock-in elem a rendszerben, de a váltással megint több lehet.

Tehát, ha A vendor-ról könnyen lehet váltani B, C, D, E, F -re, attól még egy G-re váltás lehet nagyon macerás. Ezután pedig lehet, hogy a G-ről egyetlen másikra sem lehet könnyen váltani.

Tehát a jelen helyzetben pl., ha azt mondják, hogy LiMux-ról Ubuntu-ra, LibreOffice-ról OpenOffice-ra (vagy fordítva, nem tudom melyiket használják) váltanak, akkor valószínűleg sokkal egyszerűbb lenne a váltás, mint Windows-ra és MS Office-ra.

Remélem így már érthetőbb!

Betűkkel, elméletben mindent le lehet vezetni szépen.

Én azt kérdeztem fentebb, hogy mi igazolja, hogy a Windows 10 épp a G csoportba esik? Ugyanis LibreOffice van rá, WollMux (az űrlapkitöltő, ami a projekt büszkesége) szintén, a böngésző meg egész jól jelenít meg szabvány weblapokat. Erre a kérdésre nem volt válasz, csak fdavid odadobott egy csomó  fogalmat, pl.  hogy más a filerendszer meg az API. Hűha!

Amúgy nézzük a példáidat, felfejtve!
LiMux-ról Ubuntu-ra == Ubuntu' -> Ubuntu
LibreOffice-ról OpenOffice-ra == StarOffice'' -> StarOffice'
Ezek tényleg érthetően egyszerűen működő példák, hiszen közös ősű rendszerek forkjai/variánsai.

De jó, fogadjuk el hipotetikusan, hogy a Windows a G rendszer és azt is, hogy B, C, D, E, F rendszerek közül akár egy is létezik. Ha G a legelterjedtebb rendszer desktopon, elterjedtségben nagyságrendi eltéréssel, akkor  milyen fényt vet A rendszer megalkotójára, hogy  olyat tervezett, ami épp a legelterjedtebb rendszerrel nem kompatibilis?

Amúgy a valóságban még a LiMux -> LiMux' váltás sem ment nekik... 

Üdv,
Marci

Irtam peldat is pl. a filerendszerhez, de mondjuk tudnek a halozati kronyeztehez is, stb., ugyanis ezeket hordozza az operacios rendszer.
Nyilvan azt erolteted, hogy vannak keresztplatformos applikaciok, amik hordoznak egy kompatibilitasi reteget az operacios rendszer folott. De ez nem minden, ezen kivul meg szamos problema van. Jelentos egyszerutsites az office es a HTML oldalarol megkozeliteni a problemat, meg akkor is ha ezek lenyeges elemek.
enpassant teljesen jol leirta, hogy a vendor lock-in megszuntetese nem jelent minden iranyu kompatibilitast. En is erre utaltam.

"De ez nem minden, ezen kivul meg szamos problema van."
Mégis mik ezek? Ha LiMux-ról Windows-ra akarok váltani, mi minden lesz nehéz műszakilag? (Az oktatási igényt, meg hasonlókat  hagyjuk most)
Thunderbird kliensről váltani? Van Windowsra is, meg migrálni is lehet belőle... Vagy a fileokat átmenteni? Pár Windows-on tiltott karakter lecserélése azért nem űrtudomány...
Tényleg érdekel, nem kötözködés.

Üdv,
Marci

> Én azt kérdeztem fentebb, hogy mi igazolja, hogy a Windows 10 épp a G csoportba esik?

Nem tudunk részleteket az ottani rendszerről, így csak találgatni lehet. Te próbálod keresni a közös pontokat a LiMux és a Windows 10 között, de sajnos könnyedén lehet találni eltérő pontokat is. Ha az eltérésekre alapozva van, akkor nehéz a váltás, ha nincs, akkor könnyű. Ha viszont nincs alapozva semmi eltérésre, akkor mi indokolja, hogy Windowsra váltsanak és ne Ubuntura, Linux Mint-re, Debian-ra, ...? Valószínűleg az, hogy olyan eszközöket is akarnának az új rendszeren használni, ami csak Windows-on fut, és itt megint eljutottunk a vendor lock-in-hez.

> De jó, fogadjuk el hipotetikusan, hogy a Windows a G rendszer és azt is, hogy B, C, D, E, F rendszerek közül akár egy is létezik. Ha G a legelterjedtebb rendszer desktopon, elterjedtségben nagyságrendi eltéréssel, akkor milyen fényt vet A rendszer megalkotójára, hogy olyat tervezett, ami épp a legelterjedtebb rendszerrel nem kompatibilis?

1. Ez valóban nem tűnik egy (jól) tervezett rendszernek. Természetesen sokkal jobb egy olyan rendszer, ahol a G-re is könnyedén lehetne váltani, de
2. Ez a rendszer még így is sokkal jobb, mintha a G rendszer lenne és nem lehetne semmi másra sem könnyen váltani.

> G a legelterjedtebb rendszer desktopon

Ha már jól tervezett rendszerekről beszélünk, akkor ez is egy fontos pont. Sokkal jobb volna az általam is már sokszor vázolt WEB-es rendszer, ha ilyen lenne A, akkor G-re is könnyen válthatnának, de még akár nem desktop rendszerekre is, pl. tablet, Pi, Chromebook, mobil, ... Ez utóbbi esetben meg már nem is a G a legelterjedtebb! ;-)

nem tudom miért vitatkoztok vele, amikor tisztán látszik hogy fizetett m$ troll.

Új lehetsz itt errefelé.

a fizetés az fizetés.

van az a pénz amitől az embernek korpás a haja.

Azért, mert hátha megérti, hogy mi az a vendor lock-in, és az miért rossz az ügyfélnek.
Bár lehet, hogy erősen a vendor szemszögéből nézi, annak meg ez nem egy rossz felállás! :)

hogyne értené.

annak meg ez nem egy rossz felállás! :)

Nem, erősebb a helyzet: a cég létezésének ez az alapja, a legfőbb hittétele. Erre épült, ettől lett nagy, ettől lett olyan, amilyen, hülyék lennének változtatni rajta.

Az első pillanattól értem, mi a vendor lock-in. És nem, pont, hogy Ügyfél szemmel néztem. Ezért próbáltam a feltételezhető nehézségekről beszélni.
A véleményemet pedig nem írtam le, mások álláspontját és az ellentmondásosnak tűnő dolgokat próbáltam jobban megérteni.

Üdv,
Marci

Mutass, kérlek, egy trollkodó mondatomat. enpassant végre érdemben elolvasta, amit írok.

Üdv,
Marci

Sejtettem.

Üdv,
Marci

akkor flamebait
egyszar:/

Az is jönni fog, hogy a hwsw beépített ügynöke vagyok klikkszám növelésre?

Üdv,
Marci

Sok mindenben egyetértünk, inkább apróságokban nem.

Üdv,
Marci

Bocsánat, hogy közbe szólok, de egy kicsit viccesnek érzem ezt a vendor lock-in dolgot.
Hogy miért?

1. Mert alapból csak Windows - MS Office és Linux - Libre(Open)Office váltásról beszélünk. (Most zárjuk ki a Mac-et meg az egyéb Office csomagokat). Így szerintem értelmezhetetlen a vendor lock-in, mivel csak A és B közül választhatok.
2. Ezek - operációs rendszer, Office program - általános célú szoftverek. Hagy ne legyen már szempont, hogy mennyire tudok beleszólni a fejlesztésbe.
3. Bocsánat, de ha egy platformról döntök, akkor az nem 1 évre szól. Hagy ne legyen már a legfontosabb szempont, hogy milyen könnyen tudok róla migrálni.

4. Kipróbáltam egy kicsit a Google táblázatkezelős megoldását. Nem is olyan rossz, de! Legalább 20 %-kal lassabb vagyok, egyrészt azért mert böngészőben fut, másrészt a program felülete sem olyan jó. Márpedig ez munkavégzésnél komoly érv a webes felület ellen.

> egy kicsit viccesnek érzem ezt a vendor lock-in dolgot.

Sokan vannak így, a jelek szerint a Müncheni városvezetés is még mindig így gondolja.

> 1. és 2. pont

Nézz már utána a vendor lock-in-nek, mert nagyon nem vagy képben vele!

> 3. Bocsánat, de ha egy platformról döntök, akkor az nem 1 évre szól. Hagy ne legyen már a legfontosabb szempont, hogy milyen könnyen tudok róla migrálni.

Minél hosszabb időszakról és (minél nagyobb költségről) szól a döntés, annál fontosabb, hogy az egyes eszközöket minél könnyebben ki tudjam cserélni egy másik szállító hasonló termékére. Ha nincs egyáltalán vendor loc-in, akkor szó sem lenne migrálásról, egyszerűen csak lecserélem az egyik eszközömet a másikra és folytatom a munkát, vagy akár csak az eszközök egy részét cserélem le.

> 4.

Nem az Office vs. webes Office a lényeg. Eleve az Office önmagában lassítja a folyamatot. Egy webes céleszköz jelentősen tudná gyorsítani a folyamatot. Pl. képzeld el a Facebookot, hogy a hozzászólásokat Office formában lehetne felrakni, meg lekérni.

Képzeld el, hogy az infoworker a kimutatásait, BI frontedjét, reportjait a facebook post lehetőségeivel kellene elvégezze...
Meg lehetne csinálni? Sok-sok facebook ui fejlesztéssel meg. Hatékonyabb lenne? Nagyon nem.
Nem mindenre jó a webes felület. Fényévekre van a profi célalkalmazások hatékonyságától.

> Meg lehetne csinálni?

Meg, rengeteg kimutatás készítést támogató eszköz van.

> Hatékonyabb lenne?

Sokkal.

> Nem mindenre jó a webes felület.

Ma már nagyon kevés olyat találsz amire nem jó. Csak pár ízelítő, vagy ezek.

Meg lehet jeleniteni 3d-t weben? Hú, hurrá. Ettől még ugyanott vagyunk: Fényévekre van a profi célalkalmazások hatékonyságától.

De én sok sikert kivánok mindenkinek aki weben fog komolyabb BI frontend-et használni excel helyett (powerquery?) vagy éppen webes "office"-t használni. Láttam már pár ilyen próbálkozást cégeknél, hullott a hajuk rendesen, aztán vissza is tértek full office-ra.

> Meg lehet jeleniteni 3d-t weben? Hú, hurrá.

Ez csak arra példa, hogy az utolsó bástyák is beomlanak, ma már nem nagyon van olyan terület, ahová a webes technológia ne lenne jó.

> Ettől még ugyanott vagyunk: Fényévekre van a profi célalkalmazások hatékonyságától.

Épp fordítva, te általános célú alkalmazásokról beszélsz, én beszélek célszoftverekről. Az önkormányzatok esetén az Office-nak nem a WEB-es Office az ellenfele, hanem az adott folyamatra készített célalkalmazás.

Ott hibázik a gondolatmeneted, hogy nem veszel figyelembe pár fontos dolgot.
-Első, hogy a tevékenységeknek milyen nagy része nem formalizált.
-Második, hogy azok közül, ami pedig formalizált, jópár olyan kevésszer fut le és/vagy annyira szövevényes és/vagy annyira változékony, hogy nem éri meg célszoftvert készíteni rá.
-Harmadik, hogy a formalizált folyamatok egyes lépései nem ritkán tartalmaznak kollaboratív hurkokat, melyeknek a célszoftverekben való kezelése megint csak nemigen optimális. Például: egy formalizált beszerzési folyamat tartalmazza azt a lépést, hogy "műszaki követelmények meghatározása", melynek kimenete a "Műszaki követelményspecifikáció". Ez persze - beszerzendő holmitól függően - jelentheti jópár ember együttműködését, akár mindig másokét. Készülnek az egyes fejezetek, véleményezik, jóváhagyják, újragondolják, bevonják az eddig érdektelennek tűnő személyeket stb. Végül megegyeznek és megy tovább a formalizált folyamat.

Ezeket hogyan kezelnéd Office-szerű (akár webes, akár klienses) eszközök nélkül, célszoftverekben?

Üdv,
Marci

> Ezeket hogyan kezelnéd Office-szerű (akár webes, akár klienses) eszközök nélkül, célszoftverekben?

Vannak, illetve készíthetők olyan eszközök, ahol a tartalomra koncentrálva, a megjelenítéstől függetlenül adhatók meg az adatok. Az adatok megadása wysiwyg módon, kényelmesen történik, mégis az adatok a bevitel során validáláson esnek át, strukturált formában, számítógépes feldolgozásra alkalmasan kerülnek mentésre.

Ilyen eszköz pl. az XEditor, vagy a Xopus. Ez utóbbival van egy recept készítésről videó, de ezt ki is lehet próbálni a xopusfiddle.net oldalon, ahol vannak még egyéb példák is: Chart, Simple, Rich Text. A receptes példánál a tápérték tartalomnál pl. csak számokat enged bevinni.

Nagyon nem értelek.

1) A nem formalizált tevékenységeknél nincs adatséma és folyamati séma és ami kialakul addig, az is menet közben változik. Hogyan segít ezen egy XML-szerkesztő? (Példa: cégünket eladjuk és ezt a szerződést kell előkészíteni.)

2) Mit segít egy XML-szerkesztő a kevésszer lefutó és/vagy szövevényes és/vagy változékony tevékenységeken? (Példa:a cégnél egy mozgássérült Kolléga van, egyedül az ő számára kell évente az Önkormányzatnál parkolóhelyet intézni.)

3) Mit segít egy XML-szerkesztő a kollaboratív hurkok kezelésén: megjegyzések, vélemények, javaslatok, jóváhagyások, újrakezdések?

4) Az Általad ajánlott eszközök általános célú WYSIWYG XML-szerkesztők. Mennyiben tekinthetők ezek "célszoftver"-nek?

Üdv,
Marci

Lehet, hogy félreértettelek korábban.

1), 2), 3)-ra rengeteg csoportmunkát segítő (web-es) szoftver van. Azokkal az ilyen feladatok megoldhatók.

> 4) Az Általad ajánlott eszközök általános célú WYSIWYG XML-szerkesztők. Mennyiben tekinthetők ezek "célszoftver"-nek?

Ezek az általános szoftver és a célszoftver közt helyezkednek el, de sokkal közelebb a célszoftverhez. Akkor válik célszoftverré, amint definiálsz a rendszeresen megadandó adataidhoz sémákat, pl. űrlapok, sablon szerződések definiálása, ...
Mondok példát, hogy világosabb legyen.
Egy ügy intézéséhez ki kell tölteni egy adatlapot, akkor
a) vagy kezelheted végig papír alapon, vagy az annak kb. megfelelő word-ös doksikban, egyik ügyintézőtől a másikig;
b) vagy bekéred papír alapon, majd egy ügyintéző felviszi az adatokat egy célszoftverbe és innentől kezelheted az adatokat célszoftverekkel;
c) vagy eleve olyan célszoftvert készíttetsz, amit már az ügyfél is ki tud tölteni, mert akkor megspóroltad az ügyintéző munkájának egy részét, a továbbiakban ua., mint b);

A fenti esetekben, ha változnak az adatok vagy új űrlapot kell bevinni, akkor módosítani kell a célszoftvert. Ezen tud segíteni egy a fentiekhez hasonló strukturált adatbevivő rendszer. A sablon módosításával vagy egy új sablon definiálásával máris be tudod kérni a kívánt adatokat.

Az 1), 2) és 3) esetén az ott bekérendő adatok felvitelét lehet esetlegesen ezzel megtámogatni.

Jót változott az álláspontod! :)

Korábban: "Épp fordítva, te általános célú alkalmazásokról beszélsz, én beszélek célszoftverekről. Az önkormányzatok esetén az Office-nak nem a WEB-es Office az ellenfele, hanem az adott folyamatra készített célalkalmazás."
Most: "rengeteg csoportmunkát segítő (web-es) szoftver van. Azokkal az ilyen feladatok megoldhatók."

Csakhogy ezek nem célalkalmazások, hanem általános csoportmunka eszközök, a Microsoft esetén pont az Office család részei mind! Korábban azt mondtad, hogy a célalkalmazás az Office ellenfele, most meg azt mondod, hogy ezeket a feladatokat Office-szal vagy versenytársaival lehet megoldani. :)

"Akkor válik célszoftverré, amint definiálsz"

Mármint ki definiál sémát? A Felhasználó maga vagy valaki más (pl. IT)?

"Ezen tud segíteni egy a fentiekhez hasonló strukturált adatbevivő rendszer."

... ami a Microsoft esetében szintén az Office része. Körbeértünk! :)

Üdv,
Marci

Az álláspontom nem változott :)

A fenti példákat nem tartom tipikus önkormányzati feladatoknak. A véleményem még mindig az, hogy az önkormányzatoknál a folyamatok nagy részét web-es célszoftverekkel lehetne intézni.

Abban egyetértünk, hogy más cégeknél, más tevékenységeknél alkalmas lehet az Office nagyon sok feladatra. Főleg akkor, ha egyik napról a másikra Office-ról pl. LibreOffice-ra váltás semmiféle mellékhatással nem járna.

> Mármint ki definiál sémát? A Felhasználó maga vagy valaki más (pl. IT)?

Igen, a felhasználó. Természetesen nagyobb cégeknél ez az IT csapatát jelentené. Illetve az XSD, XSL alkalmazása helyett lehetne sokkal egyszerűbbet is kitalálni pl. Json alapokon.

> ... ami a Microsoft esetében szintén az Office része. Körbeértünk! :)

Ezt nem ismerem, ez melyik? (Web-es és valamilyen szabvány adatstruktúrában áll elő a végeredmény?)

"A véleményem még mindig az, hogy az önkormányzatoknál a folyamatok nagy részét web-es célszoftverekkel lehetne intézni."

OK, de mit csinálsz a kis részével?
-EU-s projekt keretében esővízgyűjtő edények kihelyezése a lakosságból pályázóknak?
-A település #00 éves fennállása keretében szervezendő ünnepségek?
-stb stb stb.

"Igen, a felhasználó. Természetesen nagyobb cégeknél ez az IT csapatát jelentené."

Nono. Kis cégnél képes rá a Felhasználó, nagynál meg másra kell várnia? Vagy hogy?
Magánvéleményem: az IT ipar egyik legnagyobb csúsztatása az efféle workflow és űrlap csodákra, hogy majd a Felhasználó megcsinálja. Az legfeljebb a kivétel, az eddigi tapasztalataim szerint.

"Ezt nem ismerem, ez melyik?"

InfoPath-nak hívják, egyes Office klienscsomagok része. WYSIWIG XML űrlapszerkesztő. Roadmap információ

Üdv,
Marci

>nem nagyon van olyan terület, ahová a webes technológia ne lenne jó

[img]

Ez csak arra példa, hogy az utolsó bástyák is beomlanak, ma már nem nagyon van olyan terület, ahová a webes technológia ne lenne jó.

Sajnos még nem látom azt a technológiát, ami ezt valóban tudná. Az, amit JS címén manapság a browserek csinálnak, az pl. biztosan nem tudja. Csilliárd erőforrással rendelkező modern pc-ken is laggol az egész, állandóan én várok a gépre, mert az nem instant reagál.
Én az az ember vagyok, akit az XP Start menüben a gyárilag beépített 400ms-os büntetés annyira irritált, hogy megkerestem, hogyan lehet kiiktatni, és bárki gépéhez leültem, ez volt az első, amit kikúrtam onnan. Ha rábökök egy gombra, akkor az 'azonnal' működjön, ne pár 100ms múlva. Ezt amúgy a pc-k lokális alkalmazásokkal >10-15 évvel ezelőtt már simán tudták, a web meg egyre messzebb kerül tőle.

> Az, amit JS címén manapság a browserek csinálnak, az pl. biztosan nem tudja. Csilliárd erőforrással rendelkező modern pc-ken is laggol az egész, állandóan én várok a gépre, mert az nem instant reagál.

Ez nem a technológián múlik, hanem a megvalósításon. Mindent lehet rosszul csinálni és szokták is. Az tény, hogy nagyon sok rossz web oldal van.

> Ha rábökök egy gombra, akkor az 'azonnal' működjön, ne pár 100ms múlva. Ezt amúgy a pc-k lokális alkalmazásokkal >10-15 évvel ezelőtt már simán tudták, a web meg egyre messzebb kerül tőle.

Ezt a web is tudja már most is, ami a legnagyobb korlátot jelenti az a hálózat sebessége. Ez lokális hálózaton, amiről most szó van, nem szokott gond lenni.

Ez nem a technológián múlik, hanem a megvalósításon. Mindent lehet rosszul csinálni és szokták is. Az tény, hogy nagyon sok rossz web oldal van.

Viszont ha gyakorlatilag nem tudok mondani modern JS-alapon jó oldalt, akkor lehet, hogy a technológiában (is) gondok vannak... az, ahogy a JS-t manapság mindenki használja, az biztos, hogy nem jó irány. És a klasszikus idióta fejlesztő taktikát sem látom alkalmazhatónak (várjunk addig, amíg a vasak meg a net annyira meg nem erősödnek, hogy elviseljék a bloatware-t).

Az pedig nagyjából tény, hogy nem lehet nagyobb táblázatos tartalmat olyan minőségben kezelni webes technológiákkal, mint egy natív alkalmazással. Próbálj csinálni egy excel-pótlót, ami pont ugyanúgy kezelhető, aztán rá fogsz jönni, hogy nincs az a browser, ami ne gebedne bele egy 50-100 ezer soros 10-20 oszlopos táblázatba (vagy lazy loading van, és egy lapozás másodpercben mérhető ideig tart).

Ezt a web is tudja már most is, ami a legnagyobb korlátot jelenti az a hálózat sebessége. Ez lokális hálózaton, amiről most szó van, nem szokott gond lenni.

Még lokális hálózaton, sőt, még localhoston is érezhető különbséget látok a reszponszivitásban. Lehet, hogy ez már inkább a CPU-bloatware jelenség - de azokat sem becsülném le. Meg a végeredmény az, hogy nincs 'instant' működés.

Másrészt az az architektúra irreális elvárásokat támaszt a hálózattal szemben, ami minden egyes mozdulatra (klikk, pláne egérmozgatás, tooltip on hover) hálózati kérést generál. Ezt egész egyszerűen nem lehet a hálózaton át biztosítani, Interneten keresztül meg pláne irreális a ~10-20ms-os szerverválasz.

> Viszont ha gyakorlatilag nem tudok mondani modern JS-alapon jó oldalt, akkor lehet, hogy a technológiában (is) gondok vannak.

Pedig vannak, egyik legjobb példa a lichess, de a gmail, google maps sem olyan rossz példák. Tehát nem a technológiával vannak gondok.

> Az pedig nagyjából tény, hogy nem lehet nagyobb táblázatos tartalmat olyan minőségben kezelni webes technológiákkal, mint egy natív alkalmazással.

Szerinted a Google maps az kisebb problematika az utcanézetével?
Ráadásul nem az Office programok átirata a megoldás, ahogy már sokszor kifejtettem. Miért lenne szükség több ezer soros és oszlopos táblázat kezelésére? Ez hol felhasználóbarát?

> Interneten keresztül meg pláne irreális a ~10-20ms-os szerverválasz.

Ha így lenne, akkor nem lennének online 3D játékok és játék streamingek.
Egyáltalán nem irreális, itt tesztelheted a sajátodat is.

Lokális hálózatos sebességhez, hogy legyen egy kis viszonyítási alapod, itt van a Kafka sebesség tesztje. Ez ~2 millió, 100 byte méretű adatot küld és fogad másodpercenként, miközben a "szerver" ezt tárolja és három példányban, három gépen replikálja is. Mindezt viszonylag olcsó gépeken, 1Gb-s hálózaton.

A lichess egész pofásnak tűnik. A google maps egyértelműen nem jó példa, mondhatni az iskolapéldája a nemjónak. Nem túl sokat használom, de kb. amióta létezik, azóta konstans probléma, hogy ha nem atomvilágbajnokjó a hálózat (márpedig általában nem szokott az lenni, ahol én megfordulok), akkor rendszeresen megakad scrollozgatás közben. Ha az interakció és a megakadások megfelelő scenáriója összejön (és általában aktívan tologatom, zoom in-out, nem csak bámulom statikusan, és ilyenkor az "interaktivitás-queue" előbb-utóbb megtelik), akkor behal az egész, és lehet nyomni neki egy reloadot ("se oda, se vissza, se tyű" a konklúzió), mert többet magától nem tér észhez, vagy csak nem volt türelmem kivárni. Ez mondjuk simán lehet, hogy nem technológiai limitáció, csak nem volt kedvük megírni jól.

Miért lenne szükség több ezer soros és oszlopos táblázat kezelésére? Ez hol felhasználóbarát?

Hát nézd, én vagyok a felhasználó, és nekem ez az igényem, ergó minden, ami ennél kényelmetlenebb nekem, az bizony kevésbé felhasználóbarát.

Tipikus példa mondjuk a lognézegetés. Már az sem triviális, hogy sima textsorokat lehessen nagytempóban scrollozni (nagy tempó: amit a szemem elbír, úgy, hogy legalább mintákat lássak belőle), de igazi igény az lenne, hogy strukturált adatok legyenek (oszlopokba rendezve). Ezt a "minden scrollozásnál elkérjük a szervertől a sorokat" technológia nem tudja olyan tempóban, mint pl. egy less egy lokális fájlból. Úgy nagyságrendi különbség van a kettő felhasználói élmény között. Az egyikben látom, hogy hol tartok a fájlban, a másiknál meg tudok gyorsan scrollozni, de akkor üres a képernyő közben... A "töltsük le a 225 ezer soros logfájlt a browser memóriájába" megoldást pedig semelyik browser nem bírja, még egy sima textfájlnál sem, tehát az, ami praktikus volna (a JS majd lokálisan elvégez mindent), az ezért nem működik.

Ha így lenne, akkor nem lennének online 3D játékok és játék streamingek.

Félreértesz. Nem azt mondom, hogy nem létezik olyan, hogy valakinek jó, hanem azt, hogy az nem reális elvárás az emberek 90-95%-ával szemben, hogy ilyen jó legyen neki. Mert egész egyszerűen nincs ilyen jó netje mindenkinek: budapesti kerület szívében gimnázium, telefonközpont légvonalban egy sarok, 1 évvel ezelőttig a max. elérhető net 20/1Mbps volt, ennél jobbat az egyetlen elérhető szolgáltató nem tudott/akart adni, namost képzeld el, hogy ha egy ilyen netre ráraksz nemhogy 600 embert, de akár csak 60-at is, akkor abból milyen válaszidők jutnak az egyes embereknek...

A Kafka jó cucc. Nyilván nem kérdéses, hogy ttcp-vel ki lehet hajtani egy lan-t. Azért a szerveroldal mögé adatbázis is szokott kelleni, nem elég egy FIFO. Így viszont bejátszik az adatbázis latency is.

> Tipikus példa mondjuk a lognézegetés. Már az sem triviális, hogy sima textsorokat lehessen nagytempóban scrollozni ...

Ilyen problémára sokkal jobb, ha megadsz szűrő feltételt és azokat adja vissza ami érdekes, nem pedig több százezer sor közül próbálod szemre megtalálni a keresettet. Én ilyesmit értek felhasználóbarát alatt.

> A Kafka jó cucc. ... Így viszont bejátszik az adatbázis latency is.

Egyrészt a Kafka tárolja az adatokat, akár az idők végezetéig, tehát tekinthető adatbázisnak is. Másrészt, a kliens oldali cuccnál is ugyanazok játszanak, mint a szerver oldali cuccnál, egyedüli különbség a kérés-válasz ideje, ami lokális hálózaton 1-2ms-ből megoldható. Emellett a szerver oldal lehet sokkal ütősebb, mint a kliens, így az egyéb dolgokon pedig jócskán visszahozhat ebből a pár ms-ból.

Ilyen problémára sokkal jobb, ha megadsz szűrő feltételt és azokat adja vissza ami érdekes, nem pedig több százezer sor közül próbálod szemre megtalálni a keresettet. Én ilyesmit értek felhasználóbarát alatt.

Nade ez nem mindig hatékony. Nem hatékony, ha pl. nem tudom pontosan, hogy mit is keresek.

tehát tekinthető adatbázisnak is.

Hát query speciel nincs benne, szóval elég messze van az adatbázistól.

Másrészt, a kliens oldali cuccnál is ugyanazok játszanak, mint a szerver oldali cuccnál, egyedüli különbség a kérés-válasz ideje, ami lokális hálózaton 1-2ms-ből megoldható.

Nem. A kliensnél nem túl nagy kompromisszum, hogy az egész cucc a memóriában legyen. A szerveren ez azért nagy kompromisszum, merthogy kliensenként kell ennyi memória, egy gépben. Jól érezhető, hogy míg nem kihívás a kliensbe 4-8GB memóriát berakni, egy 50 párhuzamosan beloggolt (de nem 100% kitöltési tényezővel kéréseket generáló, tehát cpu-ban nagy terhelést jelentő) kliens kiszolgálását végző gépbe (ehhez nem kell csillió dolláros szerver) 200-400GB RAM-ot berakni kicsit nehezebb/drágább. A cachelés nem oldja meg ezt a problémát, ha nem elfogadható a diszk read okozta extra latency (ami nagyságrendileg is több lesz, mint 1-2ms).

Egyébként pont ennél a pontnál vérzik el jelenleg a webes browseres technológia a vastagklienses cuccokkal: C-ben, C++-ban, de tán még Javaban is teljesen értelmesen be lehet cuppantani egy pár 100MB-os adathalmazt, amit utána hatékonyan lehet a memóriában matatni. Ezt a webes cuccok nem tudják. Ha ez adja azt a válaszidőt, amitől ez elfogadható lesz felhasználói szinten, akkor sajnos a webes cuccal nem tudom ugyanezt megvalósítani.

> Nade ez nem mindig hatékony. Nem hatékony, ha pl. nem tudom pontosan, hogy mit is keresek.

Annál tényleg nem :)

> Hát query speciel nincs benne, szóval elég messze van az adatbázistól.

Nem RDBMS, ha arra gondolsz, ahogy rengeteg NoSQL adatbázis sem az, és nincsen bennük "SQL query". Ha nem SQL query-re gondolsz, akkor az van benne, mert lehet topic-ra, partition-re és offset-re lekérdezni.

> Nem. A kliensnél nem túl nagy kompromisszum, hogy az egész cucc a memóriában legyen. ...

Egy pár dologról itt megfeledkezel:
1. Nem olcsóbb 50 kliensbe 4-8GB-ot tenni, mint egy szerverbe 50-szer annyit, vagy 50 szerverbe 4-8 GB-ot.
2. Az egyes kliensek által kezelendő adatok között rendszerint igen nagy az átfedés. Ezért sokkal kevesebb helyen el lehet tárolni egy helyen, mint kliensenként.
3. Vannak kliensek, amikbe extra nehéz sok memóriát rakni, mobilok, tabletek, Pi, ...

Hasonló a helyzet a CPU-nál is, az előző három pont hasonlóan érvényes arra is.

Ha nem SQL query-re gondolsz, akkor az van benne, mert lehet topic-ra, partition-re és offset-re lekérdezni.

Arra gondolok, hogy bármilyen lekérdező nyelven, de értelmesen, többféle paraméter alapján lehessen benne hatékonyan keresni (nyilván megfelelő indexelés fog kelleni, de ne legyen a keresési struktúra fixen bedrótozve). Mivel ez nem adatbázis, ezért ilyet nem tud. Az előre lefektetett egy paraméter (topik) szerint lehet válogatni, és azon belül sorrendiséget ad, és csókolom.

1. Nem olcsóbb 50 kliensbe 4-8GB-ot tenni, mint egy szerverbe 50-szer annyit, vagy 50 szerverbe 4-8 GB-ot.

Az a helyzet, hogy ez így nem állja meg a helyét. A kliensben ugyanis alapból van 4GB memória, még akkor is, ha semmit sem csinálsz, mert ennél kevesebbel gyakorlatilag már nem veszel gépet jóideje. Ennek a jelentős részét azonban el tudod használni működés közben, mert nem eszik ennyit meg az üres OS. A desktop gépbe olcsó ramot tudsz rakni, <10 rugó egy 4GB-os ddr3 modul manapság, míg szerverbe azért nem tudsz olcsó ramot rakni, mert amibe egyáltalán belemegy ennyi memória, ott már a szerver sem lesz olcsó, hát még a ram bele.

2. Az egyes kliensek által kezelendő adatok között rendszerint igen nagy az átfedés. Ezért sokkal kevesebb helyen el lehet tárolni egy helyen, mint kliensenként.

Vagy igen, vagy nem. Ha olyan a feladat, akkor lehet, hogy nem. Ha mindenkinek egyedi nézetet kell tudni adni, akkor pl. nem.

3. Vannak kliensek, amikbe extra nehéz sok memóriát rakni, mobilok, tabletek, Pi, ...

Ez nem érv arra, amit felvetettem. Onnan indultunk ki, hogy van olyan feladat, amire desktopon jobb megoldás a vastagkliens. Erre nem érv az, van olyan, amire meg nem jobb (ezt ugyanis senki nem vitatta). Erre az lenne az érv, hogy minden feladatra minimum ugyanolyan jó a webes megoldás, de ez meg nem igaz.

> Mivel ez nem adatbázis, ezért ilyet nem tud.

Gondolom fordítva akartad írni, hogy mivel nem tud ilyet, ezért nem adatbázis.
1. Ilyen elven egy rakat NoSQL Key-Value adatbázis kiesik, pl. Riak.
2. Mivel rengeteg adat van tárolva visszakereshető formában, ezért nem nagy kunszt hozzá ilyen lekérdező nyelvet fabrikálni, ahogy ezt meg is tették a PipelineDB (SQL on Kafka) keretében.

> Onnan indultunk ki, hogy van olyan feladat, amire desktopon jobb megoldás a vastagkliens.

Onnan indultunk ki, hogy egyre kevesebb az olyan feladat, amire a vastag kliens jobb megoldás.

>Ez nem a technológián múlik, hanem a megvalósításon. Mindent lehet rosszul csinálni és szokták is.

cipőfűző-bekötő mesterként alkotott véleményed szerintem releváns a témában

Obligát webgl fun

volt már 20 éve is hasonló a weben :) Csak akkor még vrml volt a menő, nem a webgl.

Amúgy egyetártek azzal, hogy sokminden megoldható webböngészővel.

Tudod lehet, hogy nem értem ezt a vendor lock-in dolgot. De szerintem csak ott van értelme, ahol ténylegesen válogathatok a beszállítók (Mert vannak beszállítók, akik közül választhatok!!!) között. Ha csak A és B között választhatok, akkor tökmindegy melyiket választom, mert a másik szemszögéből ez úgyis vendor lock-in. És tényleg!

"Minél hosszabb időszakról és (minél nagyobb költségről) szól a döntés, annál fontosabb, hogy az egyes eszközöket minél könnyebben ki tudjam cserélni egy másik szállító hasonló termékére. Ha nincs egyáltalán vendor loc-in, akkor szó sem lenne migrálásról, egyszerűen csak lecserélem az egyik eszközömet a másikra és folytatom a munkát, vagy akár csak az eszközök egy részét cserélem le."

Te elolvasod, amit írsz? Most komolyan, szerinted ha bevezetsz egy technológiát, amit várhatóan évtizedekig akarsz használni, ott az a legfontosabb szempont, hogy milyen költségekkel tudod lecserélni? Nem tudod érted-e, mekkora marhaságot írtál! Eleve azért választom, mert eszem ágában sincs lecserélni. Mi fenéért érdekelne a lecserélés költsége? Pláne informatikában, ahol a az 1-2 év is nagy idő! Mi a francnak foglalkozzak most a váltás költségével, mikor 1-2 év múlva olyan változás jöhet, ami teljesen felborítaná a mostani elképzeléseimet.

Leírok egy egyszerű példát. Csak hogy érthető legyek.
Ma München úgy dönt, hogy lecseréli a Linux+LibreOffice-t Windowsra és MS Office-ra. Csináltatnak egy szép (és drága) tanulmányt, hogy mibe kerülne a migrálás mondjuk Chromebookra és webes technológiára. 2 év múlva meg kiderül, hogy az önkormányzatok munkáját központosítják. A gépek meg a munkavállalók meg mennek a levesbe. -> Volt értelme foglalkozni a migrációval? Ne mondd már nekem, hogy minél nagyobb az időtáv annál fontosabb azzal foglalkoznom a jelenben, hogy hogy tudok migrálni. Nem tudom érted-e. Azt se tudom, hogy migrálni fogok (Lehet nem is akarok). Nem tudom mikor. És végképp nem tudom mire. Ezzel az erővel lottózhatnál is. Annak is több értelme van.

"Nem az Office vs. webes Office a lényeg. Eleve az Office önmagában lassítja a folyamatot. Egy webes céleszköz jelentősen tudná gyorsítani a folyamatot. Pl. képzeld el a Facebookot, hogy a hozzászólásokat Office formában lehetne felrakni, meg lekérni."
Erre meg azt tudom mondani, hogy több tízezer különböző munkakörű emberről beszélünk. A webes célszoftver jó is lenne, ha ez a sok ember csak néhány jól modellezhető és leprogramozható dolgot csinálna. De nekem fogalmam sincs, hogy ez így van-e. De ha nem így van akkor b@szhatod a webes célszoftveredet. Mert ha párezer ilyen célszoftvert kell lemodelleztetni, meg lefejlesztetni, meg karbantartani, meg stb. akkor abból a pénzből röhögve vesznek évente új gépet Windowssal, meg MS Office-szal az összes alkalmazottnak és még marad is a vezetőknek prémiumra. A dolgozók meg úgyse fogják használni, mert előbb összedobnak valamit Wordben vagy Excelben, minthogy megkeressék melyik formot kéne használni. Ja és persze, ha valami böngészőben fut az eleve lassítja a folyamatot, minnél összetettebb a folyamat annál jobban. Nem azt mondom, hogy München esetében nem lenne olyan helyzet, ahol a webes felület hatékonyabb, de azt erősen kétlem, hogy mindenre megoldás lenne.

Most komolyan, szerinted ha bevezetsz egy technológiát, amit várhatóan évtizedekig akarsz használni, ott az a legfontosabb szempont, hogy milyen költségekkel tudod lecserélni? Nem tudod érted-e, mekkora marhaságot írtál! Eleve azért választom, mert eszem ágában sincs lecserélni. Mi fenéért érdekelne a lecserélés költsége? Pláne informatikában, ahol a az 1-2 év is nagy idő! Mi a francnak foglalkozzak most a váltás költségével, mikor 1-2 év múlva olyan változás jöhet, ami teljesen felborítaná a mostani elképzeléseimet.

No, akkor pont saját magad indokoltad meg, hogy miért értelmetlen az, amit mondasz.

Évtizedekig _akarsz_ használni valamit egy olyan környezetben, ahol 1-2 év is nagy idő, és nem tudhatod, hogy mi lesz pár év múlva? Ne haragudj, de nem vagy abban a helyzetben, hogy megalapozottan hozhass olyan döntést, hogy évtizedekig mit akarsz használni. Még ha Billy Gates személyesen ígérné meg neked, hogy nem fogják elbaszni a termkéküket, akkor sem lehetsz benne biztos, hogy nem jön közbe valami, és nem csukják be a boltot/dobják a terméket/perli el a cégüket valami patent troll és emeli a fizetendő díjat a 100x-osára/stb. Bármikor bármelyik cég/termék eltűnhet a süllyesztőben.

Ilyen körülmények között éppenhogy az a botorság, ha valaki nem gondolkodik előre, hogy mit fog csinálni, ha majd váltani kell. És pont ebből a szempontból szopás az, ha a váltás nehéz.

Ja. A volt munkahelyem vagy 15 éve bevezették az SAP-t. Elég nagy cég. Saját céget csináltak az SAP supportra, meg a SAP funkcióinak a bevezetésére. Hacsak nem dől be az SAP (ez nem valószínű), nem fognak váltani. -> A váltás költséges, kockázatos, és az új rendszer se tud többet vagy annyival többet, hogy megérje váltani. Leírom még egyszer: A váltás költséges, kockázatos, és az se biztos, hogy jobb lesz!!! Mondanám példának München-t. Ahol azt senki nem emlegette eddig, hogy kb. 2 éves csúszással jelent meg a LiMux, az alapját adó Kubuntu után, ami szerintem elég gáz. Szerintem a saját linux tutira rossz ötlet volt. Egyszerűen kevesek voltak egy önálló disztribúcióhoz. Kb. semmit nem adott hozzá, viszont időigényes volt, és valószínűleg költséges is. Tuti bukta. -> Haszontalan, költséges, időigényes. Én nem csodálkozom, hogy bebukott a projekt. Nem volt itt minden olyan csodálatos. Ajánlom tanulmányozásra.
https://annex.debconf.org/debconf-share/debconf15/slides/341-linux-in-the-city-of-munich-aka-limux.pdf

Váltani akkor vált az ember, ha elégedetlen a használt rendszerrel, az új rendszer előnyei kárpótolnak a váltás nehézségeiért. -> Érted? Alapesetben a kutya se akar váltani, ha már időt, pénzt stb-t rááldozott a bevezetésre. Legalábbis rövid időn belül tutira nem. Pláne egy München méretű projektnél. Szerintem 2025-ig akkor se lenne téma a váltás, ha esetleg visszakerülne a linxubarát vezetés, még az se biztos, hogy sikerül addigra visszaváltani.

Hát ha már bizalom, én inkább elhiszem, hogy az MS meg a Windows, meg az MS Office meglesz még x év múlva, mint bármelyik dzsunka linux, meg ki tudja mikor forkolják a LibreOffice-t, és a FreedomOffice lesz az alapértelmezett office program a linuxokban, mert összevesztek a LibreOffice fejlesztők.

Maradjunk annyiban, hogy az a szopás ha váltani kell.

Váltani akkor vált az ember, ha elégedetlen a használt rendszerrel, az új rendszer előnyei kárpótolnak a váltás nehézségeiért. -> Érted?

Valamiért azt képzeled, hogy a nemváltás az ekvivalens a meglevő megtartásával, mintegy statikus állapotként. Sajnos ez az esetek jelentős részében nem így van. Olyan ez inkább, mint a rodeó: a rajtamaradáshoz is időt, pénzt, energiát kell befektetni, ha pedig megállsz, leülsz, akkor leesel a lóról. Azaz nem csak az új rendszer előnyei kárpótolnak a váltás nehézségeiért, hanem ezzel szemben áll a meglevő megtartásának költségei/nehézségei, illetve a meglevő megtartásából újonnan fakadó szopások (pl. kivesznek valamit a frissített verzióból, ami neked nagyon kellene).

Az a helyzet, hogy hiába használhatod a licenc szerint pl. a 15+ éves MS Office-t is, hiába lenne az neked funcionálisan tökéletes (= elégedett vagy a használt rendszerrel), ha már nem javítják a security bugokat, és emiatt vállalhatatlan, hogy megtartsd a régit. Jön valami új makrós szar, és beszívja a Mancika. Az nyilván irreális, hogy a kedvedért a gyártó majd még supportálgatja pár évtizedig a régi dzsunkát, hiába fizetnél érte még sokáig - és mivel a forrás nem nyilvános, még esélyed sincs, hogy erre mást felbérelj. Egy Internetre kidugott webshopnál meg aztán gyakorlatilag folyamatos verziókövetésből áll az élet: ha pár hetet késel, simán feltörik a webshopodat, aztán baszhatod.
Mivel már minden hálózatba van kötve, minden mindent elér, minden multiuser - authentikáció kötelező, így nem sok szoftver maradt, aminél megteheted, hogy maradsz a régi verziónál (aminél meg megtehetnéd, ott meg kirohad sokszor alóla a platform).

Szóval az van, hogy a nemváltás is váltás, sokszor bizony kényszerpályán. Minél zártabb a platform (és minél kisebb szereplője vagy a játéknak a gyártóhoz képest!), annál erősebb a kényszerpálya. MS vs mezei kuncsaft a legtipikusabb esete ennek a történetnek, gyakorlatilag zéró érdekérvenyesítő képessége van. Az sem működik, hogy előre megnézed, hogy merre vezet ez a kényszerpálya, és akkor majd nem érnek meglepetések, mert ugye "1-2 év alatt sokat változik az ipar"...

Maradjunk annyiban, hogy az a szopás ha váltani kell.

Lehet, de még nagyobb, ha úgy készültél, hogy nem fogsz, aztán mégis kell.
A "de biztos úgyse fog kelleni" a fentiek szerint nyilván hibás válasz.

Idézet:
Szóval az van, hogy a nemváltás is váltás, sokszor bizony kényszerpályán.

+1. A legszebb példa a vendor lock-inre pont az ikszcséndzs, amitől mindenki odáig van: gyakorlatilag verziónként új protokollt találnak ki (ill. wrappelik újabb rétegbe a protokollokat a "megváltozott igényeknek megfelelően"). És utána már csak a support táblákkal kell játszani ahhoz, hogy folyamatosan frissítési kényszerben legyél, ha fenn akarod tartani a rendszered: az Exchange N+3 verzió dobja az Outlook N supportját (gyakorlatilag mainstream support periódus utáni kövi verzió már bukó), így mindkét felét folyamatosan frissítened kell, hogy támogatott legyél. Persze az Outlook külön nem frissíthető, ahhoz az egész Office-csomag kell. Ami azt jelenti, hogy ha a szervezeten belül vannak nem Exchange felhasználóid is, azoknál is frissítened kell, különben az egymásnak küldözgetett Word doksik szétmennek (bár ezt N és N+/-1 vagy N és N+/-SP között is elő tudja adni). De persze az Office N+3 már nem támogatja a Windows N-t (Office 2013 vs. Vista), úgyhogy azt is mindenhol frissíteni kell. És így tovább ad nauseam.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

-1000
Amit leírtál az nem vendor lock-in, hanem üzemeltetési probléma.

Mi nem vendor lock-in abban, hogy a protokollok/fájlformátumok folyamatos, senki mással nem egyeztetett (max. utólag dokumentált, hála az EU-nak) módosítgatásával/cserélgetésével elérik, hogy folyamatos fejlesztési kényszerben legyen az ügyfelük - hogy aztán a sales jól el tudja adni a volume license + software assurance csomagot (hogy legalább ne pár évente egyszerre kerüljön sokba egy upgrade), amivel időarányosan "odakötötted" magad (különben buktad a VL+SA csomagok hátralevő idejének az árát). Ráadásul a nem dokumentált protokollok miatt kényszerből csak mindent egyszerre tudsz cserélni (kivágod az Exchange-t, akkor játszhatsz ugyan az ActiveSync-es open cuccokkal, de az megint software patentes jogi kérdésbe csap át, vagy válthatsz "közösségi" protokollokra, aminél viszont az Outlook-ot kell cserélned, mert nagyon látszik rajta, hogy nagyon utolsó prio...).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

-1000
Amit leírtál az nem vendor lock-in, hanem üzemeltetési probléma.

Apropo outlook:

Fel lehet tenni egymas melle az office2010-et, es az office 2013-at.

Csak mind a ketto beallito felulete szogre ugyanigy nez ki, csak az egyiknek a vezerlopultban mail a neve a masiknak meg posta. Egy napig vernem f*szkorbaccsal aki ezert felelos.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Na, ez új, amikor utoljára néztem, még nem is engedte :)
De ez nem túl bíztató:

Idézet:
You can have two different versions of Outlook on the same computer, but we don’t recommended it. If you do install two versions of Outlook, you can only run one version at a time. If you have one version of Outlook running, for example, Outlook 2010, and you then try to start Outlook 2013, you’ll get this error:

Sorry, we're having trouble starting Outlook. Only one version of Outlook can run at a time. Check to see if another version of Outlook is running, or try restarting your computer.

(https://support.office.com/en-us/article/Office-2010-and-Office-2013-side-by-side-eb569695-ce97-4841-831e-236f095f7803?ui=en-US&rs=en-US&ad=US - kiemelés tőlem)

De pl. egy 2013/2016-ra már expliciten írják, hogy nem fog működni, kivéve, ha (https://support.office.com/en-us/article/Install-and-use-different-versions-of-Office-on-the-same-PC-6EBB44CE-18A3-43F9-A187-B78C513788BF)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nalam 2 gep igy megy. Office 2010 (masikon office 2007) plusz mindketton office 2013.

Epp migralunk office 2013-ra. Plusz az office 2010-nek (outlook 2010) van egy olyan idegesito bugja, hogy a postazandoban ragad a level. Ez kb. heti egyszer fordul elo es altalaban el is vesz a level(csak egy gepen, de ugyanaz a windows+hardver+office van meg 5 masik gepen is, ott nincs problema)

Ez olyan bug, amire lepni kellett. Igy kerult fel az office 2013. Viszont az exchange miatt imap+smtp-re lett allitva. Eddig (kopp-kopp) semmi kulonbseg. Igy a maradek gepek is migralva lesznek office 2013-ra (2010,2007-rol vegyesen).

Szerencsere tavalyi evben mind a naptar, mind a nevjegy mar migralva lett (carddav, caldav), fokent az iphone/ipad miatt.

Igy outlook 2013 teljesen vallalhato imap+smtp klienskent (+ carddav es caldav klienskent).
Az, hogy helyi gepen foglalnak a levelek 20-30GB-ot (.ost) az a mai vilagban .lesz*rom kategoria.

Plusz androidon a nevjegyek is fel vannak szinkronizalva. Bar, hogy mindenki viberezik, lehet ez nem is az en dolgom lenne, az ugyis szinkronizal....

Meg a franya .pst fajlokra kellene valami ertelmes megoldast kitalalni. Szerencse most egyik outlook kiegeszito se akad ossze vele (az apple naptarszinkronizacios kiegeszitoje behalt par havonta es a halozati .pst fajl volt a ludas). De szerencsere caldav ota nem hasznaljuk....:)

Szoval a szerver oldali webexchange-t kellene meg kukazni, es ajkor az exchange-t is lehetne. Talan idei evben. De mivel minden mukodik, igy nagy motivacio nincs....

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

btw, akkor van szivas, ha mind a ket outlookot hasznalod felvaltva, es mind a kettonel exchangere van allitva a fiok.

De nem probaltam komolyabban igy..

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Még az jutott eszembe, hogy belinkeltem ezt a prezentációt, - aminek a hitelességét ugyan nem ellenőriztem, de a készítője valószínűleg tagja a müncheni linuxos csapatnak - ami szerintem elég korrekt tájékoztatás ad a projektről, és világosan kiderül belőle, hogy
- sok bajuk van a harver támogatással
- a fejlesztés nem a tervek szerint haladt
- a LibreOffice-szal is gondok voltak

Ehhez érdemi hozzászólás nem született.
Sokkal érdekesebbek az alábbi témák:
- korrupció
- vendor lock-in
- MS mindenkit lefizet
- Windows-sal kapcsolatos összes rossz tapasztalat

Biztos bennem van a hiba, de ilyeneket gondolok:
- gáz ha egy önkormányzatnak azzal kell bajlódnia, hogy működjön egyáltalán egy hardver
- egy önkormányzat ne fejlesszen op. rendszert
- gáz hogy egy önkormányzet office programot patchel

Egész korrekt érveket és észrevételeket írtál. Szinte el is felejtettem, hogy hup-fórumon ilyen is tud lenni hangnem! ;-)

Az eleje személytől függetelnül mondhatniforró téma. Abba most nem is akarok belenyúlni, inkább csak a "hibás" részekre reagálnék:

Amolyan pre-ambulumkénti gondolatok:
Ezt így is meg lehet közelíteni, ahogyan te.

Vagy úgy is, hogy München Mo.-tól picit nyugatabbra van. Amennyire külföldön élő honfitársaktól tudom, Németországban kifejezetten jól tud működni közügyek és közműügyek intézése.


- gáz ha egy önkormányzatnak azzal kell bajlódnia, hogy működjön egyáltalán egy hardver

Ez gáz, de nem az önkormányzat vagy a linux hibájának tudom be. Részemről legalábbis.
Részemről mondjuk azt is megnézném, hogy mennyi ilyen problémájuk volt a projekt elején, és mennyi a vége felé.
Én pl. sejtek egy katalizáló tényezőt is emögött, hogy a projekt mentén a hw-gyártók is elkezdték a Linuxot komolyabban venni, és a támogatás pl. driverek minősége is részben ennek a projektnek köszönhetően is javult.

Ha ezt a teljes képet nézzük, akkor már nem biztos, hogy annyira gázosnak itélném a helyzetet. Persze ez részemről csak feltételezés, sem alátámasztani, sem megcáfolni nem tudom.
De ha a projekt mögött, ilyen gondolkodású vezetők (is) voltak, akkor már egy jobb cél felé haladtunk.
Szerintem.


- egy önkormányzat ne fejlesszen op. rendszert

Az oprendszert nem tudom milyen értelemben értetted. Ugye a linux-szal és avval, hogy van belőle egy nagy rakás disztribúció már a kifejezés is összetettebb lett.
Nem tudom fejlesztettek-e a Müncheniek "oprendszert", vagy "csak" saját disztribúciót. Ill. mekkora rész volt ebben.
De ha egy közügyek ellátására létrehozott szervezet, mint egy önkormányzat, olyan fejlesztéseket végez közpénzből, aminek az eredménye a végén a közhöz visszakerül, én ebben abszolút semmi kivetnivalót nem látok.
Magyar szemmel nézve meg még inkább üdvözítőnek látom, hogy a nagy rakás közpénz nem csak pályázatok elmutyizására megy el, de még a közvetett hatásait tekintve is a köznek tud jó lenni, amellett, hogy a közvetlen hatása akár az is lehet (némi bevezetéskori nehézség után), hogy egy még függetlenebb még professzionálisabb közszolgálatot látnak el.


- gáz hogy egy önkormányzet office programot patchel

ld. előbbi indoklásom: közpénz, és ami közvetett eredménye a "side-projektnek" az is visszakerül a közhöz.
A "köz" szempontjából nézve én azt látom, hogy evvel méginkább javul a pénz felhasználásának effektivitása.

Ugyanez vendor lock-in / MS szoftverek használata esetén:
München: - bug van
MS: - jó megnézzük / leszarjuk (napszaktól, kedvtől, holdállástól, egyéb időjárási, hangulati stb. ro..tul nem professzionális tényezőktől függő válasz)
és az eredmény, hogy egy valamilyen pályázatot megnyerő cég, húz hasznot belőle, aki már eleve monopol helyzetben, és ezáltal, ha épp olyan kedvük volt, hogy kijavítják a hibát, akkor is az ő termékük fog tőle javulni, amiből csak azok részesülnek (legálisan!) akik hordják tonnaszám a pénzt az ő budzséjükbe, mert megvették a termékeiket.

Szóval, még ha flame-be is csaptak át az "érdekesebb" témák, de nem véletlen, hogy ezek érdekesebbek.
Ha azt nézzük, hogy merre megy a világ, az MS zsákutca.
Nézd meg milyen technológiai óriások vannak most, és milyen technológiák mentén lettek ők óriások: sort()
Amazon, Facebook, Google, Linkedin, Twitter, ...
és ezek csak tovább nőnek.
Milyen technológiákat használnak?
Mind linux és más open source technológiákat használnak az alapjaikhoz.

Nézd meg az őskövületeket: sort()
MS, Oracle, SAP...
Kicsit korai jósolni, de szerintem ezek hosszútávon, hacsak nem csinálnak valami óriási hátraarcot, akkor leáldozott nekik.
Lásd pl. az MS kapálózását az Azure-ral, hogy legalább egy hangyabokányi szelet jusson neki is abból a tortából. Meg hogy hirtelen mennyire opensource barátok (másképp fogalmazva: képmutatók) lettek, csak hogy az olyan MS-vak cégeket is be tudják csalogatni az Azureba, akiknek van néhány Linux-only rendszerük, amire nem tudtak MS alternatívát adni. Ha úgy vesszük az MS egy jókora fele már most egy jó nagy hátraarcban van, és kb. gusztustalan módon olyan előadásokkal tudnak OpenSource konferenciákon megjelenni, hogy azt a képet próbálják festeni magukról, hogy ők mekkora opensource támogatók, meg szinte mintha ők találták volna fel az opensource-t.
A legundorítóbb ebben, hogy még működik is nekik; hiszen elég gyorsan fiatalodik a szakma, és a fiatalok már nem emlékeznek a történelemre, hogy milyen gusztustalan módon jutott abba a monopol pozícióba az MS, ahol most van.

"Ha azt nézzük, hogy merre megy a világ, az MS zsákutca."

Azért ez, pont ebben a topicban nem kispálya :)
(hogy ugyanezt a beszólást elő tudjuk szedni bármelyik hup topicból, 1-5-10 vagy éppen 15 évvel ezelőttről külön vicces, közben az msft részvények az egekben...)

Az azure kapálózásával kapcsolatban ugye jól sejtem, hogy kb annyit értesz azure-ból, hogy olvastad valahol, hogy linux vm-eket is lehet ott futtatni? Ez esetben halkan megjegyezném, hogy vm futtatás kb. elhanyagolható része. Egészen másról szól az azure és egészen más felé tart, de ez itt teljesen off.
(az meg, hogy mennyire kapálózik jól mutatja, hogy a második legnagyobb cloud szolgáltatóvá nőtte ki magát az amazon mögött, annál sokkal gyorsabban növekedik és pl. az általad emlitett google cloudja fasorban sincs hozzá képest)

De ha egy közügyek ellátására létrehozott szervezet, mint egy önkormányzat, olyan fejlesztéseket végez közpénzből, aminek az eredménye a végén a közhöz visszakerül, én ebben abszolút semmi kivetnivalót nem látok.
Tudod, te valami nagy tévedésben vagy. A szabad szoftver (közte a linux és a LibreOffice) nem közügy, se nem közfeladat. Az csak egy szoftver terjesztési módszer, meg a hozzá kapcsolódó jogok, aminek a célja, hogy a kód (a benne lévő tudás, munka stb.) ne veszhessen el meg egyebek. Az államnak nem lehet célja, feladata se a terjesztése, se a zárt forráskód állami "betiltása".

A másik nagy tévedésed, hogy a szabad szoftver előbb-utóbb lenyomja a zárt szoftvereket. Nem fogja. Pláne az ilyen Google féle szabad szoftver, ahol kiadják a ugyan a kódot, de te ki vagy zárva a fejlesztésből, meg minden módon akadályozva vagy, hogy a fejlesztést a saját céljaidra használd. Igazából nem is tartom az Androidot szabad szoftvernek. Se a szabad szoftver sikerének, ez a Google sikere.

Nem tudom feltűnt-e, de én nem feltételezek, legfeljebb következtetek. Azaz ha állítok valamit, igyekszem valamilyen ténnyel, adattal alátámasztani. Ha lehet ilyen marhaságot nem írok le, mert ez pusztán az előítéleted, fantáziád szüleménye, fogalmad sincs az egészről:

Ugyanez vendor lock-in / MS szoftverek használata esetén:
München: - bug van
MS: - jó megnézzük / leszarjuk (napszaktól, kedvtől, holdállástól, egyéb időjárási, hangulati stb. ro..tul nem professzionális tényezőktől függő válasz)
és az eredmény, hogy egy valamilyen pályázatot megnyerő cég, húz hasznot belőle, aki már eleve monopol helyzetben, és ezáltal, ha épp olyan kedvük volt, hogy kijavítják a hibát, akkor is az ő termékük fog tőle javulni, amiből csak azok részesülnek (legálisan!) akik hordják tonnaszám a pénzt az ő budzséjükbe, mert megvették a termékeiket.

Tudod felteszek egy kérdés:
Miért rossz a monopólium?
Mert ilyen szavakat használsz: undorító, gusztustalan, meg tonna szám lapátolják a pénzt? De szerintem fogalmad sincs a monopóliumról. Ja és persze a profit is egy teljesen normális dolog. Minden gazdasági társaság célja. A többiek (köztük te is) közvetve, közvetlenül ebből élnek. Ha nem lenne profit mehetnénk vissza a kőkorszakba. Ja és persze, ha nem lenne profit szabad szoftver se lenne.

Idézet:
A szabad szoftver (közte a linux és a LibreOffice) nem közügy, se nem közfeladat.

A szabad szoftver nem, viszont a saját fejlesztés lehet; ebben a nagyságrendben (vagy legyen csúnyább: országos szinten) már komoly gazdasági jelentősége lehet annak, hogy kifizetsz X összeget, ami után egy cég befizet 10-27% ÁFÁ-t és azzal a mozdulattal viszi ki az országból vagy hogy kifizetsz Y összeget (Y akár egy nagyságrenddel is lehet több), amit utána a lakosod/állampolgárod a sarki boltban fog elkölteni. A min(X,Y) kiadás ugyanúgy ott lesz a költségvetésedben, csak utána nem mindegy, hogy annak hány százalékával számolhatsz a bevételi oldalon.

Idézet:
Miért rossz a monopólium?

Egyszerű: kontroll. Ki vagy szolgáltatva a monopol helyzetben levő beszállítónak, ami ezzel visszaélhet. Pl. azzal, hogy árat emel (mivel "tisztítja a licenszelési portfólióját" :) ), vagy azzal, hogy újabb piacokon szerez monopóliumot a már meglévőire építve. Nem ok nélkül nem szeretik jobb helyeken a monopol-helyzetben levő beszállítókat.

És természetes, hogy minden vendor igyekszik a termékeit integrálni. Ha építesz egy tisztán Süsü hálózatot, akkor a kliens feltételezi, hogy ott lesz a Yast-tal összerugdosott SLP-szerver, amivel megtalálja a Yast-tal összerugdosott LDAP-szervert, amihez tud autholni a Yast-tal összerugdosott Kerberostól kapott tickettel és egy mozdulattal a kliens oldali Yast-ból csatlakozni tud ahhoz. Ha építesz egy tisztán piroskalapos hálózatot, akkor a kliens feltételezi, hogy ott lesz a FreeIPA-alapú Idm, amihez egy paranccsal tud csatlakozni a realmd-vel. Ha építesz egy tisztán Windows hálózatot, a kliensed simán feltételezi, hogy ott lesz a Windows Server, rajta az AD Server Role-al. Teljesen korrekt, többé-kevésbé még keverni is lehet őket különösebb gond nélkül.

A probléma ott kezdődik, amikor valamelyiknek (és itt figyelj: for-profit cég, nem alapítvány) 95%-os piaci részesedése lesz (kb. monopólium). Mert onnantól kezdve (ahogy most az MS-nél látjuk) a mindenki mással való kompatibilitás nem az _ő_ problémája, oldják meg a "többiek". Mert onnantól kezdve kezdődhet az, hogy a létező szabványok helyett vagy azokat inkompatibilis módon kiterjesztve, saját protokollokat, formátumokat, ... kezdünk el használni - legjobb esetben is utólag dokumentálva és specifikálva őket, hogy ha valaki ki akarná váltani valamelyik termékünket, akkor azt csak bug-by-bug reprodukálva a mi működésünket tudja csinálni. Aztán ha valahogy ez sikerülne mindenki másnak, akkor (mivel nem kell szabványosítási folyamatokkal bajlódnunk, meg így kommunikálnunk másokkal) bármikor lecserélhetjük a protokollt, mert úgyis mi adjuk a kliens és a szerver oldalt is.
Erre a Samba és az SMB egy szép példa: a CIFS-hez/SMB1-hez még készült [na nem az MS-től] egy POSIX extension. Aztán a Vista előtti időkben már eljutottak oda, hogy sokkal komolyabb clustering megoldásuk volt (CTDB, tisztán szerver oldal), mint amit az akkori Windows Serverek tudtak, skálázható volt stb. Jött a Vista és az SMB2, egy-két hasznos frissítéssel. Bukó a vendor-specifikus kiterjesztéseknek. Aztán jött a 8/2012 és az SMB3, amiben ráfeküdtek a clusteringre - természetesen saját, új protokollal (Witness, részben kliens oldal), mert ők a 95%-os desktop, és nem nekik kell egy már meglévő infrastruktúrához alkalmazkodniuk, hozhatnak sajátot.
És persze ezeknek mind volt valami technológiai alapja (az SMB1/2 váltásnak speciel szerintem az, hogy a protokol egyeztetés állapot-átmenet diagramját már ők se látták át...), nem is azzal van a gond, hogy mit csinálnak. A probléma, hogy mivel ezen a piacon gyakorlatilag monopóliumuk van, ezt bármiféle egyeztetés nélkül tudják megtenni, max. egy darabig legacy code path-ként otthagyják a régi protokollok támogatását. Egy kiegyensúlyozott, mondjuk minimum három közel azonos erősségű szereplős piac (Linuxnál erre a Canonical-RedHat-Süsü azért ott van példának) azért jobb lenne, mert még ha mindegyik a saját megoldásait fejlesztgeti is, előbb-utóbb közelítenek egymáshoz vagy egységesednek.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

ebben a nagyságrendben (vagy legyen csúnyább: országos szinten) már komoly gazdasági jelentősége lehet annak, hogy kifizetsz X összeget, ami után egy cég befizet 10-27% ÁFÁ-t és azzal a mozdulattal viszi ki az országból vagy hogy kifizetsz Y összeget (Y akár egy nagyságrenddel is lehet több), amit utána a lakosod/állampolgárod a sarki boltban fog elkölteni. A min(X,Y) kiadás ugyanúgy ott lesz a költségvetésedben, csak utána nem mindegy, hogy annak hány százalékával számolhatsz a bevételi oldalon.
Ebből kiindulva, akkor ezek szerint a magyar állam jobban tenné, ha bezárná a határokat, és mindent helyben termelne meg, mert az abból befolyó pénzt is itthon költenénk el. Ja mégse.

Miért rossz a monopólium?
Egyszerű: kontroll.

Először is közgazdaságtan elmélet szerint minden eladó a profitját akarja maximalizálni, hangsúlyozom MINDEGYIK. A monopólium is. Csak annyi a különbség, hogy a monopólium ezt egy magasabb áron, és alacsonyabb mennyiséggel éri el. Emiatt a vásárlók egy része nem jut a termékhez, ami sérti a szabad versenyt. Tehát mese hogy a monopólium tetszőlegesen tud árat emelni, mert nem tud. Ha túl magas lesz az ár, a vevők vagy lemondanak a termékről, vagy még rosszabb esetben alternatívákat keresnek. Pláne egy szoftvernél. Tudod valamikor régen, mikor elkezdtem Linuxot használni, én is azt hittem, hogy itt van egy ingyenes op.rendszer, ami az internetről szabadon letölthető, hogy pár év múlva simán lenyomja a Windowst. De nem ez történt, márpedig ha túl magas lett volna az ár ennek kellett volna történnie. Szóval egyrészt nekem senki ne mondja, hogy az MS mocskosul visszaél a monopóliumával, mert az otthoni felhasználóknál rohadtul nem tud. Ha otthonra Linuxot akarsz, letöltöd, felteszed, használod. Ennyi. Mégse állnak sorban az emberek, hogy letöltsék. Erre várok én is már vagy 12 éve, de már nem hiszem, hogy bekövetkezik. Az összeesküvéselméletek meg a fantáziálások nem érdekelnek.

Erre a Samba és az SMB egy szép példa: a CIFS-hez/SMB1-hez még készült [na nem az MS-től] egy POSIX extension.
Bocsánat ehhez nem értek, de a Samba tudtommal a Windows hálózati protokoll leutánzása. Hagy ne akarjon már az MS ezzel kompatibilis lenni. Bocsáss meg, de hálózat támogatása nélkül egyetlen op.rendszer sem működhet manapság. Az MS meg hagy fejlessze úgy a sajátját, ahogy akarja. Ehhez nem értek, nem akarok róla vitatkozni.

újabb piacokon szerez monopóliumot a már meglévőire építve
Ennek a veszélye tényleg fennáll, de tekintve hogy azokon a piacokon verseny van, meg hogy mennyire volt sikeres mondjuk az MS a mobil piacon vagy a böngésző piacon, azért ezt nem érzem túl nagy problémának.

Idézet:
Ja mégse.

Nem, persze, hogy nem. Viszont illene a döntéshozóknak számolni a belátható következményekkel egy-egy döntésnél. Egy 90M Eurós tételnél pl. már illene számításba venni. Ha kijön, hogy az MS megoldás a jobb és valami ellen tudja súlyozni vele ezt a kiadást, akkor ok.

Idézet:
Bocsánat ehhez nem értek, de a Samba tudtommal a Windows hálózati protokoll leutánzása

Eredetileg IBM termék volt :)

Idézet:
Az MS meg hagy fejlessze úgy a sajátját, ahogy akarja.

Igen, ebből lesz a vendor lock-in, ha nem egyeztetsz senkivel, egyszerűen azért, mert megteheted. Pl. per pill az MS-t semmi nem akadályozza meg abban, hogy kidobja az AD infrastruktúrát és azt mondja, hogy ahelyett csinálnak egy raklap WebService alapú protokollt. És hogy abba a protokollba beleteszik, hogy csak egy root CA által kiadott tanúsítványban bízhat meg a kliens. 3-5 éves kifutási idővel ki tudná szórni az új megoldását, kliens oldalon lehetne is újra implementálni az összes protokollt, de a szervert nem tudod kiváltani, mert nem kapsz hozzá certet. Nyílt protokoll? Az. Cserélhető? Nem, mert nem volt iparági egyeztetés.
Ha meg azt gondolod, hogy ez mennyire elborult: Secure Boot?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Tudod lehet, hogy nem értem ezt a vendor lock-in dolgot. De szerintem csak ott van értelme, ahol ténylegesen válogathatok a beszállítók (Mert vannak beszállítók, akik közül választhatok!!!) között. Ha csak A és B között választhatok, akkor tökmindegy melyiket választom, mert a másik szemszögéből ez úgyis vendor lock-in. És tényleg!

Nem ott van értelme, hanem ha válogathatok, akkor nincs vendor lock-in, ha nem válogathatok, akkor van.
A vendor lock-in nem az eszköztől függ!. Pl. Webes rendszernél ha Microsoft Windows-t használok Internet Explorerrel vagy Edge-dzsel, akkor sincs vendor lock-in, nem függök a Microsoft-tól, bármikor lecserélhetem az OS-t bármelyik másik OS-re, a böngészőt bármelyik másik böngészőre.

Alapvetően ne a migrálásra gondolj, hanem egy új rendszer kialakításáról, már ott kell(ene) minél inkább szállítótól függetlenül megtervezni a rendszert.

> Te elolvasod, amit írsz? Most komolyan, szerinted ha bevezetsz egy technológiát, amit várhatóan évtizedekig akarsz használni, ott az a legfontosabb szempont, hogy milyen költségekkel tudod lecserélni? Nem tudod érted-e, mekkora marhaságot írtál! Eleve azért választom, mert eszem ágában sincs lecserélni. Mi fenéért érdekelne a lecserélés költsége?

vs

>Pláne informatikában, ahol a az 1-2 év is nagy idő! Mi a francnak foglalkozzak most a váltás költségével, mikor 1-2 év múlva olyan változás jöhet, ami teljesen felborítaná a mostani elképzeléseimet.

Az első részére: nem az a terv, hogy lecseréljem, hanem az a terv, hogy nem cserélem le, de ha beüt valami váratlan és megdrágul az eszköz, vagy használhatatlan lesz, akkor le tudjam váltani minimális költséggel. A hosszú távú terv nem az eszközök megtartása, hanem a kialakított rendszerem megtartása. Az a terv, hogy a kialakított rendszer minél rugalmasabban tudjon alkalmazkodni a megváltozott helyzethez. Ha ezzel nem törődsz, akkor nem csak az eszközöket kell minimális költséggel lecserélni, hanem a rendszeredet is át kell alakítani, ami már jóval nagyobb költség szokott lenni.

> Erre meg azt tudom mondani, hogy több tízezer különböző munkakörű emberről beszélünk. A webes célszoftver jó is lenne, ha ez a sok ember csak néhány jól modellezhető és leprogramozható dolgot csinálna. De nekem fogalmam sincs, hogy ez így van-e.

Így van, erről nem sok konkrét dolgot tudunk. Ellenben azt tudjuk, hogy az önkormányzatoknál a munkák döntő többsége adminisztratív jellegű, ami nagyon jól gépesíthető, főként amiatt, hogy az önkormányzati működés az egyik legjobban leszabályozott terület (rendeletek, szabályzatok, törvények által).
Épp ma olvastam egy cikket, ami kissé idekapcsolódik, ahol épp arra figyelmeztet Bill Gates, Elon Musk, és Stephen Hawking, hogy egyre jobban gépesítenek egyre több munkahelyet.

Szerintem te összekevered, hogy mit mihez írtam:

1. Egy infrastruktúra bevezetése beruházási döntés. A beruházási döntés jellemzően hosszú időre szól. -> Lásd München
Ez nem egy olyan dolog, mint hogy kitől rendelem az irodaszert. Ha egyszer eldöntöttem, a döntésem évekre szól. Nem tudom értelmezni a vendor lock-in-t. Ha egyszer eldöntöttem, onnan csak nagy nehézségek árán tudok szabadulni, de nem azért mert vendor lock-in hanem azért, mert ez egy beruházási döntés.

2. Semmi értelme a jelenben foglalkozni egy jövőbeni döntéssel, mert csak olyan "lényegtelen" információk hiányoznak, mint váltok-e, mire váltok, mikor váltok, ez mennyire lesz nehéz és költséges. Hangsúlyozom beruházási döntésről beszélünk. Ide jön a magyarázatom: "Pláne informatikában, ahol a az 1-2 év is nagy idő! Mi a francnak foglalkozzak most a váltás költségével, mikor 1-2 év múlva olyan változás jöhet, ami teljesen felborítaná a mostani elképzeléseimet." A váltást tervezését akadályozza a gyorsan változó informatika környezet, nem a meglévő projekt működtetését. -> Értelmetlen a jelenben a váltással foglalkozni, kivéve ha váltani akarok.

3. Én adminisztratív munkakörben dolgozom, a munkám egy része automatizálható, de nagyon sok külső adatok kapok. Aminek a formájára kevés ráhatásom van. Azt a részét nem igazán lehet automatizálni. Egy önkormányzatnál se hiszem, hogy csak 1-2 dolgot csinálnának.

"Az első részére: nem az a terv, hogy lecseréljem, hanem az a terv, hogy nem cserélem le, de ha beüt valami váratlan és megdrágul az eszköz, vagy használhatatlan lesz, akkor le tudjam váltani minimális költséggel. A hosszú távú terv nem az eszközök megtartása, hanem a kialakított rendszerem megtartása. Az a terv, hogy a kialakított rendszer minél rugalmasabban tudjon alkalmazkodni a megváltozott helyzethez. Ha ezzel nem törődsz, akkor nem csak az eszközöket kell minimális költséggel lecserélni, hanem a rendszeredet is át kell alakítani, ami már jóval nagyobb költség szokott lenni."
Bocsáss meg, de pont magadnak mondasz ellent. Egy meglévő projekt már nem fog tudni hirtelen megdrágulni, hiszen azt már kifizettem, működik, már csak üzemeltetem kell. Minél tovább tudom üzemeltetni, annál "olcsóbb" volt a beruházás költsége, hiszen hosszabb időre tudom szétosztani.

+1

Időbe telik mindenhová betenni újra a függőséget okozó protokollokat és formátumokat, ms only scripteket, hogy az ms számára ideális legyen a helyzet.

Itt leginkább arról van szó, hogy egy linux stackkel elvben meg lehetne csinálni, hogy ha azt látjuk, hogy az üzemeltető banda nincs a helyzet magaslatán (mint erre utaltál is ebben a konkrét esetben, és aminek simán lehet valóságalapja), akkor az üzemeltető bandát lehet elküldeni, hozni helyette másikat, aki rendbeszedi a stacket, anélkül, hogy bármit bárhova kellene migrálni, míg egy zárt rendszernél meg ezt annyira nem úszod meg.

Az más kérdés, hogy egyrészt itt a legnagyobb baj valószínűleg nem az os, hanem a workflow támogatásra összetákolt bazi sok izébigyó, meg hogy tulajdonképp windows üzemeltető is lehet cserélni, és valószínűleg in-practice nem lesz fajsúlyosan olcsóbb ha az esetleges javításokat valami hozzáértő megcsinálja az opensourceban, mintha megcsinálná a vendor. Bár az kétségtelen tény, hogy annak azért megvan az esélye, hogy ha valami nagyon kritikus, akkor egy open stacken lehet rá találni valakit, ellenben ha mondjuk az ms megvonja a vállát, hogy ők ezt nem, akkor ÍJ.

A Linuxra migralas lassu volt, mert egy csomo vendor lock-int meg kellett szuntetni. Ami ennek koszonhetoen megy egy Firefoxban vagy LO-ban, az Windows alatt is menni fog nagyion nagy valoszinuseggel, erre nem kell kolteni.
Viszont el kell tapsolni egy nagy rakas penzt mindenfele licenszekre, gepek lecsereleserol volt szo (amire egyebkent nem lenne szukseg).
Es a felhasznalokat ugyan ugy kell oktatni, mintha Windowsrol valtananak Linuxra, csak most a masik iranyban.

Szerintem ha jol csinaltak a vendor lock-in megszunteteset, akkor a fenti haromnak kellene lennie a legnagyobb koltsegnek.

Viszont szivesen latnek egy olyan tanulmanyt is, hogy a most fennallo problemakbol mennyit lehetne 2021-ig abbol a penzbol megszuntetni amibe az at/visszaallas kerul.

--
http://blog.htmm.hu/

A visszaváltással a transzparenciának is jó eséllyel búcsút mondhatsz. Eddig tudtad, hogy mi folyt ott, eddig hívtak külsős szakértőket, eddig voltak tanulmányok, ezeket eddig publikálták.

--
trey @ gépház

Idézet:
To the extent permitted by applicable law, the terms and conditions of this agreement are confidential. Neither party will disclose such terms and conditions, or the substance of any discussions that led to them, to any third party other than Affiliates or agents, or to designated or prospective resellers who: (1) have a need to know such information in order to assist in carrying out this agreement; and (2) have been instructed that all such information is to be handled in strict confidence

Szerintem kizárt. ;)
(Max annyit ami törvényileg kötelező mint például gondolom a fenti esetben is :))

Tehát a mutyit ezután már nem kell álcázni, mert amúgy is eléggé el lesz takarva. Csak isteni szerencse lesz, ha véletlenül kitudódik.

--
trey @ gépház

Ez egy 19 éves email egy olyan embertől, aki 17 éve nem CEO-ja a Microsoftnak. Hadd ne kelljen több évtizeddel ezelőtti megszólalásokon is vitatkozni.

Mikor született a döntés, hogy Münchenék Linuxra váltanak? :)
(szerintem akkor még javába a "másik" Microsoft voltatok :))

"Mikor született a döntés, hogy Münchenék Linuxra váltanak?"
2003-ban.

Kérdés mennyit változott az MS ez idő alatt.

Idézet:
5.3.1.2.5 Conclusion

It follows from the foregoing considerations that Microsoft's behaviour risks eliminating competition in the work group server operating system market, due to the indispensability of the input that it refuses to supply to its competitors.

Olyan sokat nem. (2004) :)

"due to the indispensability of the input that it refuses to supply to its competitors."
vs
https://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise
és
https://msdn.microsoft.com/en-us/library/dd208104.aspx

Ezek mind 2004 utániak, és pont az általad idézett dolgok is szerepet játszottak a létrejöttükben szerintem.

Úgy értettem, hogy Gates 1998-as levele és a Müncheni döntés között. Azóta természetesen változott (igaz ebbe az irányba szerintem inkább kényszerből :))

> igaz ebbe az irányba szerintem inkább kényszerből :)

Az evolúció már csak ilyen kegyetlen. ;)

nehezen..

Mert ilyenkor elképesztő vendor lock-in van és kész.
Olyankor nincs vendor lock-in, amikor ugyanezen foss huszárok állitják, hogy a libreoffice-ra átállás az tök egyszerű, mert az aztán kompatibilis és mindent tud, amit a user használni akar.
Ez már csak igy megy :)

de legalább verzióváltásnál nem kell importszűrőt vadászni éjjel a neterdőben :)

pont most amikor a libreoffice végre kezd valahogy kinézni ezzel a notebookbar-ral... vicc... van az a pénz...

--
GPLv3-as hozzászólás.

Azért azt tegyük hozzá tényleg, hogy a LibreOffice UI úgy ahogy van, egy hányadék. Mindig is az volt, már az OpenOffice idején is. Szerintem azok az eszközök közelében sem vannak az M$ releváns termékeihez. Körülbelül annyi a hasonlóság, mint a Photoshop és a GIMP között: csak az mondja, hogy ugyanannyi idő megoldani benne valamit, aki még sosem próbálta mindkettőt.

Nem védeni akarom az M$-t, nekem dual OS-sem van. (Kubuntu - munka, Win10 - szórakozás, kivétel ha grafikai vagy irodai szoftver kell)

-------
It is our choices that define us.

"mint a Photoshop és a GIMP között: csak az mondja, hogy ugyanannyi idő megoldani benne valamit, aki még sosem próbálta mindkettőt."

Emlékszem arra a csúnya égésre, amikor egy Photoshopper ugyanezzel jött nekem és kiguvadt a szeme, amikor megcsináltam Gimp-ben egy egyszerű taskot, amit szerinte ő Photoshopban ilyen könnyen és gyorsan nem tudott volna.

Szóval: attól függ.

--
trey @ gépház

Ez egyéni vélemény volt, biztosan nem vagyok egyedül vele. Nem állítom, hogy mindenben jobb a Ps, arra is felróható, hogy lassú, zabálja a memóriát, stb... mert az Adobe sem töri magát egy kiadós refact-ra.

Pár éve, amikor a Creative Suite csomag megjelent, tényleg megpróbáltam átállni mindenben Unix eszközökre. Mindent megtanulni, alternatívák, billentyűkombinációk, stb-stb. 2 hónapig ment a dolog. Most is tudnám használni talán, de a Ps sokkal jobban kézreáll. Talán megszokás, nem tudom.

-------
It is our choices that define us.

az számít hogy milyen a skin a szövegszerkesztőn?

Nem a skinről beszélek. Hanem a menükről, a használhatóságról. Bár azért az sem utolsó dolog, hogy amikor sötét skint használok KDE-ben, akkor üszök-ronda lesz tőle a LibreOffice default skinje. Ez még nem is zavarna annyira.

Az M$ Office szalagos megoldása pl. eleinte rohadt nagy baromságnak tűnt, de azóta rájöttem, hogy zseniális ötlet volt. Az aki egész nap ezeket nyomkodja - mondjuk egy titkárnő - nyilván számítani fog neki, mennyi idő megoldani benne bonyolultabb megoldásokat, mint mondjuk egy táblázat kiszínezése. Ez lehet 2 kattintás, meg 25 is.

-------
It is our choices that define us.

ez nem tartozik ide ugyan, de az a titkárnő amelyik wordben tud táblázatot csinálni, pláne olyat ami még számol is, az már soha többet nem csinál ilyen táblázatot, mert az minimum irodavezető v. ilyesmi. aki meg színezni is tud táblázatot, nem is tudom:)

Mondjuk szerencsére nem kell sokat officet használnom, de gondolom a robotszerű ismétlődő folyamatokat végzők számára alapból felkínálja azt a két ikont amit használ.
A következő verzióhoz lehetne mellékelni egy külön billentyűzetet, amin csak szóköz, pont és tab gombok vannak, formázáshoz úgyis csak azt használja sok irodista :D

Többször futottam már bele, hogy ha géppel szerkeszthető változat is van, akkor azt meg kell formázni előbb, hogy be tudjam írni az adatokat. Pl csomó pontot kitörölni. Vagy ha excelben csinált nyomtatványt, akkor egyesíteni a cellákat, ahová írni szerenték. Igazából ezek csak arra jók, hogy kinyomtatva kézzel ki lehessen tölteni, de arra a pdf változat is jó lett volna, csak én vagyok hülye, hogy inkább géppel írom bele, mert azt talán kevésbé olvassák férre. Vagy vennek kéne egy hagyományos írógépet, amivel a kinyomtatott doksira rágépelek. Vagy pdf fölé újabb rétegként szöveget írni engedő alkalmazás kell.

Aki tudja mit csinál, annak talán az értelmes menü jobb, akinek fogalma sincsen és ki sem használja a funkciókat, annak meg a dizájnos. De megvan az esélye, hogy csak számomra nehezebb megtalálni bármit is a szalagom, miközben a menünk rögtön látom merre induljak.

"Aki tudja mit csinál, annak talán az értelmes menü jobb, akinek fogalma sincsen és ki sem használja a funkciókat, annak meg a dizájnos. De megvan az esélye, hogy csak számomra nehezebb megtalálni bármit is a szalagom, miközben a menünk rögtön látom merre induljak."

Szerintem a ribbon jó. Mert általában azok a dolgok vannak éppen rajta, amik jó eséllyel relevánsak lesznek. Ráadásul nem értem ezt a fene nagy nem találok meg rajta semmit, mintha legalábbis randomszámot dobálna, hogy mi hol legyen, miközben gyakorlatilag annyi az egész ribbon, hogy kiteszi neked az épp aktuálisnak tűnő főmenük tartalmát egy toolbarra, szép nagy gombokkal (amiket egyébként faszán elárulják, milyen shortcuton vannak, ha neked az kell). Én mostanában ültem vissza linux desktop elé, és hát mikor először elindítottam egy writert, akkor finoman fogalmazva nem az volt az első gondolatom, hogy de jó, hagyományos menük.

+1

-------
It is our choices that define us.

Aki akar az a LibreOffice-ban is használhat majd Ribbon menüt. Az 5.3-as verzióban már benne van experimental feature-ként.

Ez jó, talán majd eljut hozzám f26-al vagy valami. Hálistennek mostanság nem kell annyit csinálnom ilyet, hogy nagyon fájjon.

Hahhh. Egesz gyorsan haladnak a korral, most mar akar suthetnenek Vancza sutoporral is.

Szerk: annyira jol nez ki a cucc, hogy elkezdett learaszolni egy pre-release PPA-bol az uj LO.
--
Blog | @hron84
Üzemeltető macik

Az Office-ban lévő ribbon valóban jó.
Azonban maga a ribbon UI az csak egy UI paradigma, lehet azt rosszul is csinálni. Az Office jól csinálja.

A ribbon UI története: https://www.youtube.com/watch?v=AHiNeUTgGkk
Baromi jó videó.

persze, nyilván nem office specifkus, csak épp itt jött elő. :)

Jónak tűnik, egyszer megnézem, danke.

csinálj magadnak saját toolbart/menüt. és kész.
ha nem megy szólj, keresek neked lépésről lépésre leírást, libre- open- ms officehoz :)

csináljon a nehézség. Vagy a szoftver fejlesztői :) Nyilván tudnék, ha akarnék, de nem akarok, annyira nem mozgat.

Egyébként meg ez most hogy jön ide, mikor a ribbon jóságáról / nem jóságáról beszélgetünk?

nemt'om

azt mondod, jó eséllyel rajta van a robbon menün az ami neked kel.
csinálj saját menüt, és BIZTOS rajta van ami neked kell.

talán így.

És olyat hogy csinálok így, hogy ne legyen rajta az a rakás izé, ami éppen nem kell? Meg azok a dolgok, amiket esetleg nem is tudok, hogy kellenek, mert nem tudtam a létezésükről? :)

hát 200 rugóért kell is hogy jó legyen az a photoshop. de ennyivel nem jobb.

sőt..

A lényeg az, hogy egy vagyonba került átállni opensource alapra, majd egy vagyonba kerül visszaállni. Mindkét alkalommal csurrant-cseppent ide-oda haveroknak. És ez az utolsó mondat a kulcs. Ott is így mennek a dolgok, csak sokkal szofisztikáltabban kell művelni a korrupciót, mert van tétle a lebukásnak.

Na, ide is egy Subscribe

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Amúgy aki üzemeltet linux desktopot, mancika-kompatibilis már?

Anyám rühelli az ubuntut, vagy 10 éve az van a családi gépen, amióta tabletje van, szinte csak az abev miatt kapcsolja be évente 1x.

Én 12 éve kiszálltam a linux desktopról, OS X, kb úgy fogtam fel mint egy nagyon drága de jól összerakott unix alapú os, nem vicc: én a DE-ket meg a lib- és csomagháborút adtam fel.

Ha ma kezdenék desktop cuccba az vagy webkit-node vagy android-java vagy .NET alapú lenne, és nyilván ha lehet inkább webes mint desktop, de a GTK/Qt eszembe nem jutna valahogy, fejlesztőt se tudom, találnék-e eleget.

Szóval miután kisírtuk magunkat a korrupción (igen, van), el lehet 2017-ben user sírás nélkül DE szinten lenni linuxon?

Hát, ha te azt hiszed, hogy Windows-only cégnél a Mancikák nem ugatnak a szoftverre, akkor te valószínűleg vagy sosem dolgoztál support oldalon vagy bicikligumi belsőben élsz.

--
trey @ gépház

Csak amikor windows-on vergődnek akkor be van fogva a szájuk hamar és elcsendesednek. Általában a szoftver ára (többszöröse a dolgozó 1 éves fizetésének, tehát Ő egy kis légypiszok) van emlegetve, tehát sok pénzért szar nem lehet párhuzam, ingyen pedig persze hogy csak szart kaphatsz feldíszítve. Ha pedig ez nem eléggé meggyőző akkor el van intézve azzal, hogy ez van és ezt kell szeretni, változtatni nem tudunk rajta. (lásd. fentebb a release, open/close szál)
Ezt én csak iphone effektusnak szoktam nevezni. Amikor is veszel egy eszközt jó sok pénzért, majd amikor szembesülsz a hibáival akkor saját magadnak sem vallod be, inkább meggyőzöd magad is arról, hogy biztos a legjobbat választottad, hisz másnak is ez van. Ha kifizetsz egy telefonért 300k-t akkor nem fogsz utána magadra szarvakat is ragasztani hogy milyen ökör voltál. Inkább élsz hamis önigazolásban.

"Általában a szoftver ára (többszöröse a dolgozó 1 éves fizetésének"

Szerintem ez még egy közmunkásnál sem igaz, windows, office, windows server + mindenféle CAL-al sem, nehogy a magyar átlagfizetéssel.
Viszont közkeletű tévedés, ebből fakadnak az ilyen félresikerült történetek is, amikor azt hiszik, hogy az oprendszer árát megspórolva majd mekkorát spórolnak, aztán kiderül, hogy ellenkezőleg.

Nem windows/ms office-ra gondoltam, vagy akármi hasonlóra. Hanem az egyedi programokra. Legye akár a kiterjesztése XLS(X), vagy bármi más.

Egyedi szoftver minden oprendszerre drága, ott nincs különbség.

Erről két gondolatom van:
1) ugatnak, de nincs "különleges tényező": a légminőségre is kevesen ugatnak szmog idején, az úgy van, a természetes közeg, márpedig a Windows az elterjedtebb, kevesebbet okolják
2) bár repedezik a rendszer erősen, azért normális esetben a MS-nek több pénze és fókusza van usability engineeringre, amit jobban meg is fogadnak - én mai napig emlékszem a Canonical usability jelentésére a rhythmbox-ról, amiből két év alatt szám szerint nullát javított a projekt, a fő zenelejátszóban. Nem ismerem a TDF helyzetét de ott se érzem hogy egy usability marvellel lenne dolgom - aztán lehet csak nem használom eleget

Csak nekem jut eszembe az alábbi vicc?

Kiss 2000 forinttal többet talál a fizetési borítékjában, mint amennyi az elszámolási papírján van, de senkinek sem szól róla.
Egy hónap múlva már 2000-rel kevesebbet számol, és azonnal reklamál.
A pénztáros utánanéz, kideríti a múltkori hibát is, és számon kéri Kisst.
- Miért nem szólt már az első alkalommal is?
- Azt, hogy egyszer hibáznak, még elnézi az ember, de hogy kétszer, azt már nem lehet szó nélkül hagyni.

Hivatja a pincert a vendeg, hogy fizetni szeretne. Amikor hozza a pincer a szamlat, azt mondja a vendeg:
- Ennyire fortelmesen rossz kajat meg eletemben nem ettem, rettenetes itt a konyha.
Pincer:
- Akkor miert repetazott?
Vendeg:
- Mert elsore nem akartam elhinni.

:D