Vlákno názorů ke zprávičce Ubuntu přechází na systemd od Trident - Tak to soucasti vseobecne strategie zprznit co se...
-
Trident (neregistrovaný)
Tak to soucasti vseobecne strategie zprznit co se da. Pulseaudio-Uhnity-systemd co bude dal? Divte se pak ze widlari si delaji z linuxaku srandu. Jeste ze mame BSD.
Je cas na to zrusit ubuntu na jednom svem desktopu kvuli systemd. Aspon ve chvili kdy dojede podpora.
Problem neni ani tak v myslence ktera je v zakladu dobra, ale v Lennartovi a jeho parte ktery designem a implementaci rozs...u na co prijdou.
Navrhuji crowdfunding na rentu pro nej a jeho nohsledy aby uz nic nevyvijeli.Proc je ta sr... zavisla na dbus? Nechci d-hnus! Chci veci co nejvic transparentni.
Init system by mel byt co nejvice minimalisticky. Naco early services? Jak to bude pak znovupouzitelne na embedded zarizenich kde je treba optimalizovat?Porovnani:
https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems -
muf (neregistrovaný)
Souhlasím.
Pokud bude možnost nějakou finanční sbírkou ty magory zastavit a poslat někam, kde nebudou škodit, rád přispěji řádově v tisících korun.
Zrovna dnes jsem na OpenSUSE 13.1 řešil problém s tím, že po bootu nenaslouchal na LAN CUPS a uživatelé marně a marně posílali další joby na tiskárnu... Po startu PC s tiskárnou bylo vždy třeba CUPS nahodit ručně.
Nakonec jsem to víceméně obešel - zrušil tu hovadinu se .socket a udělal CUPS jako normální .service, která se při startu systému prostě spustí.
Mě teď, musím říci, nezajímá, že je to možná chyba správce systemd u SUSE a ne přímo bug v upstreamu. Mě prostě _s_e_r_e_, že ztrácím čas(v sobotu) nad hovadinami, ze kterých nekouká žádný technický benefit. Dříve bylo nahození služby průhlednou a triviální záležitostí, teď je to zasviněno produkty jakýchsi chorých mozků a o vše se stará více než pochybný superuniverzální moloch, bůhvíjak interpretující konfigurační soubory.
Nakopat ty magory a poslat je k Laelovi do Microsoftu - přesně tam patří. Jak jsem psal, rád se na tom budu finančně podílet. -
> Jak to bude pak znovupouzitelne na embedded zarizenich kde je treba optimalizovat?
Nijak. Robil som taky sukromny port userspacu Archu do x86 Androidu. Absolutne vsetky sluzby su dodavane so .service subormy, este aj v AURe furt niekto p.cuje, ze ma clovek sluzbu v /etc, kde normalne patri. Vo vysledku sice mozem nainstalovat napr. Apache, ale spustat si ho mozem akurat rucne, bo .service samozrejme nic pouzitelne neprecita.
Ale hlavne ze mame... co vlastne? -_-
-
ZiGi (neregistrovaný)
neviem ci sa da odrezat zo startu viac ako 2-3 sekundy zmenou init sysemu.
najvacsia zmena v rychlosti startu za posledne roky bolo zavedenie fast start v UEFI (alebo ako sa ta featurka vola). a ze by mi tie 3 sekundy stali za systemd a s nim spojene sracky...
Mozno som uz stary, ale vobec netuzim po journald, logind, uz tak je problem nastavit udev, srackovite polikity a podobne veci mi strpcuju zivot. a to ani nie som developer, staci administrovat nejaku tu zbierku serverov a desktopov. Preco, kurva, po kazdej zmene miesto slubovaneho zlepsenia su veci iba neprehladnejsie a horsie? -
zzz (neregistrovaný)
No ono neni az tak dulezite co chces ty, ale co chce RedHat a ten plati lidi jako Lennart aby makali pro _jejich_ cile. LP se zbytecne demonizuje. Je to jako v te bajce o oslu kteremu se vsechna zvirata v dzungli neodvazila postavit. Ne ze by se obavala jeho, ale lva ktery stal celou dobu za nim. Pokud by odesel on nebo Sievers, tak nasadi obratem nekoho jineho.
Ale jinak souhlas, pod taktovkou RedHatu - kolaboranta s nechvalne proslulou NSA, se ekoystem Linuxu vytrvale rozbiji a vzdaluje od *nixu smerem k Windows-like systemu. Jinak predem lituju adminy CentOS/RHEL.
-
sid (neregistrovaný)
Chlapci management RH na vas caka. Keby tusili, ze co za zbierku geniov tu je tak uz ten microsodf maju 5x zniceny:-). Preco miesto debilnych kecov si neforknete napr centos a neurobite si vlastny init? Kedze kazdy tomu tak rozumiete tak najneskor do roka urcite kazdy rozumny clovek to bude pouzivat. Specialne ten clovek co ma o
suse je uplne bozi. Takze chyba je mozno v upstreame odstranena ale sw je shit lebo to neni v jeho distribucii. Zasnem. -
muf (neregistrovaný)
Já žasnu nad tupostí některých lidí.
Tak ještě jednou pro ty pomalejší:
Psal jsem, že popsaný problém asi není způsoben chybou v upstreamu, ale možná nedostatkem při implementaci do distribuce. Vůbec se tomu nedivím a ani nenadávám správcům systemd a cupsu u SUSE, protože vidím, v jakých sračkách (udělaných dle nejlepších tradic Microsoftu) se v případě systemd ti nešťastníci musejí hrabat.K čemu mně systemd vlastně je? Rychleji to s ním nebootuje, je to uvnitř zbytečně složité a nepřehledné a tím náchylné ke všemožným chybám, nic to neušetří, distribuce s tím mívají problémy. S elegantním řešením to nemá nic společného, když s tím pracujete na příkazové řádce, připomíná to všechno možné jen ne unixový nástroj. Z dříve triviálních věcí se díky systemd někdy stane komplexní problém.
Určitě by to byla zajímavá čísla, pokud by si někdo dal tu práci a vyčíslil kolik času admini díky tomu ztrácejí zcela zbytečně.
A nejhorší na tom je, že to začíná prorůstat skoro všude - init je těm magorům málo...
Často se nadává na Canonical, ale jejich upstart se za slušnou náhradu rc scriptů považovat kupodivu dal. V CentOS 6 mě kupříkladu nikdy nenasral.... -
sid (neregistrovaný)
Jasne, admin sa nedokaze nic nove naucit? Neviem ci vam celkom dochadza ze to co bude implementovana a ako zavisi na ludoch co to robia a venuju tomu cas. Navyse nic vam nebrani si zaplatit support a potom sa dozadovat riesenia. Takto mozete maximalne zaplatit niekomu chytrejsiemu aby vam to urobil. Pripadne odist inde.
-
Trident (neregistrovaný)
Uvedom si ze tato oblast nejsou nagelovany startupovy agilni pometla programujici webovy pizmone v HTML666.9. Admini potrebuji stabilitu,prehlednost,jednoduchost a _zpetnou_kompatibilitu. Protoze sami musi spravovat slozity ekosystem a nemaji cas se piplat s takovymi trivialitami.
Maji spoustu jine prace nez zkoumat overingeneered zbytecne komplexni system. V momente kdy zajistuju clustery a staram se o to aby server mel spravne pripojeny disky neni muj problem zkoumat jak je momentalne roz...... systemd v jake verzi. Extremy typu ze si stracem pul dne zjistuju kam ta kravina vlastne saha nebudou vyjimkou.
Systemd porusuje pravidlo "Keep it simple, stupid" na vsech frontach.Proc se ucit neco co nedava smysl a je rozbity a rozbije se dal?
Proc se ucit neco co lenart pri pristi verzi zase jinak rozbije?
Proc se ucit neco co se vyviji odspodu nahoru?
Proc se ucit neco co pouziva zbytecny sluzby ktery v produkci nepouzivam?
Proc se ucit neco co ma spoustu tykadel okolo pres ktery je mozny to hacknout?
Jak maji chudaci distra udrzovat tenhle silenej moloch?
Cas je drahy. A je lepsi ho venovat studiu kvalitni technologie ktera ma nejakou budoucnost.Komplexnejsi Solarisi SMF jsem se naucil protoze mi reseni davalo smysl a celkem dobre to funguje. Sice se zde projevila uchylnost Sun/Oracle mit vsechno v xml - tipuju kvuli toolum pro engineered systemu, ale ten system funguje dobre a je prehledny. Pokud clovek a jen jak opica manazuje sluzby staci dva/tri prikazy. Stale vsak drzi zpetnout kompatibilitu s init skripty.
Tradeoff toho ze musim stravit cas naucenim se neceho jineho se vyplatil.A i doted po nakych 8mi letech od uvedeni ho rada adminu neumi. Vcetne Oraclu samotneho.
-
sid (neregistrovaný)
Garantujem vam ze naucit sa dobre programovat je nepomerne zlozitejsie a ladit napr telefonu ustrednu (teraz mam na mysli to co sa predava pre gigantov ako TCom) je tak inde, ze mi vase vyplakanie o zlozitom ekosysteme pride sorry ale usmevne. Takze toto nekonecne fnukanie pri kazdej zmene hocicoho je podla mna znak toho, ze kopec adminov tomu figu rozumie a ma este mensiu chut cosi sa ucit. Naucili sa zaklady bashu a tym padom maju pocit, ze mozu kecat k veciam o ktorych ani netusia a jedine co vedia, ze pri pive mu pepa povedal, ze systemd je chujovina, tak ano urcite je to tak.
Dokazem pochopit, ze nie kazdy ma chut a cas sa ucit cosi uplne nove ale kolkokrat prechadzate na novy init system? Co vam brani pockat na centose 6 dalsie 3 roky kym sa systemd dostane na level ktory ocakavate? Zaroven stale je tu moznost prejst na nieco uplne ine, pripadne sa spojit zaplatit si ludi a naprogramovat si vlastne vyhovujuce riesenie.PS:
Keby zrovna teraz fungoval vsade systemd uz 10rokov a niekto by rozhodol, ze je dolezite mat init zalozeny na scriptoch a pid suboroch som absolutne presvedceny, ze ludia co teraz kricia boli v prvej rade a znova kricali, ze vsetko je rozbite, je to stupidne, atd atd. -
muf (neregistrovaný)
Škoda slov k těm vašim blábolům.
Naučil jsem se konfigurovat systemd docela dobře(když nic jiného, aspoň nějaká dokumentace k tomu je), totéž jsem učinil s upstartem. Jak jsem psal, upstart kupodivu nevadí. A právě proto píšu to co píšu.
Živím se mimo jiné také programováním v embedded a naprosto sebejistě můžu říci, že Poetering a spol. nemají s inženýry nic společného. Pokud bychom my přistupovali k softwaru jako oni, autům by nečekaně chcípal motor, blokovala by se kola a kdybychom škodili v leteckém průmyslu, letadla by padala a nikdo by nevěděl proč. Zato by se po havárii inspektoři přehrabovali v tunách zbytečného balastu a ztráceli cenný čas. Oni mají štěstí, že PC nebo server stojí v klidu na podlaze nebo v racku.
To že z někoho tryskají "skvělé" nápady a vize ještě neznamená, že jejich realizace bude přínosná, pokud se při tom nebude přemýšlet. Zatím se jim daří jediné - prznit linuxový "ekosystém". -
Sid (neregistrovaný)
ak mate pocit , ze systemd je pre RT embedded systemy tak tomu zjavne nerozumiete. Ak teda chapeme RT rovnako (len staticke alokacie, RT kernel, casova zlozitost algoritmov). Mate pocit ze Poetering a spolok mieria primarne na embedded zariadenia? Mna stale udivuje, ze velke firmy zamestnavaju dementov ked tolko "inzinierov" je v kazdej diskuzii. Vy viete o jednom svojom use case, ludia co to realne robia musia riesit xy dalsich a obcas protichodnych. Takze tieho hrdinske reci bez nejakej implentacie alebo navrhu (realnom) ktory za vami stoji su ako ked je u nas 5 milionov trenerov hokeja.
-
„Mate pocit ze Poetering a spolok mieria primarne na embedded zariadenia“
Já bych tomu neříkal pocit, jejich zaměření na embedded zařízení mi připadá více než zjevné. Pokud vím, tak glib a služby postavené nad glib odmítají s odůvodněním, že to není staticky analyzovatelné a tudíž to není obecně nasaditelné (tedy především v embedded světě). Mnohá rozhodnutí odůvodňují potřebami embedded vývojářu z různých větších společností.
-
Karel (neregistrovaný)
Nedávno jsem v podobné souvislosti slyšel krásné přirovnání:
Je to jako přecházet od dynamitu ke střelné bavlně. Má menší účinnost, je dražší, je nebezpečnější a přeprava je o dost náročnější. Ale dá se nacpat do kanónu a půjde z něj vystřelit, což se vám s dynamitem nepovede. Navíc je práce s ní mnohem větší adrenalin než ta nuda s dynamitem.
-
j (neregistrovaný)
Boze, ty ses zjevne z M$, tak je podobnych volu neurekom ... takze firma si misto admina bude jeste platit support, kterej ji ovsem posle doprdele s tim, ze za to muze tvurce balicku, takze ve finale si muze najmout asi tak 10 000lidi a nechat si napsat vlastni system ... aby mela pod kontrolou vse.
-
PavelC (neregistrovaný)
To organizujete nějakou soutěž v rychlosti bootování ? Sorry, ale mě to přijde jako neuvěřitelná hovadina nejen na desktopu (kde je suspend do paměti nebo na disk) a na serveru už tuplem. Kolik procent času připadá na čas bootu z celkové doby práce s počítačem ? 0,01 % ??
Až někdo napíše jinej init, kterej bude startovat ještě rychleji tak se zahodí systemd a přejde se na něj ?
Ach jo :( -
Ono to ma samozrejme vyznam, pokud je serverova infrastruktura "on demand". Ale taky nemam pocit, ze by rychlost bootu byla nejdulezitesi kriterium (na druhou stranu: pokud na ctyrjadre s kopcem pameti a rozumnym SSD neco bootuje do desktopu trebas minutu, tak to take neni pro init zrovna vyznamenani a uvazoval bych, cim ho nahradit).
-
Trident (neregistrovaný)
Pokud je on demand tak jsou to stejne virtualy,hw partisny, zalozni boardy ktery nahodis..
A hot standby ty muzou byt jen zmrzly at uz ve stavu snapshotu nekde na discich a nebo zmrzly primo v ram aby se nahodily rychle.To co popisujes ty je cold-standby nabeh systemu uplne z vypnuteho stavu a tam se stejne pocita s nakou dobou nabehu protoze cold zejo.
Takze opet je tu tradeoff komplexity vetsi nez co ziskam na rychlejsim bootu. Rychlejsi boot mohu zajistit snadno jiz alternativnimi a odladenymi metodami.
Velke zelezo je stejne nabehle stale protoze boot trva fakt dlouho.
-
j (neregistrovaný)
Oni ti lidi tady kolem pak ty sracky musej adminovat vime? A je jim zcela uprdele kdo to posral, je zajima to, ze (jak tu je vejs) musej v sobotu misto vlaleni se u kafe resit, ze je neco rozmrdany, pricemz je to tim, ze nefunguje nejakej binarni moloch. Pokud mi nefunguje script, tak si za par minut napisu vlastni - mozne neuniverzalni, mozna uplne blbej, ale bude fungovat. Kdyz nebude fungovat binarni moloch ... tak muzu leda psat stiznosti na nadrazi.
-
liquidwater (neregistrovaný)
http://techrights.org/2013/11/24/tpm-back-doors-patriot-act-etc/
Na podvrzeni kryptografii ktere umi NSA cracknout v realnem case nebo primo backdoory jasny dukaz primo neni, ale minimalne ta vzajemna nepopirana spoluprace, co je NSA zac a co vyplavalo na povrch o spolupraci na smirovani se softwarovymi giganty jako Microsoft, Oracle, Google, Facebook, Apple je alarmujici. Tezko uverit ze s nekym takovym maji jen formalni vztahy.
-
Robert Smol (neregistrovaný)
Tak zkusim zareagovat jen na ty lepsi casti.
Proc d-bus/d-dbus? Protoze je to schopny mechanismus pro IPC. Standardizovany IPC pro Linux chybi. Sice je na systemu spousta IPC, ale zadny z nich vam standardne nedokaze dat ty vveci navic (zaruceni doruceni zpravy, fronty, bezpecnost) v ucelene podobe.
V tom porovnani vychazi systemd absolutne nejlepe, namitate ze ma proprietarni implementace cron/at? Co vam brani bezet cron/at?
Minimalisticke to je dost, podivejte na zdrojove kody https://github.com/systemd/systemd/tree/master/src, zjistite, ze takto dobre oddelenne moduly a ciste napsany kod tezko jinde najdete.
Lennartovi mozna muzete vytknout zpusob komunikace, ale osobne mi prijde dost podobny tomu co dela Linus. Rozhodne bych se ale s Lennartem neprel o technickou implementaci (ten clovek se tomu doiopravdy uz x let venuje, problematiku zna velmi dobre). Navic systemd/k-dbus neni zalezitost pouze Lennarta .
Systemd nam ve Fedore jede nejakou dobou a sama spokojenost. Jeden krasny system na spravu systemu, jeden .service file pro vsechny distribuce. Nevim, ja osobne jsem velmi spokojeny.
s pozdravem
-
j (neregistrovaný)
Ve widlich mi taky nic nebrani si nainstalovat vlastni shell, vlastni browser, vlastni ... ale vazne nevim, proc mam kurwa v tom systemu mit ten deravej exploder, kterej nanic nepotrebuju ... zato kdyz se podela, tak mi jen zpusobuje problemy.
Tohle je naprosto PRESNE totez, navic to mrvi dalsi balicky, ktery se to snazi schramstnout a integrovat => klidne z nich vyhodi funcionalitu, kterou pouziva bambilion lidi, jen proto, ze to politicky nezapada do systemd.
Ale nekteri toto samo nedokazou a nedokazou pochopit. Potrebujes udev? Musis mit systemd. Potrebujes d-bus? Musis mit systemd .... podela se neco na systemd = nebude ti fungovat system, a to i v pripade, ze systemd nepouzivas primo.
ČLÁNKY DO MAILU