Az Ubuntu 18.04 LTS szakít a Unity desktoppal és újra GNOME-ot szállít majd alapértelmezett desktopként

Ubuntu

Mark Shuttleworth ma bejelentette, hogy az Ubuntu a konvergencia és telefon helyett a jövőben inkább a cloud és IoT területre fókuszál. Az irányváltás részeként erőfeszítéseiket immár már nem az Unity 8-ba fektetik, hanem más területekre fókuszálják. Ezért az Ubuntu 18.04 LTS-től kezdve az Ubuntu alapértelmezett desktopja nem az Unity, hanem ismét a GNOME lesz:

I’m writing to let you know that we will end our investment in Unity8, the phone and convergence shell. We will shift our default Ubuntu desktop back to GNOME for Ubuntu 18.04 LTS.

Az irányváltás részleteiről részletesen itt lehet olvasni.

( trey | 2017. 04. 05., sze – 19:56 )

Az Ubuntu Phone-ban sosem hittem. Az Unity-vel semmi bajom sem volt, régen pedig GNOME felhasználó voltam. A konvergencia nem hozott lázba. Szóval nekem mindegy. Csak könyörgöm, KDE ne legyen!

--
trey @ gépház

Nekem a DE nem sarkalatos kérdés, ha el tudja indítani a Firefox-ot, a Thunderbird-et, a terminal-t, akkor már el is végezte a dolgát.

"más: kde, ha ezek is alányúltak volna"

Nekem mindegy lenne, mert a KDE-nek nem volt olyan verziója (1997-ben vagy 1998-ban használtam talán először), ami tetszett volna.

--
trey @ gépház

( kikadff v | 2017. 04. 05., sze – 19:59 )

Maradt még valami saját világmegváltó projectjük, amit még nem kukáztak?

A research ilyen. Elindul 10 project, és jó esetben 1-ből lesz is valami. Nálunk a research beállított egy világmegváltó ötlettel, majd közöltük, hogy 10 éve kint van ügyfélnél, köszi! ;)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

A GNOME lesz a default, de értelem szerűen a jelenlegi Unity7 elérhető lesz. Unity8 szerintem soha nem fog feature parity minőségi szintre jutni.

> Szemelyesen neked mi a velemenyed errol a dontesrol, ha szabad ezt kerdezni?

A döntés maga időszerű volt. Olyan sok hibát görgetett már maga előtt az Ubuntu, hogy mindenképpen ideje volt egy határozot döntésnek.

Engem sokkal jobban aggaszt és zavar az a sok hibás technológiai döntés ami végülis oda vezetett, hogy a konvergencia terv, Unity8 és a Mir valamint ezekkel együtt az Ubuntu Phone életképtelenné vált.

Most akkor technológiai a döntés, vagy pénzügyi?

Azt írod, hogy Mark nem akar több pénzt erre költeni - ez egyáltalán nem technológiai döntés.

Meg azt mondod, hogy a research bizony ilyen, nem minden jön be - ez sem feltétlenül technológiai döntés.

A technológiai döntés az mindig megjavítható pénzzel és idővel, akár egy rewrite árán is.

Másrészt, ha már nagy opensource és nagy közösség: miért nem csinálja meg Mark azt, hogy kinyitja az Unity fejlesztését teljesen, és masszívan a közösségi (aka más cégek által is pénzelt) contribra támaszkodik 100+ fizetett fejlesztő helyett?

> Most akkor technológiai a döntés, vagy pénzügyi?

Egyértelműen pénzügyi a döntés. De ehhez a döntéshes sok hibás technológiai döntés vezetett.

> A technológiai döntés az mindig megjavítható pénzzel és idővel, akár egy rewrite árán is.

Igen, csak ehhez két dolog kell:
1) a hibás döntések felismerése
2) pénz a korrekcióra

Jelenleg egyikben sem vagyok biztos :(

> miért nem csinálja meg Mark azt, hogy kinyitja az Unity fejlesztését teljesen, és masszívan a közösségi (aka más cégek által is pénzelt) contribra támaszkodik 100+ fizetett fejlesztő helyett?

A Unity fejlesztésére soha nem érkezett nem Canonical alkalmazotól kontribúció. Ha mégis azt az arcot egy idő után felvette a cég.

„De ehhez a döntéshes sok hibás technológiai döntés vezetett.

Részleteznéd ezeket? Most már komolyan érdekel. Akár jöhet PM-ben is, mert itt szétflamelik. :(

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Bonyolult téma mindegyik...

Részben írtam róla már korrában. Fő pontokban:

1) a toolchain folyamatos változtatása volt az ami a Vivid - Xenial váltást lehetetlenné tette a telefonokon. Ezzel tulajdonképpen kinyírta a Canonical a sajáz platformját
2) nyomatni kellett volna a kínai text input fícsört, mert ez volt a világ legnagyobb operátorának egy feltétele, hogy tízmilliószámba nyomtassanak Ubuntu telefonokat
3) hagyni kellett volna a snap történetet és nem oda tolni tucatszám a fejlesztőket

de még van sok... nagyon sok.

"A Unity fejlesztésére soha nem érkezett nem Canonical alkalmazotól kontribúció. Ha mégis azt az arcot egy idő után felvette a cég."

Akár hibás döntés ez, akár nem, ez nem technológiai, hanem menedzsment döntés. Ha a Unity fejlesztése nincs nyílt fejlesztésként promotálva és nem kéri Mark a közösséget, hogy dolgozzon egy jobb Linux desktopért és Linuxos telefonért, akkor nem is történik más.

> A döntés maga időszerű volt. Olyan sok hibát görgetett már maga előtt az Ubuntu, hogy mindenképpen ideje volt egy határozot döntésnek.

Miert nem leptek vissza, javitottak a hibat es csinaltak?
Inkabb ugy erzem, h a desktop vonalat fogja hanyagolni valojaban az Ubuntu.

A Unity (7) jo, szeretik a userek. Van par tobbnyire felulrol jott ostoba dontes alapu basz (en pl. most a systray-en meg nem jeleno ikonnal szivok epp, amit Mark erobol hozott allitolag), de ezek javithatoak, mivel a dontes elott minden rendben volt.

Nem láttam konkrét számokat, de nem értem miért ne lehetett jó biznisz. Amikor kijött a BQ telefon, szinte azonnal elkapkodták. Akkor nem vettem, mert nem volt időszerű. Most jött el az ideje a telefon váltásnak. Figyelgetem is egy ideje, hogy hol juthatnék hozzá egy ubis telefonhoz, de nem lehet kapni sehol. Persze az, ha valami nem kapható, tényleg nem jó biznisz. Kifejezettem mérges vagyok, és elárulva érzem magam. Irgumburgum.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

https://hup.hu/cikkek/20170405/az_ubuntu_18_04_lts_szakit_a_unity_deskt…

Szoval jol ertelmezem szerinted is.

Csak Mark masrol beszel:

"The choice, ultimately, is to invest in the areas which are contributing to the growth of the company. Those are Ubuntu itself, for desktops[...]"

"a jelenlegi Unity7 elérhető lesz. Unity8 szerintem soha nem fog feature parity minőségi szintre jutni."

Kár. Unity 7 a compiz függőségével zsákutcának tűnik, Unity 8-ra férne rá egy jó adag fejlesztés, hogy Wayland alatt menjen, és akkor hosszútávra lehetne vele tervezni.

Vagy akár azt is el tudnám képzelni, hogy az Unity gnome shell alternatívaként folytassa az életét. Persze ez mind sok munka és ráfordítás volna.

> Unity 8-ra férne rá egy jó adag fejlesztés, hogy Wayland alatt menjen

Olyan, hogy "wayland alatt" nincsen... a Wayland egy protokol definíció, nem szoftver.

Maga a Unity8 mint DE szerintem marha jó cucc lenne. De még egy jó 3-4 hónapos fejlesztésre van szükség, hogy a desktop szinten hozza azokat a fícsöröket amiket elvárnánk.

Ha úgy kell érteni akkor fogalmazzunk úgy.

Amúgy nagyon nem mindegy. Ugyanis 2012-ben amikor az Ubuntu elkezdte a telefonos platform fejlesztést még nem volt a fasorban sem használható wayland implementáció.

Azt meg konkrét tény, hogy a wayland protokolhoz és a weston implementációhoz is akartak komntributálni Ubuntu fejlesztők, de ideológia miatt elhajtották őket fenébe. Szóval nem minden úgy van ahogy azt a bulvármédia megírja.

"sok hibás technológiai döntés "

meg szabad kérdezni mikre gondoltál? érdekelne... sose fogtam kezemben Ubuntus telefont, de nagyon tetszett. Mire odáig jutottam, hogy vennék , már nem lehetett kapni ...

------------------------------------------
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

> meg szabad kérdezni mikre gondoltál?

A legsúlyosabb a Vivid -> Xenial toolchain változtatás. Ez gyakorlatilag világossá tette, hogy a bq telefonokat nem lehet soha 16.04-re frissíteni. Ez brutálisan nagy hiba volt. Lényegében emiatt farolt ki szerintem több gyártó is.

A másik az volt, hogy a világ legnagyobb operátora akart Ubuntu telefonokat tízmilliós példányban. Csak kérte, hogy legyen kínai szövegbevitel. A főnökség erre nem adott embert. Könyörögtünk, de nem adtak. Ez is hatalmas hiba volt.

De van még több ilyen...

( Kronosz v | 2017. 04. 05., sze – 20:07 )

Hála istennek, hogy megy a Unity a kukába...

Meg vagyunk egy páran, akik szerint meg a leghulladékabb DE volt, amit valaha csináltak. A Macet másolni a Gnome3 is képes, de legalább sokkal normálisabb, mint a Unity, és a Mirre sem volt szükség. Ezzel a döntéssel egy régi nagy hibájukat csinálták vissza. Nagyon sok kezdő linuxost is elijesztett az Unity, feltették az Ubit, mert arról hallottak, aztán egy olyan spéci felület fogadta őket, ami teljesen más volt, nem keltett épp bennük sok bizalmat. Rég örültem már ennyire egy hírnek, pedig nem is Ubuntut, hanem Archot használok, ráadásul KDE-vel. Azt viszont nem értem, hogy sokaknak mi a bajuk itt a KDE-vel.

„sok kezdő linuxost is elijesztett az Unity, feltették az Ubit, mert arról hallottak, aztán egy olyan spéci felület fogadta őket, ami teljesen más volt[/qupte]

Másoknak meg pont ez jött be, avagy ezek alapján az OSX is szar.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Szerintem ha valakit a Unity elriaszt en-bloc a linuxtól, az ne is használjon linuxot. :P
Én teljesen semleges vagyok, semmi problémám nem volt soha vele.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( uid_15480 v | 2017. 04. 05., sze – 20:16 )

Itt is feltennem a kerdest (OMGUbuntun mar megtettem, am kivancsi vagyok az itteni kozosseg velemnyere is):

Most ez komoly? Azt gondoltam, hogy aprilis elseje mar reg elmult. Ezek utan mi lesz a celja az Ubuntunak (miert lesz erdemes ezt valasztani mas nagy disztroval szemben) ha minden egyedi fejlesztest kiolnek a rendszerbol a kozeljovoben? Igazan kedveltem az OSX fele (am ennek ellenere megis egyedi) UI megkozelitest, mert ezer kozul is felismerted, tudtad mutogatni ismerosoknek, hogy milyen tok jo, izleses, ujszeru az UI, hisz ezek a rendszerek mar nem azok mint amik 10+ eve voltak. Nem egy felhasznalot ennek koszonhet a rendszer (ha csak ismerettsegi es csaladi korombol indulok ki, akkor is).

A globalmenu es a HUD ugyancsak jo volt.

Igy felek, csak egy lesz az x^n+1 Linux disztribucio kozul.

Ami kene az Ubuntunak az egy normalis, bugmentes szoftverkozpont, meg egy rancfelvarras a jelenlegi Unity-ra, es korulbelul ennyi szvsz.

Udv. Egy hosszu evek ota elegedett Ubuntu felhasznalo

> Ezek utan mi lesz a celja az Ubuntunak (miert lesz erdemes ezt valasztani mas nagy disztroval szemben) ha minden egyedi fejlesztest kiolnek a rendszerbol a kozeljovoben?

Ahogy irjak is: szerver es IoT. A desktop szerintem uzletileg nem tul fontos, marad a szerver, elsosorban; az IoT-t meg majd meglatjuk, de jo eselyeik vannak.

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

Azt tudom, mar kiserleteztem vele korabban. :)
Keskenyebb panel, hasonlo dock... hat pont itt van a gond. 16:9-es monitornal a dock merete esa keperno szelen teljesen vegigfuto megoldasa pont tokeletes.
Na ezt Gnome Shellel nem tudod megoldani pont ilyenre, de meg csak hasonlora sem. Konkretan a Gnome3-tol sikitofraszt kapok pont ezert.

Udv.

"mindenféle alternatív dock" es olyan ami hasznalhato is, es jol integralodik a kornyezethez? En is probaltam tobbfele dockot a multban, koztuk az macos dockot is, es hat merfoldekkel voltak elmaradva ahhoz kepest. Talan meg a unity dock adta a legnativabb elmenyt, azt ereztette velem a rendszer, hogy a dock szerves resze a DEnek, nemcsak egy app, amit elinditottam es ikonokat tud rajzolni.

-
Go konkurencia kezelés gyorstalpaló

Nekem a 12.04. A 14.04-re is csak a támogatás miatt frissítettem. De már érezhetően gyengébb. A 16.04-től meg úgy fázok, mint egyszál pólóban a szibériai hidegtől. Halasztom ameddig lehet. Vagy váltok másra.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

...csak var es var az ember, bootolgat a rendszer, nezem systemd-udev meg wifi driver behuzas miatt mehetek kavezni. Na lebaszom rola ezt a fost. Voila vagy 7-8 masodpecet sporoltam a systemd nelkul. o wait hat nem arra van a systemd hogy gyorsabban bootoljon minden? mar azon kivul, hogy lassan a linux kernel helyet is atvenne?...

Ez csak nalam volt. Meg meg ezer mas dolog. De ez volt a legidegesitobb.

Na ennyit a systemd-rol :D
Szervereken meg aztan semmi ertelme a systemd-nek. Dekstopra meg csak-csak ra lehet eroszakolni, meg igenyt tamasztani ra, de meg a SysV init hasznalhatosagat sem eri el.

A Dell XPS 13-mam 14.04-es Ubuntuval kezdte eletet (meg Windows-zal, de az most nem erdekes). Emlekszem, hogy az elejen leesett az allam, hogy kb. 5 masodpercen belul bebootolt kesz desktopra, ebben benne volt a BIOS boot, a Unity betoltese, a jelszavam beirasa, a grafikus felulet megjelenese illetve egy terminal elinditasa. Magyarul _tenyleg_ hasznalatra keszen volt a rendszer. Azert maradt meg ennyire, mert suspendbol felebredni sem volt neki sokkal gyorsabb.

Aztan jott az uj verzio, es hirtelen latvanyosan belassult a boot, minimum duplazodott de inkabb triplazodott az egesz. Kenyelmesen el tudom olvasni peldaul a semmitmondo boot uzeneteket meg a szoveges kepernyon.

Annyira nem zavar, csak vicces, hogy erre miert volt szukseg. Azt mondod, koszonjem a systemd-nek? :)

Hat mindenesetre profilozd le azt a szart: systemd-analyze stb. Egyebkent van ahol gyors de az en gepemen 4-5szor lassabb volt a boot systemd-vel. Forgott magaban az egesz fosthalmaz. Ja es miutan bejott a desktop meg azutan sem volt wifi vagy egy percig. Repult a systemd es megoldodott a problema. :D

"a systemd automatikusan is behúzza a swap-eket és igen lelassul, ha meg is van adva."

