Linux has lost its way

Flame

http://changelog.complete.org/archives/9299-has-modern-linux-lost-its-w…

  • 14052 megtekintés

( cheeky v | 2015. 02. 10., k – 09:24 )

Már megint a systemd...
Kár, hogy ha valaki aktív, és hangos, akkor átveheti az irányítást akkor is, ha baromság, amit mond. :(
De erre számtalan példát láttunk már máshol is.

( uid_4656 v | 2015. 02. 10., k – 14:08 )

Igazából nem az a baj ezekkel az új csodákkal, mint a systemd meg a NetworkManager meg a firewalld meg ilyenek, hogy önmagukban rosszak, hanem az, hogy az emberek nem ismerik őket. A szoftverek készítése igazából 9% tervezés, 1% kódolás és 90% nem-túl-informatikai tevékenység, mint pl. reklámozás, oktatás, dokumentáció... És azok, akik ezeket az új programokat készítették, nem nagyon értenek a 90%-hoz. (Egyébként pl. én sem, de a hiányt látom.)

Nekem az sokkal fontosabb, h vmi biztonságos, kiforrott, kezelhető legyen, mintsem, h új.

Mondjuk ezzel a hozzáállással elég nehéz fejlődni.

Értsd: ha MINDENKI úgy áll hozzá, ahogy te, akkor senki nem fog kipróbálni semmi újdonságot, következésképp minden mindig újdonság marad, amit nem kerriggenésricsi talált ki... BTW, systemd esetében 4 éve kap éles, elterjedt tesztet, akkor tette defaulttá a Fedora.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Én a systemd és társai esetén, azt látom, hogy szeretnének mindent egy helyről "iranyitani", egy helyre bezsufolni. Sajnos még nem fordítottam, kellő időt a megismerése, szóval fix me. Nekem az elsőre a Solarison lévő svc-t juttatja eszembe, vagy a MacOS X-en lévő launchd-t. Az, azért mutat valamit, hogy a RedHat csak most rakta bele a vállalati disztribuciojaba. Ergo, tanulni kell.
Biztonsági hiba meg lehet most is benne, meg 10 év múlva is.

Mindhárom meglátásod igaz:
1) irányítani, egy eszközből, konzisztensen - hogy pl. garantáltan ugyanúgy induljon el egy process, függetlenül attól, hogy parancssorból systemctl-el indítottad, függőségként indult vagy pl. időzítő miatt. pl. egy monit-nak egész más elképzelése van arról, hogy mit jelent az, hogy elindítasz egy szolgáltatást, a service-nek szintén egész más elképzelése van, mint a /etc/init.d/foo -t hívogató adminnak [gyakorlatilag a service csak próbálja kitakarítani a környezetet] stb. És persze minden ilyen meghívási mód külön-külön kód, mind a maga sebezhetőségeivel. (* amúgy tényleg van egy határ, ami már WTF kategóriás, de azok többnyire a systemd ernyőprojekt részei és nem magának a systemd-nek. pl. nézz meg egy openSUSE-t, akik systemd-znek ugyan, de az ernyőprojektek cuccokat [pl. ntp kliens] nem nagyon használják)
2) Az svc-re és launchd-re azért emlékeztethet, mert mindkettő (bevallottan) inspirálta
3) A biztonsági hiba 10 év múlva is az, viszont ha erre hivatkozva soha, senki nem vált, akkor 10 év múlva is benne lesz az a biztonsági hiba.

RH-nál ez leginkább a release cycle-nek köszönhető, a RHEL6-nál ugye még sehol nem volt (Fedora 12 alapú, a systemd meg 15-től jelent meg).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Mondjuk, arra előbb elkezd gyanakodni a zember, hogy "már megint a registry szopat", mint arra, hogy "ez csak az ODM lehet, mert amúgy minden jónak látszik". Most ez nem is tudom, hogy jó vagy rossz - talán inkább az utóbbi, mert tovább tart az izolálási fázés és olyan áldozatot találni (ha egyáltalán), aki hasonló csapdába esett, hát még olyat, aki ki is mászott belőle.
Meg a registrynek legalább van böngészője/editora - elismerve, hogy ezt bizony olykor csesztetni kell. Az ODM diszkrétebb.

Az irónia jogos, de azért ne felejtsük, hogy volt a történelemben jópár kísérlet (atombomba, állatok honosítása más földrészeken), amik aztán katasztrófába fulladtak, mert megjósolhatatlan következmények közül bejött valamelyik. Vakon kísérletezni olyan dologgal, ami 0 idő alatt elpusztíthatja a világot, az azért tényleg lehet veszélyes is. És ugye vannak az elméletek, amiket a kísérletek alátámasztanak, vagy cáfolnak. De a lényeg, hogy biztosan senki sem tudja garantálni 100%-ra, hogy nem lesz katasztrófa az egyik ütköztetés vége. És a Föld pusztulását még 0.0000001% eséllyel se biztos, hogy kéne reszkírozni. Én nem ellenzem az LHCt, egyébként is, ha tényleg felrobban a föld, fekete lyuk stb. abból úgysem veszünk észre semmit :D Csak mondom, megértem, akinek vannak kételyei. Egy csomó tudósban semmi alázat nincs, nyíltan ateisták, és magukat képzelik istennek. Puszta tényt írtam.

" De a lényeg, hogy biztosan senki sem tudja garantálni 100%-ra, hogy nem lesz katasztrófa az egyik ütköztetés vége."
Azt sem tudja semmi sem garantálni, hogy te nem alakulsz-e át a következő másodpercben csirkévé. A fizika törvényei megengedik, de csillagászatian kicsi valószínűséget adnak neki. Ugyanígy itt is, a kísérlet nagyon alacsony valószínűséggel vezet oda, hogy elpusztul a világ. Annak nagyobb a valószínűsége, hogy te csirke leszel holnap reggel.
Az is lehet, hogy azzal, hogy leütöd a billentyűzeteden az Entert, elpusztítod a Földet. Ennek is van egy eléggé alacsony valószínűsége, de nem 0. Sosem 0.

