Názory k článku Ekonomická válka ve FOSS
-
ksd (neregistrovaný)
Jak vidno, pro některé už Poetteringův Operační Systém není jen softwarový projekt, ale spíš něco jako náboženská víra s odpovídajícím způsobem propagace a potíráním odpůrců. Jinak článek takhle prosycený demagogií, polopravdami a překrucováním reality se na rootu neobjevuje často. Asi vás mrzí, že jste tady dlouho neměli pořádný flamewar, ne?
-
Ondra Satai NekolaZlatý podporovatelProč by si třebas RH likvidoval dojnou krávu?
Mně přijde, že argumentace Pravdou spíš než pravdou je spíš záležitost systemd haterů, ale nečetl jsem samozřejmě všechno...
-
Ondra Satai NekolaZlatý podporovatel
Tak pokud zrovna relativne maly kus kodu, jako je systemd, vyvola trebas u SuSE zavislost takovou, ze nebudou schopni pripadne forknout... tak pak ma skutecne linuxovy ekosystem problem
-
rws (neregistrovaný)
Hehe, to je prave ten problem. Kdyby systemd byl "maly kus kodu", tak by se nikdo neohrazoval a proste by vse fungovalo jako s jinym SW. Kdo by chtel systemV, mel by systemV, kdo by chtel systemd, mel by systemd.
jenze systemd neni maly kus kodu, navic je to hlavni kus kodu, ze ktere se startuji jine kody, a navic spoustu projektu zacina vyzadovat pouze systemd a nic jineho.
Ano, systemd se da forknout, ale co by to jako potom melo delat? stejnou funkci jako systemV? to se nemusi nic forkovat, ale rovnou systemv pouzivat. Jenze oni programy nutne vyzaduji pro svuj beh systemd. A v distribuci uz nepujde vybrat, jestli chci systemv nebo systemd. Proto to taky vypada, ze systemd je vnucovan.
-
Ondra Satai NekolaZlatý podporovatel
Standardni odpoved je, ze jsou do toho hnane stvavou kampani imperialistickych central nebo tak neco.
-
Petr M (neregistrovaný)
To bych taky rád věděl.
Nejsem expert na boot se systemd, vlastně jsem boot řešil naposledy na jednom embedded systému nějakých šest let nazpátek. O rozdíl mezi systemd a initd jsem se aktivně nezajímal, proč taky, když s tím zatím nikdy nebyl problém. Vlastně vím jenom to, co vypadává z flame:
- systemd pochází od RH.
- systemd je špatný, protože pochází od RH.
- systemd je ještě horší, protože je to nástroj RH, jak zastavit otáčení Země.Aktivně jsem nehledal, čas je drahý na řešení každé blbosti, která mě osobně moc netrápí, ale je někde tabulka srovnání obou systémů bez nesmyslů typu "vymyslel to satan starý zlý chlupatý a smradlavý"? A seznámili se s ní všichni, kdo se toho flame účastní? Vidí do detailů? Prozuměli tomu dobře?
Vím, že každá změna znamená se něco učit a krátkodobě moc nepotěší, ale kdyby člověk o initu nic nevěděl a začínal se učit od nuly, který systém by byl výhodnější?
-
Ondra Satai NekolaZlatý podporovatel
Kdybys chtel zacit od nuly pouzivat, tak je to IMO prast jako uhod. Spustit neco nebo si napsat spoustedlo nejake servicy je v obou pripadech snadne.
Pokud bys chtel resit vnitrnosti, tak je urcite slozitejsi systemd.
-
Ondra Satai NekolaZlatý podporovatel
Ja si pamatuju, ze initd to hned zacal chytat zprava, zleva kvuli autorovi (a protoze to nebyla cesta Unixu). Jeste kdyz to byl ciste init.
Mne na systemd nektere veci vadi (binarni logy), ale celkove tu hysterii nechapu.
-
Petr M (neregistrovaný)
Říkám, neřešil jsem to. Takže fakt nevím. Funkce obojího je stejná. Pro začátečníka je to prý jedno. A použít se dá obojí. Fakt mě nenapadá nic jinýho, než přeučení na nový systém. Ale pozor, problémy s přeučením nemusí být ve složistosti systému, ale i v nechuti / lenosti něco udělat. Jinak fakt nevím. Proto se ptám.
Netýká se to (jenom) initu, ale docela obdivuju ty, co místo hodiny zkoušení nové věci věnují 10 hodin očerňování autorů a sprostýho nadávání.
-
"Funkce obojího je stejná."
Nevím, kdo vám tohle to řekl. Na to, zda je funkce obojího stejná si odpovězte následovně:
* Poběží systém s init a systemd stejně, když se v kernelu vypne cgroups?
* Poběží systém s init a systemd stejně, když neinstalujete dbus?(Odpověď, initu je celkem jedno, co děláte s kernelem. Systemd má naopak poměrně zásadní požadavky.)
* Kdy si naposledy init chtěl dostat něco do jádra?
(Odpověď: systemd, protože závisí na dbus tak si vymyslel, že chce kdbus do kernelu.)
A třeba jako třešničku na dortu si odpovězte, co má společného podsvícení displaye (systemd-backlight) a třeba já nevím sítí (systemd-networkd) a proč to vlastně musí být součástí initu.
-
Petr M (neregistrovaný)
Funkce obojího je stejná - spouštnění a konfigurace. Každý to ale dělá trochu jinak.
Postaru se to zapisuje <i>SetProperty(5)</i>
Ponovu se to zapisuje <i>Property = 5</i>Co mají společnýho? Třeba to, že
- obojí závisí na nějakým HW a po bootu je potřeba natáhnout ovladače
- na obojím můžou závidet nějací démoni (u sítě třeba automount, u podsvitu třeba něco ve styluRedShiftu) a systém by měl vědět, co je k dispozici
- Obojí může chctít nějaká aplikace nebo jiný balík konfigurovat. pokud je daný specifikací, kde a jak to změnit, je pro programátora jednodušší situace, než modifikovat pět různých typů skriptů podle výrobce, hledat v nějakým spustitelným souboru konkrétní kosntrukce,...Pokud se to spojí v seznamu ovladačů k zavedení a v seznamu dostupných modulů, nevidím v tom problém. Pokud ovladač backlightu posílá něco po management busu fyzické vrstvy Ethernetu, je to průšvih.
-
Netuším, zda jste četl můj komentář. Patrně ne.
Zkuste si zprovoznit systemd třeba na xBSD. Nezprovozníte. Autoři systemd samotní říkají o BSD nepěkné věci (Toy OS apod.). Nezajímá je POSIX (sám Lennart to psal), nezajímá je kompatibilita s ostatními unixy.
Není to jen "jiný styl" spouštění služeb a nastavování, jak jste tu několikrát napsal.
-
Petr M (neregistrovaný)
Ok, takže kompatibilita s úplně jiným systémem z pravěku... Tu já rád, učení se nových technik zdržuje. Ale někdy prostě není zbytí...
Fajn, buďme kompatibilní s prasítí, kde byli jenom prověření zaměstnanci firmy a zahoďme SSH. Máme přece Telnet...
Zahoďme HTTPS, přece jsou to jenom prolinkovaný stránky textu od vědecké autority, na co šifrovat? Je tam přece jenom hrstka slušných lidí,co se k tomu dostanou...
Jo, a abych nezapomněl na starý dobrý neprolomitelný TSL... To byl řev, když nedávno vyšlo doporučení ho zabít na serverech...
Pokud něco nevyhovuje dnešním požadavkům, je to potřeba řešit. A když se najde lepší řešení, tak je fajn ho využít (tím neříkám, kdetý init systém je lepší) a vychytat mu mouchy.
-
muf (neregistrovaný)
Ať se na to podívám z jakéhokoliv úhlu, vidím v případě xBSD velmi profesionálně a čistě vyvíjené efektivní systémy s téměř nepřekonatelnou stabilitou, bezpečností a výbornou dokumentací.
Jistě ne náhodou z nich čerpá Apple i Microsoft(BSD licence je prostě tak benevolentní, že jí nevadí ani jisté vykrádání např. implementace TCP/IP). Mimochodem běží třeba i v Sony Playstation nebo routerech Juniper.
Ani náhodou pravěk. Jen čistota, řád, profesionalita.
Nesmíte dát na řeči narcistního asáka z Hannoveru, který chce "měnit svět". -
Ondra Satai NekolaZlatý podporovatel
Tak alespon nemusis mit strach, porad tu mas alternativu, ne?
(Jinak co se tyka te stability, bezpecnosti... na FreeBSD jsem nenasel poradny ekvivalent pro GRSecurity nebo SELinux. Co se tyka ficur, tak AFAIK neni nic jako Docker. Ale pokud si vystacis s tim, co tam je, asi jsi za vodou a Linux te palit nemusi. Jinak nerad bych tu otviral flame BSD/Linux, jsem skutecne rad, ze BSDcka existuji a mam o nich celkem vysoke mine. Jenom nevidim vyhodu delat z Linuxu dalsi praunix stejne jako asi nema smysl roubovat do BSD vsechno z Linuxu.)
-
"Jinak co se tyka te stability, bezpecnosti... na FreeBSD jsem nenasel poradny ekvivalent pro GRSecurity nebo SELinux. Co se tyka ficur, tak AFAIK neni nic jako Docker."
Na obojí by se dal použít Jail. Není to sice úplně totéž (houska není rohlík, těsto je stejné), Jail je o hodně lepší chroot, což je ale Docker taky.
V době, kdy je na každou appku jedna virtuálka nemá grsecurity nebo selinux smysl. Bezpečnost stojí a padá na protokolu dané aplikace, nikoliv na tom, že se nedostane k datům (která tam stejně nejsou).
-
Je rozdíl mezi evolucí, revolucí a pučem.
To, že se zjistilo, že by bylo vhodné telnet povýšit mimo jiné o šifroví je evoluce. Umožňuje to totéž co původní řešení a něco navíc. A hlavně, kdo chce, může ono původní řešení dále používat. Tím, že nainstaluje sshd si nezablokujete telnet. Když chcete, můžete mít obojí.
Ad TSL asi jste chtěl napsal SSL. Za SSL existuje kompatibilní náhrada v podobě TLS. Pokud ale chcete provozovat SSL, opět vám nikdo nebrání.
Všimněte si, že předchozí evoluční kroky nijak nepostihly původní staré řešení. Stále ho můžete použít.
-
Ľubomír Mlích (neregistrovaný)
ale je někde tabulka srovnání obou systémů bez nesmyslů typu "vymyslel to satan starý zlý chlupatý a smradlavý"?
Nejsem si jist, zda splním všechny požadované podmínky, nicméně jedním z výsledků diskuze technické komise debianu, zda systemd nebo upstart, jsou následující dokumenty:
https://wiki.debian.org/Debate/initsystem/systemd
https://wiki.debian.org/Debate/initsystem/upstartDávám sem i odkaz na upstart, protože v daném dokumentu je uveden i pohled na to, v čem je upstart lepší než systemd.
-
Petr M (neregistrovaný)
Díky, konečně to chápu. Je to boj mezi příznivci spouštění procesu stylem "napřed udělej to, potom tohle a nakonec tamto" a "tady je seznam toho, co musí běžet, tohle jsou požadavky co proces chce a mašino, standardně se s tím popasuj". Takže v podstatě jako přechod mezi C a VHDL, odlišná filozofie a styl myšlení. To bez vášní prostě nejde.
-
muf (neregistrovaný)
Příliš to nechápete pravděpodobně proto, že vám Unix nikdy moc neříkal. To opravdu nesouvisí příliš s initem.
To, že někdo Unix nepochopil, tomu rozumím, ale co nechápu je to, že se někdo snaží unixový OS přeměnit v cosi jiného, když takový OS už dávno existuje v podobě produkce Microsoftu a existoval i dříve např. v podobě VMS. -
Jirka (neregistrovaný)
AFAIK si Linux na nějaký opravdový Unix nikdy nehrál. Být kompatibilní s Unixem mělo v začátcích Linuxu svůj smysl, ale IMHO to nikdy nebyl cíl, svatý grál Linuxu. Dnes už Linux Unix přerostl, je to nejpoužívanější systém na světě sám o sobě.
Držet kompatibilitou s ostatními systémy, aby byly aplikace skvěle portovatelné, je nádherná myšlenka, ale v praxi to znamená hodně snahy s minimálním efektem. Kompatibilita s BSD kernely byl hlavní argument proti systemd v Debianu. Když se Lennart zeptal na DebConfu v místnosti s několika sty vývojáři Debianu, kdo Debian na BSD kernelu používá, tak se nepřihlásil jediný, jediný (!) člověk.
-
muf (neregistrovaný)
Nikdy bych neřekl, že se někdy dožiju toho, že se na takovýchto webech a v takovýchto diskusích budou zcela vážně hlásat tyto názory. Ano, máte na ně právo, nikdo vám nebrání, ale podle mě prostě jste na špatném místě. :-(
Ale je fakt, že jsem se vždy děsil toho, co se bude dít, až jednou nastane na naše platformy invaze lidí, vychovaných na CP/M, MS-DOSu a Windows, případně staré VMS.
Ten způsob myšlení sem prostě nepatří a je vidět, že komunity kolem Linuxu byly od začátku svým způsobem slabé a příliš rozhádané na to, aby tomu efektivně bránily... -
Jirka (neregistrovaný)
Nevím, jestli jsem vzhledem k realitě dnešního linuxového světa na špatném místě. Problém je v tom, že v diskusích pořád někdo kříčí, že se musí dodržovat POSIX a kompatibilita s Unixem, ale když dojde na nálámí chleba, tak se zjistí, že to prostě nechce nikdo dělat. Např. o Gnome se pořád píše, jak je čím dál víc Linux-only, ale je to hlavně kvůli tomu, že kompatibilitě s BSD je ochotný se věnovat jeden člověk ze zhruba 1000, kteří přispívají do Gnome, takže podpora je taková, jakou ten jeden člověk zvládne. A že by mu ostatní házeli klacky pod nohy, to se říct nedá.
Pro mě není v případě OS dogma POSIX a Unix (tím nechci říct, že to pro mě nemá žádnou hodnotu), ale otevřený vývoj s otevřenými zdrojovými kódy. To je asi zásadní rozdíl mezi mou a vaší filozofií.
BTW na CP/M, MS-DOSu, Windows, ani VMS jsem nezačínal. Ano, hádáte správně, byl to starý dobrý Unix, ale tak nějak od přírody nejsem konzervativní a ani Unix a jeho principy nepovažuju za něco, co nebude nikdy překonané.
-
muf (neregistrovaný)
Váš problém je v tom, že chcete "překonávat" a inovovat pomocí principů, které s Unixem existují paralelně dlouhá léta a za tu dobu prokázaly spoustu nedostatků. Určitě i pár předností, a právě od toho tu ty platformy jsou, aby sloužily těm, kterým vyhovují.
Vy nechcete tvořit něco nového. Jen se snažíte roubovat poměrně staré věci do světa, který je s nimi nekompatibilní. Výsledkem budou různí kočkopsi, daleko horší než to co bylo na obou stranách před tím.
-
Karel (neregistrovaný)
Jste pragmatický. Jste tak ukrutně pragmatický, že se až divím, že jste nenavrhl Linux na desktopu zahodit a pohřbít, protože ho používá jen zanedbatelné množství kocových uživatelů.
A váš druhý odstavec odhaluje, v čem se lišíme. Vy chcete otevřený vývoj, já chci stabilní a odladěný systém, do kterého vidím.
-
zz_indigo (neregistrovaný)
To ze podporu pre BSD robi jeden clovek moze znamenat aj nieco ine ako ze o gnome na BSD nieje zaujem.
Cim je aplikacia napisana prenositelnejsie tym menej su potrebny ludia specializovany na dany posix/unix system. A pisat prenosne aplikacie nieje az taky problem jak sa zda.
-
rws (neregistrovaný)
Tak asi vsichni systemd nechteji, ze? Jinak bychom tady nevedli tuhle diskuzi. Jinak by nevznikaly boycot stranky. Jinak by lidi vazne nepremysleli o forku debianu.
Vetsine lidem (tem, co jsou proti systemd) by systemd ve skutecnosti vubec nevadil, kdyby na nem nebyla NUTNA zavislost jinych aplikaci. Problem je, ze hodne baliku zacina byt na systemd zavislych. Kdybych si mohl vzdy vybrat, jestli chci systemd nebo systemv, tak si pro servery vyberu systemv, kde si kazdy init.d script muzu prohlednout a pripadne prizpusobit, kdyz neco nechodi a pro pracovni stanici, kterou casto zapinam/vypinam bych si zvolil systemd, aby to rychlejc startovalo.
Jenze, kdyz budu nuceny pouzivat systemd a neco nepujde nastartovat, protoze nekde bude chyba, tak do te 1MB binarky (ani do tech zdrojaku) systemd se jednoduse nepodivam (protoze nejsem programator) a nezjistim, kde je chyba.
V systemv je to jednodussi. Systemv init je jednoduchy hlavni proces, ktery na zaklade jednoduche prehledne konfigurace v jednom souboru startuje par shell scriptu (/etc/init.d/rc) a par binarek (getty). Dalsi veci uz se startuji pomoci toho rc a ty init.d jsou take shell scripty. V systemv init neni nic, co by mohlo prestat fungovat (a pokud kdy bylo, tak uz to bylo za tech X let pouzivani opraveno).
Systemd je novy, jeste se to poradne neozkouselo, dela to oproti systemv init spoustu jinych veci, ktery se muzou pokazit (je to neco jako Gentoo, kde je spousta variability ohledne instalace balicku). Jedine, co muzu jako admin/uzivatel ridit, jsou systemd config soubory, kde rikam, co se ma spoustet, co to potrebuje. Ale co kdyz bude nekde v systemd chyba a bude to zlobit? Co udelam? Reportuju na systemd upstream a dostanu odpoved notabug/wontfix/cannotduplicate? To mi bude na nic.
Je to opravdu boj o svobodu, podobne jako BSD vs. GPL. GPL zarucuje plnou svobodu uzivatelum, ale nuti programatora davat zdrojovy kod. BSD dava plnou svobodu programatorum, ze si muzou rozhodnout, zda daji zdrojaky nebo ne, ale uzivatel tedy o svobodu "ziskat zdrojovy kod" prichazi.
U systemd vs. systemv je to podobne. Bud budeme chtit zachovat svobodu uzivatelu, aby si zvolil systemv, pak ale sebereme vyvojarum/balickarum svobodu zvolit si, jak a co budou podporovat (zda oba systemv a systemd nebo pouze systemd) a budeme je nutit podporovat oba systemy. Nebo se ted bere svoboda uzivatelum/administratorum zvolit si init system a jsou nuceni pouzivat systemd.
Proto hodne lidi systemd nema rado, protoze neni zamenitelny. Pokud neco funguje se systemd a pak to nefunguje s jinym init systemem. Pokud se pouzivaji rc a init.d scripty, tak je jedno, jaky system to spousti, jestli systemv, upstart (s nejakou init.d podporou) nebo systemd (s init.d podporou).
-
Petr M (neregistrovaný)
Takže kde je problém?
Hypoteticky, když se komunita dohodne (třeba 80% hlasů), že bude chtít u souboru v inodu atribut pro označení "hidden" pro uživatele, skupinu a ostatní a při té příežitosti upustí od tečky před souborem pro ty skrytý, někdo do bug reportu napíše "soubor s tečkou je vidět", co by měl dostat jako odpověď?
"Je to chyba, opravil jsem to revertnutím jádra"? "Není to chyba, soubory s tečkou měly automaticky nastaven atribut při migraci ze staršího systému a teď se podle konvence už půl roku nesmí jenom na základě tečky skrývat", nebo snad "Pošlu ti mailem fix, nahraj si ho do komplu a hlavně nikdy nepoužívej žádný update systému, ať si to nepřepíšeš"?
Jiná situace je v případě, že se soubor neskryje na disku přimontovaným po NFS na základě těch atributů...
A co se týká binárky, tak tam je poměrně jasno. Měla by dělat standardní věci - vzít si ze souboru ve standardním formátu informace o procesu a podle toho ho standardně spustit. Stejně pro aplikaci A, B i C. Když se někde chová nestandardně, tak místo skriptu zkontroluju data o procesu, jestli tam něco nechybí nebo nepřebývá. Nejste progamátor, tak by pro vás mělo být jednodušší zkontrolovat seznam něčeho, než sekvenci nějakých příkazů, dohledávat co který dělá,...
-
j (neregistrovaný)
Co nechapes na tom, ze systemd pozral trebas udev, a zacal ho mrvit k obrazu svymu? Co nechapes na tom, ze admini chteji textovej log, a kazdej navic jinej, pricemz v systemd proste dostanou binarni blob? Co nechapes na tom, ze script si spravi kazdej pepek vyskoc, kdezto s binarkou neudela nic? Co nechapes na tom, ze zadnem svepravnej clovek nespousti na stanici dhcp server? Natoz aby spoustel zcela libovolny sitovy sluzby pred startem firewallu?
-
Lael Ophir (neregistrovaný)
Ovšem na druhé straně:
- Initd je klubko skriptů, které se nedá používat pomocí API. Nejdou ani základní operace jako zjištění nainstalovaných deamonů, zjištění stavu deamonu, jeho nastartování a zastavení. Vám to jako adminovi asi může být jedno, protože API v životě neuvidíte, mě to jedno není.
- Initd neumožňuje ani zjistit jestli deamon běží. Obchází se to například pomocí signal files, ale ty nejsou spolehlivé (například když systém neočekávaně vypnete, signal file zůstane, takže deamon "běží"; ochrana číslem procesu v signal file není spolehlivá).
- Initd neposkytuje deamonům interface například pro jejich ukončení, takže se to implementuje jak se dá. Už jsem viděl i init skript, který se pomocí řádkového klienta připojoval k DB a posílal ji příkaz aby se ukončila. WTF?
- Initd prakticky neřeší závislosti.
- Initd skripty jsou klubko které si admini rádi přizpůsobují, i když mají jen startovat a zastavovat deamon. Jakýkoliv upgrade obsahující změnu init skriptu pak změny přepíše.
- Initd neřeší restart daemonu nebo jinou akci v případě neočekávaného ukončení daemonu.
- I unixová konkurence má lepší daemon management (nemluvě o Windows, které ho mají minimálně 19 let). Solaris má Service Management Facility, Apple má launchd (který je "standardně" zplácaný ve stylu Applu, ale na API se alespoň dá dostat). -
Petr M (neregistrovaný)
Co nechápeš na tom, že SD je jiný, ale ne horší?
Vem si takový proces. Co představuje z pohledu jádra? Záznam v tabulce, kde je hlavní vlákno, vlastník, přidělená paměť,... a nějaká standardní část jádra s tím standardním způsobem pracuje. Nepíše se to pro každý proces extra.
Co je z pohledu systému to vlákno? BInární blob maplněný prioritou, statusem, vlastníkem, pointerem na instrukci, kde se tomu sebere procesor při multitaskingu, obrazem stack pointeru,.. obsluhovaným standardníma funkcema v jádře bez rozdílu. To zpracování a multiplex se neprogramuje pro každý vlákno extra.
Co je zavedení modulu / spuštění procesu? Z pohledu jednoho spuštění skriptu (čti extra programu) pro činnost, která se dělá na X modulech stejně, náchylná na chyby. Z pohledu druhýho nějaký popis, kde je napsáno, že požaduje běh toho a toho modulu, že vlastnost X má mít hodnotu Y,... a definovaným kódem, kde část ověří běh požadovaných modulů (případně je standardní cestou automaticky spustí, aniž bych musel dopisovat závislosti do skriptů), část se stará o to, aby pomocí nějaké funkce GetProperty(X) byla proměnná v procesu naplněna hodnotou Y. Obojí funguje, ale je tam jiná náchylnost k chybám, jiná údržba...
Co je ale zásadní, pokud dostanu při psaní SW požadavek " ovládací prvek funkce x se zobazí, pokud běží démon y, který s touto funkcí pracuje", budou dvě možnosti spuštění systému (skriptem, kde není korektní způsob, jak běh démona rozeznat (jeden dodavatel použije mutex v paměti, další něso píše do nějakýho souboru, v nové verzi se změní text v mutexu,...) a druhý na to má API funkci Is DaemonRunning() ), pochopitelně to napřed vyzkouším tam, kde je to jednodušší. Pokud se autoři distra domluví, že ten jednodušší systém bude preferovaný, protože jim ulehčí práci, bude postupně ubývat aplikací pro ten první. Až to dojde do bodu, že ten první zhyne na nedostatek kompatibilních aplikací. U initd je to teď ve fázi, kdy se nikomu z pogramátorů nechce dělat to pro dva systémy (stojí to čas a peníze) a nechce si komplikovat život s podporou obojího, když v jednom někde není jednoznačná specifikace, jak to udělat. Když chce někdo initd, může si to do balíků klíďo píďo dopsat, zdrojáky má k dispozici. Pokud nechce / neumí, musí holt vzít za vděk tím, co udělali jiní.
BInární log je taku jenom jedna z možností. Textpový je čitelnější, ale jak se do něj díváte? Napíšete příkaz a soubor logu. Jak se podíváte do binárního? Napíšete příkaz a soubor logu. Kde je tady sakra rozdíl v tom, jaký je formát dat toho souboru?
U binárního odpadá konverze do textu přímo v systému - ušetří se čas při pádu a není potřeba konvertovat data do logu, na který se nikdo nepodívá. Do stejně velkýho souboru na disku se vleze víc záznamů (char[16] vs. longint pro čas - 75% úspora bez ztráty dat apod.). Když chci vlastní pohled na data (třeba formát času v sekundách do konce století), stačí si přebuildovat prohlížecí nástroj a změnit formátovací string na jednom řádku bez toho, že bych psal nějakou novou utilitu, která bude parsovat text a pak ho zpracovávat... Možnost rovnou tu rutinu jednoduše upravit na výstup třeba v .html apod.
Nesmíš se na to dívat tak pesimisticky. Kdyby byl systemd blbost, tak by se nechytl. Asi hodně lidem dává něco, co starý systém neměl.
-
j (neregistrovaný)
Od kdy nejaky api zjisti, jestli demon bezi? Jo aha, tys widle vzivote nevidel zejo ... lo lool looooll ....
Zrovna dneska sem resil, ze "sluzba bezi" ... ale jaksi ... nefunguje, protoze ... jo aha, ona nebezi, prestoze si api mysli ze bezi, a proto ji pochopitelne nedovoli nastartovat, protoze startovat bezici sluzbu je prece volovina, a stopnout ji nejde, protoze sluzba neodpovi ... lol.
Mno du preinstalot tuxe na widle, tam zabira aspon restart HW ... a kdyz nic jinyho, tak se muzu uspokojit tim, ze co znamena "neznama chyba #A32456786" nevi ani M$. A logy to projistotu nema zadny, takze ani nema smysl v nich neco hledat.
-
Petr M (neregistrovaný)
Pokud je to rozumně*) definováno a korektně**) implementováno na straně systému i démona, tak zjistí. Když to korektně nefunguje, dá se reportovat bug a řešit.
Horší je situace, kdy neexistuje standardní metoda, kterou by šlo takovou věc zjistit. Funguje snad jenom ústní dohoda s autorem, že máš zkusit něakou fintu... a když na tuhle dohodu původní autor zapomene nebo ve vývoji pokračuje někdo jiný, tak jsi se svou aplikací v háji.
*) Rozumně znamená s ověřováním za běhu, např. watchdogem, ne jenom uložení flagu při startu.
**) Autor musí vědět, co dělá. Podle jasné a jednoznačné dokumentace. -
Lael Ophir (neregistrovaný)
API zjistí, jestli je služba nastartovaná. Samozřejmě neřekne jestli ta služba dělá co má. Jinými slovy víte že DB engine je nastartovaný, ale nevíte jestli opravdu odpovídá na requesty. Přesně jako na Unixech.
Ad "sluzba bezi" ... ale jaksi ... nefunguje, protoze ... a stopnout ji nejde, protoze sluzba neodpovi - to máte nějakou chybu v dané službě (opět podobně jako se to občas stává na Unixech). BTW často je to vidět u služeb zbastlených přes prunsrv.exe nebo srvany.exe, kde executable není ve skutečnosti není služba. Workaround je sestřelit proces, pak je možné službu znovu nastartovat.
To co popisujete je popis chyby servisu, a tedy dost nezajímavé. Já psal o tom, že initd neposkytuje API pro 1. zjištění jestli je daemon nainstalovaný, 2. jeho spuštění, 3. jeho zastavení.
-
Lael Ophir (neregistrovaný)
Ad co znamena "neznama chyba #A32456786" nevi ani M$ - pokud jde o standardní Win32 chybu, tak to samozřejmě MS ví. A jako admin byste to měl vědět i vy. Ale člověk nesmí mít na některé adminy přehnaná očekávání, že? :)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx
http://blogs.msdn.com/b/alexdan/archive/2008/02/28/looking-up-error-codes-with-err-exe.aspx -
Petr M (neregistrovaný)
To mě vždycky zajímalo, jak se může někdo vydrápat na nějakou vlivnou pozici, všechny urazit a naštvat a ustát to. Jeden blbec vždycky mává x lidma, přitom kdyby se domluvili proti němu, tak nemá šanci.
Bohužel, mám jenom technický vzdělání a to odpověď na autoritu blbce ani na blbost stáda nedává...
-
Ľubomír Mlích (neregistrovaný)
Imho se autor nestaví na žádnou ze stran a je objektivní. Říká, že když se někdo chová určitým způsobem, může to pro (jakýkoli) FOSS projekt znamenat problém a doporučuje způsob, jak reagovat, aby se dopady problému co nejvíce snížily.
Respektive protože Ubuntu integruje systemd, tak by šlo říct, že autor se staví na stranu systemd. Nicméně není mi jasné, z které části textu plyne, že autor "myslí" článek pouze za jednu ze dvou stran. Rád si přečtu objasnění.
-
zz_indigo (neregistrovaný)
Ono sa to da vysvetlit rozne.
- Je fakt tak dobry a pre ine veci tak dolezity ze mu to toleruju.
- Niekdo moc vysoko nanho stavil a priznat si ze je to zly krok je preneho tazsie ako tvarit sa ze blbci su ty ostatny.
- Patri do medzi medzi ludi o ktorych je dokument "ryba smrdi od hlavy" https://www.youtube.com/watch?v=zjQw-lRWrRk -
No samozrejme o likvidaciu dojnej kravy nejde, ale snaham o obfuskaciu celej zalezitosti by som sa nedivil.
Pokial ma pamat neklame, RH sa nestiti (alebo v minulosti nestitil) niektore svoje patche do kernelu obfuskovat, alebo publikovat v takej forme, aby ich neslo aplikovat na vanilla kernely lavou zadnou. Vobec by som sa preto ani nedivil aby bolo v ich zaujme vytvorit systemd "opened behind glass curtain" v zmysle, ze je to sice opensource, ale na to aby clovek pochopil, co sa vovnutri deje, spotrebuje neumerne vela casu vzhladom k tomu, co potrebuje urobit.
V modeli, kde Linux zaraba peniaze to dava zmysel, pretoze RH ani tak nie je poskytovatel produktov, ako poskytovatel sluzieb. A cim viac ho je potreba, tym viac sluzieb moze poskytnut. Dojna krava, ktoru moze dojit kazdy je pekne nahovno, lebo kto potrebuje mlieko ju proste podoji. Ale dojna krava, ktoru dojim len ja, je zlata bana, pretoze kto potrebuje mlieko, pride za mnou! A presne o toto tu ide. Strategia ako zmenit kazdym dojitelnu kravu na kravu, ktoru dojim len ja.
Co mi na systemd nejde vobec do hlavy je to, ze sa takyto brutalne nestabilny, nedokonceny a v mnoho ohladoch nedomysleny, potazmo vobec nenavrhnuty, ale z hliny povstanuvsi system proste nasadil. Nahodou som mal vcera moznost s nim obcovat a divim sa vobec ze distribucie toto nasadzuju. U mna bola jedna z prvych veci ku ktorym som sa dogoogloval pri hladani nejakej zakladnej dokumentacie ubuntia workarounds wiki page pre systemd a hned za nou zoznam problemov so systemd v zuze a archu. Nasadit nieco taketo nestabilne by si za normalnych okolnosti nikto, komu zalezi na stabilite jeho riesenia, nedovolil, takze nejake politicke tlaky na presadenie systemd budu.
-
Ondra Satai NekolaZlatý podporovatel
Na nestability jsem nenarazil, ale nejsem schopen tvrdit, ze nejsou.
Ale obvinit systemd z toho, ze je nenavrhnuty, to chce vazne odvahu. Na rozdil trebas od SysV initu nebo BSD initu si nekdo sednul, zamyslel se, jak to udelat poradne, a pak neco implementoval. (To same bude asi launchd od Apple, jine "moderni" inity jsem nepouzival.)
-
... není ani třeba navážet se do systemd, takový firefox si vystačí sám a komunita jeho haterů se zřejmě úspěšně rozrůstá
http://www.root.cz/zpravicky/firefox-34-vypina-sslv3-a-prinasi-hello/ -
Tomas Z (neregistrovaný)
A teď si představme jiný projekt, pro jednoduchost třeba komunitní výrobu perpetua mobile (ok, to je hraniční, ale nic lepšího mne nenapadá).
Stadium 1: Hromadné nadšení (projekt zachrání svět). Pár brblalů ale šíří na kanálech zvěsti, že to celé je kravina a že to celé mohl ve dvacátém století (jsou to starší lidi, zjevně trochu zaseklí) vymyslet jen i...t. Vzhledem k tomu, že se často jedná o lidi s určitou reputací, jsou docela slyšet
Stadium 2: Objevují se malicherné posměšky fanouškům projektu urážející jejich vzdělání. Někteří to chápou jako útok na svoji inteligenci. Někteří se nechají přesvědčit, že to kravina opravdu je.
Stadium 3: Postupně i přispěvatelé zjišťují, že ani o tři milimetry delší trubička z duralu problém nefunkce neřeší a odcházejí.
A teď mi řekněte, jak tenhle scénář zejména ve stadiích 1. a 2. (úmyslně neříkám kroky, protože to implikuje vůli nebo koordinaci) rozpoznat od toho v článku. Buďte si jistí, že vzhledem k lidské nátuře budou i u tohohle útoky ad hominem, a že komunikační a zkušenostní bariéra způsobí, že technické poznámky budou příznivci vnímány jako remcání nad nepodstatnými problémy které se rychle vyřeší.
-
Petr M (neregistrovaný)
Opravdová kravina se obvykle dá rozeznat, třeba to perpetuum mobile na základě zákona zachování energie. Stačí poslouchat hlasy "Je to nesmysl, protože A+B < C a ten rozdíl nijak nekompenzujete" místo "Je to blbost, protože XY je ... a s knížkou o fyzice se setkal, jenom když ho s ní spolužák fláknul po palici."
A nadšencům ať už z jednoho, nebo druhýho tábora, se zásadně oponuje otázkou. "Máš lepší řešení tohoto dílčího problému?" "Jak jsi se vyrovnal s faktem, že kompresní algoritmus zmenší data maximálně o X% a přenos po téhle lince by potřeboval kompresi o X+5%?" - to ho buďto donutí se nad problémem zamyslet, nebo začne sprostě nadávat. V prvním případě je možnost přehodnotit projekt nebo konstruktivně hledat řešení, v tom druhým nestojí za to se jeho komentáři zabývat a plýtvat časem, který je nedostatkovým zbožím a dá se využít líp.
Bohužel, pro většinu lidí je jednodušší porozumět iracionální vulgaritě, než racionálně sestavené diferenciální rovnici.
-
Existují lidé, kteří atakují fyziky (třeba učitele na SŠ, VŠ), a posílají návrhy na překonání rychlosti světla. Většinou je to nějaký návrh mechanické součástky (dejme tomu kladkostroj, soustava ozubených kol), která v nějakém poměru zrychluje vstup. Dejme tomu poměr 1:10^9. Pokud na vstupu, říkají oni, budu mít rychlost 1 m/s, tak na výstupu musím mít rychlost 10^9 m/s a tedy překonal jsem rychlost světla. Dokonce více než 3x.
A tito lidé argumentují podobně, jako zastánci určitých FOSS projektů. (Nebudu jmenovat.) "Když tvrdíte, že rychlost světla nejde překovat, ukažte mi na KONKRÉTNÍ kolečko, které to brzdí a já vám dokážu, že je v pořádku." Jo, neustále se snaží zaměřovat na detail, jednotlivá kolečka. Jenže ten stroj je špatně jako CELEK. Vychází z kompletně špatného předpokladu, že v=v1+v2. Nelze ukázat na jednu kladku. Jedna kladka s násobícím poměrem 1:5 bude ve všech měřeních vycházet zcela v pořádku. Ti lidé to nechtějí pochopit a za měsíc pošlou další návrh.
Stejně tak zastánci jistých software. Problém často není v jedné binárce, v jedné proceduře. Problém je v nepochopení celku. Proto je zcela nesmyslné požadovat (to je zase "zbraň" na druhé straně války) bugreport. Tyto bugreporty jsou potom označovány jako WONTFIX, NOTABUG apod s tím, že jsou příliš obecné a neřeší jednu věc.
-
Journald ukládá logy do binárních souborů. Zastánci původního řešení argumentují tím, že:
* Textové logy přečtete kdykoliv čímkoliv. (Stačí cat, less, jakýkoliv textový editor.) Binární logy pouze pomocí příslušné aplikace.)
* Binární logy se mohou pokazit a už se nepřečtou vůbec. Z textových logů vždy něco vytáhnete. (Upřímně, tento argument mi přijde takový ... hromada dat se ukládá binárně a není žádný důvod k poškození.)
Mě se binární logy nelíbí hlavně z prvního důvodu. Jenže, to by nesměl být LP, aby nepokryl i ten druhý. Na stroji za UPS (ostatně ani výpadek napájení nebyl), který nikdy nespadl, nikdy ani náznak nestability čehokoliv (včetně journald) , jsem zjistitl, že některé funkce (jako například journalctl --list-bo...) nefungují dle představ. Po kontrole pomocí journactl --verify jsem zjistil, že cca 50% souborů s logy je poškozených (opakuji, na kompletně zdravém stroji). Pomohlo jejich smazání. Ale tím jsem přišel o ty záznamy, které jsem si chtěl prohlédnout (tím jsem zjistil výše popsaný problém).
LP na to reagoval takto:
https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3
Není to můj bugreport, stejný problém má hromada dalších lidí. Pro Lennarta je poškozování logů zkrátka zcela normální jev, nebude to řešit, je to váš problém.
Poznámka: Zcenzuroval jsem argument --list-něco, protože spam filter root.cz argument programu ze sbírky systemd vyhodnotil jako spam (možná je chytřejší než my).
-
muf (neregistrovaný)
To je filosofie, kterou vyznává i řada fanoušků nejmenované velké sw firmy: "Že to občas dělá něco, co nelze deterministicky popsat nebo reprodukovat, je normální. Že je to třeba restartovat při výskytu problému, je také normální. Že je to tak zamotané, vše souvisí se vším, takže už ani autoři občas netuší, co se uvnitř děje, to je také normální. Máte špatný hardware, upgradujte...."
V podobném duchu je vyvíjen systemd.
-
j (neregistrovaný)
Jop a to je jeden z miliardy duvodu, proc se to pouzivat neda, da se rict, ze celkem pididuvod (logy prece nejsou data, bezne je nanic nepotrebujes ...).
BTW: Prave kdyz se nejaky ten binarni format podela, jdu se podivat do toho textovyho logu, kde doufam, ze najdu nejakou pricinu. Jiste, muzu obnovit backup, a doufat, ze to (podobne jako ve widlich) byla proste nejaka haluz, a pobezi to vesele dal.
-
Tomas Z. (neregistrovaný)
O zakonu zachovani energie samozrejme vime a ten neporusujeme. Nase perpetuum funguje na principu odebirani energie z pracovni materie. Jo, a navic se da pouzit i jako lednicka. Jeste nam to uplne nefunguje, tady potrebujeme malinko zvysit efektivitu, mas napad jak to resit? Jak nejde, zkus byt trochu konstruktivni.
Jinymi slovy, i jak psal nize Heron, clovek opravdu nema cas a chut probirat bod po bodu proc je neco spatne, zvlast kdyz podobnymi debatami v minulosti prosel, a druhy zakon je proste prirodni zakon a dokazat se moc neda, proste zatim to vypada ze plati.
Ton a charakter argumentace neco naznacuje, ale kdyby to bylo tak jednoduche a lide diskutovali slusne a k veci a drzeli se argumentu, a kdyby lide nebrali utok na nazor/srdecni produkt jako utok na sebe tak tu nemame skandaly okolo globalniho oteplovani ani Velikovskeho aferu.
-
strepty (neregistrovaný)
Ale to je normalny postup, tak isto ako vo vede. Ked zacal hlasat Einstein svoje teorie tiez vela vedcov odporovalo. Tazko povedat ci si vtedy dovolili utocit na inteligenciu oponenta, ale nepriamo to tak vyznievalo.
Este poznamka, na perpetu mobile neverim ale keby niekto chcel pokorit rychlost svetla, to by som mozno prispel :-). -
Pan Hribik (neregistrovaný)
Treba si uvedomit, ze vacsina ludi je hlupa, mensina je inteligentna. Ak dame niekde demokraticku volbu, t.j. nechame zvolit vacsinu (demokracia = vlada vacsiny) tak na 95% to bude hlupost. Na druhu stranu, ak nechame aby par vychytralych hajzlikov ovladalo zvysok stada, dopadneme mozno este horsie.
-
Přezdívka (neregistrovaný)
Při vší úctě, tenhle článek je neskutečná snůška blábolů. Průjem nepodložených dojmů a obecného blábolení a zřejmě snaha racionalizovat si ne úplně sluníčkové události poslední doby. Už jenom použití zájmena my o lecčem napovídá, jak z nějaké sekty nebo politické strany. Nevím na čem autor jede nebo jestli je lehce retardovaný, ale jeho naivita i z jiných blogpostů přímo čiší. Autor-překladatel p. Mlích je zřejmě z podobného soudku, alespoň podle jeho zdejších článků. Nechci nikomu zazlívat, že se řídí spíš podle emocí než rozumem, jen varuju před scestím ke kterým to logicky vede a vždy vedlo.
Komentář Marka Clarka věci jasně, bez emocí a z nadhledu shrnuje a pod něj bych se klidně podepsal. Těm co si věci zjednodušují na černobílé my vs. oni se ale asi moc zamlouvat nebude.
-
-
Ľubomír Mlích (neregistrovaný)
Při vší úctě, pane Přezdívko, tento komentář je neskutečná snůška blábolů. Průjem nepodložených dojmů a obecného blábolení... :-) Bohužel mi není jasné, co jste tím chtěl říct nebo změnit - jaký je cíl Vašeho komentáře?
Když napíšu svůj subjektivní názor na věc:
Velmi nepříjemně působí, že článek mezi řádky tvrdí, že takové komentáře, jako píšete vy, nejsou v některých případech výplodem náhodných kolemjdoucích, ale organizovaná činnost s nekalým záměrem. Tohle tvrzení je nepodložené, na druhou stranu článek Michaela Halla nikoho konkrétního neobviňuje, nikoho neposílá k soudu - spekulace se objevují v komentářích níže pod článkem díky době vydání a pracovní pozici autora.Autor ale nehodlá nikomu nic prokazovat, pouze nabízí svůj názor, jak se proti takovým ať už organizovaným nebo neorganizovaným útokům bránit. Berte nebo ne.
Můžete mít jiný názor, dělat to jinak, myslet si, že takové problémy nikdo nemá a nikoho ten článek nezajímá :) Šéfredaktor rootu, však má jiný názor - myslí si, že to lidi zajímá, tak to zvěřejnil :) - no a já si jdu dál spokojeně sjíždět heroin :))
-
Ľubomír Mlích (neregistrovaný)
Ale jo, překladatel je tak hloupý :)
Ba co víc, ještě hloupější.A dnes večer bude činit pokání, aby dosáhl patřičné úrovně pokory, a aby se nic takového nikdy více nemohlo stát :-))
Otázka do pranice. Bude nutné znát těch 250 000 řádek kódu? :) Nestačí znát architekturu systému, konvence psaní kódu a vědět kam sáhnout, když chci něco upravit? Zná některý z vývojářů systemd do detailu těch 250 000 řádek kódu? Umí je odříkat ve dvě v noci, když je probudíte ze spaní? :)
-
sid (neregistrovaný)
Myslim, ze sa zbytocne namahate.99% ludi co pisu tieto veci nechape trivialne veci nie ze v programovani ale obecne v inite. Cest vynimkam s konkretnymi technickymi dovodmi preco takto teda nie. Uplne zvlastna kapitola su ludia na krizovej vyprave ako muf pod zastavou unix filozofie o jednoduchosti a tak dalej.
-
Santiago (neregistrovaný)
No, prijde mi, ze cely clanek je navod, jak se uzavrit proti jakekoliv vnejsi kritice. Negativni komentare odsuzovat (jako 'demonizace projektu'), zatimco pozitivni vychvalovat. Vyborny zpusob, jak posilit groupthink a vybudovat sektu.
Uz jenom premisa z uvodu: "Když se objeví projekt, který někteří lidé nemají rádi, ale nemohou (nebo nechtějí) s ním soutěžit, příliš často se uchylují k sérii útoků, kterými projekt systematicky zničí."
Priis casto? Vazne? O zadnou 'ekonomickou valku' nejde. V FOSS pro to je naprosto minimalni duvod. FOSS projekty, s kterym Tvrdit, ze je nejaky FOSS projekt takto 've valecnem oblezeni', je absurdni a je to IMHO jen manipulace na stmeleni vlastni komunity (BTW, tato manipulace je mnohokrat historicky proverena).
A ze se objevuji ruzne 'hate' komentare a (malo verohodne) vyzvy k nasili? Na to neni treba nejake spiknuti, staci prosta hra velkych cisel. Pokud nekdo mirne nastve miliony lidi, tak jedno procento emocne nevyrovnanych ho za to bude nenavidet a z nich jedno procento silne vysinutych navic psat vyzvy k nasili a hned tu mame stovky vyzev k nasili. To ovsem nic nerika o te majorite milionu lehce nastvanych. Tohle je problem u vsech verejne cinnych osob, staci se podivat na komentare o politicich, aktivistech ci korporacich.
-
Ľubomír Mlích (neregistrovaný)
No, prijde mi, ze cely clanek je navod, jak se uzavrit proti jakekoliv vnejsi kritice.
- na to je již odpovězeno v přeložených komentářích na konci článkuTvrdit, ze je nejaky FOSS projekt takto 've valecnem oblezeni', je absurdni
Autor článku neukazuje na žádný konkrétní projekt, nicméně v komentářích je jich pár vyjmenovaných. Samozřejmě se těžko prokazuje, že někdo úmyslně organizuje takovýto útok, zvlášť když jsou "útočníci" přesvědčení o své pravdě a dělají to, protože si myslí, že to je správné. Ale nevylučoval bych, že to je možné. Třeba náš pan prezident věří, že účel světí prostředky (Budeme říkat, že je v pořádku, když Čína obsadí Tibet, když z toho budeme mít zakázky pro české firmy do Číny), tak organizovat něco takové by pro něj určitě nebyl velký problém.Tohle je problem u vsech verejne cinnych osob, staci se podivat na komentare o politicich, aktivistech ci korporacich.
Článek neříká, že takové chování existuje pouze FOSS. Věřím že i jinde lze použít v článku popsané metody obrany. -
j (neregistrovaný)
Projekt, ktery nikomu nic nerozbiji, je kazdemu zcela u zadnice, takze nemuze mit z principu zadne odpurce. Tak maximalne nekdo muze kritizovat, ze to nedela neco, co by melo, nebo dela neco, co by nemelo, ale ve finale to nemusi pouzivat.
Az zacne calc scitat 1+1=3, protoze autor dosel k nazoru, ze je to tak naprosto dokonale spravne, tak ho proste prestanu pouzivat a najdu si neco jineho. Pokud mi ale bez calcu nenabootujue system, pujdu autorovi s radosti slapnout do usmevu.
-
kolemjdoucí (neregistrovaný)
upřímně, já nástup systemd vůbec neprožíval, nezajímal se...hmm místo service systemctl - ok, ale když musím kvůli té sračce kopírovat rsyncem pdfka na jiný stroj, abych si mohl cokoliv vytisknout, tak se to pak nastřádá...(+ gnome-hell)
Btw. off-topic, ví někdo jak moc je Centos 7 kopií RHEL 7? protože jestli je rhel 7 takový zabugovaný nepoužitelný krám jako centos 7, tak očekávám davový odliv zákazníků redhatu :)
(musím to už přeinstalovat něčím jiným, ale tak moooooc mě to netěší......)
-
My sme ostali na CentOS6 a ziaden problem s tym nemame. Navyse firmy ako HP este len teraz zacinaju dodavat softver pre RHEL6 k niektorym svojim produktom, cize este dobre 3 az 4 roky nebude ziaden dovod menit. A dovtedy mozno pride RHEL8, ktory opat bude pouzitelny.
Pripadne to dokope cloveka k nastudovaniu gentoo, ktore mi pride ako spravny evolucny krok po napevno nabalickovanych distrach.
-
Ondra Satai NekolaZlatý podporovatel
Dovolim si poznamenat, ze po Vistach prisly sedmy, coz bylo to same, jen poradne odladene. A byl to megauspech.
-
Nechajme sa prekvapit. Ja by som bol len rad, lebo CentOS 5 a 6 mam naozaj rad. Aj ked neistota, ktora prisla s CentOS 7 nas prinutila viac dbat na prenositelnost aplikacii, ktore vyvijame. Sice to je niekedy narocne, ale mozno nakoniec z toho budeme profitovat o par rokov.
Vsetko zle je nakoniec na nieco dobre :)
-
LEdoian (neregistrovaný)
Mě mnohem více nemile překvapilo (abych byl slušný), že můžu (minimálně v Archlinuxu ve výchozím nastavení) z libovolného uživatele vypnout systém i přesto, že je přihlášen kdokoliv jiný (včetně roota)
$ reboot
User test is logged in on tty2.
User root is logged in on tty3.
Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl reboot -i'.
$ systemctl reboot -i
[reboot]
Ano, reboot systému, na kterém je přihlášený root, z běžného uživatele.
A když jsem si tu hlášku chtěl uložit??
$ reboot > /tmp/cokoliv
[reboot]
Jako vážně?? (root byl stále přihlášen)
Kdysi jsem také přechod na systemd nijak neřešil, ale tohle mě docela dostává. -
Lael Ophir (neregistrovaný)
Klientské Windows může vypnout člen skupiny Administrators, Backup Operators, Power Users a Users (což je celkem pochopitelné - nechcete aby mohl stroj vypínat jen admin). Na serverech jsou to Administrators, Backup Operators a Power Users. V doméně to samozřejmě záleží na nastavení v Group Policy.
BTW jde o práva k API. User může kdykoliv zavolat funkce API ExitWindowsEx() nebo InitiateSystemShutdownEx(), ale pokud nemá právo, tak smůla. Srovnejte s tradiční situací na Unixech: root smí všechno, nikdo jiný shutdown provést nesmí, uživatel volá utilitu s nastavením SUID, a API k dispozici není (utility interně požívají nestandardní syscally).
-
Ondra Satai NekolaZlatý podporovatel
Funguje to jenom lokalne. Navic tim parametrem rikas, ze vis, co delas.
Vzdalene to nefunguje a lokalni uzivatele stejne mohou restartovat i jinak, protoze kdo ma k masine fyzicky pristup, to je proste pan.
-
Petr M (neregistrovaný)
Ok, řekněme, že je admin patla s heslem na lístku u monitoru. Ty zjistíš, že se jeho jménem přihlásil na SSH kdoví kdo jako root a chceš sestřelit systém, aby se kdoví kdo nedostal k datům. A tahle featura by nebyla... Nebo se root zapomene odhlásit a ty nemůžeš vypnout mašinu...
Přepínačem říkáš, že víš, co děláš a je to na tvoje riziko.
-
Ondra Satai NekolaZlatý podporovatel
Tohle je stejne jenom akademicka. Funguje to pro lidi, co sedi u toho pocitace fyzicky. Ti, kdyz ho chteji restartovat, ho mohou restartovat systemd nesystemd. Protoze kdo ma fyzicky pristup, to je proste pan.
