YaST byl zkonvertován do Ruby

YaST, instalační a konfigurační nástroj používaný v distribuci openSUSE, je od nynějška v Ruby. Původní zdrojový kód napsaný v nevyhovujícím jazyce YCP byl do Ruby automaticky zkonvertován pomocí transpileru Y2R. Celkem bylo převedeno 594 680 řádků YCP na 724 687 řádků Ruby. Konverze je vyvrcholením projektu YCP Killer, na kterém 6 měsíců pracovali vývojáři pražské pobočky SUSE.

Vývojáři YaSTu očekávají, že po konverzi se zjednoduší další vývoj a údržba tohoto nástroje. Ruby by též mohlo nalákat nové přispěvatele, kteří se nyní nebudou jen kvůli YaSTu muset učit nový jazyk.

Z uživatelského hlediska by se změna implementačního jazyka neměla nijak projevit. Zkonvertovaný YaST bude možné vyzkoušet v openSUSE 13.1 Milestone 4 již tento týden.

5.8.2013 14:12 | David Majda | Zajímavý software

Komentáře

[Tomas]

Tesim se az si prectu zpravicku, ze byl vydan SuSE killer, ktery uzivatele bezstarostne prevede na redhat like system

[little.owl]

prevede na redhat like system

Ovsem napsany v Ruby.

[JoHnY]

Musim se nekdy podivat jak vypada /etc v SuSE.

[kouzer]

Co je na SUSE (potažmo openSUSE) špatného?

[heh]

To je přeci jasné. Nemá to pomalý, paměťově náročný, funkčně chudý YUM.

[little.owl]

zypper je fajn, ale co vam chyby funkcne na yum-u?

[heh]

Je to fakt pomale, pametove nenazrane, napsane v Pythonu. Dependency solver je pomaly a hloupy (videl jsem dokonce nejaky navrh na portaci SAT solver z libzyppu pro yum). Pokud vim, neumi to v CLI spravovat repozitare. Pouzitelne GUI to nema taky.

Uprimne, Zrovna Zypper je asi tak 100 let pred YUMem a to nejen poctem funkci. Nechapu, proc Fedora YUM davno nezahodila. Oba dva nastroje pouzivaji identickou strukturu repozitaru, a nahradit YUM tak neda prakticky zadnou praci.

[little.owl]

Yum je pomalejsi nez zypper, nicmene v praxi na s tim problem nemam a Python mi spise v danem kontextu vyhovuje.

Dependency solver je pomaly a hloupy (videl jsem dokonce nejaky navrh na portaci SAT solver z libzyppu pro yum).

Viz zde.

Pouzitelne GUI to nema taky.

Poradne GUI ma pouzivat zypper jako jeden z backendu, ale jinak ma byt nezavisle.

Uprimne, Zrovna Zypper je asi tak 100 let pred YUMem a to nejen poctem funkci.

Vyborne, tak mi to ukazte na konkretnich prikladech, 100 let dlouha doba.

[potato]

Pokud vim, neumi to v CLI spravovat repozitare.

yum-config-manager

Ale popravdě řečeno nevím, k čemu to je. Pro konkrétní akci se repo povolí/zakáže přímo v příkazu nebo v yum shellu, natrvalo vimem.

Repositář se přidá instalací příslušného foo-release rpm, což kdyby mi nepřišlo padlé na hlavu, mohu udělat i rovnou z web browseru. Odstraní se zase odstraněním toho rpm. Není zapotřebí nějaká speciální věc, která by to dělala, protože to není žádná speciální akce.

[little.owl]

Uprimne vzato, nevim co tim chce rici. Jsou tu CLI yum tooly jako treba createrepo, repoquery, reposync, repoview, repoclosure nebo repotrack. Vrcholem vseho je, ze zypper v Meego a Tizen pouziva prave format yum repositories.

[heh]

Opensuse pouziva format Yum repositories z duvodu kompatibility s RPM Fedory. Proč mít 150 implementací něčeho tam, kde je to zbytečné. Zypper podporuje i jine typy repozitaru, ale tym YUM repozitar je proste hlavni format v SUSE. Jde jen o adresarovou strukturu a format metadat.

[little.owl]

Proč mít 150 implementací něčeho tam, kde je to zbytečné.

Jiste a to zahrnuje i satsolver.

[heh]