Az LHC t nem tudom, de kísérleti atomrobbantásnál volt már, hogy az elméletbe hiba csúszott, és kicsit nagyobbat szólt a pukkanás, mint amire számítottak. Konkrétan erre gondolok: http://hu.wikipedia.org/wiki/Castle_Bravo

"A Bravo teszt 15 megatonnás hozama két és félszer nagyobb volt, mint a várt érték. Ennek oka egy elméleti hibában keresendő. A bomba tervezői azt feltételezték, hogy a lítium-deuteridben egyedül a lítium 6-os izotópja reaktív, és a lítium mennyiség 60%-át kitevő 7-es tömegszámú izotópot inertnek vélték." blabla. Ez ha jól értelmezem a cikkben a számított robbanás háromszorosa lett, ami elég durva hiba. De mi lett volna, ha pl. 1000x ese? Én úgy gondolom probléma, ha valaki okosabbnak (mindenhatónak?) hiszi magát, mint amilyen.

"biztosan senki sem tudja garantálni 100%-ra, hogy nem lesz katasztrófa az egyik ütköztetés vége."

Itt igazolódik, hogy a modern ember elég matematikát tanult ahhoz, hogy tudja, hogy matematikailag a 6*10^-23 nem nulla.
És az is, hogy nem tanult elég fizikát ahhoz, hogy tudja, hogy mégis nulla.

Ez mindent visz:

Egy csomó tudósban semmi alázat nincs, nyíltan ateisták, és magukat képzelik istennek.

A sok hitetlen, aki "érdemtelenül" kapott elismerést, bár hogy ezek közül melyik képzelte magát istennek, nem tudom. Nekem a "teista tudós" egy oxymoron. Bár tudom, hogy voltak és vannak ilyenek is.

Ave, Saabi.

Az alázat hiányára szerettem volna kihegyezni, nem arra, hogy ateista, vagy nem. Egyébként sok ismert, neves tudós istenhívő, vallásos, és ettől azért még tudósok (bár szerinted kizáró). De mégegyszer mondom, nem ezen volt a hangsúly. Egy ateista tudósban is lehet(ne) annyi alázat, hogy elfogadja a tudása határait, és ez nem mindig van meg.

Kb. Newton óta az ateista tudósnak van egy príma alázatpótlója: a falszifikációból és kísérleti megismételhetőségből álló hagyományőrző játék*, ami által a közeli és távoli kollégái nem kötelesek inkvizíció terhe mellett azt vallani, amit ő, bármekkora nagy tudósnak tartják vagy tartja magát.

Akár te is bekopogtathatsz az LHC kapuján a hírrel, hogy láttad Schrödinger fekete macskáját egy ciánkapszulával átszaladni egy kétrésen, ami a nálad lévő számításaid szerint nem jó jel.

Addig is óvakodj a DVD-írástól, nehogy a lézersugár belépési pontján valami rossz süljön ki!

*A nemateisták speciális tudósféléjének nincs olyan pechje, hogy a bizonyítás terhét viselnie kellene. Ők ugyan nem istenek, de nagy alázattal pont tudják isten gondolatait: hogy utálja a buzikat; hogy bírja a hitetlenek torkát elvágókat; hogy fals dinócsontokat ásott el a mi próbatételünkre az 5000 éve teremtett anyaföldbe; hogy nem nézné jó szemmel, ha nem születnének éhezésre ítélt gyerekek egy bűnös gumidarab miatt; hogy fényt kell enni, mert ami az ibolyának elég, az embernek is elég; vagy hogy a vérátömlesztés bűn.
Birtokában vannak e tudásnak, és viszik, mint a mentős a rovarirtós pogácsát.

"kísérleti megismételhetőségből álló hagyományőrző játék"

Egy kísérletet akkor is meg lehet ismételni, ha a hozzá fűzött tudományos elmélet hamis. A tudomány fejlődése nem is áll másból, mint egy-egy hamis elmélet lecserélése egy igazra vagy részben igazra, esetleg egy újabb hamisra. :)

Ettől függetlenül élek a gyanúperrel, hogy az iráni atomprogram akkor is a világról alkotott mai téves képünket jelentő számításokon alapszik, ha - és ez borítékolható - a résztvevők nem ateisták.
Hogy aztán ez a részvétel mennyire tekinthető a fentiek szerint alázatosabbnak, mint ateista atom- és rakétatudósé az megérne egy misét, csak legyen, aki erről kész misézni.

A Linux valójában mindig is kísérleti rendszer volt, és a bazaar fejlesztési modell és a "release early, release often" open source mantra elhozta az egyik legnagyobb faszságot, ami létezik és az éles kereskedelmi rendszerek ellen szól: az örökös beta állapotú szoftvereket.

Az éles kereskedelmi rendszerek futhanak éles kereskedelmi oprendszereken (akár RHEL, akár Windows Server). A Linux bleeding edge meg hadd bohóckodjon ahogy akar.

Azaz: az éles kereskedelmi rendszereknek lehet teher a folyamatosan változó környezet, de közben az OSS fejlődése rengeteg új lehetőséget nyit meg, amikkel más, komolytalan projectek örömmel élnek. Ez a modell visszafelé kompatibilis, hiszen nem muszáj követni a változásokat, ld pl RHEL ELS. Ellenben az, hogy semmin ne változtassunk mert "így volt, így lesz!", az semmiképp nem kompatibilis előrefelé. Nincs más út, csak előre.

Igen, ráadásul a RHEL6-ból van 32 bites (2020-ig bőven jó a támogatás), a retek7 meg csak 64 bitre jött ki - igen, tudom, de sajnos vannak még olyan esetek, amikor nem opció, hogy 64 biten fusson minden. A nagyobbik probléma az, hogy a retek7 ahogy kijött, feature/csomag szinten úgy marad hosszú ideig, ami azért más szempontból nem igazán jó dolog...