Ha ez így van, az azért elég kemény. Nem kéne a programozóknak ennyire trehányaknak lenniük. (Programozó alatt itt értem egyrészt a systemd programozóit, akik ezt a gányt előállították; másrészt a disztribúció előállítóit, akik sikerell elfelejtették a swap kezelésbe az

if not_running_under_systemd ; then swapon -a ; fi

iszonyat bonyolult kódrészletet beleeszkábálni. És persze a systemd-nek is kb ugyanennyi lenne a fordítottja.)

Persze az is igaz, ez itt shell-script, az meg az ördögtől való. (A megtanulása meg pilótavizsgás agysebészeknek sem megy.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"o wait hat nem arra van a systemd hogy gyorsabban bootoljon minden"

Nem.

"Szervereken meg aztan semmi ertelme a systemd-nek"

Igazad van, elvégre arra egy szerveren egyáltalán nincs igény, hogy automatikusan újra tudjon indulni egy lehalt service, vagy el tudj indítani úgy egy servicet, hogy automatikusan elindulnának annak függőségeit is.
/sarcasm

ilyenkor mindig a fájdalom játszik a mosolygó szám szegleteiben, amit a szerencsétlen agyaroggyantakkal empatizálva érzek akiknek dogmatizált agyába nem jut el az információ hogy ezeket az igényeket már a poetterix előtt évtizedekkel megvalósították, hogy mást ne mondjak /etc/inittab

ez a "service függőség elindítása" mellesleg nemtommi lehet az NFS-en kívül, főleg hogy 1. úgyis újraindul 2. hát hová lett a nagy párhuzamosság 3. graceful exit vajommi

"Szervereken meg aztan semmi ertelme a systemd-nek" vitatkoznek. Azt hogyan oldod meg sysv-vel, hogy mondjuk mas user neveben fusson egy service? Vagy mondjuk azt, hogy legyen egy plusz kapcsolo amivel indul, vagy azt, hogy induljon ujra, ha valami miatt nem erheto el, vagy azt, hogy a sajat cuccod mondjuk csak azutan induljon el, ha mar valami elindult? Persze mindezt reprodukalhatoan, akar tobb disztribucion, es termeszetesen anelkul, hogy scriptekben kene sed-elni?

-
Go konkurencia kezelés gyorstalpaló

Nem. Marmint a megoldas mukodik, csak nekem nem elfogadhato 2017-ben, hogy fajlban kell szoveg-muveletet vegezni (sed, grep, es tarsai, tudom alulspecifikaltam a dolgot). Nem uzembiztos, es nehezebben automatizalhato, mint az, hogy leteszek egy filet valahova, ami szepen felulirja a meglevo beallitast. Ha akarom torlom, ha akarom masikat hozok letre a helyebe, szabad kezet kapok distro fuggetlenul. Nekem az echo "[Service]\nUser=joskapista" > /etc/systemd/system/valami.service.d/user.conf sokkal szofisztikaltabb megoldas. Nem kell tudni egy valtoztatashoz, hogy van-e mar letezo bejegyzes az inittabban, hogy a bejegyzesnek mi a tartalma, stb. Pl meg szeretned valtoztatni a usert, akkor tudnod kell, hogy volt-e mar valtoztatva, es ha volt mire, hiszen valamit valamire kell cserelni, mikozben minden mas beallitast meg meg kell tartani, vagy el kell kezdened regexp magiakkal dolgozni, amit tesztelni kell, hogy tuti ne legyen mellekhatasa. Egy szo mint szaz, az inittab elegy addig, amig egy szerveren kell megcsinalni, es a reprodukalhatosag nem szempont. Odamesz atirod, mukodik, jo. Amint ezt mondjuk 4-5 kulonbozo disztribucion kell tudni csinalni, valami toollal, akkor, es hangsulyozom 2017-ben szerintem, sokkal kenyelmesebb valasztas a systemd fele megoldas.

-
Go konkurencia kezelés gyorstalpaló

nekem nem elfogadhato 2017-ben, hogy fajlban kell szoveg-muveletet vegezni

vs.

echo "[Service]\nUser=joskapista" > /etc/systemd/system/valami.service.d/user.conf

Ha át akarod írni joskapista-ról pistajoska-ra, akkor mit csinálsz? Újra nyomsz egy echo-t, de véletlen se nyitnád meg a user.conf-ot, hogy egy bejegyzést átírj benne, inkább kockáztatod annak a lehetőségét, hogy elvesztesz az eredeti user.conf-ból további beállításokat, mikor az echo ... > ...-val felülírod.

A mai napig nem értem, hogy miért nincs egy (vagy kettő) config formátum es hozzá tartozó toolok szabványosítva, elérhetően a unix toolok részeként.

Már látom magam előtt az ide vonatkozó xkcd részletet, pedig olyan egyszerű lenne, ha ahelyett, hogy minden projekt feltalálná a saját, egyébként többnyire ini-re hajazó formátumát, lenne két formátum, egy komplexebb és egy egyszerűbb adatstruktúrát leíró, és az esetek 99%-ában nem kellene sed-del próbálkozni, és szívni, mert nem gondoltál arra az egy speciális karakterre, vagy különös esetre.

Már a 4.x-es AIX-nek voltak szabványos parancssori eszközei a /etc/inittab piszkálására. Már akkor rühelltem őket. A HP-UX-nek a mai napig van toolja a /etc/rc.config.d/* fájlok módosításra. A FreeBSD-nek van sysrc-je a /etc/rc.conf túrására. 3 különböző rendszer 3 különböző parancssori eszköze.

Ezzel együtt is az ötlet nem rossz, de ha lesz is belőle valami, az kb olyan lesz, mint a systemd: mindent fog tudni. Egy kicsit. De azokat legalább szarul.

(Mai agybaj: egy CentOS7-esen nézegettük a "netstat -napA inet" kimenetét, és a hajam égnek állt, amikor konstatáltam, hogy az 1-es PID LISTEN állapotban van a 0.0.0.0:111/tcp-n. rpcinfo -p kimenetében látszik, hogy a portmapper szolgáltatáson kívül más legalábbis nem hirdeti magát, de hogy ezt a szolgáltatást minek kellett a systemd-be integrálni, és ha amúgy senki olyan nem fut aki RCP-t használna, akkor minek hallgatózik a nagyvilágban - hát azt egyelőre nem értem. Természetesen systemd-hívők/guruk felokosíthatnak.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"voltak szabványos parancssori eszközei a /etc/inittab piszkálására"
"kb olyan lesz, mint a systemd: mindent fog tudni"

Pont az ilyen hibákba nem kell beleesni. Valahogy egy ed meg egy vi is került a szabvány unix toolok közé anélkül, hogy túlzásba esett volna valaki, és milyen jó, hogy ott vannak!

"konstatáltam, hogy az 1-es PID LISTEN állapotban van a 0.0.0.0:111/tcp"

Fura, itt is systemd, de ilyet nem látok

Most direkt bebootoltam a CentOS7-es gépemet. Azon is ott van. (És ezen a gépen az is feltűnt, hogy a 0.0.0.0:111/udp is ott van, de ez már legalább a klasszikus rpcbind, és nem systemd.) Netes keresgélés szerint ez a systemd-féle socket activation következménye. Mindenesetre elég meghökkentő látvány.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem tudom kinek a feladata ez. Nyilván valamiért a már meglévő szabványok is elkészültek, nyilván valakinek érdeke volt, és végigvitte azt, hogy az unix toolok listája rögzítve van, stb.

Honnan kéne tudnom, illetve mit változtat ez a szükségességén egy ilyen megoldásnak?

"de véletlen se nyitnád meg a user.conf-ot, hogy egy bejegyzést átírj benne" Felulirom a filet. Kb sosem fordul elo, hogy belepek egy szerverre es barmit is atirok. 2017 van ;) Ha egy szerver konfiguracio nem reprodukalhato, akkor az szart se er, max a home nas-on fordulhat ilyen elo.

-
Go konkurencia kezelés gyorstalpaló

2017 van ;)

Ah, 2017, a felülírás éve. Tényleg, mintha olvastam volna valahol :D

Értem én, hogy tudod reprodukálni a konfigurációt, de miért szívatnád magad a "helyreállítással", ha véletlen olyat írsz felül, amit nem szerettél volna? Vagy lehet, hogy ez a munkád, és így úgy tűnik, hogy fontos ember vagy a cégnél, mert mindig a problémákat oldod meg :) Vagy egyszerűen csak azért, mert 2017 van.

"de miért szívatnád magad a "helyreállítással", ha véletlen olyat írsz felül, amit nem szerettél volna?" ezt nem igazan ertem.

"Vagy lehet, hogy ez a munkád" az a munkam, hogy olyan szoftvert irjak, ami kb tetszoleges cloudba kb tetszoleges hadoop clustert huz fel nullarol. Es az a tapasztalatom, hogy egyszerubb/uzembiztosabb/tesztelhetobb egy konfig fajlt felulrini vagy letrehozni ha nem letezett, mint szoveg-manipulaciot vegezni.

-
Go konkurencia kezelés gyorstalpaló

Arrol beszelek, hogy uzembiztosabb, reprodukalhato, es distro fuggetlen megoldas a systemd fele konfig kiterjesztes, mint az inittab magia, amit vagy szoveg-manipulacioval tudsz csinalni, vagy 3rd party toollal. Mert ahhoz, hogy meg tudj valtoztatni egy sort egy fileban, elobb meg kell azt talalni, tehat tudnod kell mi az aktialis tartalma, mert pl azert mert mas user neveben futtatod meg nem akarod az ujrainditasra vonatkozo szabalyokat megvaltoztatni. Ha pedig tul altalanosra irod a kereso kifejezest, akkor arra is meg van az eselyed, hogy olyat is atirsz, amit nem szeretnel, hiszen egy darab file tartalmaz mindent. Ennyire egyszeru.

-
Go konkurencia kezelés gyorstalpaló

es distro fuggetlen megoldas a systemd fele konfig kiterjesztes, mint az inittab magia

No, én meg erről pont nem beszéltem.

Ha pedig tul altalanosra irod a kereso kifejezest, akkor arra is meg van az eselyed, hogy olyat is atirsz, amit nem szeretnel, hiszen egy darab file tartalmaz mindent.

Pont ezt írtam itt :)

Itt csak próbáltam azt a kettősséget megvilágítani, hogy nem akarsz fájlokban matatni, de bátran hozol létre/írsz felül fájlokat. Ekkor még nem volt szó arról (vagy ha igen, elkerülte a figyelmem), hogy a háttérben dolgozik egy konfigmenedzser (lehet, hogy neked természetesen magától értetődő volt).

Csak nem hagyott nyugodni, csak telepítettem egy bash-t és csak kipróbáltam: 

$ echo "[Service]\nUser=joskapista"
[Service]\nUser=joskapista

Nem ismerem a systemd konfig-parszolását, de szerintem nem lesz jó, ha ez kerül a user.conf-ba. Tipp: egy -e lemaradt az echo után :P
Csak biztonságosabb lett volna vi(m)/emacs/nano/joe/mcedit/...-ben megnyitni a fájlt...

Te tenyleg nem erted, vagy csak kotozkodsz? Javaslom ne nyomd fullba a kretent ;) Azert uzembiztos, mert mindig ugyanazt csinalja.

Ez mindig ugyanazt csinalja: echo "asd" > asd

Ez meg nem: sed -i 's/qwe/asd/' asd

A belepek a szerverre es atirom meg tovabbra sem jatszik.

DE! Tesztelni mindet kell!!!

-
Go konkurencia kezelés gyorstalpaló

Ez mindig ugyanazt csinalja: echo "asd" > asd

Feltételezve, ha létezik a könyvtár, ahova akarod a fájlt, másrészt van írásjogod (ill. nincs semmi speciális flag beállítva) a könyvtárra, ill. a fájlra (ha már a művelet előtt is létezett).

Ez meg nem: sed -i 's/qwe/asd/' asd

Dehogynem. Legfeljebb az eredménnyel nem leszel elégedett, mert nem feltétlen csak azt a qwe-t fogja cserélni, amit te szerettél volna, hanem az összes többit (mármint soronként mindig csak az elsőt, mivel nincs g opció megadva). Persze a csere nyilván csak akkor történik meg, ha az asd fájl már eleve létezett, ill. a megfelelő jogokkal bírsz (mint az előbb).

Tesztelni mindet kell!!!

Pontosan.

Kifelejtetted, hogy felteve, ha van operacios rendszer, meg felteve ha be van egyaltalan kacsolva a gep, felteve ha nem egy irogepbe irtam be a parancsot. Kertelek mar, hogy ne nyomd fullba a kretent, es probald meg megerteni a dolgot.

"Dehogynem" hat nem. Szerinted a sed ugyanazt csinalja ha van a fileban qwe meg akkor is ha nincs?? Gondolkozz ezen egy kicsit.

-
Go konkurencia kezelés gyorstalpaló

"Vagy" ugyanezt a szot tudnad az echo-s megoldasra is alkalmazni kerlek? A vagy azt jelenti, hogy vagy igy mukodik vagy ugy, tehat side effect van a mukodesben. De leforditom a konkret esetre. Az inittabban szeretned, ha joskapista helyet pistajoska futtatna a daemont. Csak akkor fog pistajoska neveben futni, ha elotte joskapista neveben futott (es volt bejegyzes az inittabban), minden mas esetben minden marad a regiben.
-
Go konkurencia kezelés gyorstalpaló

Te a végeredményt nézed, én meg magát a tevékenységet.
Te azt nézed, hogy a fájlban megjelenik-e a pistajoska (a megfelelő helyen, és csak ott), én meg azt nézem, hogy ki lett-e cserélve az összes joskapista pistajoska-ra.

A te válaszod az, hogy nem, nem jelent meg a pistajoska.
Az én válaszom meg az, hogy igen, ki lett cserélve az összes joskapista pistajoska-ra.

Érted, hogy hogy értem az "igen"-t? :)

"A te válaszod az, hogy nem, nem jelent meg a pistajoska." igen engem nem erdekel mas, minthogy a szerver ugy funkcionaljon, ahogy szeretnem. A hajamra kenhetem az "igen, ki lett cserélve az összes joskapista pistajoska-ra" amikor 100 szerveren elmegy a konfiguracio, es nem azt csinaljak, amit szeretnek, es az ugyfelnek nem megy a szolgaltatasa ;)

-
Go konkurencia kezelés gyorstalpaló

Nyugtass meg, te a disztributálandó konfigurációs fájlt sem szövegszerkesztővel állítod elő (bármly szoftver bármely konfigjáról van szó), hanem valami webes (?) űrlapon kitöltöd és SQL-adatbázisba tolod, és onnan generálod ki. (Vagy noSQL?)

Annyira vehemensen támadod azt, aki meg merészel piszkálni egy konfigot kézzel, hogy nekem kell ez a biztonság.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Eleve sql-be irom a konfiguracios filet, es irtam egy sajat FS implementaciot, ami be van csatolva a /etc ala, es amikor valami filet akar olvasni, akkor real time eloallitja a konfiguraciosallomany tartalmat. Persze, hogy a konfigok szoveg fajlokban vannak (altalaban valami templateben).

"vehemensen támadod azt, aki meg merészel piszkálni egy konfigot kézzel" en csak az ellen vagyok, hogy barki belepjen a szerverre, es ott atirkaljon dolgokat, mert az "IT ertelemben" nem reprodukalhato, nem beszelve arrol, hogy amikor az a kerdes, hogy mi a fene van a szerveren, akkor szinten be kell lepni, hogy megnezze az Nber. A konfiguracio source kontrol alatt legyen, es lehetoleg tetszoleges szamban lehessen reprodukalni kulonosebb skalazasi gondok nelkul (az operatort nehez skalazni, mert veges szamu terminalt tud egyszerre kezelni :D). Szerencsere vannak eszkozok, amik elvegzik ezt a feladatot. Ennek kapcsan irtam, hogy nekem szimpatikusabb a systemd fele konfiguracio kiterjesztes az inittabos megoldasnal.

Egy szerver nem szerver, ket szerver eseten meg szukseges, hogy szinkronban legyenek a beallitasok.

-
Go konkurencia kezelés gyorstalpaló

Már csak az nem világos nekem, hogy ahonnan disztributálsz, ott miért lehet systemd-s konfigokat tárolni/módosítani/szétszórni, és miért nem lehet inittab-ot tárolni/módosítani/szétszórni? A systemd - szigorúan IMO - pont ugyanúgy lehetővé teszi azt, hogy az egyes Linux-terjesztésekben másként oldjanak meg dolgokat, mint ahogy ezt a SysV-init lehetővé tette. Azaz ugyanúgy tárolni kell egy RH7-es systemd-konfigt, meg egy Ubuntu systemd-konfigot meg egy SLES systemd-konfigot. (És akkor még nem beszéltem valódi multikulti környezetről, ahol a millió Linux mellett előfordul egy-egy SUN/HP/IMB/egyéb *X rendszer is - amin jelenleg még nem systemd fut.)

Számomra nehezen hihető, hogy soha semmilyen körülmények között nem kell belépni egy szerverre, de biztos azért mert nem láttam még rendes szervert :-)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"biztos azért mert nem láttam még rendes szervert" ketlem, sot egeszen biztos sokkal tapasztaltabb vagy ezen a teruleten (nagy tisztelod vagyok ;))

"lehet", "nem lehet" ez igy ki van sarkitva, mert 1x sem allitottam, hogy nem lehet. Azt allitottam, hogy atlathatobb/uzembiztosabb/stb. Persze mindent lehet, de systemd eseten minden konfiguracios darabnak tudok letrehozni egy kulonallo filet/templatet, amit csak a megfelelo helyre kell masolni amikor szukseges, tehat kiterjesztem a configot. Ellenben az inittabnal, egy fileod van, ami tartalmazza a bejegyzeseket (plz fixme, en nem talaltam olyan opciot, hogy inittabba lehet includeolni fajlt). Szoval inittab eseten allapota van a fajlnak, amit kezelni kell tudni valahogy (hozzatenni, elvenni, lecserelni), igy ha mondjuk ugyanaz a recept/playbook/whatever felelos a master meg a slave nodeok telepiteseert, akkor szet kell if-elni azt az 1 inittab templatedet attol fuggoen, hogy milyen modban fut eppen.

"Azaz ugyanúgy tárolni kell" Amugy nem szent gral, es nem vagyok bigott hivo sem, hiaba nem ugy tunik. Van egy dolog, ami nagyon kenyelmes es megkonnyiti a napi munkankat, es amellett kardoskodok itt. Szoval nyilvan a feladattol fugg a megoldas. Lehet disztronkent tarolni kulon filet, ha ordenare modon elternenek, de lehet csak a templateben elagazni, ha aprobb az elteres. De igazan, ami jo az egeszben, hogy tudok olyat csinalni, hogy 1 darab konfig set van, ahol minden letezo dolgot felulirok, ami csak elofordul a kulonbozo disztribuciok miatt, es akkor pontosan ugyanugy fog viselkedni minden kornyezetben. Persze fenntartom a "tevedes" eselyet, mert neha belefutni ordas nagy szivasokba, amikor nincs mas, mint letolni a gatyat, es elorehajolni.

"amin jelenleg még nem systemd fut" ahol nincs systemd ott nem hasznaljuk mi sem, nem kell hozza egzotikus rendszer, egy mezei aws linuxon sincs by default :)

"soha semmilyen körülmények között nem kell belépni egy szerverre" belepni be kell neha, tesztelni, hibat keresni (legalabbis a sajat installaciokra), de atirni azt nem. Nincs olyan, hogy valamit at kell pockolni egy szerveren, es azt nem kell atpockolni az eppen futo tobbi gepen, meg a jovoben letrehozottakon is. Nalunk jonnek mennek a szerverek, egyszer 10000 node fut maskor meg 600, igazabol fingom sincs a pontos szamrol, mert nekunk nincs is ralatasunk azokra gepekre, amiket managelnek a szoftverunkkel. Csak arrol tudunk, ha nem megy valami. Ami a konfiguracio managerben van az van a gepeken, es ha javitani kell valamit, akkor azt a kov patch/release majd fixalja.

-
Go konkurencia kezelés gyorstalpaló

Félreérted, én arra reagáltam (csak egy sorban és nem felsorolásszerűen), hogy "Mit találtál másnak?" Szóval előző megjegyzésemben a két kérdőjelet soremelésre cserélve talán érthetőbb lesz:

- systemd
- több erőforrás igény

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Leginkább a systemd-től félek. Ahogy látom, nem vagyok egyedül ezzel.
Meg a próbafrissítés is elhasalt. Befagyás, eltűnt dolgok, ilyenek.

Szóval egyelőre nem. Ennyi.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Nincs véleményem a systemd-ről. Gyakorlati okból minden gépemen systemd van, hogy ne kelljen egyszerre több ilyen szarral vacakolni. Ubuntu, Debian, Raspbian mind systemd-s. Szépen megtanultam, hogy kell vele a saját démonaimat automatikusan indítani, nincs vele gond.
--
ulysses.co.hu

Es pl. hogy kell a caps-lockot bekapcsolni bootidoben vele?:)
Vagy egy napom rament anno, de aztan valahol elkallodott az okossag. Nincs kedvem ujrasz*pni vele.

Vagy laptopra radugott macintosh kulso usb-s billentyuzetben az alt-almat cserelje fel.
Anno ez tok egyszeru volt, de mostmar ehhez is mintha systemd kellene.

Amit ki akarok hozni belole, hogy rohadt nehez barmi egyedi dolgot megcsinalni, es
lenyegeben szakirodalom (ie. forumok) alig vannak, mert kb. mintendki feladta a kiserletezest.

Vagy csak oregszem, es nem szanok ra egy-egy napot ilyen aprosagokra....

En mind a NetworkManager, mind a systemd helyett orulnek, hogyha jonne valami esszerubb es hasznalhatobb.:)
(a NetworkManagerrel az a bajom, hogy gui nelkuli gepeken egeszen mas a halozat elesztese (aka szerver), mint guis gepeken (aka laptop))

---
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....

"Amit ki akarok hozni belole, hogy rohadt nehez barmi egyedi dolgot megcsinalni,"

Pedig nem sokkal komplexebb (csak kicsit) írni egy systemd service-t, mint egy initscriptet, ami lefut bootkor, és megcsinálja az okosságokat.

"a NetworkManagerrel az a bajom, hogy gui nelkuli gepeken egeszen mas a halozat elesztese"

Én nem állnék neki networkmanagert használni szerveren, de desktopról meg hiányozna. Egyébként van networkmanager cli, szóval nem gondolnám, hogy ne lehetne egységesen kezelni a kettőt.

( uid_16313 | 2017. 04. 05., sze – 20:37 )

Kicsit lassan jutottak el idáig, hogy belássák, a Unity zsákutca.
Viszont a Gnome egy újabb esélyt kapott arra, hogy kvázi szabványos linux DE legyen. Az Ubuntu-val a háta mögött komolyabbak az esélyei.

--
robyboy

A Unity nem zsákutca. A hír nem is erről szól.

Arról szól, hogy Shuttleworth nem akar pénzt költeni semmilyen desktop fejlesztésre, mert legyen az bármilyen jó, üzleti sikerre nincsen kilátása. A GNOME-al sem lesz biznisz, de arra nem fog költeni egy büdös buznyákot sem.

Jelenleg 100+ ember dolgozik a Desktop/Convergence dolgokon. Beleértve a Unity-t és a Mirt meg az egést hóbeleblancot. Ez most szépen lemegy max 20-ra. Nem lesz sok upstreamed fícsör a GNOME-nak. Lesz Ubuntu wallpaper meg esetleg valami Ubuntu skin.

Dehogynem zsákutca. Nem emlékszem pontosan, de kb. 2004 óta fejleszthetik a Unity-t, költöttek rá rengeteget, stb... persze, amikor már 100%-ban látszik, hogy nem jött be a terv, megmagyarázzák.

Akárhogy is nézzük a Story-t, hatalmas kudarc. Az elsö perctöl lehetett tudni. A fejlesztése sem haladt sosem igazán.

--
robyboy

2011-ben kezdték el fejleszteni a Unity-t. 2012 óta default DE a Unity. 5 év alatt többtízmillió asztali számítógépet adtak el szerte a világon Unity-vel. Öt év alatt a legnépszerűnn linux disztróvá vált az Ubuntu a Unity-vel. A mai napig az egyetlen olyan teljesen szabad forráskódú DE aminek került érintőképernyős portja kereskedelmi forgalomba.

Ez miért kudarc?

Bevallom én nem értem ezt a bulvárszemléletet. Ha Usain Bolt nekilendül egy 100 méter lefutásának akkor a végén amikor megáll, kifújja magát, körölnés és továbblép akkor hirtelenm lúzer lesz???

Miért gondoljátok sokan, hogy ha egy szoftver projekt nem radírozza le a világot, ha mem ér el világhatalmat és nem alapítanak rá milliárdos nagyvállalatokat akkor az máris kudarc? A Unity 2011-ben nekifutot... ment szép öt évet és most érz véget a pálya. Eddig jött és amit eddig elért az szép és jó. Igen, futhatott volna tovább, nagyobbat, gyorsabbat. De az élet már csak ilyen :) A legtöbb szoftver projekt egyszer végetért. Még az Android is véget fog egyszer érni. Meg az OSX is.

Ki többet fut, ki kevesebbet. Ez ilyen bringa :)

Minden a kukában landol egyszer. Minden. Nincsen olyan szoftver ami gízai piramis vagy római kolosszeum lenne. Minden szoftvernek lefő egyszer a kávé.

Én nem tudok kudarcnak értelmezni egy olyan projektet amit a fejlesztők örömmel csináltak és a felhasználók örömmel használnak. Igen, minden tarthat tovább, minden lehet nagyobb. De én nem szeretem azt a megközelítést, hogy csak a világhatalom és a milliárdos birodalom számítana.

minden változik a szoftvervilágban is, mint egyébként, és itt is azok maradnak talpon, azok élik túl, akik tudnak alkalmazkodni a mindenkori elvárásokhoz. Sokan belebuktak már abba, hogy nem tudtak asszimilálódni a piaci elvárásokhoz.

Azok a cégek, akik hajdanán formálták a piaci elvárásokat (pl. Apple, Microsoft), mára már csak loholnak a pénzük után, és fogalmuk sincs, hogy az adatgyüjtésen felül mit kellene tenniük pontosan. Mark-nak sem sikerült elképzeléseit ráeröltetni a világra. Ha a Unity valóban sikeres lett volna, nem kellene abbahagyni a fejlesztését.

Az uttörö géniuszok világa már elmúlt.

--
robyboy

Rossz, illetve hibás a prekoncepciód.

A szoftver ipar nem sportverseny és nem is hegylakók küzdelme. Minden szoftvernek megvan a maga kifutása. Egyiknek ennyi, a másiknak annyi. Van olyan amelyik világhíres lesz és milliárdokat hoz a gazdinak van olyan amelyik egy kisebb klubban muzsikál csak.

A te megközelítéseddel lényegében minden szoftver kudarc. Mert nincsen örök szoftver.

Szerintem ez a "nem sikerült ráerőletni a világra" egy teljesen téves dolog. Stukkert tartott a fejedhez, hogy Unity-t használj? Ostorral vert téged, hogy használd a Launchpad-et? Rádküldött verőembereket, hogy bazaar-t használj???

Nem a szoftverek örökkévalóságáról akartam papolni. Arra akartam rávilágítani, hogy Mark Suttleworth megálmodta a jövöt Ubuntu alapokon, aztán valahogy nem úgy alakult az élet, nem abba az irányba ment, amerre szerette volna. Ebböl az aspektusból nézve tünik számomra hiábavalónak a sok belefeccölt energia, amit olyan technológiákba toltak bele, ami nem lesz már 2 év múlva.

Ez olyan, mint amikor elvesztettük a második világháborút, de a rádióban végig azt lehetett hallani, hogy hol meddig tartanak ki harcoló alakulataink. Vagy a "Magyarország jobban teljesít". De nem akarok itt politizálni.

Lehet vakon hinni valamiben, de ha nincs mögötte tehetség, akkor veszett fejsze nyele. Volt akiknek ez bejött, pl. Steve Jobs-nak. Amióta nincs, azóta züllik szét az Apple is szép csendben pl.

Nem kellett volna saját DE. Nem kellett volna Upstart. Nem kellett volna Mir. Nem kellett volna csomó minden. Maradhattak volna a compiz nélküli Gnome2 vonalon, akár MATE késöbb. Stb... stb...
Nagyon sokan elhagyták a distro-t, amikor a Unity megjelent. Ezt a zakót nem heverték ki sosem.

--
robyboy

Fejlesztesz egy terméket, majd közben rájössz, hogy a másik jobb.
Ha a fejlesztésed a jobb, akkor mások választják azt a sajátjuk helyett.

Ha lesz jobb a systemd-nél, majd lesz. Attól még az Upstart egy sikertelen próbálkozás volt.

Ide nem a jó, meg a jobb a legmegfelelöbb szó, inkább az életképesebb, ami jelentheti akár azt is, hogy szar.

Ld. pl. OS2/Warp, ami jobb volt sokkal a Windows 95-nél, mégis kihalt.

--
robyboy

Miért, szerinted nem így volt? A szar Windows 95-re ezerszer több applikáció volt elérhetö, mint OS/2-re. Ennyi. Ugyanez történt az Android kontra Microsoft Phone esetében is. Akármennyire is jó technológiailag egy rendszer, ha nincs mögötte fogyasztható tartalom, veszett fejsze nyele. A Microsoft idöben felismerte, hogy le kell fizetni a piacot (OEM, Softwarefejlesztök, stb...). Ök nyertek.

--
robyboy

Röviden:

Létezett egy tökéletesen jó szó, az "application" mint program/szoftver fordítására, az "alkalmazás". Nem mondom, hogy ez a legjobb szó amit használhatnánk rá, de létezett, és ennek ellenére valami oknál fogva mégis ki kellett találni egy új terminológiát. Ez egy kicsit fura és indokolatlan.

Ez olyan, mint ha valaki jönne, és elkezdene fordító helyett "kompíláló"-t használni, és mire pislogsz kettőt mindenki ezt használja.

Az indokot egyébként nem tudom. Az rémlik, hogy először azok a rétegek kezdték el használni, akik amúgy az informatikától távol állnak. Gondolom a mobilos alkalamzások terjedésével elkezdett a témával a szakmától távolabb álló sajtó is foglalkozni, akik szimplán nem foglalkoztak a meglévő terminológiával, és átfordították angolból magyarra így. De ez csak egy tipp.

Az applikáció egy létező szó, nyelvtanilag is helyes. Latin eredetű. Ugyanabból a latin szóból van származtatva, amiből az angol application. Tehát, az angolok se használják az applicationt tovább, mert az nem angol (eredetű) szó. Nézd már végig a nyelvünket, hogy hány idegen eredetű szavat használunk? És nem csak a magyar, az angol, a német, stb...sorolhatnám. Minden nyelv tele van idegen kifejezésekkel, sokszor honosítva, sokszor nem (na, ez szerintem az igazi probléma).

A latin meg úgy általában ott van mindenhol. Operáció (műtét), injekció (oltás) és a többi. Vagy sufni, pajszer, sublót, muszáj (muss sein), rengeteg germanizmus. Ezeket se használjuk már jó?
Meg millió török eredetű szó, ami a 150 év itt tartózkodásuk után megmaradt, és valljuk be, úgy használjuk őket, hogy azt sem tudjuk már, hogy nem magyar eredetű szavak.

Ha valakit zavarnak a honosított idegen eredetű szavak, az kezdjen el rovásírást tanulni, az a "magyar" nemde? Kb. a baromfiudvarnál nem jut messzebbre az ember, mert hogyan írod le rovásírással pl. azt, hogy számítógép?

Azt is viccesnek tartom, ha már szóba hoztam, amikor mai településneveket írnak ki rovásírással, mintha valaha leírhatta volna így bárki is az adott település nevét.

Szóval, alkalmazás vagy applikáció egykutya.

u.i.: Akkor ne használjuk az "app" rövidítést sem ugyebár, inkább az "alk"-ot helyette, mennyivel jobb. Aki meg fejleszti az "alk"-ot, legyen "alkesz".

Wikipédiáról még egy kis szösszenet:

"Sok latin alapú szó (elsősorban nemzetközi szó) található más modern nyelvekben is, mint például az angolban – ahol a francia közvetítésével a latinból származó szavak aránya szélsőségesen magas, az Oxford Dictionary szerint a ma használatos angol szókincs fele (például szinte az összes elvont fogalom) – és a magyarban is. Egyes kifejezések annyira beépültek a magyar nyelvbe, hogy latin eredetüket már észre sem vesszük. Közéjük tartozik a „persze” (vö. latin per sē intellegitur ’magától értetődik’), de egy elterjedt vulgáris szavunk is régi latin átvétel, a caco, cacare igéből származó magyar „kakál”.[1]". Na, és ha már eljutottunk a "kakál" szóhoz, akkor használjuk inkább helyette a "szarni" szót, az leglább finnugor eredetű:

"Az előkelő „székelés" szó egyébként már ülő alkalmatosságot feltételez, míg a szarni szó ősi, finnugor örökség." (Wikipédia)

--
robyboy

Hasonlóképp a disztribúció, ami helyett egy időben a "terjesztést" erőszakolták. Vagy most is? Tanuljuk ugye algebrában, hogy testekben a szorzás az összeadásra nézve disztributív. Azt viszont, hogy terjedős, még sosem hallottam, pedig az volna "magyarul".
--
ulysses.co.hu

Teljesen igazad van abban amit írsz, de úgy látom nem sikerült átadnom a lényeget: Nem vitattam az applikáció szó létezését. De nem ez volt a meglévő terminológia a szoftverekre korábban. Ennyi csupán.

Te mit gondolsz miért került elő ez, és miért nem alkalmazásként hivatkozunk a mobil alkalmazásokra hirtelen?

> Nem vitattam az applikáció szó létezését. De nem ez volt a meglévő terminológia a szoftverekre korábban.

Úgy érted, hogy nem ez volt a megfelelő szakkifejezés, avagy terminus technicus rá, ugye? :)

A terminológia a szakkifejezések összességét jelenti.

Az a helyzet, hogy az Ubuntu itt tulajdonnévként szerepel, az applikáció pedig nem. Ezt is keresd ki a nyelvtankönyvből gyorsan! :)
Plusz a szó végére nem kell kötőjel, helyesen: Ubuntut.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

> Mark Suttleworth megálmodta a jövöt Ubuntu alapokon

Ismerem személyesen Mark-ot. Egy évik közvetlen főnököm vol. Sosem voltak ilyen világhódító álmai. Egy teljesen legitim üzleti ötlete volt 13 évvel ezelőtt. Tolta bele a pénzt keményen és hagyta az embereit innoválni és kipróbálni új dolgokat. Ami nem jött be azt eddig is félretette a Canonical. Nincs ebben semmi dráma. Ilyen ez az ipar.

> Lehet vakon hinni valamiben, de ha nincs mögötte tehetség,

Azt honnan gondolod, hogy nincsen mögötte tehetség? Ismered a Canonical mérnök gárdáját?

> Nem kellett volna saját DE. Nem kellett volna Upstart. Nem kellett volna Mir. Nem kellett volna csomó minden. Maradhattak volna a compiz nélküli Gnome2 vonalon, akár MATE késöbb. Stb... stb...

Miért ne kellettek volna ezek??? Mindezek tették lehetővé, hogy az Ubuntu egy ismert, elismert disztró legyen. Ezek tették lehetővé, hogy ma messze a legnépszerűbb asztali linux disztró. Érdekes, de te mintha valamilyen párhuzamos világról beszélnél, ahol az Ubuntu nem egy top disztró.

> Ezt a zakót nem heverték ki sosem.

Milyen zakót? Vagy 700 mérnökkel operáló szabad szoftverre építő elismert és ismert cég a Canonical. A Cloud bizniszben komoly nyereséget elkönyvelő linux szolgáltató. Mindez arra az ismertségre és elterjedtségre épül amit az elmúlt 13 évben csinált a Canonical.

Elismerem, hogy az Ubuntu egy top distro. Nem a mérnöki tehetségnek vannak hiányában, hanem a jövő formálásának képességében. Az, ha egy cég mindig arra sodródik, amerre az ár visz, nem nyerő stratégia. Amúgy ez már az Apple-ra és a Microsoft-ra is igaz. Mindannyian láttam már szebb időket.

--
robyboy

> Az, ha egy cég mindig arra sodródik, amerre az ár visz, nem nyerő stratégia.

Mi alapján gondolod, hogy a Canonical esetében erről van szó.

Az amiről ez a hír szól, semmi más mint az, hogy Mark Shuttleworth nem látja semmilyen módon megtérülőnek, hogy 6 év után is tovább finanszírozza az Ubuntu saját desktop keretrendszerét. Nem éppen egy hetes projekt volt a Unity.

A jövő formálása pedig egy nehéz terep...

Nézd, Mark Shuttleworth eddig cirka 300-500 millió eurót lapátolt bele az Ubuntu projektbe. Ennek az összegnek lényegében a 90%-a bérköltség volt. Egy mérnök éves költsége átlagosan 60 ezer euró. Vagyis cirka 6000 mérnök évnyi fizetést adott ki Linux fejlesztőknek. Leegyszerűsítve 10 éven át átlagban 600 hard core linux kódert nevelt és tartott el a Canonical.

Én látom az Alumni klub tagjait... tele van az ipar velük. Google, Facebook, Apple, Intel, Samsung, stb, stb... Konkrétan nettó befizetője volt a srác az elmúlt tizenhárom évben a szabad szoftvermozgalomnak. Ha holnap megszűnik az ubuntu projekt és soha senki nem használ semmilyen Ubuntu-s szoftvert akkor is elképesztően nagy az a szakmai és kultúrális hatás amivel a Canonical hozzájárult a szabad szoftver mozgalomhoz.

Hogy ez a jövőt formálja-e? Szerintem igen. Én mérnök vagyok. Engem a legjobban az érdekel, hogy a liuxos, unixos, szabad szoftveres iparban legyen innováció és legyen munkája minél több szakinak. Bevallom engem a termékeknél sokkal jobban érdekel ez a közösség, ez a szemlélet, hangulat.

Az Ubuntu és a Canonical kultúrálisan nagyon jelentős szereplője az iparnak. És ez a szerep semmit sem változik... csak mostantól nem érintőképernyős eszközök, hanem virtuális szerverparkok lesznek a cél.

Szerintem sem kérdés, hogy a Canonical rengeteget adott a Linux-os világnak,

Persze adhattak volna sokkal jobb hatásfokkal is, de persze utólag könnyű okosnak lenni.

Nekem az Ubuntu for Android fáj a mai napig a legjobban. Szerintem nagyszerű termék lett volna belőle ha egy Edge kategóriás telefont vele hoznak ki és nem az UT-val próbálják. A BQ és a Meizu cuccok is jobban fogytak volna egy ilyen rendszerrel. Magam biztosan lecseréltem volna a Note3-at egy ilyenre. Az UT-val lutris módon kísérletezni viszont nem volt kedvem (valószínűleg sok más embernek sem).

Emlékszem, hogy az UfA ellen az volt a legfőbb érv, hogy az OEM-ek nem akarták átvenni. Egyszerűen le kellett volna szerződni a Google-el mint egy OEM és szállítani az UfA-t egy mezei Android variánsként saját hardveren (idővel pedig jöhetett volna a BQ meg a Meizu, ahogy később történt is).

> Persze adhattak volna sokkal jobb hatásfokkal is, de persze utólag könnyű okosnak lenni.

Hidd el, hogy mi próbáltunk út közben is okosnak lenni. De komoly szembeszélnek kellett néha menni.

> Nekem az Ubuntu for Android fáj a mai napig a legjobban.

Bezony. Nekem is.

> Az UT-val lutris módon kísérletezni viszont nem volt kedvem

A mai napig is Meizu Pro5-ot használok Ubuntu-val. Nekem bejön. Nincs rizikó... és nincs kínai/nsa spyware

> le kellett volna szerződni a Google-el

Konkértan az ilyen B2B tárgyalásokban a Canonical nem túl erős.

> Miért ne kellettek volna ezek??? Mindezek tették lehetővé, hogy az Ubuntu egy ismert, elismert disztró legyen. Ezek tették lehetővé, hogy ma messze a legnépszerűbb asztali linux disztró.

Ezzel azért egy kicsit vitatkoznék. 2012 óta erősen zuhanó ágban van az Ubuntu desktop népszerűsége.
A népszerűségét az hozta meg, hogy jól összeválogatták és összehangolták a kész elemeket, valamint folyamatosan javították a hiányosságokat.
Cirka 2008-ig emelkedett, egy ideig stagnált, majd 2012-től csökken a népszerűsége. Tehát ezek a 2012 körül indult fejlesztések biztosan nem emelték a népszerűségét és nem ettől lett a legnépszerűbb asztali disztró.

> Ezzel azért egy kicsit vitatkoznék. 2012 óta erősen zuhanó ágban van az Ubuntu desktop népszerűsége.

Tudnál erre hiteles forrást mutatni? Nem mondom, hogy nem hiszem el, de érdekelne, hogy te milyen adatokat ismersz.

Tudtommal egyik másik Linux disztrót sem tolták OEM-ként olyan nagy gyártók mint a Dell, HP, Lenovo: https://certification.ubuntu.com/desktop/

> Tudnál erre hiteles forrást mutatni?

Majd valaki biztos kerit egy jobbat, addig itt van ez a google trends:
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F03x5qm

Ebbol egy 2008-2012 csucsidoszak latszik, azota tenyleg lohad a nepszeruseg.

---
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....

Mert nem tartom igazoltnak, hogy a keresések mögött az van, hogy "ezt szeretem, venném, veszem és ezért keresek rá"

Sokkal inkább azért keresnek rá dolgokra mert nem tudják, hogy mi az. Ha tudják akkor nem keresnek rá.

Vagyis a google trends nem választja szét az érdeklődés változát az ismertségtől. Ez pedig csalóka.

" Majd valaki biztos kerit egy jobbat, "

Szivesen latnek cafolatot is.

En a szuk kornyezetemben azt latom, hogy boldog-boldogtalan atnyergelt macos-re (macbook air/pro).
De ezt nem akarnam kivetiteni:)

---
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....

En amikor vasaroltam a laptopomat, amennyiert vettem azert az apple adott volna macbook pro-t is.

De en vilageletemben linuxot hasznaltam, sose volt se windows-om, se macos-em sajat gepen.
Egyelore gyozott a megszokas...

---
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....

A google trends csalóka tud lenni. Mert nem tudod, hogy miért keresik az emberek a kulcsszavakat.

Ha megnézed az Android kulcsszót akkor azt látod, hogy 2013-2016 között egyértelműen csökken a trend. De ennek nem az az oka, hogy kevésbé népszerű az Andorid, hanem az, hogy maga a brand beépült a köztudatba.

Van valami benne amit mondasz, de nincs teljesen igazad.

Pl. keressunk ra az ubuntu kiadasok neveire.
Ezek elore nem ismert szavak, igy egy-egy release kornyekere megugrik a kereses rajuk:
https://trends.google.com/trends/explore?date=all&q=ubuntu%20precise%20…

Meg igy sincs semmi relevanciaja szerinted?

---
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....

Relevanciája nyilván van. A kérdés az az, hogy milyen szempontból.

Szerintem az Ubuntu-s keresések leginkább a médiában való jelenléttel, marketing akciókkal áll korrelációban. Ha a nem tech sajtóban akár egészen kicsi hír van az Ubunturól az megdobja a kereséseket. Ha pedig a cég csendben van akkor kevesebben keresnek rá.

Mondom, semmilyen hiteles igazolását nem látom annak, hogy a google keresések trendjét valamiféle népszerűségi mutatónak vehetnénk.

> Ha megnézed az Android kulcsszót akkor azt látod, hogy 2013-2016 között egyértelműen csökken a trend.

Az en google trends-em mast mutat, te is igy nezted?:

https://trends.google.com/trends/explore?date=all&q=android%20gingerbre…

En hatarozott novekedest latok, azaz nem, nemely kiadas nem akkora slager (pl. honeycomb).
De a trend az novekedest sugall.

Itt a folytatasa egyebkent:
https://trends.google.com/trends/explore?date=all&q=android%20kitkat,an…

Bar ugye csak azt a statisztikat erdemes elfogadni, amit az ember sajat maga hamisit:)

---
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....

A google trends csalóka tud lenni. Mert nem tudod, hogy miért keresik az emberek a kulcsszavakat.

Ha megnézed az Android kulcsszót akkor azt látod, hogy 2013-2016 között egyértelműen csökken a trend. De ennek nem az az oka, hogy kevésbé népszerű az Andorid, hanem az, hogy maga a brand beépült a köztudatba.

"Hát, ha valami a végén a kukában landol, az bizony kudarc" ez mekkora baromsag. Ott van pl az upstart. Nem tetszett nekik a systemv, ezert fejlesztettek egyet, ami megfelelt az igenyeiknek, aztan mikor elterjedt a systemd, kvazi szabvany lett, akkor kukaztak az upstarttot. Szerinted az kudarc, hogy 5-8 akarhany evig volt egy rendszeruk, ami kiszolgalta oket, es jobb volt, az elodjenel?

-
Go konkurencia kezelés gyorstalpaló

Az a vicc, hogy nem felelt meg nekik a SystemV. Èn, mint mezei Linux user, simán elvoltam SystemV alatt is, ahogy Upstart alatt is, illetve Systemd alatt is. Àltalános felhasználásnál semmi különbség. Akkor mégis mire volt jó?

Rájöttek, hogy tök fölösleges minden kvázi elterjedt megoldás helyett saját, házi megoldást gyártani, ami kvázi ugyanarra hivatott. Felesleges idö és pénzpocsékolás. Meg akarták váltani a világot, ami nem sikerült. A felesleges dolgok meg mindig a kukában landolnak.

--
robyboy

Az upstart megoldott nekik olyan problémákat, amit SysV inittel nem lehetett megoldani. Miért vicc az, hogy nem felelt meg nekik?
A systemd pedig jóval az upstart után kezdődött el.

Upstart: 2006
Systemd: 2010

Ők is azért kukázták, mert a többi nagy distro a systemd-t választotta az upstart helyett.

Meg is valaszoltad: "mint mezei Linux user ... semmi különbség"

"ami kvázi ugyanarra hivatott" pont ott van a lenyeg, ahol kvazi eltert az upstart a systemv-tol, azert fejlesztettek ujat. Mondok egy peldat, upstarttal megoldhato, hogy egyik szolgaltatas a masikra dependaljon, ez nem alhanyagolhato kulombseg

"A felesleges dolgok meg mindig a kukában landolnak" Persze, csak az ha valami a kukaba kerul mert mar felelsleges nem egyenlo azzal, hogy a feleslegesse valasa elott is kudarc volt a dolog. Mondok erre is egy peldat. Nem hasznalunk gozgepet mindenre manapsag, de mondjuk kudarcnak sem nevezzuk, vegulis csak a vilagunkat valtoztatta meg

-
Go konkurencia kezelés gyorstalpaló

Az ilyen hasonlatok mindig sántítanak. Ha abból indulunk ki, hogy hányféle linux létezik, és mindegyikben lehet valami "forradalmi", ami megváltoztatja a világot... oh wait. Gőzgépnek nem volt alternatívája, és az valóban korszakalkotó volt. Az Upstart semmiképpen sem hasonlítható az ilyen találmányokkal össze.

Pont ez a lényeg, hogy eltűnik, aztán később visszagondolva max. a nosztalgia érzését táplálja.

Ugyanúgy igaz ez a Systemd-re is. Ami a gőzgéppel egyenértékű találmány, az kb. maga számítógép.

--
robyboy

A Unity8 zsákutca, mivel sose jutott el odáig, hogy az éles ubuntu kiadásban default DE legyen, azért ez akárhogy nézzük, ahány évet beleöltetek, sz.pó.

A Unity7 nem zsákutca, anyám is használja, de azért az gondolom érthető hogy ő csak LTS disztrókat kap és default shell-t, nem fogunk kísérletezgetni.

Szerintem nem a zsákutca a jó szó. Az unity 7 azért zsákutca, mert nincs jövője, mivel egy compiz plugin, ami x-re épül, és az x-et épp leváltani akarja mindenki.

Az unity 8 lehet zsákutca, mert mir-re épül, aminek ugyanúgy nincs jövője, de volna értelme felkapni, mert maga a DE jó.

OK. Elhiszem. Ezért írtam, hogy laikusként kérdezem. Amúgy kíváncsi lennék, milyen lenne ha valaki portolná a gnome shell-t Qt-ra :) Gondolom nem lenne lehetetlen, csak GTK toolkit helyett Qt-t használni. Minden bizonnyal a Qt-ben is megvannak azok az eszközök, amik a GTK-ban.
*szerk.: a másik dolog, a GTK+ az sima C, a Qt meg C++, gondolom sokkal egyszerűbb C++-ban "leprogramozni" egy sima kis programot, mint tisztán C-ben. (nem tudok programozni)

"Semmit nem tudott fél éve, összeomlott, stb."

Az összeomlásra nem tudok mit mondani, az pedig hogy semmit nem tudott. Ez nem KDE, hogy mindenre van opció, szerintem sose volt a célja hogy egy széthekkelhető, agyonállítgatható DE legyen. A feladatát ellátja.

A nautilusra: Tény, hogy lehet mást használni, de ennyi erővel minek a DE-ben egy csomó default program, ha mást kell használni helyettük? Ráadásul a nautilus jó cucc volt amíg nem álltak neki ritkítani a funkcionalitását.

> Az unity 8 lehet zsákutca, mert mir-re épül, aminek ugyanúgy nincs jövője, de volna értelme felkapni, mert maga a DE jó.

Igen jó barátom a Unity8 fő fejlesztője. Ő at mondja, hogy a Mirben már semmi ráció nincsen. A Mir-t a telefonok miatt kezdte el fejleszteni a Canonical, mert szorította a határidő a hardvertgyártók oldaláról és nem volt használható alternatíva. De most, hogy nincs ilyen nyomás a U8-et megcsinálni Wayland kompatibilisre úgy fél éves kemény munkája lenne 2-3 jó mérnöknek. Sajnos ez 100-150 ezer eurós befektetést igényelne. Ezt nem fogja senki beletenni.

Pedig jelenleg a Unity8 a legjobb olyan DE ami értelmezhető desktop és touch környezetben is.

Ott nem DE, ott launcher.

Értem én hogy ti komolyan gondoltátok a "két méret - 1 env" elgondolást, de nem látom, ez mennyire reális a gyakorlatban, és úgy látszik, már nem is fogom látni.

Elvileg az IA elvén fel lehet építeni ugyanazt a funkcionalitást két felületre, a gyakorlatban ennyire általánosan nehéz belátni, hogy a concept mindkét oldalon működőképes lehet.

A material is brutál kényelmetlen jelenleg desktopon, maga a teljes vizuális nyelv is, és akkor még a shell appjait nem is nézzük.

A Windows meg kb egy baromi nagy if volt a gyakorlatban minden körül (vagy használhatatlan volt a program desktopon).

> Ott nem DE, ott launcher.

A launchernél lenyeges több fícsörről van itt szó

> Értem én hogy ti komolyan gondoltátok a "két méret - 1 env" elgondolást,

A méret csak egy szempont a sok közül. Még csak nem is a legérdekesebb, mert speciel ezt a Qt tudja minden erőfszítés nélkül. Lényegében minden Qt alapú keretrendszer automatikusan skálázódik egy ideje.

Nagyon sok olyan apróság van aminek jelentősége van a konvergencia szempontjából.

> úgy látszik, már nem is fogom látni.

Miért ne látnád??? Az imánt soroltam fel azokat az eszközöke amikből ipari/kereskedelmi volumenben van Unity8. Az, hogy te nem futottál még bele attól még az látezik.

( falu v | 2017. 04. 05., sze – 20:54 )

Ennek örülök is meg nem is. Örülök, hogy belátták, hogy ez zsákutca, annak viszont nem, hogy nem ilyen sokáig tartott mire rájöttek.
Én igazából sosem értettem, hogy miért készül az Ubuntuból ennyiféle változat (Kubuntu, Lubuntu, Xubuntu, stb) ahelyett, hogy a telepítő felkínált volna pl két-három választási lehetőséget az ISO-ból, a többit meg netinstallból.

[ Falu.me | Tárhely | Domain ]

"miért készül az Ubuntuból ennyiféle változat"

Ahhoz, hogy mindegyik DE telepíthető legyen net nélkül nagyra hízott volna az az ISO.

Úgy tudom az Ubuntu live telepítő úgy működik, hogy egy előre összeállított rendszert (azt, ami a live cd-t is hajtja) másol át telepítés gyanánt, nem pedig egyesével telepíti a csomagokat. Ezáltal sokkal gyorsabb. Ez nem igazán lehetne megvalósítható, ha volnának választható komponensek.

Ráadásul nem hiszem, hogy kevesebb munka lenne úgy, ha a telepítőben lenne a választás lehetősége.

( krychek | 2017. 04. 05., sze – 22:27 )

Unity, Phone, Convergence... kár értük.
Pont amikor kijön a Samsung Dex.

( neuron | 2017. 04. 06., cs – 02:21 )

Örülök, hogy dobják a Mir-t.

By switching to GNOME, Canonical is also giving up on Mir and moving to the Wayland display server, another contender for replacing the X window system. Given the separate development paths of Mir and Wayland, "we have no real choice but to use Wayland when Ubuntu switches to GNOME by default," Hall told Ars. "Using Mir simply isn't an option we have."

https://arstechnica.com/information-technology/2017/04/ubuntu-unity-is-…

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."

Igy van, ez a hir legfontosabb resze szerintem. Nem csak hogy lesz egy "standard" Linux desktop vegre (Gnome), de a Wayland is kap egy eselyt.

Tehat barmilyen furan hangzik, az a hir, hogy az egyik fo Linux desktop szereplo abbahagyja a desktop fejlesztest a legjobb hir a Linux desktop szempontjabol :)

Csak azokat a borzalmasan gnom (bocsi:)) vastag Gnome ablakszeleket/ures feluleteket kellene lereszelni, es maris teljes lenne a boldogsag...

A linux desktop sikerét és előretörését nem az akadályozta, hogy több DE létezett.

A főbb okok között az van, hogy
1) sosem volt semmilyen stabil platform vagy alkalmazás API amire nyugodtan lehetett volna alkalmazásokat fejleszteni.
2) minden disztró ívesen tett az ABI kompatbilitásra. Ha megvakarta egy RedHat/Suse/Ubuntu/Debian guru a fejét hétfő reggel és lecserélte a komplett fordítót akkor senki nem szólt semmit

A masodik ponttal egyetertek, de nekem a Qt es a Gnome is annak az API-nak vagy platformnak tunik, amire lehet UI-t fejleszteni. De nem tudom, a valosagban is igy van-e, sosem irtam UI programot. Mi ezekkel a problema?

Valamint az X kulcsproblemaja a Linux desktopnak, ezert az X levaltasara indult kezdemenyezes a legfontosabb az elmult 20 ev tortenelmebol, es az, hogy az egyik fo szereplo nem allt be a kozossegi projekt moge, hanem a sajat elmebajat tolta (akarmilyen megfontolasbol), es most ennek vege, es csatlakozik vegre a fosodorhoz - nos, ez kabe ahhoz hasonlithato szerintem, mint amikor a Microsoft belatta, hogy a webet nem tudja tovabb akadalyozni az IE inkompatibilitasaival es megfojtott fejlesztesevel, es inkabb beadta a derekat es csatlakozott a modern bongeszokhoz.

Persze itt kisebb a dolog tetje, hiszen a Linux desktop ugymond nem letezik, de a hasonlatert vallalom a felelosseget :)

> A masodik ponttal egyetertek, de nekem a Qt es a Gnome is annak az API-nak vagy platformnak tunik, amire lehet UI-t fejleszteni.

Szerintem, amikor az Ubuntu phone-ba belevagtak akkor megversenyeztettek a GTK, es Qt-t, es a Qt-ra esett a valasztas. Ugye ha valaki emlekszik meg az Openmoko telefonra, azok is GTK-val kezdtek. Vagy a Nokia900-ra (maemo). Aztan az openmoko enlightenment-re valtott (aztan be is fulladt, bar nem emiatt), a Nokia900 utan meg Qt-ra valtottak.

Igy vegul azert latszik, hogy barki hozzanyult a GTK-hoz atvaltott rola. Tehat a Qt a technikailag jobb valasztas.

Ezekutan visszavaltani Gnome-ra, egy technologiai visszalepes.

---
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....

> megversenyeztettek a GTK, es Qt-t,

A Gtk sosem volt versenyben. Ott voltam annál az asztalnál, ahol megszületett a döntés, hogy Qt legyen a Unity8 DE és app framework alapja. Ez jó döntés volt.

A félreértés elkerülése végett... most nem az lesz, hogy jön a Gtk. Most az lesz, hogy nem jön semmi. Az Ubuntu lényegében feladja a desktop ambícióit.

> A Gtk sosem volt versenyben. Ott voltam annál az asztalnál, ahol megszületett a döntés,

Most döntés volt, vagy sem?
Ha döntés volt ezek közül lehetett választani:
1. gtk
2. qt
3. enlightenment

Namost ha a GTK fel sem merült, mert egyikőtök se hallott róla, akkor legalább a következő ubuntu lts-ben kipróbálhatjátok:-P

> Az Ubuntu lényegében feladja a desktop ambícióit.

Az Ubuntu a desktopnak köszönheti, hogy szerver oldalon sikeres.
De ugye ez is csak egy állapot. És már szépen leáldozóban van:-\

---
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....

Kezdésként annyit, hogy ha cinikus provokálás a célod akkor inkább hagyjuk. Okés?

Roppantul kellemetlen érzés, hogy én igyekszem szakmai alapon, egy olyan cég belső működéséről és döntési mechanizmusáról információt adni az érdeklődő közönségnek miközben de pusztán cinikusan beszólogatni akarsz.

Szívesen válaszolok minden kérdésedre, de előbb elvárom, hogy megadod nekem a minimális tisztelet, hamár a szabadidőmben itt közszolgálatiskodom.

Cinizmus ide, vagy oda; pusztan egy logikai hibara vilagitottam ra.

Nekem volt rengeteg kerdesem, de azokra sose valaszoltal, mert nem "publikusak".
Most is lenne rengeteg kerdesem, de nem hiszem, hogy toled kapnek ra valaszt.

---
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....

Minden olyan kérdésedre válaszoltam amelyekre a szerződésem lehetőséget ad. Értelm szerűen egy HUP nick kedvéért nem fogok szerződést szegni.

Logika hiba nincsen, egyszerűen nem tudod miről beszélsz. Annyit segítek, hogy 2012-ben a döntés nem a Qt és Gtk közötti választás volt, hanem a QML és Nux között. De látod, fingod nincsen a témához, viszont marha nagy mellénnyel genyózni akarsz.

Sajnos a hozzászólásaidből leginkább a cinikus rosszindulat jön le. Ezt pedig én szakmai témákban nem tudom és nem is akarom értelmezni.

Érdekes, én szakmai témában, szakmai fórumon valahogy sosem állnék le úgy netó gecizni ahogy azt te teszed. Valahogy úgy vagyok vele, hogy kicsi ez a szakma, a fene tudja mikor és kivel kerülök egy asztalhoz.

Ezért nem tudom, hova tenni, hogy te, lényegében ismeretlenül miért csinálod ezt? Nem gondolod, hogy ez valamikor vissza fog ütni? Nem gondolod, hogy mások is olvassák ezeket a trollkodásokat? Eszedbe sem jut, hogy a korrekt, kimért és alpavetően barátságos hangnem az ebben a szakmában többre visz mint a cinikus piszkálódás? Vagy esetleg te még olyan fiatal vagy, hogy el sem tudod képzelni, hogy valaha mást és máshol is fogsz csinálni mint amit és ahol ma?

Furcsa... tényleg nem értem. Illetve, dehogynem értem... felelőtlenség és habókosság.

A félreértés elkerülése végett... most nem az lesz, hogy jön a Gtk. Most az lesz, hogy nem jön semmi. Az Ubuntu lényegében feladja a desktop ambícióit.

Sose az volt a piaci igény szerintem az Ubuntu fele hogy saját desktopot fejlesszen, vagy hogy saját mobil-oprendszert fejlesszen, hanem hogy legyen egy decens open source rendszer, amitől a profik se menekülnek ki a világból, meg édesanyáinknak és enterprise telepítésekben a Mancikáknak oda lehet adni, nem tudják nagyon szétrúgni, de a levelezés, Word és PDF doksik nyitogatása, meg a webes / java-s / GTK-s vállalati appok elfutnak rajt.

Ha ezt saját desktoppal tudja megoldani mint rendszerintegrátor akkor oldja meg azzal.

Időközben lassan a Google Drive webfelülete többet tud mint a Unity7 fájlkezelője, anyáink pedig átálltak tabletre (nagyiokosteló), de így vártuk hogy akkor mi lesz a következő non-Windows enterprise desktop.

Ehelyett Shuttleworth minden pénzét beleölte ebbe a mobilplatformba, ami szép, de nekünk ebből elsősorban csak a desktop része kellett volna csak, a mobil-desktop konvergenciát számunkra megadják a PWA-k, a reszponzív webappok.

A kérdés az, ebből az ubuntu fel tud-e állni és szállítani egy decens enterprise DE-t amit a profik is tudnak használni fejlesztéshez meg rendszerüzemeltetéshez, vagy meg kell várni amíg a Windows-ökoszisztéma a saját súlya alatt rohad meg, esetleg a Google előrukkol valami értelmes desktop offeringgel.

A Unity8-ból engem a mobil csak marginálisan érdekelt, az érdekelt, mi lesz a következő A Linux Desktop.

> Sose az volt a piaci igény szerintem az Ubuntu fele hogy saját desktopot fejlesszen

Ezt az igény dokumentáltal létezett. Erre az igényre, illetve ezen igéby kielégítésére épült PC gyártókkal való üzleti kapcsolat a Canonicalnak.

Az a baj, hogy néhányatok a saját izléseteket vetítitek ki a teljes iparágra. Mik9zben az évente többmillió eladot Ubuntus desktop gépek és minden népszerűségi mutató tökéletesen az ellentét mutatja annak amit mondasz. Az Ubuntu desktop az egyik legnépszerűbb rendszer. Egyetlen mésik disztrót sem használnak olyan sokan a laikusok táborában mint az Ubuntut. Ez tény. Nekem sem a kedvencem a Unity. Mielőtt a Canonicalhoz szerződtem volna én sem nyúltm volna még bottal sem a Unity-hez. De nem én vagyok a tipikus felhasználó.

> Időközben lassan a Google Drive webfelülete többet tud mint a Unity7 fájlkezelője

Hááát én a napu melóra használom a Google Drive-ot, de szerintem űbergagyi és igénytelen hulladék.

Amúgy te is beleesel abba a hibába, hogy a Unity-nek tulajdonítasz egy nem oda tartozó problémát. Az Ubuntu-ban a Nautilus alkalmazás a fájlmenedzser. Ez egy alkalmazás. Ha nem tetszik, használj másikat.

> A Unity8-ból engem a mobil csak marginálisan érdekelt, az érdekelt, mi lesz a következő A Linux Desktop.

Szíved joga, hogy az érdekeljen téged amit akarsz. De itt nem a mobilról van szó. A laptop is mobil... Nekem már vagy 10 éve nincsen nem mobil Desktopon. Ettől csak egy lépésre van az, hogy lecsatolható keyboarddal és érintőképernyővel jöjjön _MINDEN_ laptop. Nyugodj meg, tíz év múlva ez lesz az alap. Na és akkor mi lesz a következő Linux Desktop? Megnyugtatlak akkor minden disztró elő fogja húzni pöccre ugyanazokat a terveket amik alapján a Unity8-at elkezdte az Ubuntu.

Egyszerűen minden disztrónál korábban tudott a Ubuntu korábban becserkészni érintőképernyős hardvert gyártó céget. Ezért kellett ebbe az irányba fejleszteni a rendszert. Más is ezt csinálta volna, ha ilyen igényekkel találkozik. Könnyű a GNOME-mal meg KDE-velvagánykodnia a többi disztrónak ha egyszer a kutya nem akar milliós példányban velük hardvert szállítani.

> Az a baj, hogy néhányatok a saját izléseteket vetítitek ki a teljes iparágra. Mik9zben az évente többmillió eladot Ubuntus desktop gépek és minden népszerűségi mutató tökéletesen az ellentét mutatja annak amit mondasz.

Az OEM eladások nem tudom mennyire mutatnak reális képet.

Nézd, én általában vállalati informatikában dolgozom 17 éves korom óta. Most épp az egyik állami mamut pénztári rendszereit rajzolom, ami .NET-ben van Windows alapon, de elvileg lehetne linux is alatta.

Előtte orvosi rendszert fejlesztettünk, ott már neccesebb, mert ha még mi el is futnánk linux alatt, az EKG-nak meg a laborrendszernek nem lesz linux kliense.

De ezek azok amikhez sok PC kell, meg amihez PC kell. Ezen kívül az aktatologatáshoz kell PC, meg a fejlesztéshez.

Viszont itt qrvára nem érdekes az érintőképernyő meg a mobil, ezek egeres, sőt, billentyűs rendszerek. Ha a feladat gyakran ismétlődő, ügyfélszolgálati jellegű, de relatív komplex és sok szövegbevitellel jár, akkor billentyű, ha meg nem tudni pontosan mikor mihez kell nyúlni akkor egér.

Használod a mobilodat fejlesztésre (mmint tudom, rádugható egérre-monitorra, de anélkül)? Használod olyankor ha két-három dolog összefüggése kell? (Mittom, ticket, kód, doksi, kóderedmény)?

A konvergencia konzumerben megvalósult, most mobilról gépelek a HUP-ba, meg van a mobilomon facebook is, az ne gond, ott a cloud meg a reszponzív web oszt szevasz.

A desktop nekem ott érdekes ahol a form factor a feladat jellege miatt nem a mobil.

Ctrl-F-eztem a konvergencia szóra, őszintén nem tudom, mit jelent számodra.

Valami olyasmit írtál hogy a laptop is mobil, meg érintőkijelzős laptop amivel a Canonical megegyezett, én meg olyasmiről írok hogy vannak taszkok amikhez kell az egér meg a billentyűzet, esetleg a komplex UI ami nem fér ki mobilra.

Nálad egy filozófiai álláspontot látok, én meg a gyakorlatban próbálom megfogni hogy mi az aminek ma nem elsődleges platformja a mobil és miért nem az.

A gyakorlatban egy orvosi szoftvert szerintem nem lehet mobilszintig lekicsinyíteni pl, egyszerűen azok az infók amiknek folyamatosan jelen kell lenniük (beteg állandó betegségei és allergiái) önmagukban egy képernyő.

Tabletre levittük. Finoman szólva nem elég a nagyobb gombméret, olyan trükkök kellenek hogy a fejedet fogod.

A pénztári rendszerünkből is van érintőképernyős változat, de billentyűvel egyelőre úgy látjuk, hogy gyorsabb.

Egy IDE-t fogalmam nincs, hogy vinnék le mobilra, de tabletre se nagyon. Nem látok jó tabletes szövegszerkesztőt, amivel meg lehet írni valami hosszabbat. Nem látok jó vektoros rajzprogramot amivel lehet UI-t tervezni pl. Nem látok precíz videószerkesztőt.

Ha nekem kéne konvergálnom, nem az lenne a kérdésem, hogy hogy építek félátlátszó API-t a mobilok meg a laptopok eltérő hardveres működésére, hanem hogy hogy tudom az adott form factorba beleszuszakolni úgy a funkcionalitást hogy a taszkot kényelmesen meg lehessen oldani.

A kérdés nekem a konvergenciában az, hogy oldod meg, hogy a delikvens ne érezze sz.pónak a mobilon a dolgot, mint ahogy a facebook-ot vagy a spotify-t nem érezzük sz.pónak nagyrészt, és ez azért nem kis feat.

A material egész jó próbálkozás, de desktopon még gyenge.

A konvergencia nálam nem egy filozófiai álláspont. Én API szempontból nézem a kérdést. Például nézd a UI komponenseket. Mert ezekből épülnek fel az alkalmazások.

Egy alkalmazás nem tud konvergens alkalmazás lenni, ha a UI komponensek nem alkalmasak erre. Például egy text inputnak adaptálódnia kell billentyűzetes és egeres környezetre, de működnie kell touch környezetben is. Vagy egy listának kell scrollbar ha van egér és le-fel gombok, de ha touch-on fut akkor lehet ujjal böködni. Ha van egy ilyen UI Toolkit akkor onnantól az alkalmazásfejlesztő dolga eldönteni, hogy akar-e konvergens alkalmazást csinálni. Vannak olyan alkalmazások amikben van ráció, de ahogy te is írtad egy IDE vagy egy komplex ügyviteli rendszer nem biztos, hogy jó ötlet. De mondjuk egy képböngésző app vagy egy jegyzetelő alkalmazás, esetleg egy borkóstoló jegyzeteket tároló és megsztó alkalmazás is lehet ilyen. A lényeg az , hogy a platformnak csak a konvergenciát lehetővé tevő API-kat kell felkínálnia.

Én azt látom a piacon, hogy az általad írt appokat mobile-first írják.

Továbbá van egy natívan konvergens web API, hívjuk mondjuk bootstrapnek.

A Microsoft írt egy konvergens API-t, ez az UWP, nekem az ott dőlt be, hogy sose tudott többet mint a web, le volt korlátozva, cserébe desktopon borzalmas volt (és mobilon se szép).

Papiron konvergens a material is, valamelyest a sok telóméret miatt muszáj neki, de fionoman szólva nem tökéletes.

Mi az az API, amit ezeknél jobban tudott a Unity8?

Most abba bele se menjünk hogy egy csomó cucc cloud backenddel van, ami ha elég jól van megírva akkor a user minden form factoron eléri az adatait és el tudja végezni a műveleteket rajt.

Most csak arra lennék kiváncsi, mi az az API, ami olyan konvergenciát hozott volna amit a jelenleg erre használható technológiák nem.

Azt se értem, mit akartak ott pontosan a gyártók - saját telefon os-t a laptop mellé? Esetleg ilyen "dokkoló" laptophéjakat amibe beledugod a telefont és a futó alkalmazások ablakként jelennek meg?

> Mi az az API, amit ezeknél jobban tudott a Unity8?

Parancsolj:
https://developer.ubuntu.com/api/apps/qml/sdk-15.04.6/
https://launchpad.net/ubuntu-ui-toolkit

Ezt csinálta az én csapatom. Én és 3-4 másik srác. A csapat fele magyar volt :)

> mit akartak ott pontosan a gyártók

A gyártók sokmindent akartak. Igen, konvergens OS-t és dokkolhatóságot is.

Aha, szóval ti a Meego-ban is használt QML-t (használtuk mi is a térképrészlegen) fejlesztettétek tovább, és tettétek "reszponzívvá", ha jól értem.

Ez tök jó, csak akkor ha jól értem nem érkezett meg a piaci igény hogy ehhez társuljon egy n+1. OS ami ezt tudja, mondván hogy van web meg material, elég lesz az?

Mi amúgy bootstrap-et használunk ezekre, ha kell wrapperrel, azaz simán lehet hogy te desktop/mobil alkalmazásnak látod (akár mert durván hozzá kell nyúlnunk hardverhez is), miközben a háttérben ez egy NW.js vagy egy Apache Cordova.

> Aha, szóval ti a Meego-ban is használt QML-t (használtuk mi is a térképrészlegen) fejlesztettétek tovább, és tettétek "reszponzívvá", ha jól értem.

A Meego alatt hozta ki a Qt először a QML technológiát. De igazán csak 2012-2013-ra forrta az ki magát. A Meego idejében még súlyos preformance problémák voltak vele.

Mi nem továbbfejlesztettük ezt, bár nagyon sok fixet és bővítést toltunk ezzel kapcsolatban az upstreambe. Mi egy olyan QML alapú UI Toolkitet csináltunk ami teljesen adaptálódik mindenféle kijelzőhöz és input típushoz. Ilyent még a mai napig sem csinált senki. A Qt a legtöbb jó megoldást át is vette tőlünk. Szóval messze nem kuka az amit csináltunk.

> ha jól értem nem érkezett meg a piaci igény hogy ehhez társuljon egy n+1. OS

Nem igazán erről van szó. Inkább arról, hogy úgy általában a PC piac stagnál és a mobil piacról is vonul ki az innovációra mozduló tőke. Egyszerűen konyhai botmixer szinten vannak az okostelefonok és nem éri meg senkinek komoly új technológiába fektetni. Akkor sem ha az a technológia űberkirályság. Rossz analógiával élve, megcsináltuk a 95 pontos, fantsztikusan jó ízű és zamatos vörösbort akkora amikorra antialkoholista lett az egés világ :)

A webes technológia amúgy él és virul. De natív teljesítményt ezek soha nem fognak meg sem közelíteni.

De mi az überkirályság a rendszeren?

Qt, c++... félre ne érts, használtam, de a programozói gyorstalpalókba a memóriamenedzsment manapság nem fér bele.

Az hogy a régi QML bűnlassú volt, azt bármikor aláírom.

A PC piac persze hogy stagnál, az munkagép lett speciális feladatokra. A droid meg occsó, 100 dollárért tökéletesen funkcionális gépet kapsz, amivel email meg web megy, meg nézegetheted a fényképeket (csinálni annyira nem javasolnám vele), dolgozni nem jó, de azt ritkábban csinálod.

Megnéztem most az ubi "store"-t, de natív appot alig találtam benne.

TFH lement volna a deploy, és a 18.04 LTS szállítja a unity8-at, a telók meg elérnek egy windows phone szintű elterjedtséget, én meg ott állok hogy döntenem kell, egy vállalati deployban webre fejlesszünk és lesz@rom milyen OS van, vagy legyen egy material java kliens meg egy másik, esetleg Windows Phone-okat dokkolunk az UWP-vel, vagy pakoljunk minden workstationre ubit meg osszunk ki ubi telókat, miért választottam volna az uccsó opciót?

> Az hogy a régi QML bűnlassú volt, azt bármikor aláírom.

Értelem szerűen nem összehasonljtható a 2011-es QML egy mostanival. Ég és föld.

> De mi az überkirályság a rendszeren?

Milyen rendszeren?

> telók meg elérnek egy windows phone szintű elterjedtséget,

Ehhez nagyon vissza kellett volna esnie a windows phone-nak :) még a mostanihoz képest is.

Nézd, az Ubuntu phone sajnos ezer sebből vérzett. Hosszú történet. Megvolt benne a potenciál, hogy egy teljesen valid és legit platform legyen egy speciális igényhalmaz kielégítésére. Szerintem benne volt 15.04-ig az, hogy egy globálisan 30-50 milliós példányszámban jelen legyen a piacon. De 3-5 éveb belül semmi realitása nem lett volna méga legjobb esetben sem kihívni még a windows phone-t sem.

De ... és komolyan _DE_ ettől még egy fenntartható és izgalmas szereplő lehetett volna. A lehetőség adott volt. Ezt a lehetőséget csak és kizárólag Mark Shuttleworth engedte el. Sorban álltak a gyártók, hogy kérik az Ubuntu Phone-t és a Canonical mondott erre nemet...

> miért választottam volna az uccsó opciót?

Gőzöm sincs. Nem vagyok sem sales, sem marketing szakember és nem ismerem sem a cégedet sem a pontos körülményeket.

Egyébként pont válllati környezetben ahol huszadrangú a százezer fingóalkalmazás létezése elég jó lett volna az Ubuntu Phone már mostanra is... ha... ha ... nem barmolják egy a nagyfőnökök.

Leírtam: vállalati rendszereket tervezünk. Terveztünk tavaly ügyvédi és orvosi rendszereket, és nem titok hogy a MÁV automaták következő generációját is a mi terveink alapján fejlesztik. Tavaly JavaScript (angular-ui-bootstrap), XAML, WinMo 6.5, Android és Delphi is volt a terítéken.

A máv automatának pl. majdnem tökmindegy milyen OS van rajt, a pénztárakban pedig custom hardvert cserélnek épp PC-re.

Szóval nekünk bőven vannak olyan dolgaink ahol "így is, úgy is" kell hardvert venni, de általában vagy webtechnológia van, vagy droid és tucatszámra veszünk, vagy windows, részben aszerint is hogy mihez értenek a UI fejlesztők - a C++ ritka állat arrafelé.

Nyilván ha azt mondanám hogy legyen natív linux, azért egy csomó menedzsmentrétegtől kapnánk hideget-meleget, egy ChromeOS telepítést még kb. meg tudnék védeni, még talán egy Gnome3-at is, feltéve ha a kliens webes, a hiszti arról szólna hogy future proof, meg fejlesztői HR piac.

Szóval nem is azzal lenne a baj hogy legyen egy linux körbetelepítve a desktopokon, az még megy, ha kell Office+Email vagy egér+bill, de az hogy erre natív appot fejlesszünk az már necc lenne. Nem a 20.000 ft-os windows licensz szokott hiányozni a büdzséből.

Ezért kérdem, mi az érv a QML/C++ alapú UbiUI mellett amire te azt mondod, hogy Ubercool?

Az Ubuntu Phone konzumer termék, nem enterprise platform, nem is értem ezt a megközelítést. Ha felkapják a geekek, akkor űbercool lett volna és megéri rá fejleszteni, mert ott a fejlesztői HR piac egy szignifikáns része.

Szerintem ti sem azért fejlesztetek Androidra enterprise alkalmazást mert az űbercool, hanem mert más nem nagyon van.

A geekek most már sokan vannak. Egyszerűen jövedelmező az IT, meg különbenis, az informatika nem a Commodore 64 amit nem csak játékra lehetett használni (hey-hey, 16k...), hanem a napi valóság: a hírek, a TV, a kommunikáció és az adminisztració alapja.

Mi azért fejlesztünk Androidra üzleti alkalmazást mert a Material design nyelv elég jól ki van találva erre, cserébe amióta a nagyiknak is van okostelójuk hogy Skype-olhassanak a onokákkal, azóta nekik se kell elmagyarázni hogy a levelet a jobb felső sarokban lévő gombbal kell elküldeni.

Konkrétan 40+-os átlagéletkorú de nem geek felhasználóbázisnál mobilos patterneket csempészünk desktop meg webappokba is, mert az a tapasztalat, hogy jobban értik mint a "natív" megfelelőit.

Nekünk az elsődleges kérdés mindig az, mi a lowest barrier, akkor is ha enterprise. Amúgymeg, annak senki nem látta realitását hogy ez lett volna a legelterjedtebb konzumer platform, a Canonical ehhez túl pici cég a Google-höz és az Apple-höz képest, az enterprise szerintem sokkal valószínűbb irány.

> JavaScript (angular-ui-bootstrap), XAML, WinMo 6.5, Android és Delphi

Hát nem esz a sárga irigység :) hogy diplomatikusan fogalmazzak :)

> C++ ritka állat arrafelé.

Hát ugyebár a QML az nem C++

Én amúgy az ilyen beágyazott rendszrbe kérdés nélkül egy Boot to Qt megoldást választanék és a faék egyszerűségű QMl technológiával gyorsan és olcsón csináltatnám me a UI-t.

Ennek megvan nyilván a technológiai alapja is, de azért nyilván az is szempont, hogy leokádnám a kezemet ha JS, Pascal meg WinMO cuccokhoz kellene nyúlnom.

> Nyilván ha azt mondanám hogy legyen natív linux, azért egy csomó menedzsmentrétegtől kapnánk hideget-meleget,

Mert nem értenek hozzá. Az inkompetencia még mindig a legjelentősebb szempont egy-egy technológiai döntésnél.

> future proof, meg fejlesztői HR piac.

Igen, és ez miért is probléma?

> mi az érv a QML/C++ alapú UbiUI

Kevésbé az UbiUI itt a lényeg. Az Ubuntu mint platform, szóval konkrétan az Ubuntu Core azért jó, mert piszok olcsó, halálosan megbízható és konkrét referenciával rendelkező globálisan ismert céggel lehet support szerződést kötni arra, hogy a platform az működik mint pinty. Ez nem kérdés. Egyébként nagyjából ugyanezt tudja a Suse is, szóval nem vagyok elfogult a Canonical iránt.
Ma 2017-ben aki egy Linux disztró futureproof-sága miatt aggódik az egyszerűen ostoba. Ostoba embernek pedig nyilván nem lehet érvelni.

A másik és érdekesebb terep az a Qt/QML.

A legfontosabb szempont, hogy a QML az _NEM_ C++, egy QML kódot nem kell fordítani. Lehet, persze... ha C++ wrapperbe vagy C++ extension-ökkel használod akkor kell, de ez nem feltétlenül szükséges. De amúgy nem akkora vaker a Qt/C++ fordítás. Van SDK hozzá, vannak toolchain-ek. Nem nagy ügy.

A QML önmagában azért frankóság, mert borzalmasan gyorsan lehet vele nagyon szép, gyors és rugalmas UI-t csinálni. Ha valaki nagyon pervezr akkor a QML-hez lehet HTML5 cucokat tolni és simán lehet benne JS kódot használni. Beteg egy ötlet, de ha valaki irgalmatlan nagy JS mágus és nem valami űberreszponzív high performance dolgot (szóval nem automotive) akkor tolhatja akár azt is.
A deklaratív UI irgalmatlanul nagy királyság. Gyorsan és olcsón lehet benne fejleszteni. Egy közepesen balfék kezdő kóder 1-2 nap után teljesen produktív QML-ben.

A másik frankóság a QML-ben, hogy azzal ugye jön maga a Qt amihez lényegében minden fontos API adott... ott kérlek alásan van 3D grapfikától kezdve, a Location API-n át, a full multimédiás, webes, xml parseres cuccokig minden. Accounts, Contacts, network API-k minden... ja és mindez a QML layerig elérhető. De sima Qt-ban is morbid módon egyszerű.

Szóval nem kell mindenféle szirszar JS hulladékokban guberálni, nem kell kompromisszumokat kötni a Cordova szarrakással, hanem ott van egy majd húsz éve létező, szolid Qt API halmaz. Ja és emögött is van cég, a Qt Company akivel le lehet szerződni és akor olyan szolgáltatást kapsz, hogy megnyalod a tíz ujjadat.

Nem ok nélkül és nem brahiból döntötött az Ubuntu is 2012-ben a Qt/QML mellett, a Nokia Meego is dobta a Gtk/Cluttert a Qt-ért és tolta a Sailfish is a Qt/QML-t. De ugyebár a KDE is ezzel megy. Mostanában ráadásul nagyon megy a Qt az embedded cuccokon. Automotive rendszerek jellemzően Qt-ra épülnek.

> Hát nem esz a sárga irigység :) hogy diplomatikusan fogalmazzak :)

Én azért büszke vagyok, hogy a csapat egzotikus technológiákra is tud tervezni, nem az van hogy ismerjük a WIn32API-t vagy valamelyik webes UI készletet és csók

A WinMo-n mi is leokádtuk magunkat meg a fejlesztők is, de ha egy WinMo-only készülékre kell tervezned akkor evvan.

A problémám az, hogy mi a tervezőcég vagyunk: nekünk adsz egy technológiai stack-et, az lehet az általatok tervezett UbiAPI, az lehet a XAML, az lehet a LogMeIn-féle SanyiUI (a saját kis belső framework-jük, arra is terveztem), de nem sok éles kódot fogsz tőlünk látni, pszeudokódban írt speciket fogsz kapni, amik kihasználják az adott platform képességeit / kikerülgetik a hátrányait (embeddednél szokott lenni).

Egy menedzsernek viszont elsősorban arra kell gondolnia, hogy a kódnak olyannak kell lennie, hogy ha a release party-ról hazafele menet elüti egy kisbusz az összes fejlesztőt aki összerakta, akkor a piacról tudjon hozzáértő embereket szerezni, akik a kisebb-nagyobb változtatásokat beleerőszakolják.

A JavaScript egy elég elterjedt rendszer ehhez, tetszőleges script kiddie bele tud nyúlni, nyilván olyan minőségben is. Nyilván nem elég gyors, ezért van az hogy a mobilos dolgokat rendszerint Androidra írjuk.

Nincs bajom magával a Qt-val, sőt, fejlesztettem GTK-ban és Qt-ban is, a Qt-nak nagyságrendekkel érettebb, szebb API-ja van. A bajom ott van, hogy ha körbe kéne kérdeznem, hogy "helló, van egy QML-alapú alkalmazásunk, elütötték a programozókat és kéne valaki aki hozzáír egy modult meg átír másik kettőt", előbb kapnék árajánlatot az egész átírására JS-ben, XAML-ben vagy Android alapokon, minthogy találjak ezekhez értő fejlesztőt.

Ami persze részint önmagát generáló folyamat, a Boot to Qt viszont jó ötlet, ha legközelebb nagyon embedded eszközre kell dolgoznunk akkor gondolok rá (mert a sebesség vs készülék ára vs kültéri strapabírás ettől még érv)

> Én azért büszke vagyok,

A büszkeség teljesen indokolt és megalapozott

> A WinMo-n mi is leokádtuk magunkat meg a fejlesztők is, de ha egy WinMo-only készülékre kell tervezned akkor evvan.

Nyilván a hw választással kezdődik a történet. Mindenesetre manapság azért már furcsa eg Win only hw.

> A problémám az, hogy mi a tervezőcég vagyunk:

Hát ha ez bisznisz és el tud tartani mérnököket akkor az szép és örömteli dolog. Mondjuk összeségében nézve nem a mérnöki teljesítmén csúcsra járatása ez megosztott modell. És akkor még finoman fogalmazok. Nyilvánvalóan az a szerencsésebb ha jobban egy ernyő alatt van a hw kiválasztás a tervezés és a megvalósítás.

Amikor a hw kiválasztó egy kibic és bármilyen fost odatolhat a tervezőknek meg az amikor a tervező úgy ír pszeudo kódot, hogy finga sincsen hogyan fog az a valóságban fordulni, futni, teljesíteni, kinézni is elég veszélyes csapdákat hoz magával.

De mondom, ha ebből emberek élnek meg akkor az valid és legit :)

> Egy menedzsernek viszont elsősorban arra kell gondolnia, hogy a kódnak olyannak kell lennie, hogy ha a release party-ról hazafele menet elüti egy kisbusz az összes fejlesztőt aki összerakta, akkor a piacról tudjon hozzáértő embereket szerezni, akik a kisebb-nagyobb változtatásokat beleerőszakolják.

Ezt a kritériumot a Qt/QML kényelmesen teljesíti.

A JS egy fostalicska, ez objektív tény. Józan és embertársait értékelő, tisztességes ember önszántából nem használ JS-t.

> van egy QML-alapú alkalmazásunk, elütötték a programozókat és kéne valaki aki hozzáír egy modult meg átír másik kettőt

Akkor röhögve fogsz találni ilyen szakembert. Az lehet, hogy nem kizárólag Jászalsóbuttatöttösön fognak lakni, de fogsz találni.

> a Boot to Qt viszont jó ötlet, ha legközelebb nagyon embedded eszközre kell dolgoznunk akkor gondolok rá

Megfontolni mindenképpen érdemes. A legrosszabb esetben egy megvalósíthatósági tanulmány és egy prototípusig érdemes elvinni, hogy ehhez is értsél.

> Nyilván a hw választással kezdődik a történet. Mindenesetre manapság azért már furcsa eg Win only hw.

Látszik, hogy nem Magyarországon élsz :) Egy állami cégnél lehetnek járulékos előnyei egy WinMo készülék választásának, és a hardverkiválasztásnál nem feltétlenül műszaki szempontok dominálnak.

> amikor a tervező úgy ír pszeudo kódot, hogy finga sincsen hogyan fog az a valóságban fordulni, futni, teljesíteni, kinézni is elég veszélyes csapdákat hoz magával.

Általában mi inkább azt a problémát látjuk, hogy az "ismeret" és a "fókusz" nem válik külön egymástól. Természetesen van fogalmam arról, hogy egy Qt kód hogy fog futni, de a pszeudokód szintjén (ahol OnClick eseményvezérlőkről, tárolt változókról és képernyőváltásokról van szó) a megvalósítási technológia majdnem mindegy. Embeddeden persze van sok sírás, de végigbeszéljük olyankor úgyis és tulképp al-nyelvet hozunk létre, ez történt a WinMo-nál is.

Ritka modell az, hogy külön van a tervezőcég, de az én habitusomhoz ez passzol a legjobban és eszem ágában sincs feladni :) Előtte szállingóztam a fejlesztőcégek közt, de sehol nem éreztem magam jól, így viszont az idők végezetéig is tudnám csinálni.

> Akkor röhögve fogsz találni ilyen szakembert. Az lehet, hogy nem kizárólag Jászalsóbuttatöttösön fognak lakni, de fogsz találni.

Mit kell beírni ehhez a Google-be?

Amúgy ez alapján ott még látnék ennek a frameworknek esélyt hogy mondjuk buszok menetrendkijelzőjén fusson, meg plázákban infópultok meg reklámok, és ott még a touchnak is lesz értelme, csak ugye az is kérdés, miért ne dobjunk rá egy HTML view-t, de arra lehet érv hogy a raspberry nem bírja meghajtani tempóban a HD kijelzőn...

"Nekem itthon RPi fajt meg tizengigás HD filmeket a nagytévén. "

Nekem is. Ugyanez a pi nem volt képes akadásmentesen lejátszani egy anim gifet :) Videólejátszás hardverből megy neki, ami nem, az botrányosan lassú (pl egy sima sd wmv). Első gen pi-ről beszélek, és arra akarok rávilágítani, hogy a videolejátszásból nem érdemes kiindulni.

> Biztos vagyok benne, hogy egy elég impresszív számot lehetne mondani az évente eladott freedos-os gépekhez is :)

Kétség kívül ez egy nem elhanyagolondó érv :)

Ezért az archive adminok update statisztikái a leghitelesebb források. Értelem szerűen ezt nem szokás még FOSS körökben sem publikálni.

> Ezért az archive adminok update statisztikái a leghitelesebb források.

Nem hiszem, hogy egy ubuntu mirror uzemeltetoje csomagra lebontva vezetne statisztikat.
Ha ez nincs akkor az ubuntu server-t es az ubuntu desktop-ot nem lehet megkulonboztetni.

---
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....

> nekem a Qt es a Gnome is annak az API-nak vagy platformnak tunik, amire lehet UI-t fejleszteni.

Lehet.

De ezek a alklamazásfejlesztési keretrendszerek is fejlődnek, változnak. Vagyis korántsem stabilak. Egy Qt 5.9 nem kompatibilis a 4.7 verzióval. A disztróknak és a linux desktopnak az lenne a dolga, hogy egy-egy stabil UI framework-öt stabilan támogassanak.

De jelenleg minden disztróban máshogy van a helyi Qt fordítva, más verzió, más csomagnevekkel, más konfigurációban. Vagyis egy Ubunu 17.04-en készített Qt alkalmazás nem portolható csak úgy egy Susére mondjuk.

> az egyik fo szereplo nem allt be a kozossegi projekt moge,

Ez a linux bulvármédia egyik legnépszerűbb tévhite. Akkor amikor az Ubuntu elkezdte a Mir-t fejleszteni akkor még sehol nem volt használható wayland implementáció. Gyakori hiba összemosni a wayland-et ami csak és pusztán egy protokol magával az implementációval a westonnal ami még a fasorban sem volt akkor amikor az Ubuntunak már volt telefonon működő saját display servere.

Ez az egész egy buta flamewar volt amit jellemzően azok tüzeltek akiknek az égvilágon semmi köze nem volt egyikhez sem.

Ertem amit irsz, de a program szempontjabol nem teljesen mindegy, hogy a DE alatt milyen framework van, ha a program tartalmazza a neki szukseges libeket, statikusan forditva vagy mashogy (lasd snap es tarsai)? Marmint attol, hogy Gnome-ot hasznalok, vigan futtathatok Qt-s appot, ha megvannak a megfelelo libek, akar igy, akar ugy. Illetve: ?

Nyilvan a Canonical a sajat erdekeit kovetve kezdett Mir-t fejleszteni, en nem hibaztatom oket ezert vagy nem gondolom, hogy rosszfiuk, egyszeruen csak orulok, hogy ennek a leallitasaval megszunt a divergencia. Teljesen fuggetlenul attol, hogy milyen flamewar volt vagy kinek volt igaza (mindenkinek van igaza), vagy hany eves a kapitany. Csak objektive szemleltem az esemenyeket.

A fejlesztőnek nem mindegy, hogy az alkalmazás amit megír az fog-e működni más disztrókon és ugyanazon a disztrón egy hét múlva is. Mert az az amivel egyik disztró sem foglalkozik.

Nagy nehezen megírsz egy frankó appot Debiánra mondjuk. Betolod a repóba még nehezebben. Jön egy új Qt és az appod omlik össze... te meg állhatsz neki adaptálni az új Qt-ra, az új gcc-re, meg az ezernyi egyébb folyamatosan változó API-ra. Na ehhez nincsen a francnak sem kedve.

Szerintem egy szabad szoftver leállása mindenképpen kudarca az egész mozgalomnak. Mert én egy mozgalomnak tartom az szabad szoftver világot.

Amúgy pedig nem, nem volt mindenkinek igaza. Aki egyáltalán leírta, hogy "Mir versus Wayland" vagy "miért nem a wayland mögé álltak be" azok mind tévednek... a Mir egy implementáció a wayland pedig csak egy protokol. Répát hasonlítunk össze a rakétával.

A fejlesztőnek nem mindegy, hogy az alkalmazás amit megír az fog-e működni más disztrókon és ugyanazon a disztrón egy hét múlva is. Mert az az amivel egyik disztró sem foglalkozik.

Nagy nehezen megírsz egy frankó appot Debiánra mondjuk. Betolod a repóba még nehezebben. Jön egy új Qt és az appod omlik össze... te meg állhatsz neki adaptálni az új Qt-ra, az új gcc-re, meg az ezernyi egyébb folyamatosan változó API-ra. Na ehhez nincsen a francnak sem kedve.

Szerintem egy szabad szoftver leállása mindenképpen kudarca az egész mozgalomnak. Mert én egy mozgalomnak tartom az szabad szoftver világot.

Amúgy pedig nem, nem volt mindenkinek igaza. Aki egyáltalán leírta, hogy "Mir versus Wayland" vagy "miért nem a wayland mögé álltak be" azok mind tévednek... a Mir egy implementáció a wayland pedig csak egy protokol. Répát hasonlítunk össze a rakétával.

Oke, szoval azt a reszet tovabbra sem ertem, hogy ha statikusan hozzaforditod a libeket a programodhoz, akkor miert szamit, mi van telepitve a user OS-en, plane, hogy mi a DE. Szerintem nem tekintheto komoly fejlesztonek, aki barmilyen programot kiad a kezebol ugy, hogy nem tudja, futasidoben pontosan milyen konyvtarakkal kell majd dolgoznia - igy tenyleg nehez stabil programot fejleszteni :)).

Az egesz dinamikus linkeles egy felrement technologia, pont mint az X - jo otletnek latszott, es kezdetben azok a kompromisszumok, amiket meg kellett kotni, elfogadhatonak tuntek. Ma azonban kit erdekel _valojaban_, hogy a programja nem 4KB, hanem 40MB, pedig csak egy hello world (kisse extrem pelda) - senkit, a savszelesseg olcso, a diszk meg olcsobb, az idom meg draga. Letoltom, mukodjon, ennyi.

A szabad szoftverben meg pont az a jo szerintem, hogy olyan, mint az evolucio - rengeteg uj dolog szuletik, es ezeknek a 99%-a zsakutca, es kihal elobb vagy utobb. Ez az elet rendje, es semmifelekeppen nem kudarc, sot.

> ha statikusan hozzaforditod a libeket a programodhoz

Az szabad linceszes Qt libeket például nem linkelhetsz statikusan alkalmazáshoz. Erre csak a kereskedelmi Qt használata esetében van joga a fejlesztőnek.

> nem tekintheto komoly fejlesztonek, aki barmilyen programot kiad a kezebol ugy, hogy nem tudja, futasidoben pontosan milyen konyvtarakkal kell majd dolgoznia

Vagy nem érem ezt a mondatodat, vagy kikérem a fejlesztők nevében, hogy jóslási képességet vársz el tőlük :)

Honnan a fenéből tudná egy fejlesztő, hogy a libXXX egyszercsak lecserélődik egy API inkompatibilis frissítésre?

A statikusan linkelt appok előnyét illetőleg tökéletesen egyetértek. Sajnos rendszerint license okai vannak, hogy ezt nem lehet megcsinálni.

Ez (a lib licenszeles) uj info volt, koszi. Ez bizony problema. Marad a snap/flatpak, esetleg a docker :)

A kerdojeles reszt megprobalom ujrafoglamazni: ha end usernek fejlesztesz, akkor az egyetlen lehetoseged, hogy bebetonozod a hasznalt konyvtarak verzioit, akar ugy, hogy statikusan linkelsz (ha megteheted), akar mashogy. Mert ha nem igy teszel, akkor egyszer csak valami buzgomocsing kilovi alolad a libet a frissitesevel, amirol - minthogy a fejleszto nem jos - elozetesen nem tudhatsz, nem keszulhetsz.

De szerintem ugyanazt mondjuk, csak pepitaban - te a lib fejlesztojetol varnad azt, amit en a fejlesztotol :)

Lényegében egyetértünk.

A disztró a fejlesztő szempontjából pontosan egy lib gyüjtemény amiben meg lehet bízni. Ha nincsen ilyen megbízható lib rendszer akkor marad a statikus linkelés, ha az megoldható. De statikusan belinkelni a fél világot azért tud több lenni mint 40 mega...

De ezt a problémát célozza meg a flatpak meg a snap. Nagy érdeklődéssel várom, hogy mutassanak valamit :)

Az 1)-es pont pont ugyanaz, hogy több DE van.
Ha egy DE lenne, akkor lehetNE stabil API. Amint több DE van, a stabil API léte is el van ásva.
Az pedig, hogy egy compiler csere miatt törik az ABI, az annyit jelent, hogy aluldefiniált az ABI. Ez egy fos technikai dolog, nagyban köszönhető a fos C++ szabványnak, ami nem definiál fix name manglinget.

Sajnos nem. A DE is csak egy alkalmazás. A kulcs az magának a disztrónak a felépítésén és az API stabilitás garantálásának a módjában van. Ez a probléma jelenleg nem megoldott a Linux desktop területen.

A snap és a flatpak próbálják ezt a problémát megkerülni. Ami akár be is jöhet.

A gcc, és az összes linux-os és bsd-s (sőt osx-es) fordító az Itanium ABI-t használja. gcc 2003 óta.

Bármely lib bináris kompatibilitása más tészta, de pl. a teljes gcc 4.x széria alatt a libstdc++ kompatibilis volt. 11 évről beszélünk. (Sőt visszafelé még most is lásd Dual ABI)

Megjegyzem windowson minden visual c++ verzió új std lib verzióval jön, semerre sem kompatibilisek.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( nevergone v | 2017. 04. 05., sze – 22:53 )

Én szerettem a Unity-t, remélem nem áll le teljesen a fejlesztése. Azért vannak itt kérdések bőven:

1.) Mi lesz a Unity-vel? Pláne a 8-al.
2.) Mi lesz a Mir-rel?
3.) Mi lesz BZoltannal?
4.) A GNOME GTK+-t használ. Mi lesz a Qt alapú Ubuntu Studioval?
5.) Mi lesz a már kiadott Ubuntus telefonokkal?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Valamiről lemaradtam?

A Nokia egy gazdag és sikeres, nagy múltú cég. Jelenleg 100 ezer főt alkalmaz és 23 milliárd eurós éves forgalma van.
A Canonical egy gazdag, kőstabil alapokon fekvő cég amelynek van úgy 600 alkalmazottja és több gazdaságilag is sikees üzletága.

Én sokat szoktam röhögni a bulvárszinten drámázó közvéleményen. A technológia világa az nem foci :) tíz projektből egyből lesz sikeres. De ettől még valakinek a többi kilencen is dolgozni kell. Én elsősorban mérnök vagyok, lényegében az ipar alézatos katonáhja. Nekem trombitál egy tábornok, hogy vonjam ki a kardomat és támadjak erre vagy arra. Az, hogy most az adott csata/hadjárat sikeres le, az ritkán múlik rajtam. Ahoz pedig elég nagyfiú vagyok, hogy magamra tudok vigyázni :)

Megtisztelő a feltételezés, hogy olyan nagy hatalmat feltételezel nekem amivel én bármit csődbe tudnék vinni :) Szerencsére azok a vállalkozások amik elsősorban rajtam vannak azok kivétel nélkül sikeresek :)

De szerintem csak provokálni akarsz...azt meg én pont leszarom.

1) Kuka
2) Kuka
3) Köszönöm a kérdést :) én jól vagyok. Sem a szakmai jövőm, sem az egyéni boldogságom nem múlik ezen. Ezt a döntést én már sejtettem vagy fél éve is. Készült erre mindenki a cégnél aki nem homokban tartotta a fejét. Az IoT az nagyon érdekelne, de én személy szerint a Snap vonalon túl sok problémát látok. A szerver és a felhős dolgok pedig nem érdekelnek. Dolgoztam majd egy évtizedet nagy cégeknél szerver fronton. Unalmasnak tartom. Szóval vélhetőleg én tolom arréb a bringág :) Aminek amúgy is lassan ideje van már.
4) Kuka
5) Ez a legnehezebb és ezért vagyunk sokan mérgesek a cég vezetőire... ugyanis kuka. Én továbbra is Ubuntu telefont használok. Ha másért nem akkor szolidaritásból azokkal akik pénz adtak egy Ubuntu telefonért.

Ha valakit konkrétumok érdekelnek akkor kérdezzen bátran :) Szívesen válaszolok. Igazán nincsenek titkok.

> Mik azok a problémák ami miatt a Snap zsákutca?

Maga a snap csomagolás és a snapd mint snap alkalmazásokat/szolgáltatásokat kezelő rendszer nagyon jó ötlet. Pont ahogy a Flatpak is és az Appimage is.

A snapd egytelen komoly problémája az az, hogy nagyon zárt modellben fejlesztik. A kód persze szabad, de csak próbáljon bárki aki nem a Mark Shuttleworth legközelebbbi köre bármit hozzászólni. Szerintem így nem lehet sikeres paradigmashiftet csinálni.

De a legnagyobb probléma nem a snapd hanem a snapcraft tool. Elvileg ez a tool hivatott az upstream forrásokból kész snap csomagot csinálni. Na, ez a tool nagyon gyenge. A snapcraftot bő két éve fejlesztik. Ez alatt folyamatosan változtak az API-k, nem volt egyetlen stabil verzió sem. Az egész rendszer ezer sebtől vérzik.

Sajnálom az Unity-t, mert megszerettem, remélem a közösség tol bele valami fejlesztést. A Qt alapú fejlesztőeszközt is sajnálom, mert szerintem elég jó cucc.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

( persicsb | 2017. 04. 06., cs – 08:46 )

Na, akkor megint eljött a Linux desktop éve.

( golgota | 2017. 04. 06., cs – 08:48 )

Na hogy mer' pont a bloatware szanalom gnome a kivalasztott menyasszony? :D
Jo-jo, tudom, egymilliard legy nem tevedhet. :D

( cheeky v | 2017. 04. 06., cs – 09:24 )

Hallelúja!
(Még ha a Gnome is egy hulladék, a Unity még inkább az volt, mindig is.)

( khiraly | 2017. 04. 06., cs – 09:38 )

Soha ne legyen igy igazam. Sajnos.

A gnome/gtk is megeri a penzet: a gnome-terminalbol (amit az ubuntu is hasznal) kivettek a tabok atnevezesenek lehetoseget (igy 20+ tabbal tokre atlathatatlan, hogy melyiken mit csinal az ember).

A nautilus (ami szinten benne van a gnome-ban) egyszeruen csak veszik ki a jo megoldasokat a usability jegyeben.
Vagy pl. egy sima fajl atnevezes most mar popup-on valosul meg, ami regen in-place atnevezte a fajlokat (ez valoszinu dizajn dontes volt).

Vegulis a Unity8 csak Qt alapu lett volna, akar lehetett volna belole valami. Csak kb. alig par ember dolgozott rajta olyan 2016 szeptemberetol (eleg a repokat megnezni).

Azert a szerver oldali sikeressege masszivan fugg a desktop vonaltol.
Ha a desktopot a kutya se hasznalja, akkor a szerver is mas platformon lesz sikeres,
ha adnak hozza kiszamithato support-ot (lts).

Azert kivancsi vagyok, hogy lesz-e valaha olyan ubuntu projekt amit vegigvisznek...:-\

---
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....

„Azert kivancsi vagyok, hogy lesz-e valaha olyan ubuntu projekt amit vegigvisznek...:-\”

LXC/LXD azóta is megy és tudtommal az AppArmort is ők karolták fel (vagy ők is),

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

> Tavaly például ugyanezt írhattad a Unity-ről is. :-) Bocs, de magas labda volt

De nem írtam :) és jó okom volt rá már tavaly is, hogy nem írtam. Az LXD és LXC a virtualizáció területén nagyon ütős cuccok. A Unity8 egyetlen esélye az lett volna, ha készen van tavaly karácsonyra.

Amúgy igen... eljön az a nap is amikor az LXC egy legacy cucc lesz ami megy fel a polcra a többi veterán szoftver mellé. Mindennek lejár egyszer az ideje :)

> Az LXD és LXC a virtualizáció területén nagyon ütős cuccok.

Megy mar a docker lxd alatt? :) Ha most epp megy, akkor mas disztro alatt?:)

Egyebkent az lxd-nek hol a helye a KVM/QEMU es a docker kozott?
KVM-nek keves, docker-nak sok.

Szerintem az lxc/lxd kerdesre terjunk vissza 2019-ben. Addigra ez is kikristalyosodik (kuka).

Addigis itt van ez a kis google trend:
https://trends.google.com/trends/explore?q=lxd,docker

---
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....

En teged sose ostobaztalak le.

Viszont en tenylegesen hasznaltam/hasznalok docker-t, lxd/lxc-t es kvm-et is.
Es megmondom oszinten az lxd/lxc-nek nem latok jovot.

De mondom terjunk vissza ra 2019-ben. Van ra egy lada sorom (láda, és nem lada :),
hogy akkor mar ez lecsengoben lesz.

Lehet, hogy hianyosan merem fel a piacot, de a lada sor all :)

Ugyanigy megjosoltam elore, hogy iden az ubuntu phone-nak teljesen befellegzett,
amikor te meg eroskodtel, hogy csak szoftverszallitokent meg lehet elni igy,
es a device gyartok a hibasak... :)

De persze trollozd le a masikat. Ez nem sertes.
Az ostoba mar inkabb, bar ez inkabb rad vall (es ezt minden szemelyeskedes nelkul probalom mondani).

---
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....

> En teged sose ostobaztalak le.

Viszont folyamatosan trollként kommentelsz. Ezt hagyd abba és kezdjünk el értelmes felnőtt szakemberek módjára beszélgetni.

> Es megmondom oszinten az lxd/lxc-nek nem latok jovot.

Ebben az esetben ne használd. Én látok bennük jövőt.

> Van ra egy lada sorom (láda, és nem lada :), hogy akkor mar ez lecsengoben lesz.

És ez miért baj. Az a sör amit ma este fogok meginni, holnap reggelig huggyá változik. Ettől még ma este jól fog esni az a sör. Mi ezzel a baj?

> amikor te meg eroskodtel, hogy csak szoftverszallitokent meg lehet elni igy, es a device gyartok a hibasak... :)

Egyrészt kérlek, hogy ne tulajdoníts nekem olyan állítást amit én soha nem tettem. Soha nem mondtam, hogy bárki "hibás" lenne.

Azt mondtam és azt mondom most is, hogy az Ubuntu csak szoftver vendor. A gyártókra tartozik, hogy leveszik-e a polcról a terméket avagy sem. Ha igen az jó, ha nem az nem jó.

Amikor ezeket indítottuk, akkor a Docker még nagyon kezdetleges volt, a KVM pedig túl nagy overheaddal járt, nekünk csak sok konténer kellett. Az LXC bevált azóta is, fel sem merült a Dockerre váltás, plusz a Docker sem jó mindenhova. Ezeknél pl. fontos volt, hogy a konténer megtartsa az állapotát a leállítás után is.

Egy szó, mint száz: az LXC sokkal jobb dolog annál, mint amilyennek elsőre látszik egy külső szemlélőnek.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Kezdetben azt használt, de áttértek egy traszparens megoldásra (libcontainer). Így lehetséges, hogy natívan fusson Windows vagy OSX alatt is.

https://www.infoq.com/news/2014/03/docker_0_9

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Hát nem tudom az ubuntu mint szerver :>

Ok, hogy használják sokan, de azért ha megnézed a gyártok drivereit kb suse/redhat dirvereket látok, nem nagyon botlottam olyanba hogy ubuntu. Gondolom ez is jelent azért valamit.

Arról nem beszélve hogy a szerver kiadások is hasonlóan mennek mint a desktop, ha eljön az idő kiadjuk és kész, bugok nem számítanak, majd a következő release ben javítjuk. Sajna LTS nél is igencsak kell idő mire javul, ha javul és tényleg nem csak a következő LTS be tolják.

A másik ami miat annó leváltottam az ubuntut centos-re. Hogy gondoltak egyet és kivették a xen-t. Annó debianról migrálgattam ubuntu 8.04LTS xenre, már ez megér 1 misét mert halom bugja volt. :D Ráadásul 10.04 ben ki is vették.

Úgyhogy elég volt, az akkor telepített CentOS 5 ök még most is mennek, majd most jön az upgrade.

Fedora 25, Thinkpad x220