Tady jde o to, že je potřeba vynaložit hromadu usili a naportovat SAT solver na YUM v momentě, kdy zypper je:

• 100% kompatibilní s YUM repository
• rychlejší a pamětově méně náročný
• obsahuje více funkcí než YUM

Nepoužívám Fedoru, takže mi to může být ukradené, ale jako nezávislý pozorovatel to prostě nechápu. Proč nadále vylepšovat YUM, když náhrada je imho výhodnější?

[little.owl]

Viz. dole.

[Jiří J.]

Na yumu mi oproti třeba aptitude chybí hlavně "chytré" odstraňování balíků včetně závislostí, se kterými byl balík nainstalován, ale které už nic jiného nepotřebuje. Ano, je na to nějaká optiona do yum.conf, ale ta funguje nějak divně - při pokusu odinstalovat skoro cokoli to jde zpětně po závislostech až na glibc a tím pádem na celý systém - člověk tak může buď nedělat nic, nebo s primitivním textovým editorem odinstalovat i celý systém.

A zrovna mám pocit, že ani package-cleanup --orphans nedělal nic lepšího.

Další docela významnou věcí je skutečně absence GUI / TUI. V aptitude můžu požadovanou akci doladit (třeba místo generického "MTA" jako závislost můžu vybrat kterého) a skutečně vidět, co se stane předtím, než se to stane. Taky neopravitelně pokazit RPMDB je docela snadné. A vůbec - v aptitude můžu vypnout "instaluj recommended balíky by default" a vyhnu se většině balastu. Yum mi to prostě vždy instaluje všechno.

Naštěstí jsou ve vývoji alternativy.

[little.owl]

Rekl bych ze michate dohromady vlastnosti yum a rpm, vetsina veci co zminujete je zalezitost rpm a s tim se potyka i zypper. Soucasne nastroje na odinstalovani mi vicemene staci a pomaha ze rpm based distribuce nesekaji kazdy kus SW na deset balicku. Do sporu rpm<->deb bych se nepoustel, oboji ma sve silne a slabe stranky a hlavne to nebylo podstatou meho puvodniho dotazu.

[heh]

toto neni vlastnost ani RPM ani YUM. To je problem spravce baliku, ktery nadefinoval zavislosti. Uplne stejne by to dopadlo s DEB a apitude, kdyby tam byly nadefinovany "reqiuere".

Mimochodem, Aptitude je uplne stejne neschopny jako YUM. V momente, kdy pro vyreseni zavislosti musi udelat downgrade balicku na nizsi verzi z jineho repozitare, okamzite kapituluje. Od dependency resolveru ocekavam, ze najde reseni, pokud existuje. Pripadne, nabidne ruzna reseni, pokud se jich nabizi nekolik (smysluplnych). To neumi ani apt, ani aptitude, ani YUM. Kdyz vynechame zypper, obstojne na tom byl Smart PM.

[little.owl]

o je problem spravce baliku, ktery nadefinoval zavislosti. Uplne stejne by to dopadlo s DEB a apitude, kdyby tam byly nadefinovany "reqiuere".

On je tam nadefinoval, protoze musel a protoze standardni RPM nepodporuje/ovalo veci jako soft dependencies (tusim, ze openSUSE na to melo patch).

[heh]

I bez soft dependencies se mohl rozhodnout, jestli to záviset bude nebo ne. RPM v SUSE skutečně podporuje "recommends" a "suggests". Do upstreamu RPM to zatím nedošlo?

[little.owl]

Nikoliv, bez soft dependencies vam vznikaji veci jako tohle. Mam pocit, ze souvisejici tagy jiz v upstreamu jsou, nejsem si jist, jestli to nekdo moc pouziva, ostatne ani openSUSE to nezminuje..

[Rezza]

I naznak tohohle je zabil...

[little.owl]

Otevrel jsem "rpmtag.h" a tam jsou veci jako:

    RPMTAG_SUGGESTSNAME		= 1156,	/* s[] extension (unimplemented) */
#define	RPMTAG_SUGGESTS RPMTAG_SUGGESTSNAME	/* s[] (unimplemented) */
    RPMTAG_SUGGESTSVERSION	= 1157,	/* s[] extension (unimplemented) */
    RPMTAG_SUGGESTSFLAGS	= 1158,	/* i[] extension (unimplemented) */
    RPMTAG_ENHANCESNAME		= 1159,	/* s[] extension placeholder (unimplemented) */