A systemd-re váltás nagyon sok dolgot borít, nagyon sok területen változtat a rendszer működésén, amit nem biztos, hogy szeretnék, pláne nem úgy, hogy alternatív megoldás nuku, eszi, nem eszi, nem kap mást. Nagyon sok csomag esetén nincs abból gond, hogy a régi verzió pecselgetésével megy a rendszer, de esély sincs arra, hogy frissebbet támogatott módon használjak például rsyslog-ból.
Tudom, hogy a RHEL6-ból van 32 bites - viszont ha ismerkedni akar valaki a retekhetessel, akkor nyasgem, csak 64 bites van. (Ilyen alapon a retek8 már csak ipv6-ot fog támogatni, az ipv4 csak külön reszeléssel lesz életre kelthető...)

És tényleg nincs otthon, nyugodtan bactatható gépem, amin 64 bites OS lenne. Mert az esetek 9x%-ában nincs rá szükségem.
Régi a hardver, de bőven elég - és minden működik, még az ősrégi tunerkártya, az USB-soros adapter, meg minden egyéb és nem tervezek beruházni 100E ft-os nagyságrendben újabb motyóba (illetve amibe igen, az nem erre a célra kell).

A munkahelyen van rá lehetőség, de ha rajtam múlik, retek7 még egy darabig nem lesz éles üzemben, mert nem ad annyi újat, amennyi ráfordítás kéne ahhoz, hogy a RHEL5-RHEL6 vonalnak megfelelő tudás összeálljon a csapatban. Ráadásul erre a "tanuljuk meg magas szinten"-re bőséges szabadon felhasználható idő is kéne, az meg idén eléggé hiánycikk lesz...

Értem. Tehát igazából nincs időd foglalkozni vele. Igazából nem tervezed, hogy upgradelnél, mert nincs rá igény. Igazából, ha lenne rá valós igény, lenne, ahol megnézd.

De azért az RH a hülye, mert mégsem adott ki 32 bitest, hogy ha a nem levő időd alatt ki akarnád próbálni az otthoni szutykodon, akkor megtehesd abban a 10 percben :)

Olvasni és felfogni,a mit olvastál nem megy... Otthon nem fogom szétqrni a tökéletesen működő gépemet csak azért, mert a retek7 csak 64 biten létezik.
A munkahelyen meg ha majd kell, és lesz rá elegendő idő, akkor összelapátolunk egy-két-több retekhetes gépet, és elkezdem újratanulni azokat a dolgokat, amik változtak. Vagy nekilátok AIX-et avagy Windows-t tanulni, ez sem fog sokkal több új dolgot jelenteni :-D

Ha játszani és tanulni kell, akkor pölö a Vultr.com oldalon befizetsz $5 pénzt, a megfelelő kuponkóddal kapsz $20 pénzt és ebből a $25 pénzből egészen pontosan 2500 órán át tudsz újratanulni változott dolgokat, vagyis a beletett $5 okán óránként 0,2 centbe kerül majd a tanulásod. Ha csak munkaidőben foglalkoznál ezzel a tanulással, akkor ez a $25 nagyjából másfél évig kitart.

Aki ezek után arra fogja a lustaságát, hogy sokba kerül vagy nincs lehetősége, az nem is akar tanulni...

Szerintem én felfogtam:

"- igen, tudom, de sajnos vannak még olyan esetek, amikor nem opció, hogy 64 biten fusson minden"

"Tudom, hogy a RHEL6-ból van 32 bites - viszont ha ismerkedni akar valaki a retekhetessel, akkor nyasgem, csak 64 bites van. (Ilyen alapon a retek8 már csak ipv6-ot fog támogatni, az ipv4 csak külön reszeléssel lesz életre kelthető...)"

Majd kiderült, hogy igazából ha tényleg szükséged lenne a retek7re, akkor a munkahelyeden, ott, ahol erre szükség van, természetesen egyáltalán nem probléma, hogy 64 bit, hiszen mint minden normális ilyen helyen, erre rendelkezésre fog állni mind az idő, mind az infrastruktúra, [szerk: gondolom] ráadásul az esetek döntő többségében egyébként is fog kelleni a 64 bit, mert gondolom ott is van két marék javaban írt szar, ami kevésbé buli a 32bit+PAE kombóval, ellenben memót meg kérne).

Ott probléma -- vagyis ott olyan eset -- hogy te valamilyen vélt vagy valós saját igényed miatt otthon még mindig 32 bitet használsz, mondván, hogy nem kell a 64 (és gyanús, hogy hw-d egyébként lenne hozzá, az meg látszik, hogy mégiscsak lenne rá szükség :)), és így nem tudod könnyen kipróbálni, mert lenne vele egy kis dolgod. Namost azért ugye érzed, hogy ez az eset kevésbé támaszt alá egy olyan business caset, ami miatt akár csak a 32bites fordítás áramköltségét érdemes lenne kifizetni a RH-nak.

Az infrastruktúra rendelkezésre áll, sőt gyakorlatilag nincs is 32 bites gép - viszont idő a retek7 újdonságainak készségszintű (éles üzemeltetéshez szükséges) elsajátítására nem biztos, hogy lesz. Az, hogy mi éri meg, és mi nem retekéknek, az jó kérdés - az biztos, hogy egy 32 bites build nem csak villanyszámlában jelentkezik, pláne, ha 10+ évig kell ócska verziókat toldozni-foltozni, miközben lehet, hogy a kibocsátás után nem sokkal az eredeti fejlesztőnél kiesik a támogatott verziók közül az, amit a retek beemelt az aktuális főverzióba. Nem várom el, hogy legyen 32 bites retek7, de hogy erős váltást csinált most ezzel a cég, az egyszer biztos - igaz az a terület, ahol 32 bit van csak, az nem piac számukra, úgyhogy valahol érthető a hozzáállásuk.

