Új hozzászólás Aktív témák

• #28756 inf3rno nagyúr ivana #28745

  Új Válasz 2019-10-13 22:15:49 #28756

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  inf3rno

  nagyúr

  válasz ivana #28745 üzenetére

  "Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód, ami fent van a githubon." - Hát 4 éve még nem volt túl erős a lefedettsége, reméljük azóta javult. [link] Ha már szóba került, akkor inkább OpenRC-hez lenne értelme hasonlítani, az állítólag hasonló tudású rendszer: [link].

  Mindkettő fent van githubon. Beszéljenek a számok.

  OpenRC: [link]
  - 13k sor kód C-ben (összesen 21k sor adatfájlokkal)
  - 41 nyitott issue, 114 zárt, 6 alap issue label
  - 103 contributor, 52 watcher
  - 3k commit, az utolsó 2 hónapja
  - benchmark a cikkből 46.5 sec

  SystemD: [link]
  - 355k sor kód C-ben (összesen 650k sor adatfájlokkal)
  - 1143 nyitott issue, 4226 zárt, 165 issue label
  - 1185 contributor, 332 watcher
  - 42k commit, az utolsó 3 napja
  - benchmark a cikkből 43.5 sec

  355/13 = 27, tehát 27x annyi sor kód van a systemd-ben

  13k/(41+114) = 84, 355k/(1143+4226) = 66, durván 20%-al kevesebb sor kódra jut egy issue a systemd-nél, igazából engem meglepett, hogy csak ennyivel rosszabb

  13k/103 = 126, 355k/1185 = 300 sor kódra jut egy contributor
  13k/52 = 250, 355k/332 = 1069 sor kódra jut egy watcher
  300/126 = 2.4, 1069/250 = 4.3
  tehát 2.4x több munkát végez egy contributor, és arányaiban 4.3x annyi kód jut egy watcher-re a systemd-nél, bár az utóbbi csalóka, mert

  (46.5-43.5)/46.5 = 6.5%-al több idő a bootolás OpenRC-vel

  Nagyjából annyi a véleményem, mint eddig is, most vagy nagyon balfaszok a systemd fejlesztői és overengineered az egész, vagy a kód nagyrésze egyáltalán nem is az inittel foglalkozik, ha elfogadjuk, hogy az ő megközelítésükkel ugyanannyi kódból ki lehet hozni egy init rendszert, mint az openrc megközelítésével. Igazából meg lehet nézni még más init rendszereket is. SysVinit 8k sor, upstart 71k sor, mindkettő jóval elmarad a systemd-től, az upstart, ami legalább kicsit megközelíti kód mennyiségben.

  Az a fogalom, hogy "standard-nek mondható" nem létezik. Vagy szabványosítva van valami, vagy nincs. A szabvány készítés általában több éves folyamat, nem csak ilyen összeszórunk valamit, aztán jó lesz alapon megy.

  "Ez kb. minden fejlesztő több havi munkáját igényli, költsége millió $-ban mérhető. De valószínűleg a Debiannál sem két perc volt a váltás." - Pont ezért kellett volna valami normális init rendszerre áttérni, nem erre a szemétre. Mindenkinek kevesebb munkájába került volna egy moduláris init rendszerre való áttérés, mint egy ilyen monolitot beletákolni a disztrójukba, ahol minden mindennel összefügg. Sokan hoztak már ostoba döntéseket ilyen vagy olyan okból, elég csak megnézni a főpolgármester választás eredményeit pártpreferenciától függetlenül.

• #28749 sh4d0w félisten ivana #28745

  Új Válasz 2019-10-13 20:55:55 #28749

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sh4d0w

  félisten

  LOGOUT blog (1)

  válasz ivana #28745 üzenetére

  Sokat lehetne találgatni, hogy a Debian miért emelte be a systemd-t a rendszerbe, de az tényként kezelhető, hogy nagyjából pofán köpték magukat, amikor ezt megtették - szakítottak a KISS filozófiával, a POSIX kompatibilitással - és nincs kétségem afelől sem, hogy ezzel elindították a Linux világot egy proprietary irányba és már nem mások, mint a Red Hat szócsöve.

• #28747 Jester01 veterán ivana #28745

  Új Válasz 2019-10-13 19:48:50 #28747

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Jester01

  veterán

  válasz ivana #28745 üzenetére

  azért ha a spotify-on leállítom a zenét, hogy megnézzek egy youtube videót ne kelljen valahogy átadni, mert rohadtul nem fog menni normálisan a dolog.

  Megkockáztatom, hogy alsa-ban régebb óta van szoftveres keverés (dmix/dsnoop) mint amióta a pulse létezik. Normális rendszeren az az alapértelmezett és csak akkor van baj ha egy adott program konkrétan a hw eszközt kéri. De a legtöbb programban ez egyébként is konfigurálható. Ha meg nem, arra nem az a megoldás, hogy kitalálunk egy új hangrendszert amit minden programba külön implementálni kell hanem megjavítjuk azt az egy programot ami hülye volt. A spotify-t amúgy nem ismerem de esélyes hogy nem hülye és be lehet állítani melyik hangeszközt használja. A teljesség igénye nélkül a chrome, firefox, mplayer, xine, xbmc, wine, teamspeak, openal mind kiválóan működik alsa-val.

  Az egyetlen pulse szolgáltatás ami kicsit hiányzik az az alkalmazásspecifikus hangerőszabályzás de általában ezt tudják a programok maguk.

• #28746 bambano titán ivana #28745

  Új Válasz 2019-10-13 18:58:57 #28746

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  LOGOUT blog

  válasz ivana #28745 üzenetére

  "A klasszik BSD style init lényegében egy shell scriptet indít, esetleg több shell scriptet, rohadtul nem a stabilitás mintaképe.": értem, tehát az egy darab, ezer éve használt, debuggolt init shell szkript az instabil, a rakás systemd szkript meg stabil.

  kizártnak tartom, hogy magamévá tegyek egy ilyen véleményt systemd-től függetlenül.

  "Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód": ez csak annyit jelent, hogy a teszteset írók munkája se ér egy vödör csavart se.

  "service fájlt írni elég egyszerű.": és működő service fájlt?

  "a sysvinit buta, mint a franc": aki ért hozzá, az ezt a tényt pozitívumként kezeli, nem hátrányként. érdekes módon én mindent meg tudtam oldani vele triviálisan.

  "A gcc talán a legkomolyabb compiler jelenleg": melyik gcc? és miért nem az intel c fordítója a legkomolyabb?

Új hozzászólás Aktív témák