...
    RPMTAG_BUILDSUGGESTS	= 1172, /* internal (unimplemented) */
    RPMTAG_BUILDENHANCES	= 1173, /* internal (unimplemented) */

Takze se s tim asi pocita, ale neni to naimplementovane.

Soft dependency je chybejici featura a tu averzi nechapu.

[heh]

V Opensuse se to normalne pouziva.

[little.owl]

Tedy soft/weak dependencies jsou uz v openSUSE implementovany na urovni rpm? Ja jsem mel pocit, ze to byl jen flag ve schematu yum repository. Jak tedy ted psat openSUSE spec soubory?

[heh]

Nevím, na které úrovni to je implementováno.

[Stanislav Brabec]

Je to naimplementováno v libzypp. RPM tam jenom přidá značky, které sám neumí používat.

Síla zypperu je naplno vidět až v konstrukcích typu:

• Pokud je nainstalován současně balík A i balík B, pak nainstaluj i balík A-plugins-B. (Supplements: packageand(A:B))
• Pokud je jazyk CZ mezi jazyky zvolenými pro instalaci, a balík C je nainstalován, instaluj i balík C-lang-cz. (Provides: locale(C:cs))
• Pokud upgradujete z verze D-1.0 na verzi D-2.0, která je rozdělená do více podbalíků, nainstaluj D-part1-2.0 i D-part2-2.0. (Provides: D:soubor_který_je_teď_v_jiném_balíčku)
• Pokud je nainstalován balík E a je připojeno zařízení s USB id xxxx:yyyy, nainstaluj i balík E-usb-device-foo. (Supplements: modalias(usb:identifikace_jako_u_kernelového_modulu))

[little.owl]

To je velmi dobre, v tomto smeru je libzypp skutecne dale. Stale mi neni jasne, kde jsou tyto zavislosti a jak specifikovane. Ve spec file?

[Stanislav Brabec]

Ve spec souboru se to definuje, rpmbuild to pouze překlopí do rpm souboru, a libzypp s tím pak pracuje.

[little.owl]

Ja to chci ve Fedore take ....

[David Jaša]

Tady konkrétně chybí rpm(db) jiná věc: příznak "odinstaluj mě až na mě nebude nic záviset". Na úrovni yumu to je implementované pluginem (yum*leaves*) a pokud ten se přidá hned po minimální instalaci, tak to i docela funguje.

[kavol]

nemůžu si pomoct, ale spíš než takovéto harakiri ze strany správce balíčku/balíčkovacího systému se mi líbí přístup Gentoo - prostě máme seznam toho, co uživatel nainstaloval explicitně, a k tomu řešíme závislosti, když na něčem nic nezávisí a není to v seznamu, co tam uživatel chce mít, tak pryč s tím

[little.owl]

+1

Takhle to ma v podstate udelany take Debian - automatic flag u nainstalovanych dependencies.

[David Jaša]

Však to přesně píšu... Znám trochu debian a tam je ten seznam implementovanej právě výše popsaným flagem.

[little.owl]

I kdyz Debian to rozbiji tim, ze pouziva obri metapackage jako gnome-desktop-environenent a vse ostatni je pak zavislost. Kdyz chcete vyhodit Evolution, musite delat psi kusy.

[Bystroushaak]

S evolutionem si tuším uměl poradit apt-get, který se narozdíl od aptitude dá přesvědčit, že ne, opravdu nechci odinstalovat celý desktop.

[tom62]

pomaha ze rpm based distribuce nesekaji kazdy kus SW na deset balicku

Zrovna v openSUSE 12.3 texlive (který dříve byl v řádově jednotkách nebo desítkách balíků) rozdělili na několik tisíc balíčků, což mi přijde naprosto šílené.

[little.owl]

na několik tisíc balíčků,

V openSUSE se uz take zblaznili?

[heh]

vypada to ze jo

[petr_p]

Naopak, aby se nezbláznili.

[little.owl]

Tak vitejte na palube:

$yum list texlive-* | wc -l
5067

[gtz]