Szóval tulajdonképp eljutottunk odáig, hogy egyetértünk :) Nem nyasgem, hanem maximum egyéni szociális probléma ;)

Egyébként épp amiatt, hogy szerver oldalon a 64bit már elég rég alap, nem gondolom, hogy ezzel csinálták volna az erős váltást. Akinek kell a 32bit, az valószínűleg legszívesebben betonba öntené a cuccot, eszébe sincs migrálni, marad 6oson, addigra meg csak kihal. Vagy úgymarad, ami addig jó úgy, azzal olyan komoly baj nem lehet patchek nélkül se.

1.
Nyugi, nem lesz hiánycikk a tanulásra szánható idő, sőt, várhatóan most pár hónapig tanulni _kell_ majd mindenféléket, igen, többek között Centos7/RHEL7-et is.

2. Tegyük fel, hogy egy új, RHEL-en futó rendszert akarsz építeni, és abban a szerencsés helyzetben vagy, hogy az üzlet meghatározta a várható élettartamát is: 2016-tól 2026-ig fog működni. Melyik RHEL-t tennéd ez alá a rendszer alá?

1. Hiszem, ha látom, de legyen igazad :)
2. Ebben az esetben nincs más hátra, mint előre - viszont ebben az esetben gyorsan előszedem a "milyen ütemezéssel hajítsuk ki a RHEL5-öket" munkacímmel ellátott sillabuszt, mert két főverziónál többet élesben támogatni nem biztos, hogy kéne hosszabb távon (azaz 2017-ig, ameddig a RHEL5 még valamennyire supportált a RH részéről).

Ezért kellenek új dolgok: szépen rájövünk, mik a régi rendszer korlátai, és ahelyett, hogy tákolnánk a régit, megcsináljuk rendesen.

Vagy kiderül, hogy egy rakás szar az éppen aktuális csodaúj szupercucc és megy a süllyesztőbe a devfs mellé a kocka-történelemkönyvekben.

Nekem pl. a devfs úgy maradt ki az életemből, ahogy volt.

2.4. kernelt talán 2.4.27-nél (?) hagytam el / amikor még nem volt , vagy lehet hogy experimentalként, de nem fordítottam le sose /, azután 2.6.18 volt a következő, amikor a devfs-t már kis vágták és sóval be is hintették a helyét képletesen szólva.

A jessie-re való frissités még odébb van...
Addig még sok víz lefolyik.

U.I: Emlékszik még valaki pl. a reiserfs-re ? :-))

Ezeket csak azért mondom, hogy a sok újdonságvadászatnál érdemes lenne néhány szót szólni azokról a néhai újdonságokról amik aztán a süllyesztőben végezték...

----------------

Persze én a másik véglet vagyok, asztali gépen LILO boot managerrel, és ext2/ext3-as filerendszerekkel. :-))

Vagy itt van pl. a LIRC. Az istennek nem akar menni a jó kis régi tunerkártyával, mióta beledolgozták a kernelbe.

Viszont a 6 éve megtervezett gányolási, tákolási szisztémával még ma is működik némi downgrade-el megspékelve.

Ami működik azt azért nem kellene elrontani...
És ezt nem csak az informatika területére értem egyébként.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Az, hogy ha valami működik, és nem kéne elrontani, az odaáig igaz is, hogy ha mindenhol régi komponenseket használsz (régi kernel, régi LILO, régi minden), akkor valóban működni fog.
A driverek, meg minden kód tele van a külső rendszerek hibáinak workaroundjával (rengetegszer kellett utolsó utáni pillanatban, kiadás előtt workaroundot csinálnom, csak azért, mert a másik fél lusta volt kijavítani a hibáját a megbeszélt módon, a rendszernek meg mennie kell). Azonban nem hordozhatunk magunkkal workaroundokat ezer évig (nálunk általában a következő release-ben helyre lett téve a dolog, és a saját workaroundunkat eltávolítottuk a kódból, mert a másik fél javította azt, amit kell).

Igen, tudom, hogy, hogy a hardver/firmware nem tartja be a specifikációt, emiatt persze a drivereknek kéne ezer évig magukkal cipelni minden egyes hibás hardver workaroundját, mivel a hardvert nem lehet lecserélni csak úgy.
Ennek azért megálljt kellene tudni parancsolni, el kell fogadni, hogy egy idő után nem feltétlenül fog működni a hardvered az újabb szoftverekkel.
Van, hogy olcsóbb hardvert cserélni, mint a szoftver workaroundokat cipelgetni magunkkal.
Ha nagyon kell neked a tunerkártya támogatása, akkor:
a) megfizeted, hogy valaki támogassa ezt neked
b) mivel a Linux open source, implementálod magad.

Vannak lehetőségeid.

hogy ha mindenhol régi komponenseket használsz (régi kernel, régi LILO, régi minden), akkor valóban működni fog.

Nem minden régi, új a hardver, új (?) a kernel (3.2.x), a LILO az nem tudom hányas verzió, ami a wheezyben van.
Sz'al azér' ne túlozzunk, hogy csak régi ócska szarjaim vannak. :-DD

Azonban nem hordozhatunk magunkkal workaroundokat ezer évig

A hardverek mindig is hibásak lesznek.

Workaround mindig kellett, csak mindig más miatt.
És megsúgom jövőre is kell majd, meg két év múlva is.

Sőt amikor a temetésünkön a pap valamilyen jövőbeli tabletről / okosszemüvegről olvassa majd a halotti misét, a tablet/okosszemüveg driverjei is tele lesznek workaroundokkal. :-))

És a BIOS-ok "minőségéről" inkább ne is beszéljünk...

emiatt persze a drivereknek kéne ezer évig magukkal cipelni minden egyes hibás hardver workaroundját,