no mi chybělo na yumu to, že když jsem aktualizoval kernel tak už se nenamáhal aktualizovat třeba moduly nvidie. Jedno jsem je tam nějak zapomenul dopsat a najednou černá smrt. Zypper aspoň vypíše, že bude aktualizovat ty a ty moduly a je to v klidu. Na jednom stroji si jeden známý aktualizoval pár věcí (na ostatní aktualizace systému sere) a nějak to rozbilo celý slavný GUI Yumex. Takže za mne zypper.

[little.owl]

Vas popis mi moc nedava smysl.

Pokud jsem pouzival moduly nvidia/fglrx z RPMFusion, problemy tohoto typu jsem nemel. Pokud pouzivate univerzalni instalatory od Nvidia/AMD, je problem jinde nez v yum.

Ohledne yumex, je to third party aplikace, ne cast yum a pokud nevime co vas znamy kutil kutil, tezko rici kde je chyba. Na GUI, zridka, mi staci PackageKit, ktery je podporovan napric distribucemi, vcetne openSUSE.

[heh]

On má na mysli zřejmě to, že Zypper umí vypsat, které běžící procesy (jejich soubory) byly aktualizovány a potřebují tak restartovat. Dělá to buď automaticky, nebo to vypíše na příkaz: zypper ps

[little.owl]

To umi yum, staci aktivovat plugin yum-plugin-ps.

Zatim stale nevidim ty zasadni killer features zypper oproti yum, jak jste nadhazoval.

[heh]

No tak to bude asi ten problem. Jestli je 90% funkcionality v externich plug-inech, tak vubec netusim, kolik jakych funkci YUM aktualne ma. Našel jsem i takove bizarnosti, jako je "YUM plugin to retrieve the Dell System ID"

Beru tedy zpět. Počet funkcí nejsem při existenci me neznameho poctu doplnkovych modulu schopen zhodnotit. Jako uzivateli mi to ale zasadne vadi. Nevim, proc mam mit zakladni funkce volitelne na doinstalovani.

Vyhrady - aktualni solver, pomalost, pametova narocnost a Python zustavaji.

[little.owl]

Jestli je 90% funkcionality v externich plug-inech, tak vubec netusim, kolik jakych funkci YUM aktualne ma.

Opet prehanite, jakych 90%?

Beru tedy zpět. Počet funkcí nejsem při existenci me neznameho poctu doplnkovych modulu schopen zhodnotit.

Proc se tedy snazite navazet do neceho, co v podstate neznate a nepouzivate?

Pouzivam jak zypper, tak yum a tvrdit, ze jedna strana je 100 let pozadu a ma vice funkci je nesmysl. Ani na jedne strane vas bota netlaci.

Jako uzivateli mi to ale zasadne vadi. Nevim, proc mam mit zakladni funkce volitelne na doinstalovani.

Modularni architekturu rozsiritelna pluginy je vyhodna, funkcionalita pluginu, ktere se v praxi osvedci, se v yumu integruje.

aktualni solver, pomalost, pametova narocnost

Na solveru se pracuje. Rychlost, ani pametova narocnost netlaci, zejmena kdyz bottleneck je obvykle sitove pripojeni. Novy dnf je take psan v Python - jednu vyhodu jste uz sam objevil, snadna rozsiritelnost pluginy.

[little.owl]

Nicmene, ja take preferuji zypper a ale z jineho duvodu - nevlaci to s sebou takove kvantum zavislosti jako yum - ten vam natahne python a x-zavislych knihoven.

[heh]

Opet prehanite, jakych 90%?

Staci si projit vypis moznych prikazu pro YUM a pro Zypper (-- help, manualove stranky, atd...)

Proc se tedy snazite navazet do neceho, co v podstate neznate a nepouzivate?

To, ze to nepouzivam, je dusledek nikoliv pricina. Osobni zkusenost je negativni a python je pro me u klicove systemove komponenty fatalni negativum.

[little.owl]

Staci si projit vypis moznych prikazu pro YUM a pro Zypper

Tak mi dejte priklad te zasadni feature, ktera yum-u chyby a kvuli ktere dnes nebudu v noci spat.

python je pro me u klicove systemove komponenty fatalni negativum.

S tim bych na desktopu/serveru nemel problem, u embedded systemu je to jine.

Proc je to fatalni negativum? Python je silny jazyk a jeho dobra integrace do systemu z nej ucini silny nastroj pro spravu systemu, casto lepsi nez bash.

Spustim python v terminalu, naimportuji rpm ci yum a mohu delat analyzu vseho mozneho, treba zde.