Ez kétségtelen, de ez egy ilyen kaotikus világ. Ez van.
A driver, mint afféle meghajtóprogram egyébként erre (is) való.

Az eszközt működtesse, ha az eszköznek valamilyen hibája van, lehetőség szerint a hibás működést valamilyen módon kerülje el.
(workaround).

Másik opció, hogy driverfrissítés helyett lakcímre küldenek
doksit meg anyagot, legközelebbi barkácsbolt címét,
aztán javítsa meg a user a szarját. :-DDD

Ha nem vasárnap van, meg nem Magyarország, akkor lehet hogy lesz is egy még a közelben. :-DD

És a garancialevelet is saját magának kitöltheti. :-DD

Van, hogy olcsóbb hardvert cserélni, mint a szoftver workaroundokat cipelgetni magunkkal.

Az újban is ugyanúgy kell majd valamilyen workaround csak más miatt, ha a vásárlás után még nem, majd vásárlás után egy évvel...
Akkor meg nemtökmind1 ?

b) mivel a Linux open source, implementálod magad.

Igen ennyi előnyöm van. backportolom , kigányolom, downgradelem adott esetben.

-----------------
-----------------

De hogy a konkrét példában kicsit elmélyüljünk:

De az a nyamvadt lirc_gpio modul még is ki a jó istennek a szemét bántotta 6 évvel ezelőtt? Nézzük csak mi is történt ?

Nézzük a kernel doksit:

Az a röhely tudod a konkrét példánál maradva, hogy azért szedték ki, mert hogy a kernelben úgy is lesz remote control támogatás.

Előre közölték, hogy hát ez nem támogat mindent, amit a lirc, mert alapokról újraírják. És vagy az ir-kbd-i2c, vagy az ir-kbd-gpio-t kell használni.

"ir-kbd-gpio and ir-kbd-i2c don't support all cards lirc supports
(yet), mainly for the reason that the code of lirc_i2c and lirc_gpio
was very confusing and I decided to basically start over from scratch."

Na most ez az info, amit itt olvasol, ez 5 évvel ezelőtti kernelben kb. ugyanígy nézett ki, csak közben 5 év eltelt. :-))

ir-kbd-gpio lehet hogy már nincs is amúgy / franc tudja /, ez mondjuk nem kell, hogy feltétlenül zavarjon..

És aki eldöntötte, hogy feltalálja a spanyolviaszt, lehet hogy már nem is foglalkozik vele - a doksi legalábbis biztosan nem frissített -, nem tudom név szerint kinek a nagy ötlete volt...

Közben ezt a bizonyos kernelbeli ir-remote-control részleget nem egyszer, jó párszor újraírták, aztán bevették inkább a lirc-et végül a nagy újratervezgetések után.

Ugye az egész azért indult, mert a lirc_i2c és a lirc_gpio kódja "very confusing" volt, aztán a nagy újratervezések után bekerült a lirc a kernelbe és kész. bravó !

A dologban az a komikus, hogy a lirc_gpio időközben kikerült magából a lirc-ből, mert a kernelbeli sok újratervezés során egyszercsak nem fordult le többé,
mivel az alapját képező bttv cuccok egy részét kiszórták, hogy "obsolete" (!!!), a kutya sem használja - és a lircesek elunták az utángányolást.

Amúgy a kernelben a bttv támogatja a tunerkártyát továbbra is, a lirc csak a távirányítós részhez kell. :-))

Ha anno nem kezdték volna el újratervezést, hanem bevették volna a lirc-et mindenestül, még a mai napig benne lenne a gpio és nem kéne utángányolnom.

Most már igen gyorsan végzek a gányolással nem arról van szó, mert van benne rutinom 6 éve csinálom :-)), de valamilyen szinten szánalmas azért, hogy erre van szükség.

Mert anno 6 éve feltalálták a spanyolviaszt és befuccsolt a nagy ötlet.

Nem elfelejtve persze, hogy itt legalább megvan az esélyem hogy működésre bírjam akármilyen módon, mert ópenszósz, nem mint windows alatt,
ahol már bő évtizede 3rd gányolás volt csak a tunerre amennyire tudom, távirányítóra meg semmi.

Szóval én felhasználói oldalról nem vagyok igazán oda egyes fejlesztők állandó megújhodás utáni vágyáért...

Ennyit szerettem volna kihozni a történetből.
Ami működik azt azért nem kellene elrontani.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Jóvan gabu értem én a provokációt / hízhat a májad haha, egészségedre. :-D /,
de ha valami a linuxban szar, akkor
nem elhallgatni kell,
hanem be kell vallani hogy hát ez tényleg szar,
és mit lehet tenni ellene.

Ezt a fajta állandó megújhodási kényszert szvsz kicsit vissza kellene csapni egy konszolidáltabb formába, és lehet sokan másképpen állnának a linuxhoz is.

Ha egyedül vagyok a véleményemmel, akkor egyedül vagyok és kész. Ha többen leszünk, akkor majd lesz valami előbb/utóbb...
vagy nem...

---------

Amúgy szvsz minden rendszernek megvannak a saját kissé/vagy nem kissé komikus betegségei.

--------
Pl.:

Csak neked hogy röhöghess :-DD

A kis netbookon asus előtelepített OEM win7 van / meg is hagytam, mert lustaság mindenek előtt /
annak is megvannak a rigolyái.

Pl. IE 11-et nem lehet rá telepíteni, mert a Segoui akármilyen szimbolumok 2729094-es frissítése megakasztja.

Fent volt a frissítés, akkor az IE 11 telepítő leállt / neutral package installation failed /. windows community megoldás, szedd le 272094-et szedd le IE9-et, aztán majd felmegy., mert ebből a 2729094-ből van valami v2-es verzió akármilyen okból.

Hát nem ment fel. Error code 9c57.
win community tévedett,
ua. gyártótól ua. böngésző csak nem képzeled hogy telepíthető a csodaablakokra. :-DD

Sőt, a 2729094-et eltávolítás után nem lehet még egyszer feltenni , error code 8000490 vagy mi.
Lehet hogy egy órája még fent volt, hát most nem teszed vissza. ;-)
Ez ilyen durcás frissítés, ha egyszer leszeded ott b* meg, nem rakod vissza még egyszer, pláne nem a v2-es verziót. :-DD

IE11 installer persze ekkor már közlékenyebb:
hogy nem kisöreg, amíg a 2729094 nincs fent, addig nincs IE11, mert ez a segoui update symbol olyan kurva fontos,
hogy anélkül nincs élet a világban. :-DD

Ígyjárás. :-DD szerencse hogy van más böngésző IE-n kívül.

Szóval nem egy dráma, de azért ez is szánalmas a maga módján.
Meg röhelyes is persze.

Windows community másik megoldása amúgy w7 starter upgrade install mód lett volna, mert az sfc /scannow persze mindent a legnagyobb rendben talált. :-DD

Amit majd biztos végrehajtok egy gyárilag félrekúrt "segoui symbol update" miatt mert időmilliomos vagyok... :-DD

Már ha egyáltalán végre lehetne hajtani, mert a 32 gigás SSD rendszermeghajtón maradó 4-5 Gbyte szabad hely nem biztos, hogy elég lenne a telepítőnek erre a kis akcióra. ;-)

Szóval a lényeg, hogy más rendszerben is vannak kapitális elbaszások...Ez nem linux specifikus.

Az IT egy ilyen világ. sosem lesz tökéletes.

Mindig lesz workaround, mindig elkurnak valamit valahol,
egyénileg dől el,
ki melyik rendszer melyik aktuális rigolyájával tud együtt élni.

---------

ecerűencsak nempróbáltad ki mind!!!

Tény és való más rendszert, (*bsd, macos) nem próbáltam,
én már nem tanulok meg új rendszereket / motiváció teljes hiánya /, egyszerű r=1-es user vagyok, semmi több.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Elbeszéltek egymás mellett :) Egyfelől persze hogy kell, hogy ki legyen gyomlálva csomó obsoleted vacak, másfelől viszont nem lenne baj, ha erre csak akkor kerülne sor, ha már az új kód tisztességesen teszi a dolgát minden olyan feature-el, amit a régi tudott. Persze nyilván nem árt néha a kényszerítő erő, hogy az újat használjuk, mert hát tetszik vagy sem, a tesztkörnyezet itt ilyen, az mi vagyunk :)
Engem is bosszant pl a bluez fejlesztése, ahol jelenleg pl az új 5-ös sorozat már pulseaudiot igényel ahhoz hogy megszólaltasson egy bt fülest. De legalább egyelőre nem ütközik komolyabb akadályba a régit használni helyette.

És az új motyó a 30-40 év alatt megoldott problémák helyett hoz újabbakat, miket meg kell oldani a "fejlődés érdekében".
A régit sokan nem tudták/akarták megérteni, megtanulni, átlátni (kifejezetten igaz ez a linux terjesztésekbe kerülő csomagok tákolóira), meg szépen lehet e-pélót lengetni, miközben az extra feature-ök extra sz0pást hoznak rengeteg más területen.

Ezzel nem is lenne baj, és engem sem zavarna a systemd, ha nem kényszerítenének a használatára.
Azért az open source-ban lehet azt mondani, hogy elmegy az erőforrás a sok párhuzamos projektre, de az legalább megadja a választás lehetőségét.
A systemd és társai pedig egy full integrált rendszert képzelnek el, amiben nincs meg a választás lehetősége. Ez a bajom, nem az, hogy van systemd.
Legyen! De legyen alternatíva is.
Ha az az alternatíva előnye, hogy azt ismerjük, az is előny. Majd aztán felnő egy generáció, aki már nem ismeri és (talán) a systemd-t fogja használni. Vagy valami egészen mást...

Nem kényszerítenek a használatára. Senki nem kényszerít. Open source, ha valami nem tetszik, megcsinálja valaki. Ne már, hogy a systemd fejlesztőinek kéne egy másik, párhuzamos rendszert is csinálniuk, azoknak, akik nem szeretik a systemd-t?
Ha sok embert zavar a systemd, lesz helyette más.

Csak ugye az úgynevezett "közösség" felhígulásával ma már nem a tettre kész programozók hada harsog, hanem a kényelmes usereké, akik ráadásul kevesebb hozzáértéssel, de annál hangosabban ostoroznak valamit, amiről leginkább csak szép elemzéseket olvastak, de a kódot jó eséllyel nem is látták, a stuffal saját tapasztalatuk nincs, még a dokumentációját sem olvasták. Csak jön valami új, amiért nem mindenki lelkesedik, hát akkor gyorsan be kel állni valamelyik csordába kiabálni.
Ezer lehetőség van, de ahogy a közmondás is tartja: a tett halála az okoskodás...

Miért ne lehetne választási lehetőség? Nem a RedHat az egyetlen cég, aki Linuxból él. Ha nekik nem tetszik, majd megfizetnek más fejlesztőket, hogy máshogy legyen. akár még Google Summer of Code keretein belül is fizethet a Google, ha valami nem tetszik neki.
Sok olyan nem Linux-vendor van, aki támogat open source dolgokat a Linux háza táján. IBM, Intel, Google stb.

Mutass nekem olyan, kereskedelmi Linux disztrót (lehessen hozzá supportot venni, aminek része, hogy x (x > 5) évig vállalja a cég,hogy javításokkal, dokumentációval ellát, és legalább elektronikus csatornákon keresztül közvetlen támogatást nyújt probléma esetén), ami nem használ systemd-t, és ma meg lehet venni.