[heh]

Jde mi o úroveň. Pokud si uživatel z libovolneho duvodu rozbije Python, nebude schopen spravovat system. Možnost cokoli opravit je pak dost omezena. (rucne pomoci RPM) Domnivam se, ze zakladni spravce baliku je natolik kriticka komponenta, ze by mel byt napsan v necem jako je C a pouzivat zakladni systemove knihovny. Pokud chce nekdo skriptovat v Pythonu, nevidim duvod, proc to nemit jako zasuvny modul do zakladniho spravce baliku, nebo o uroven vys u neceho jako je Packagekit.

[Mrkva]

Pokud si uživatel z libovolného důvodu rozbije libc, nebude schopen spravovat systém. :)

[kavol]

busybox?

[little.owl]

No hlavne pokud to rozjebu na teto urovni, posledni vec kterou bych na to pustil je zypper [ci yum].

[gtz]

Když jsem u něj dal yum update kernel tak to mi nenapsalo, že by měl aktualizovat i moduly pro Nvidii (FC18). Po tom co jsem si toho nevšiml a aktualizoval kernel tak jak jistě X-ka šly do smrti. Pak dohodím výpis

co vas znamy kutil kutil

doinstaloval z repos nějaký SW včtně libEGL a nyní to na EGL padá Pak dohodím výpis

Dále v zypperu jasně vidím, které balíčky jsou instalovány .... v yumu to sice také jde, ale je to složitější.

comment: Pak dohodím výpis == musím na jeho vzdálenou mašinu přes SSH

[gtz]

ten yumex

Traceback (most recent call last):
  File "/usr/bin/yumex", line 25, in module
    from yumexgui import YumexApplication
  File "/usr/lib/python2.7/site-packages/yumexgui/__init__.py", line 27, in module
    import gtk
  File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 40, in module
    from gtk import _gtk
ImportError: /lib/libEGL.so.1: undefined symbol: wl_display_dispatch_queue_pending

[little.owl]

To je spise problem v mesa-libEGL, integrace wayland, zrovna ted mi prijde mesa a vsechny drivery fragile.

[gtz]

nevím přesně proč to instaloval zda to chtěl RazorQt nebo něco jiného, ale bylo to ze dne na den. No zkusím pak udělat downgrade balíčku popř. ho dám úplně pryč.

[little.owl]

Nebo nainstalujte lib s chybejicimi symboly, pravdepodobne libwayland-{server,client} a pockejte az to opravi. Pak to pres yum history odeberte.

V tomhle zavodu o drivery a pozici mezi Ubuntu Mir/Unity a Linuxem s Wayland/Gnome-KDE-etc. si bude treba jeste drzet klobouky.

[heh]

SUSE tady bylo před RedHatem a bude tady i po něm.

[melkors]

Opravdu? Ja mel za to, ze RedHat byl zalozen v roce 1993 a SuSE 1994.
A o tom, ze SuSE de facto jiz neni, bych se snad ani nesiril ... NoWell

[heh]

SUSE bylo zalozeno 1992, initial release distribuce 1994.

RedHat byl zalozen roce 1993. initial release distribuce 1995.

SUSE a Novell jsou oddelene firmy, Novell nema v SUSE zadny podil.

[kavol]

zopakuj si pár lekcí z dějepisu

1) SuSE svoje distro vydalo v roce 1996, do té doby přebalovalo Slackware

2) první RHL, "Halloween release", vyšel v roce 1994

3) SUSE a Novell jsou nyní součastí Attachmate, takže o oddělení by se dalo úspešně pochybovat (ano, Attachmate po akvizici Novellu vyčlenil SUSE z Novellu jako samostatnou "bussiness unit", takže tvrzení "Novell nema v SUSE zadny podil" je pravdivé, leč tak trochu nahovno)

[heh]

1) SuSE svoje distro vydalo v roce 1996, do té doby přebalovalo Slackware

Podle tvojí logiky Ubuntu dodnes vůbec neexistuje, protože neustále mirrorují Debian.

Firma jako taková, zabývající se Linuxem, vznikla v roce 1992. Tolik k dějepisu. http://en.wikipedia.org/wiki/SUSE_Linux_distributions

2) první RHL, "Halloween release", vyšel v roce 1994

Beru zpět, špatný zdroj. Na výsledku to nic nemění.