Ha a kereskedelmi disztibek mindegyike átváltott a systemd-re, az nem lehet, hogy azért van, mert a systemd tényleg jó és nem azért váltottak, mert a játszóteres disztróik (Novell - openSUSE, RHEL - Fedora) váltottak? Nem lehet, hogy ugyanezen kereskedelmi disztribeket szállító cégek azért adnak pénzt a systemd fejlesztésére (Lennart ugye RHEL, Key pedig még Novelles volt a systemd elején), mert látnak benne fantáziát, és az előnyeiket/hátrányaikat mérlegelve úgy döntöttek, hogy szeretnék a plaltformjukba építeni?

És igen, lehet, hogy ebből is hátraarc lesz, ahogy az Upstartból lett. Az idő és a körülmények majd eldöntik.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A systemd-mentes korábbi RHEL-ekhez is árulták a supportot, oktatást és vizsgálkodást - annyi, hogy most megint változott a tananyag és a verzió; hasonlóan a RHEL két bármely korábbi két főverziója között. (bár februárig még lehet RHEL6-al is jelentkezni a képzésre/vizsgára)

Szerk.: Ill. pont náluk a képzés részére pont, hogy rossz az egységesedő platform, a RHEL/SuSE közeledéssel a rendszereik és így a tananyagaik között csökken a különbség :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A süsüt megnézem, de ha ott is az az elv, hogy a belecsomagolt szoftverekből ami a kibocsátáskor volt főverzió, az marad végig, akkor ugyanott vagyok, ahol a mádi honpolgár... (Ez a hozzáállás egyébként olyan, mintha a Microsoft az XP-ben nem cserélte volna le a IE-t, a mediaplayer-t, meg úgy semmit se...)

A nagy különbség az, hogy míg az IE-t, Media Player a Microsoft fejleszti, van hatása arra, hogy mivel legyen kompatibilis. Mivel a SLES is csak újracsomagolja a közösség által készített valamiket, nem diktálhat, hogy "na lécci már, az openAkármi 2.6 legyen visszafelé kompatibilis a 2.5-tel, mert más nem jó". Ha nem lesz visszafelé kompatibilis, akkor nem fogják frissíteni. That's the opensource way of life.

"Semmi új feature, semmi plusz tudás, csak és kizárólag az, ami megvolt már a születésekor."

Amikor ott az új feature, a systemd, az meg nem ízlik? Kellene egy "zeller edition" RHEL, ami 10 évig támogatott, plusz csak és kizárólag azokból a szoftverekből és éppen akkor frissül, ami éppen neked kell? :)

Ahja, de ezen elvek mentén ki kellene adni egy-egy RHEL7-et 2.2 Apache Httpd 2.2/2.4 verzióval; egy-egy RHEL7-et bash 4.1/4.2 verzióval, egy-egy RHEL7-et 32/64 bittel... ésígytovább. Aztán meg lehúzni a rolót mert már ezek így adnak 16 variációt, amit aztán lehet elemezni...

A "systemd-szkeptikusok" mondják mindig, hogy semmi hasznos új feature-t nem tud, amit meg igen, arra úgy sincs szükségük. ;) Ha és amennyiben ez az állítás igaz, az ő szemszögükből egy systemd-sysv-upstart-openrc-akármi váltás shell-csere szintű...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Egy példát tudnál írni, hogy hol módosít annyira mélyen, különösen visszafelé nem kompatibilis módon? És ténylegesen a systemd legyen, ne a systemd ernyő alá tartozó egyéb projektek.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Próbálj meg egyszer egy RHEL6-ra 2.4-es Apache Httpd-t tenni vagy RHEL7-re 2.2-es Apache-ot, aztán kiderül, hogy mennyire problémás.

Egyébként meg... én fogtam a RHEL6-on működő Cassandra, WildFly, Jira, Confluence és még pár egyéb init scriptet, odamásoltam a RHEL7-en az /etc/init.d/ alá... és... működik, le is van írva, hogy működni fog. Szóval RHEL7-en van workaround arra, ha csak a régi módszer szerint van megírva egy script...

De kérlek mond pár use-case-t arra, hogy a percek alatt átlátható systemd config-ban mit nem tudtál megcsinálni, amire nem volt jó a fenti workaround se...

Szóval RHEL7-en van workaround arra, ha csak a régi módszer szerint van megírva egy script...

Azért azt tegyük hozzá, hogy a systemd egyik alap tervezési elve volt, hogy visszafelé kompatibilis maradjon az init scriptekkel, hogy - bár a systemd nyújtotta előnyöket csökkentve -, de működjenek a korábbiak; így ez kevésbé a RHEL érdeme, mint a systemd-é. 

foo@bar-opensuse:~> ls -l /etc/init.d/ | grep -v "^d" | wc -l
24

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Hm... azt hogy oldják meg, hogy ha nekem például kell a systemd, de az Apache Httpd maradjon 2.2, neked pedig nem kell a systemd, de az Apache Httpd legyen 2.4?

Csak ebből a kettőből kijön négy variáció, amit támogatni kellene 10 éven át és akkor még nem beszéltünk a több tucat egyéb major komponensről.

10+ évig javításokat backportolni, illetve saját fork-ként javítani az azóta csillióval előrébb lévő, eredeti fejlesztő(k) által már nem támogatott verziókat sem biztos, hogy annyira jó dolog. Támogatás ide, vagy oda, nem egy orrdítóan hibás működésre (amit anno az eredeti fejlesztő egy későbbi verzióban javított) adott már a retek "wontfix" választ. Mert csak.

A fejlődésbe elsősorban, akkor van értelme erőforrást rakni, ha valami olyan probléma jelentkezik, amit a régi kereten belül nem lehet kielégítően megoldani. Vagy világosan látszik valami, ahol még hatékonyabban lehet ugyanazt. De minden más esetben ez az egész önmagért való változás csak költség lesz a fejlesztőnek is és a felhasználónak is.

Ez is és az ellenkezője is nekem kicsit nagyvonalú summázat.