SUSE a Novell jsou nyní součastí Attachmate, takže o oddělení by se dalo úspešně pochybovat (ano, Attachmate po akvizici Novellu vyčlenil SUSE z Novellu jako samostatnou "bussiness unit", takže tvrzení "Novell nema v SUSE zadny podil" je pravdivé, leč tak trochu nahovno)

Nerozumím, nechápu. SUSE je firma existující od roku 1992 (tedy déle než RedHat), v průběhu doby se měnili vlastníci. Od 2003 vlastnil firmu Novell, dnes ji vlastní Attachmate. RedHat je obchodovaný na burze, takže to je totéž v bledě modrém. Nevidím žádný rozdíl.

[kavol]

1) SuSE svoje distro vydalo v roce 1996, do té doby přebalovalo Slackware

Podle tvojí logiky Ubuntu dodnes vůbec neexistuje, protože neustále mirrorují Debian.

to nechť si každý rozmyslí sám, jak toto chápe, já jsem pouze poukazoval na to, že v souvislosti s výrokem "bude před, bude po" je nesmysl uvádět jako datum vzniku distribuce rok 1994, neboť distribuce, která vznikla v roce 1994 (ve skutečnosti bych uznal už rok 1992) zanikla v roce 1996, bez ohledu na to, jestli ji budeme nazývat "SUSE" nebo "přebalený Slackware", zatímco distribuce, která žije dodnes, vznikla (byla vydána?) právě až v roce 1996

Firma jako taková, zabývající se Linuxem, vznikla v roce 1992. Tolik k dějepisu. http://en.wikipedia.org/wiki/SUSE_Linux_distributions

zajímavá taktika odkazovat zdroj, který podporuje tvrzení oponenta

... Nevidím žádný rozdíl.

pak doporučuju kromě studia historie taktéž studium obchodního práva a věcí souvisejících

pro začátek třebas na té oblíbené wikipedii skouknout stránky o Red Hatu a o Attachmate Group, podívat se v infoboxíku na kolonku Type, poučit se o významu Public a Private, zejména co z toho plyne vedení firmy za povinnosti (tl;dr: Jim se musí snažit, abych vydělal; Nils musí poslouchat Jeffa, který ale poroučí i Bobovi)

[heh]

to nechť si každý rozmyslí sám, jak toto chápe, já jsem pouze poukazoval na to, že v souvislosti s výrokem "bude před, bude po" je nesmysl uvádět jako datum vzniku distribuce rok 1994, neboť distribuce, která vznikla v roce 1994 (ve skutečnosti bych uznal už rok 1992) zanikla v roce 1996, bez ohledu na to, jestli ji budeme nazývat "SUSE" nebo "přebalený Slackware", zatímco distribuce, která žije dodnes, vznikla (byla vydána?) právě až v roce 1996

To je slovíčkaření. Změnili základ distribuce. Zejména proto, že upstream mají nakonec všichni stejný. V RedHatu se od první verze taky změnilo všechno možné.

zajímavá taktika odkazovat zdroj, který podporuje tvrzení oponenta

Podle mě to zejména podporuje tvrzení, že SUSE (1992) je zde déle než ReHat (1993). Jinak nemám nic proti podpoře tvrzení oponenta, když má oponent zrovna pravdu.

pak doporučuju kromě studia historie taktéž studium obchodního práva a věcí souvisejících

pro začátek třebas na té oblíbené wikipedii skouknout stránky o Red Hatu a o Attachmate Group, podívat se v infoboxíku na kolonku Type, poučit se o významu Public a Private, zejména co z toho plyne vedení firmy za povinnosti (tl;dr: Jim se musí snažit, abych vydělal; Nils musí poslouchat Jeffa, který ale poroučí i Bobovi)

Není potřeba, neboť je to irelevantní. Všichni si musí na sebe vydělat.

[kavol]

To je slovíčkaření. Změnili základ distribuce. Zejména proto, že upstream mají nakonec všichni stejný. V RedHatu se od první verze taky změnilo všechno možné.

a toto je trapný pokus o demagogii

mezi těmi distribucemi není žádná kontinuita, a žádné okecávání, že to oboje má linuxovj kernel, na tom nic nezmění

Podle mě to zejména podporuje tvrzení, že SUSE (1992) je zde déle než ReHat (1993).

vznik firem jsem ovšem nijak nerozporoval, takže nechme těch úskoků stranou a vraťme se k těm distribucím, ano?

Není potřeba, neboť je to irelevantní. Všichni si musí na sebe vydělat.

mno, myslímže fakt, že Jeff poroučí Nilsovi i Bobovi zároveň, je docela relevantní, bavíme-li se o tom, zda dotyčné firmy mají či nemají něco společného ...

[heh]

a toto je trapný pokus o demagogii

mezi těmi distribucemi není žádná kontinuita, a žádné okecávání, že to oboje má linuxovj kernel, na tom nic nezmění

Jestli tam je nebo není "žádná kontinuita" neumím posoudit. K tomu slovíčkření a demagogii je myslím názorné si představit, kde bude větší rozdíl: SUSE 1.O vs. SUSE 4.2 vs. RedHat 1.0 nebo RedHat 1.0 vs. RedHat 6.4? Podle mě je evidentní, že mezi první a spolední verzí RedHatu je mnohem větší rozdíl, než mezi první a druhou verzí SUSE nebo první verzí RedHatu. Tolik k absurdnosti vaší argumentace o kontinutitě, co z čeho vychází atd.

vznik firem jsem ovšem nijak nerozporoval, takže nechme těch úskoků stranou a vraťme se k těm distribucím, ano?

Ale já si nejsem jist, jestli zde diskuujeme čistě o distribucích. Distribuce se jaksi samy nevytvářejí, že ne? Vytváří je komunity (tvořené jednotlivci či institucemi). Proto je můj výrok, že SUSE tu bylo před RedHatem důležité chápat úplně jinak, než optikou kontinuity individuálních distribučních opičáren, které tvoří zanedbatelné % kódu. Komunita kolem SUSE přežila mnohem větší turbulence než RedHat, který zatím žádné dramatické zvraty nezaznamenal.

mno, myslímže fakt, že Jeff poroučí Nilsovi i Bobovi zároveň, je docela relevantní, bavíme-li se o tom, zda dotyčné firmy mají či nemají něco společného ...

Mají společného majitele, to je vše. Vzhledem k tomu, že SUSE je nejziskovější business z portfolia bývalého Novellu, nevím, jaký vliv by současné vlatnictví jiné firmy Novell mělo mít na rozhodování finančních žraloků z Attachmate.

[kavol]

Jestli tam je nebo není "žádná kontinuita" neumím posoudit. K tomu slovíčkření a demagogii je myslím názorné si představit, kde bude větší rozdíl:

SUSE 1.O vs. SUSE 4.2 vs. RedHat 1.0

nebo

RedHat 1.0 vs. RedHat 6.4?

Podle mě je evidentní, že mezi první a spolední verzí RedHatu je mnohem větší rozdíl, než mezi první a druhou verzí SUSE nebo první verzí RedHatu. Tolik k absurdnosti vaší argumentace o kontinutitě, co z čeho vychází atd.