Tök jó, hogy mindenki kitalál mindenfélét ebben a fícsörversenyben, akkor is, ha egy-egy fícsör használata marginális, hiszen akinek éppen az kell, annak ööm é bódottá.
A problémát a rövidebb életciklusokból fakadó gyors mandatory go live-ban látom, amit megfejel az ezerfejű véleményének semmibe vétele.
Biznisz szoftvereknél a pénztárcában manifesztálódó vélemény megoldja, ha a szerzőnek nagyon elgurult a gyógyszere - a freeben torzítja a természetes kiválasztódást az, ami eddig is: "oké, ez a része szar... na de ingyé van".

Köszi. Én is így értettem: a változás önmagáért a változásért nem nagy fíling. Valamiből megcsinálni az n+1. verziót, majd azt "rákényszeríteni" a népekre számomra fura perverzió.
Jelenleg sem tudom követni az új verziókat, debian 6->7 upgradet sem tudtam mindenhol meglépni, egész egyszerűen nagy a rizikója, h a távoli gép nem indul újra. Jártam már így, azóta ilyet nem csinálok üffél éles szerverén.
És nem mindenki 1-2 szervert üzemeltet, én most 50-nél tartok, egymagam.

Megváltoztak az arányok: 15 éve az azt megelőző 25 év alatt összegyűlt tapasztalatok alapján készült rengeteg dokumentációban kíváncsiskodhatott a nem túl nagyszámú érdeklődő, akiknek ráadásul megvolt az a szerencséjük, hogy bármilyen *ix környékéről tévedtek be, legfeljebb a részletek lehettek furcsák, az egész nem idegen.

Az utóbbi 5 évben viszont az érdeklődő lett rengeteg, a változtatás szintén, ezek dokumentációja az idő sokkal zűkösebb volta miatt viszont kevesebb.
Így persze gyakran érzi idegenül magát nem csak a valamixről átpislantó, de az is, aki nem házastársi, csak munkakapcsolatban él a linuxszal.

(A fenti pillanatfotó, nem panasz: amikor pályára tévedtem magamtól is pedzettem, de a tanerő is feszt hangsúlyozta, hogy nem lesz ez olyan biznisz, ami lehetőséget ad a munkahelyi monotóniából fakadó depresszióra).

Off
Jogos, nem írtam kitől idéztem. Nos, az illető nem a profitorientált vilagnezeteirol lett volna hires.
On

A tanfolyam egy módja a tanulásnak, a tudás megszerzésének számos, más formáját is lehet alkalmazni. Pl. man pagek olvasgatasa, Google, how-to-k olvasasa esetleg empirikus módon tett tanulás stb...
Csak lustanak egyszerűbb lenni. ;)

Pontosan tudom, hogy kitől idéztél. Viszont rengetegen mennek rá a tanfolyam iparágra is, meg a szakkönyv iparágra is, és kihoznak olyan minőségű tanfolyamokat meg könyveket, amelyek 15 évvel ezelőtt összecsapott kontár munkának számítanak. A lényeg, hogy jöjjenek a friss technológiák, hogy hetente lehessen "Effective Programming with X" és "Learn X in 24 hours" könyveket kiadni :)

man pagek olvasgatása? Hát nem tudom, hogy az éppen aktuális menő XYZ JS libraryhoz hány man oldal van :)

Pár tf. után megfejtettem az ilyen tanfolyamok feelgoodjának a titkát: jó önképet ad az, hogy az elméletileg újnak szánt ismeretek 80%-át már azelőtt tudtad, hogy beléptél volna az ajtón - és persze a tényleg új 20%-nak is örülsz.

Csak a következő hétfőn jön a kellemetlen gondolat, hogy "basszus, amit konkrétan meg kellene oldani, azt pont úgy nem tudom, mint egy héttel ezelőtt, hiába kérdeztem rá".

Van azért a tanfolymoknak egy másik, szerintem elég hasznos hozadéka: időhatékonyak. Valaki előnyálazza, és elmondja, hogy kb erről szól a big picture, ezek a fontos részek, kb ez a best practice. Amit azért sokszor elég nehéz egyébként összekaparászni, a linux man oldalaknak jó részének jellemzője, hogy ezekről baromira nem értekeznek, szóval egy csomó, kevésbé up to date, meg kevésbé teljes doksiból kell egyébként összerakni. Amit nyilván lehet, de általában időigényes.

A másik nagy előnye, hogy az elmentem két-nap, egy hét tanfolyamra, és ezzel foglalkozom, az jobban működik munkahely/főnök relációban, mint hogy most hagyjatok, a héten a sarokban ülve mant olvasok.

Nyilván, ehhez azért normális tanfolyam is kell, ahol az anyag tényleg normális.

"man pagek olvasgatása? Hát nem tudom, hogy az éppen aktuális menő XYZ JS libraryhoz hány man oldal van :)"
max nem man pagenek hivjak, de van remelhetoleg egyeb dokumentacio hozza. Ha nincs:
1) megirod magad
2) keresel mas megoldast, aminek van jo dokumentacioja
3) problakozol, es aztan lesz ami lesz
4) reverse engineering, majd es/vagy 1)
5) ...

a tanfolyamok/konyvek/cikkek kozott is vannak jok, rosszak, es olyanok, amelyek azt sugalljak, mar guru vagy az adott temaban stb...
fogyasztoi tarsadalom vagyunk - ennyi.

( _Franko_ v | 2015. 02. 11., sze – 09:46 )

Tök jogos, érthetetlen, hogy mi a francnak nem volt jó Ken Thompson-nak a Multics...

( Ritter | 2015. 02. 11., sze – 23:15 )

A Linux körül általánosságban nem érzek ilyen problémát. De Ubuntunál sajnos áll a lost its way állítás... szerintem.
Mindenbe belekapnak, majd otthagyják magukra a saját korábban dédelgetett projektjeiket is.