ROFL, takže se tu bavíme o 1994 vs 1996 a 1994 vs 2013 (no, nevím, co je míněno "poslední verze RedHatu, nicméně jelikož RHL 6.4 neexistuje, předpokládám, že je míněn RHEL), tak to je hodně férové srovnání

tož mějme rodiče XY, kteří v roce 0 zplodí dítě A, v roce 2 dítě B, a v témže roce jim dítě A zemře

nyní píšeme rok 19

a teď argumentujme, že děti se prostě v průběhu času mění, že zatímco dítě B v roce 19 vypadá jako postpubertální kolohnát a umí řídit auto, tak v roce 2 vypadalo jako buclatá panenka a umělo sát z bradavky, no a protože dítě A v roce 2 také vypadalo jako buclatá panenka, sálo z bradavky a zároveň se také narodilo rodičům XY, tak vlastně dítě B je tatáž osoba jako dítě A, bez ohledu na to, že mrtvé tělo dítěte A tlí v digitálních archívech stále jako buclatá panenka, zatímco dítě B nám mezitím narostlo na šest stop a palců pět

Mají společného majitele, to je vše.

vážně? - tak proč třeba tady vidím čilý ruch okolo (open)SUSE?

lžeš, až se ti od huby práší

Vzhledem k tomu, že SUSE je nejziskovější business z portfolia bývalého Novellu, nevím, jaký vliv by současné vlatnictví jiné firmy Novell mělo mít na rozhodování finančních žraloků z Attachmate.

tato věta mi nedává smysl, speciálně v části "současné vlatnictví jiné firmy Novell"

[p.c.x.]

No to to trvalo, ale lepsi pozdejc nez nikdy. Vzdycky kdyz se vymejsli kolo, cekam jak dlouho bude trvat nez se z ty slepy ulicky vrati.

Btw. par proroku tu zpochybnovalo schopnost uplne konverze pres Y2R. Co na to rikaji dnes ?

[potato]

Dělali na tom půl roku a mají ve výsledku tři čtvrtě milionu řádek strojově konvertovaného kódu. Takže přejeme mnoho štěstí při jeho údržbě...

[Rezza]

No ale porad susakum zavidim, ze kdyz neco chteji udelat, tak to udelaji. To ve Fedore moc schopni nejsme :(

[David Majda]

Při vývoji Y2R jsme se samozřejmě snažili, aby výsledný kód byl co nejzehčí. Viz třeba Integer.ycp (před a po) nebo String.ycp (před a po). Takže si troufnu říct, že náklady na údržbu nebudou o moc vyšší než náklady na údžbu ručně psaného kódu.

[:::]

vypada to celkem rozume. Proc tam pouzivate Ops.xyz misto binarnich operaci?

Jo a jeste, proc jste zmenili odsazeni ze 4 na 2 misto na 8 (1 tab)

[rbc]

Jo a jeste, proc jste zmenili odsazeni ze 4 na 2 misto na 8 (1 tab)

Protože RoR Jinak konvence podle neoficialniho pruvodce Ruby.

[qk_]

Pouziva se tam Ops.xyz misto binarnich operaci v pripade ze neni jistota ze oba argumenty nejsou nil ( jedna z vlastnosti YCP je, ze je sice typovanej, ale cokoliv jeste muze byt nil ) no a ruby by v tom pripade hodilo vyjimku, takze Ops zachovavaji zpetnou kompatibilitu.

[rbc]

Super, samozrejme kdyby se to psalo od zakladu v "chytrejsim" Ruby, spousta krkolmnych konstrukci by odpadla a zkratil by se kod. Takhle to je rozumne a predpokladam ze v prubehu casu se pri aktualizaci/rozsirovani kod bude postupne cistit.

[gngl]

Hmm. Ale třeba ty procedury Range a RangeFrom jsou přeci úplně zbytečné? Tenhle "překlad" sice vygeneroval správnou syntaxi, ale ty správné idiomy tam už nedoplnil.

I když je zase pravda, že překlady programovacích idiomů asi nebudou o moc jednodušší než překlady idiomatických komunikátů v přirozených jazycích... (Přesto myslím, že v nějaké míře by na ně pattern matching zabrat mohl.)

[David Majda]

V principu by samozřejmě šlo překladač napsat tak, aby překládal správně i idiomy. Nicméně narazilo to na dva problémy:

• Dost často se dva podobné konstrukty ve dvou jazycích liší v nějakých okrajových případech (viz jinde zmíněné odlišné chování operátorů jako + pokud je jeden z operandů nil). Ty by se musely buď ošetřit, nebo by si překladač musel být jistý, že okrajový případ nenastává (což znamená implementovat statickou analýzu kódu). A to nemluvím o tom, že je dost práce na tyto případy jen přijít.
• Nedostatek času. Překladač jsme chtěli mít hotový do openSUSE 13.1, protože na něm bude založený SLES a SLED 12. Pokud bychom to nestihli, v YCP by bylo nutné psát kód a podporovat ho mnoho let (po celou dobu podpory SLES/SLED 12). To pro nás nebylo přijatelné.

Z těchto důvodů jsme se rozhodli překaldač implementovat na úrovni syntaxe a kód začistit později (ať už ručně, nebo s pomocí nějakých nástrojů).

[gngl]

Hahahaha... A hlavně že YaSŤáci tak děsně hájili YCP, když jsem se jich někdy kolem 2007 nebo tak nějak ptal, proč to nepřepíší do Ruby, když si tak stěžovali na maintenance vlastního VM. Koukali na mě jako na poleno, že takovou blbost snad nemůžu myslet vážně.

Směju se naposled.

[David Jaša]

Trochu mi to připomíná tohle.