Windows 10 is Getting Support for GUI Linux Apps

HUP cikkturkáló

https://www.omgubuntu.co.uk/2020/05/run-linux-apps-on-windows-10-wsl-2

  • 2074 megtekintés

( hajbazer v | 2020. 05. 21., cs – 14:23 )

Eljön még az az idő a desktop Linuxok Red Hat általi kisiklatása után, hogy Windows-on egy fokkal több értelme lesz GUI-s Linux alkalmazásokat használni, mint a GTK3 és Wayland idealizmusokkal egyre használhatatlanabbá tett eredeti platformjukon.

Ami pedig egy wrapper lesz a Windows GUI felé, nem pedig a Red Hat módra összetákolt, kiherélt funkciójú libinput, a semmivel sem kompatíbilis modesetting driverek, xwayland és egyéb szélsőségesen idealista, végletekig butított komponensek által körbehákolt trágyadomb. Tehát ilyen szempontból van rá esély, hogy jobb lesz.

Garantáltan, a dotnetben már megoldott a kérdés... Úgy kb. 5 éve kívántam valakinek, hogy "élete végéig használjon windózt, systemd-vel", de azt nem gondoltam volna, hogy egy nap ez egy reális opció lesz...dehát ez már a sokadik alkalom, hogy elsütök egy abszurd viccet a systemd-vel kapcsolatban és utána valósággá válik. :P És ebből is kiviláglik, hogy a systemd tényleg egy rohadt trójai faló. A világ legelhízottabb trójai falova... :(
Oldschool Computer - http://oscomp.hu

A systemd-vel a legnagyobb probléma, hogy kiengedték a Red Hat berkein kívülre, sőt konkrétan belekényszerítettek jónéhány más disztribúciót az adoptálásba, miután a fősodratú komponenseket, alkalmazásokat (X.org, Gnome, Firefox) már bekebelezték vagy saját maguk által, korábban életre hívott trójai Poettering falovaktól tették függővé (pulseaudio, avahi daemon, mdns, gtk3). Ez nagyjából olyan, mintha a SuSE YaST-jával kéne megjelenése óta minden egyes Linux disztribúciót konfigurálni. Lehetett volna adoptálni, de köszönjük, megvagyunk nélküle.

A Red Hat-nak sikerült, ami a patent troll SCO-nak nem a Linux kernellel a 21. század hajnalán. Arrogáns módon, mégis szépen csendben átvette a hatalmat a Linux userspace és a fontosabb rendszerkomponensek felett. Végül egy évtized leforgása alatt megtalálta a módját annak, hogy a mindenki által módosítható, elvileg "szabad", nyílt forráskódú szoftverekre rátegye a korporatokrata kezét és kevésbé szabad szoftverré tegye. Nem jogilag, hanem technikailag. Méghozzá az által, hogy ha nem akarsz az ő komponenseiktől függeni, akkor máris nyakadba kapod a fél Linux desktop világ karbantartását.

A Red Hat inváziójánál viszont sokkal nagyobb probléma, hogy a fejlesztést jelenleg merre viszik. A Red Hat desktop Linux koncepciója a csempés Windows 10 és a Google Android egyvelegéből alkotott csiligány, tablet-idealista majomutánzat, ami a két mesterpéldányhoz úgy viszonyul, mint a TV2 műsorkészítési irányelvei az RTL Klubéhoz. Az egyik szimplán szenny, de a másik a szennynek is csak egy ócska másolata. Emellett a Red Hat kimondott célja a felhasználói felületek egységsugarú tapicskolók szintjére butítása az egyszerűbb karbantarthatóság és mindenféle fejlesztési és tesztelési idealizmusok apropóján. Erről a libinput vezető fejlesztője a saját blogjában is említést tesz, piedesztálra emelve a "minél kevesebb konfigurációs lehetőség, annál jobb" szélsőségesen idealista irányvelvet. Mindeközben természetesen basznak implementálni jónéhány olyan feature-t, amit a helyettesíteni kívánt input driverek implementáltak. Szóval, nem csak a konfigurációs lehetőségek esnek ki, hanem konkrét hardverek (egerek, érintőpadok, billentyűzetek) kezelhetőségének, értelmes használatának támogatása is. A Red Hat-nál évek óta a választási lehetőségek szisztematikus kiirtása és ez által a felhasználói szabadság lábbal tiprása megy. 5 év múlva a desktop Linux nem lesz több, mint egy mobil operációs rendszer, ami alá PC kell, de annyit se fog tudni, mint egy okostelefon.

+1 És az a szörnyű, hogy mivel a Linuxos világban használt eszközök, szoftverek - elsöprő többségükben - ugyanazok, mint a többi UNIX-on, ezekkel az irányelvekkel nem csak a Linuxos, de az összes UNIX-os UX-et elkúrják, vagy csak kisajátítják; mit kezdjen egy Solaris vagy FreeBSD user egy systemd dependens cuccal? Persze lehet mindenféle underground környezetekben dolgozni (TDE, CDE, WMaker, LxQt és mindenféle fapados window managerek), direkt régi vagy alternatív toolokat és szoftvereket használni, de ezek vagy megmaradnak hosszútávon, vagy nem, mert csak pár ember áll mögöttük. Persze a remény hal meg utoljára. A másik, ami szörnyű, hogy ez a butítási mánia nem korlátozódik a Linuxos felületekre, a windóz felületét is rommábutították az xp és a hetes óta. A windózos powerusereknek megváltás lesz a ReactOS, ha egyszer lesz belőle valami.
Oldschool Computer - http://oscomp.hu

Nem elég jobb initrendszert csinálni: az is egy szakma, hogy el kell magyarázni az embereknek, hogy miért jobb a tiéd, mint a systemd. Ezt a szakmát, aminek része elég sok dolog a pszichológiától a data science-ig, szokta a tisztelt informatikus-közösség úgy emlegetni, hogy "bullshit".

Dehogy kell elmagyarázni, hogy jobb mint a systemd. 

Kétféle ember létezik. Az egyik nem tudja ésvagy nem is érdekli mi az a systemd. A másik tudja mi az a systemd és azt is, hogy egy kalap szar. 

Mégis ez terjed erőből. Ide valami voodoo mágia kellene, vagy tényleg egy elkötelezett bérgyilkos. 

A systemd nem magától terjed, hanem azért, mert akik már invesztáltak bele, élükön pl. a Red Hat, azok tolják erővel, mert nem akarják, hogy a befektetett idő/pénz kárbavesszen. A kisebb szereplők, akik most kezdenek foglalkozni vele, meg egyszerűen nem akarnak kiamradni belőle.

Szóval ha ezen változtatni akartok, akkor de, igenis elő kell venni a marketing/sales skilleket, és (a) beszervezni valami nagypályás játékost, aki majd tolja erővel a cuccotokat, vagy (b) roadshow-zni a kisebbek között, és (nagyon) apránként felépíteni a user bázist.

Máshogy nem fog megoldódni a "probléma", mert akinek számít a szava ebben a kérdésben, annak nem érdeke adni egy pofont a szarnak.

A systemd nem magától terjed, hanem azért, mert akik már invesztáltak bele, élükön pl. a Red Hat, azok tolják erővel, mert nem akarják, hogy a befektetett idő/pénz kárbavesszen.

Akkor vegyenek fel ők sales-eseket, akik eladják a RHEL-t, mintsem a Linux közösséget forgatják fel és torkokon nyomkodják le zsarolási pozícióból, befolyásgyakorlással a szarjaikat. Nekik az elsődleges bevételi forrásuk a Red Hat Enterprise Linux eladásaiból származnak, aminek a csomagjait LTS ágon ők tartják karban, például a CentOS 6 2.6-os kernelébe 1000-nél is több fixet, drivert backportoltak úgy, hogy maga ez a kernel ág már nem is támogatott. Bőven elég lett volna Red Hat-ra és Fedorára a systemd és az ott elérhető csomagokat kompatíbilissé tenni vele, illetve az init scripteket átírni, nem pedig kilobbizni minden fősodratú Linux disztribúciónál (Debian, Ubuntu, SuSE, Arch stb.) és alkalmazásnál (pl. Firefox), hogy erőltessék be a systemd-t, ráadásul úgy, hogy akkoriban még egy instabil bughalmaz volt. Ezzel jól fel is idegelték az egész Linux közösséget és megosztották őket fősodratú "kövesd a pénzszagot" korporatokratákra és a szabadelvűséget, a UNIX-filozófiát elvből megőrző "veterán" felhasználókra, utóbbiakat lesajnált, lemaradott lúzer színben feltüntetve, bemocskolva.

Szóval ha ezen változtatni akartok, akkor de, igenis elő kell venni a marketing/sales skilleket, és (a) beszervezni valami nagypályás játékost, aki majd tolja erővel a cuccotokat

Nem. Semmit nem kéne erővel tolni. Az egész open-source szoftverfejlesztésnek az lenne a célja és értelme, hogy ne erővel, lobbival, üzleti érdekek és egyéb politikai manőverek által legyen egy adott nyílt forrású komponens domináns minden Linux disztribúcióban. Inkább védeni kéne az open-source és a Linux közösséget az ilyen arrogáns, invazív szoftverpolitikát folytató multiktól, mint a Red Hat. Hiányoltam az FSF, Stallman és Torvalds kritikai észrevételeit és jelenlétét az ügyben, ha máshogy nem, mint megmondóemberek.

Máshogy nem fog megoldódni a "probléma", mert akinek számít a szava ebben a kérdésben, annak nem érdeke adni egy pofont a szarnak.

A Red Hatnak az az érdeke, hogy eladja az enterprise Linuxát, főként nagyvállalatoknak. Ezt a Linux közösség és a desktop Linux koncepciójának felforgatása nélkül is meg lehetne tenni, hiszen a systemd előtt se ment nekik rosszul. Attól még csinálhatnak nyugodtan gtk3-at, systemd-t, avahi-t, pulseaudio-t, libinput-ot, networkmanager-t, csak nem kell áterőltetni más disztrókba, pláne nem instabil állapotában, kísérleti nyúlnak használva az egész Linux közösséget. Ahogy a SuSE (Novell) is csinált YaST-ot és mégse ment csődbe tőle, hogy nem nyomta le minden Linux felhasználó és maintainer torkán. Nem mellesleg a Fedora is pont ezért van, hogy a közösség azon tesztelhesse a legújabb Red Hat idealizmusokat. Szóval még azt se lehet mondani, hogy nincs tesztelői bázisuk. A Red Hatnak a hatalom kell. Ő akarja uralni a Linux userspace-t, hogy megkerülhetetlen legyen. Ezzel pedig a GNU Linux, mint szabad szoftver eredeti célját és értelmét ássa alá, tapossa porba, zilálja szét.

Van egy ökoszisztéma, benne egy-két vízfej, meg egy csomó, hozzájuk képest jelentéktelen méretű kishal. A vízfej csinál valamit, annak hatása lesz, a kishalak nem akarnak "kimaradni", igazodni fognak. Nem is nagyon tehetnek mást, ha ül három egyetemista srác egy garázsban, és heggesztenek valami speciális use case-re egy disztrót, akkor nekik nem lesz kapacitásuk szembemenni a fősodorral.

Ezt ne úgy képzeld el, hogy odamegy egy redhates csávó a kis barkácsdisztróhoz egy nokiás dobozzal meg egy pisztollyal

Nem, nem az a zsörnyű, hanem az, hogy a sysvinit és elődein "nevelkedett" maradáspártiak nem tudják, nem hajlandóak megérteni, átlátni a szertintük faék egyszerű korábbi init-rendszereken túlmutató megoldásokat. Bár ahogy anno a sysvinit-es scripteket láttam némely linux disztróban, vagy épp ahogy a különböző runlevelek alkalmazása is gyakorlatilag "kiment a divatból" a linuxoknál... Szóval a visszasírt megoldást sem értik/tudják használni...

Ha nem tudjuk, nem vagyunk hajlandóak megérteni, átlátni, akkor miért nem a SysVInitet javasoljuk a systemd helyett, miért az s6-ot, meg a többi fullos SCS-t? Egy érv a SysVInit ellen, nem érv a systemd mellett, ez még mindig egy kamu dilemma, hogy csak a SysVInit van a systemd helyett.
Oldschool Computer - http://oscomp.hu

akkor miért nem a SysVInitet javasoljuk a systemd helyett, miért az s6-ot, meg a többi fullos SCS-t?

Lényegében a systemd ezért tud terjedni: mindenki javasol mindenfélét, aztán az egyik mögé meg odaállt a FOSS-ipar egyik húzóneve, és ez kb. eldöntötte a kérdést. Akkor is, ha esetleg az a legrosszabb választás, magyon kevesen engedhetik meg maguknak, hogy a projektjük extra erőforrást allokáljon a széllel szembe pisilésre az érdemi fejlesztés helyett.

Lényegében a systemd ezért tud terjedni: mindenki javasol mindenfélét, aztán az egyik mögé meg odaállt a FOSS-ipar egyik húzóneve, és ez kb. eldöntötte a kérdést.

Nem "odaállt mögé", hanem az egyik alkalmazásukban álló, szélsőségesen idealista, arrogáns vezető fejlesztő, nevezetesen Lenart Poettering felidegelte magát a sok init scripten és összetákolt egy bughalmazt, amit systemd-nek nevezett el. A Red Hat azon volt, hogy nyomást gyakoroljon, minden erővel, minden torkon lenyomja a systemd-t, függetlenül attól, hogy ezzel hány embernek okoznak bosszúságot és hány konfliktust generálnak a Linux közösségek felforgatásával. Pedig ekkor már jócskán voltak alternatívák, még corporate vonalon is, pl. a Canonicalnak az upstart.

nagyon kevesen engedhetik meg maguknak, hogy a projektjük extra erőforrást allokáljon a széllel szembe pisilésre az érdemi fejlesztés helyett.

Ez nem igaz. Pláne nem igaz egy Linux disztribúciónál, ahol az érdemi fejlesztés nem nálad zajlik, hanem az open source közösségben, rád pedig főleg a maintenance és tesztelés hárul. A Red Hatnak persze van lehetősége a széllel szemben pisálásra és ezt arra használja fel, hogy azok arcába pisáljon, akiken felkapaszkodott jelen pozíciójába. Úgy döntött, hogy szembeköpi a UNIX filozófiát, felforgatja a Linux közösségeket, maradinak, lúzernek és nemkívánatosnak kikiáltva mindenkit, aki hű a Linuxot érintő, szakmai elveihez. Mindeközben gyakorlatilag újraírja a rendszerkritikus komponenseket (systemd, avahi daemon, pulseaudio, libinput, networkmanager stb.), majd ezeket lenyomkodja egyenként a torkokon, hogy mások is ezeket használják, alternatíva nélkül. Ha ezt még azzal megfűszerezzük, hogy a Red Hat a "Linux is not a choice" vezérelvet vallja, még veszélyes és vészjósló is, ha figyelembe vesszük az invazív szoftverpolitikájukat és az arrogáns hozzáállásukkat. Érdekes módon a SuSE és a Canonical is tök jól elvolt idáig a saját idealizmusaik fejlesztgetésével, anélkül, hogy rá akarták volna bárkire kényszeríteni a YaST-ot, a Unity-t, vagy akár az upstartot.

Pláne nem igaz egy Linux disztribúciónál, ahol az érdemi fejlesztés nem nálad zajlik, hanem az open source közösségben, rád pedig főleg a maintenance és tesztelés hárul.

Itt nem pontosan értem, hogy ki a "nálad" a példában. Én nem a Redhat/Canonical méretű teamekre gondoltam, hanem azokra a projektekre, ahol egy maroknyi contributor valamilyen hozzáadott értéket ad egy baseline-nak választott disztribúcióhoz. Mondjuk csinálok egy otthonautomatizálásra kihegyezett distrót Ubuntu alapokon. A meló nagy részét én csinálom, két haver néha besegít, meg egyszer volt egy hackathon, ahol egy tucat ember, vagy annyi sem, összehordott valamit egy hétvége alatt.

Másnap kiderül, hogy az Ubuntu systemd-re vált. Mit csináljak? Vagy beállok a sorba, és továbbra is csak a baseline feletti hozzáadott értékkel foglalkozom, tehát systemd lesz a következő verzióban, vagy extra erőforrást adok az érdemi fejlesztés helyett arra, hogy lecseréljük a baseline distrot, esetleg kézzel kiirtsuk belőle a systemd függőségeket. Utóbbi esetben nem lesz systemd, de akkor arra ment el a (véges) idő, hogy maintenance dolgokkal foglalkoztunk ahelyett, hogy belefejlesztettem volna a backlog következő elemét, amit a user használhatna.

> Itt nem pontosan értem, hogy ki a "nálad" a példában. Én nem a Redhat/Canonical méretű teamekre gondoltam, hanem azokra a projektekre, ahol egy maroknyi contributor valamilyen hozzáadott értéket ad egy baseline-nak választott disztribúcióhoz. Pontosan így értette ő is: ezt jelentette, hogy az érdemi fejlesztés a közösségben zajlik, hiszen bármilyen disztrót is csinálsz, a programozói meló oroszlánrészét már elvégezték a kernel és toolfejlesztők, neked csak össze kell szerelned, maximum a specifikus részeket kell leprogramoznod. > Másnap kiderül, hogy az Ubuntu systemd-re vált. Mit csináljak? Szilvás buktát mert azt szeretem. Azt amivel hosszútávon jól jársz. > Vagy beállok a sorba, és továbbra is csak a baseline feletti hozzáadott értékkel foglalkozom, tehát systemd lesz a következő verzióban, vagy extra erőforrást adok az érdemi fejlesztés helyett arra, hogy lecseréljük a baseline distrot, esetleg kézzel kiirtsuk belőle a systemd függőségeket. Utóbbi esetben nem lesz systemd, de akkor arra ment el a (véges) idő, hogy maintenance dolgokkal foglalkoztunk ahelyett, hogy belefejlesztettem volna a backlog következő elemét, amit a user használhatna. Ez csak akkor állja meg a helyét, ha mákotok van és a systemd nem szívat le benneteket le sehol sem. Akkor megállja a helyét, amit mondasz. Ha viszont de és rászívtok, akkor messze több idő megy el azzal, hogy tutujgatjátok azt a vacakot és kerülgetitek a marhaságait, meg hiábavalóan próbáljátok a saját szoftveretekben megtalálni azt a hibát, ami a systemd-ben van, mint ha egyszer rááldozzátok az időt, hogy legyen egy kiforrott revert path-etek egy másik init rendszerre.
Oldschool Computer - http://oscomp.hu

" felidegelte magát a sok init scripten és összetákolt egy bughalmazt " amit a linux disztribek (tiszelet a kivételnek) csomagkarbantartói scriptek gyanánt elkövettek nem is kevés esetben... Mondjuk úgy, hogy ha másra ne, hát elrettentő példának tökéletesen alkalmasak. Ráadásul a sysvinit különböző futási szintjeit gyakorlatilag abszolute nem használják a Linuxok, de még a respawn használata sem votl gyakori - hogy finoman fogalmazzak, helyette "yol" megírták shellscriptben...

" az érdemi fejlesztés nem nálad zajlik, hanem az open source közösségben " - marha régóta nem a nagy büdös "ópenszósz közösségben" zajlik a fejlesztések zöme, a legtöbb kódot (és ezzel erőforrásokat (ember, pénz) is) bizony a nagy cégek tolják bele, nem pedig önjelölt péhápépistikék.

hát elrettentő példának tökéletesen alkalmasak

Amilyen instabil állapotában bekerült a systemd az egyes disztribúciókba, a Red Hat korporatokrata lobbijának, zsarolási pozícióinak és arrogáns hozzáállásának köszönhetően, az legalább egy nagyságrenddel elrettentőbb példa, mint akkoriban az init scriptek voltak.

Ráadásul a sysvinit különböző futási szintjeit gyakorlatilag abszolute nem használják a Linuxok, de még a respawn használata sem votl gyakori

Gondolom, végigolvastad az összes init scriptet és nem a Red Hat és a Poettering pro-systemd közhelyeit puffogtatod. Akárhogy is, a sysvinit nem megfelelő használata nem érv a systemd mellett. Gondolom a fordítottjával automatikusan egyetértenél.

a legtöbb kódot (és ezzel erőforrásokat (ember, pénz) is) bizony a nagy cégek tolják bele, nem pedig önjelölt péhápépistikék.

A Red Hat viszont jelenleg arrogáns módon kisajátítja a Linux userspace-t és vele együtt a desktop Linuxot megvalósító komponensek fejlesztését is. Csökkenti a kompatíbilitást, veszi ki a feature-öket, butít, tabletesít, összevon, centralizál mindent, amit csak ér, szembeköpve a Linux- és UNIX-filozófiát. Azzal nincs különösebb problémám, hogy multik bérkóderei munkaidőben fejlesztenek open-source szoftvereket. Azzal van, amikor ezek a bérkóderek azt gondolják magukról, hogy ők szarták a spanyolviaszt és könnyűszerrel felforgatják emberileg és technológiailag is azt a közösséget, aminek köszönhetik, hogy a munkahelyük egyáltalán létezhet és nem Redmondban kell gányolniuk PowerShellben, meg .NET-bloatban.

"Gondolom, végigolvastad az összes init scriptet " - nem volt rá szükség, mert a futási szintek nem használata, a respawn nem ismerete nem azokból derül ki, ez az egyik. (Egyébként elég sok initscriptet nyálaztam végig...) A másik, hogy az, amikor ugyanazt a feladatot 123 scriptben 123-szor valósítják meg (célszerűen legalább 123 részben vagy teljesen eltérő módon), az óriási élmény - pláne, ha kiderül, hogy egy részük bugos/sérülékeny, aztán a javítás is n+1 féle módon, n+1 időpontban történikmeg - vagy nem.

A sysvinit-et _sem_ tudták nagyon sok disztróban rendesen használni, jellemzően ismerethiány miatt - és bizony azoktól látom a legnagyobb durrogást a systemd ellen, akik a sysvinit dolgaival sincsenek kellően tisztában. Azt _se_ tudták/akarták rendesen megtanulni/használni, a systemd-t se...

"Red Hat viszont jelenleg arrogáns módon" - arrogáns módon per pillanat te nyilvánulsz meg, de persze ezt a stílust már megszokhattuk tőled. Egyébiránt szerinted a Canonical/Oracle/SuSE, meg akár a linux kernel is miért megy arra, amerre a szerinted botrányosan viselkedő, minde ésszerű, hasznos dolgot lábbal tipró RedHat is halad? Nos? Vagy azt mondod, hogy mindannyian ezt teszik, mindannyian szembeköpik a Linux-filozófiát? A Linux kernel fejlesztése köpi szembe a Linux-filozófiát? Nem érzel itt némi ellentmondást...?

pláne, ha kiderül, hogy egy részük bugos/sérülékeny, aztán a javítás is n+1 féle módon, n+1 időpontban történikmeg

Nem rosszabb élmény, mint amikor a systemd-ről derül ki, aminek a kijavításához egy nagyságrenddel több kompentencia és programozási rutin szükséges, mint egy shell scriptéhez. Egy sysadmin ki tud javítani egy init scriptet, pont úgy, ahogy egy systemd unitot. Egy systemd bug esetén kuncsoroghat Poettering-nél a javításért. Vagy túrkálhat egy túlbonyolított, architekturális trágyadomb C kódjában.

bizony azoktól látom a legnagyobb durrogást a systemd ellen, akik a sysvinit dolgaival sincsenek kellően tisztában.

Ha ez igaz, az semmi mást nem bizonyít, minthogy a sysvinit ismeretének hiánya nem érv a systemd mellett.

Egyébiránt szerinted a Canonical/Oracle/SuSE, meg akár a linux kernel is miért megy arra, amerre a szerinted botrányosan viselkedő, minde ésszerű, hasznos dolgot lábbal tipró RedHat is halad? Nos?

Szerintem ne példálózz pozitívan egy olyan céggel, aki IP cím alapján jelentget fel internetszolgáltatókat VirtualBox extension pack letöltések miatt. Az Oracle a vállalati arrogancia másik mintapéldája, a Red Hat mellett. A Canonical és a SuSE nem a Red Hat által kijelölt irányba megy, hanem a kisebbik rossz elvén adoptálja az idealizmusokat. Vagy épp nem és épp kipatcheli a Red Hat legújabb idealista baromságait, mint például a GTK3 File Chooser kikapcsolhatatlan rekurzív keresését. A systemd-nél a dilemma az volt, hogy vagy kidobják a GNOME-ot, amivel valószínűleg a Red Hat malmára hajtották volna a vizet az enterprise felhasználók körében, vagy ők tartják karban, systemd-mentesen, ami meg plusz munka, amit ugye multiék annál kevésbé szeretnek, ahány száz millió dollárt felhalmoztak. Nyilván elvégezték a maguk kis számításait és rövidtávon (mivel a multikat más nem érdekli) jobban megérte behúzni a systemd-t.

A Linux kernel fejlesztése köpi szembe a Linux-filozófiát? Nem érzel itt némi ellentmondást...?

A Linux kernel a legtávolabb áll attól, hogy a Red Hat baromságait feltétel nélkül behúzza. Javaslom olvasgatni az LKML-t, ahol Linus rendre kiosztja a Red Hat szélsőségesen idealista, elitista fejlesztőit, akik egy év alatt is képtelenek a saját hibáikat kijavítani, utána meg csodálkoznak, hogy nem kerül be a kernelbe a szarkupacuk.

Szóval, az, hogy mindenki önként dalolva megy a Red Hat által kijelölt útvesztőbe, nettó csúsztatás a részedről. Ugyanakkor, a Red Hat jó zsarolási pozícióban van, hogy a desktop és úgy általában az enterprise Linuxoknál kikényszerítse a saját akaratát. A Debian-nál, mint az egyetlen elterjedt, még közösség által karbantartott Linux-disztribúciónál ezt a kártyát használták. A Linux kernelt is igyekeznek az uralmuk alá hajtani, mindenféle kdbus és BUS1-idealizmusokkal, de egyelőre még nem sikerült.

A systemd-nél a dilemma az volt, hogy vagy kidobják a GNOME-ot, amivel valószínűleg a Red Hat malmára hajtották volna a vizet az enterprise felhasználók körében

Egyébként miért? Enterprise felhasználók nem tudtak volna KDE-t, vagy XFCE-t, vagy akármi mást használni?

Én pl. alapból Debiant és KDE-t használok, de amikor az Oracle adatbázist telepítettem egy szerverre, és Linux alatt a RedHat volt a támogatott rendszer alatta, akkor feltettem a RedHatot. Elindult a Gnome. Megcsináltam, amit kellett, aztán hagytam a gépet futni. Enterprise felhasználóként ugyan kicsit szokatlan volt a Gnome felület, de nem keseregtem miatta. Semmiképpen se mondanám, hogy előny volt. De hátránynak se nevezném.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ráadásul a sysvinit különböző futási szintjeit gyakorlatilag abszolute nem használják a Linuxok

Ez egyébként miért gond?

Én valaha egyszer régen beállítottam valamelyik laptopomon az akkor éppen aktuális rendszert, hogy legyen X nélküli multiuser runlevel, meg legyen a normál X-es runlevel, meg legyen olyan runlevel, ahol elindított még egy Oracle adatbázist is... de mivel voltaképp mindig csak az X kellett, és ha Oracle-lel akartam valamit, akkor runlevel váltás helyett egy scriptet megfuttattam általában, ezért amikor legközelebb gépcsere lett, már nem állítottam be mindezt, mert nem volt rá szükségem.

Ha valami beszart, akkor ott az 1-es runlevel, ha minden jó, akkor meg a default, ami talán 2 vagy 3, voltaképp tökmindegy.

Mielőtt azt mondod, hogy OK, de ez egy workstation volt, jellemzően egy felhasználó desktopon majomkodott rajta csak, üzemeltettem egy kis számú szervert is. Minden gép csinálta a saját feladatát. Volt mail szerver, volt tűzfal, volt adatbázis szerver, ez-az. Egyiknél sem volt szükségem runlevelek között lépkedni.

De ha kellett volna, elég egyszerűen be lehetett állítani, szóval beállítottam volna.

Eszembe nem jutott amiatt, hogy nem volt alapból valaki más által megálmodott ideális módon bekonfigurálva alapból lecserélni a SystemV initet valami más init rendszerre.

Olyan előfordult, hogy más okból lecseréltem, leginkább vagy a biztonság növelése volt az indok, ilyenkor daemontools lett helyette.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

> Ebben egy szó nincs arról, hogy mi a baj. Na ja, egyet kattintani kéne pl. a listához, ahol felsorolják tételesen, hogy mi baj vele. > Neked személyesen milyen bajt okoz? Mielőtt kukáztam, ezekbe futottam bele. > Már azon kívül, hogy meg kellene tanulni? Borítékoltam, hogy megint csak kötekedni akarsz. Ennyit rólad, meg az ígéreteidről.
Oldschool Computer - http://oscomp.hu

Nekem is rohadt le random nem dzsunkapécém - volt, hogy a kernel bugzott, volt, hogy a hardver kezdte megadni magát. Viszont ezek után a döglések után az fsck-t nem "hobbiból" futtatja, hanem azért, mert az adatintegritás fontosabb, mint a boot ideje. És igen. végig kell várni - ha dafke belerondítassz, akkor ne csodálkozz, hogy "érdekesen" fog viselkedni.

A samba nem ismer reload-ot/átnevezték/etc. A problémát a csomag karbantartójának vesd fel, merthogy a systemd-s unitot nem a systemd, hanem az adott csomag adja - és ha a karbantartó nem oldotta meg (lehet, hogy neki (is) tanulnia kéne?), hogy legyen reload bene (pedig nem űrtechnológa - ha minden igaz egy sor...), akkor nem lesz - illetve a unit a nevét is tőle kapja.

Még mindig ugyanazt a hardware-t használom, mint akkor. És semmi baja. Amióta nincs systemd, azóta ugyananúgy szökőévente fagy csak szét, mint régen. Az fsck meg eddig még sosem talált semmit. "Belerondítani" meg nem is tudtam, hiszen a systemd nem hagyta. Az lehet, hogy a unit karbantartóját terheli a felelősség, dehát minek áll valaki át egy olyan technológiára, amit nem ismer? Divatból? A systemd-ből meg divatot csináltak? Legyen a karbantartó nyomora, ne az enyém.
Oldschool Computer - http://oscomp.hu

"Legyen a karbantartó nyomora, ne az enyém." - Igen, tehát az, hogy a unit fájlt nem (sem...) bírja rendesen megcsinálni, az a csomag karbantartójának, nem pedig a systemd-nek a "nyomora". Oké, tehát a szambás problémád _nem_ a systemd-ből, hanem a samba karbantartójának a hibája. Oké, ezek a "miért sz@r..." pontjaid tehát kilőve.

Az fsck attól, hogy "nem talált semmit", még az indulásakor azt látta a rendszer, hogy a fs "dirty", és át kell nézni. Látatlanban nem fog engedni írni értelmes és az adatintegritásra adó OS ilyen fájlrendszerre - mondhatni a tervezési célok/elvárások között előrébb szerepelt az adatintegritás, mint a crash utáni boot időtartama. Neked nem ilyenek a preferenciáid, és sajnálatos módon ezt a különbséget nem igazánlehet áthidalni - el kell fogadni.

"Még mindig ugyanazt a hardware-t használom, mint akkor. És semmi baja. Amióta nincs systemd" - és a kernel is ugyanaz? Ugyanaz a build, ugyanazokkal a paraméterekkel/opciókkal buildelve? Mert mint írtam, a crash-ek döntő többsége vagy a hardver, vagy a kernel sara. Amióta Linuxom van, azóta ez a tapasztalatom. (0.93-as kernel volt az első, ami hosszabb távon is fent volt az általam használt/üzemeltetett gépen, illetve azóta gyakorlatilag folymatosan van a kezem alatt Linuxos gép. (Néhány darabtól a többszázig, vegyesen fizikai gép és VM).

> Oké, ezek a "miért sz@r..." pontjaid tehát kilőve. Nem egészen. A köztes hatások is számítanak. Az lehet, hogy nem magának a szoftvernek volt a hibája, de a szoftver mögött meghúzódó trendnek volt az eredménye. Miért adaptáltak idejekorán valamit, amit nem tudtak kezelni? Azért mert az RH része felől irdatlan pusholás volt ez ügyben mindenfelé. És ők miért pusholták ennyire, amikor még ők sem tudnak rendesen bánni vele? > Az fsck attól, hogy "nem talált semmit", még az indulásakor azt látta a rendszer, hogy a fs "dirty", és át kell nézni. Nyilván, hiszen nem szabályszerűen lett leválasztva. > Látatlanban nem fog engedni írni értelmes és az adatintegritásra adó OS ilyen fájlrendszerre - mondhatni a tervezési célok/elvárások között előrébb szerepelt az adatintegritás, mint a crash utáni boot időtartama. Neked nem ilyenek a preferenciáid, és sajnálatos módon ezt a különbséget nem igazánlehet áthidalni - el kell fogadni. Nope, én ezzel tisztában vagyok, nincsenek ezzel ellentétes "preferenciáim". El is mondtam, hogy nem szoktam lelőni az fsck-t, mert tudom, hogy bad practice. De amikor muszáj volna azonnal bebootolni, mert épp a kellős közepén voltál valami live dolognak, akkor eléggé idegesítő, hogy a rendszer kivette a kezedből a döntés lehetőségét. Én nem windózt akarok használni, ami jobban tudja nálam, ne akarjon megvédeni saját magamtól. Ha most pont gixer lett volna a fájlrendszerben, akkor az az én bajom, amiért én vállalni is fogom a felelősséget. De ha nem és most pont fontosabb volt, hogy gyorsan visszakapjam a vezérlést? A lehetőség legyen adott, hogy ha kell, akkor élhessek vele. Én értem, hogy van olyan alak, aki ezzel visszaél és szándékosan lelövi mindig az fsck-t, de az ő hülyesége miatt ne engem büntessenek le, ne tőlem vegyék el a lehetőséget, hogy adott alkalmanként, ha gáz van, akkor mondhassam neki, hogy majd a következő bootnál (touch /forcefsck) intézem magamnak. Promise. > és a kernel is ugyanaz? Ugyanaz a build, ugyanazokkal a paraméterekkel/opciókkal buildelve? Amióta upgradeltem Devuan 2-re, azóta nem, de még jópár évig toltam ugyanazon a Jessie-n, amíg ez az upgrade megtörtént és a gondok soha többé nem jöttek elő a systemd repülése után. > Mert mint írtam, a crash-ek döntő többsége vagy a hardver, vagy a kernel sara. A PID1 összeomlása is a rendszer összeomlásához vezet. Tekintve, hogy a systemd-ben számos unsafe pointerműveletet és hasonló nyalánkságot fogtak már, így nem meglepő, hogy időnként összeomlik. > Amióta Linuxom van, azóta ez a tapasztalatom. (0.93-as kernel volt az első, ami hosszabb távon is fent volt az általam használt/üzemeltetett gépen, illetve azóta gyakorlatilag folymatosan van a kezem alatt Linuxos gép. (Néhány darabtól a többszázig, vegyesen fizikai gép és VM). Nekem is ez volt a tapasztalatom évtizedeken át, Linuxon, BSD-n, OSX-en, Solarison. (windózon nem. :P ) Aztán jött a systemd. Aztán ment a systemd és megint mondhatom ugyanezt. (Oké, random fagyás szökőévente előfordul...hát shit happenz; OSX kernel panicot életemben egyszer láttam Tigeren, van ilyen, hogy sose jössz rá, miért dőlt össze/fagyott le ilyen egyszeri alkalmakként.)
Oldschool Computer - http://oscomp.hu

> Látatlanban nem fog engedni írni értelmes és az adatintegritásra adó OS ilyen fájlrendszerre - mondhatni a tervezési célok/elvárások között előrébb szerepelt az adatintegritás, mint a crash utáni boot időtartama. Neked nem ilyenek a preferenciáid, és sajnálatos módon ezt a különbséget nem igazánlehet áthidalni - el kell fogadni.

Nope, én ezzel tisztában vagyok, nincsenek ezzel ellentétes "preferenciáim". El is mondtam, hogy nem szoktam lelőni az fsck-t, mert tudom, hogy bad practice. De amikor muszáj volna azonnal bebootolni, mert épp a kellős közepén voltál valami live dolognak, akkor eléggé idegesítő, hogy a rendszer kivette a kezedből a döntés lehetőségét.

Ó, erről eszembe jut egy aranyos történet. Kb. 2001-2004 környékén lehetett. Jött a főnököm, hogy valamit akar. Bementünk egy tárgyalóba, elővettem a laptopomat, bekapcsoltam, mert meg akartunk nézni valamit. Indult a Linux, és azt mondja, hogy hát, a /home 180 napja nem volt megnézve, akkor most fsck. Meg a /usr. Meg a /var. Aztán csak ültünk, néztük a bitkolbászt a fekete képernyőn. Pár percenként elnézést kértem, hogy ezt pont most adja elő. Ő mondjuk tök jól kezelte, de bazzeg. Hát azért milyen jól jött volna az, hogy ne most, te ostoba gép, hanem majd a következő bootoláskor ellenőrizd, köszi!

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Na ja, egyet kattintani kéne pl. a listához, ahol felsorolják tételesen, hogy mi baj vele.

Mert nem az érdekel, hogy ki mekkora listát tud összeszedni, én is tudok ilyen oldalt adni az init problémáival, nem leszünk előrébb.

Mielőtt kukáztam, ezekbe futottam bele.

Aham:

1, ez előny
2, az összeomlást 99%, hogy nem systemd okozza, hanem egyéb dolgok
3, PEBKAC, user error
4, PEBKAC, user error
5, nem a systemd okozza
6, PEBKAC, user error
Bonus: valami mást is kigyomláltál.

Borítékoltam, hogy megint csak kötekedni akarsz. Ennyit rólad, meg az ígéreteidről.

Hogyne. Nyilván.

https://iotguru.cloud

> Mert nem az érdekel, hogy ki mekkora listát tud összeszedni, én is tudok ilyen oldalt adni az init problémáival, nem leszünk előrébb. Ezt is borítékoltam, hogy egy mozdulattal le fogod söpörni az egészet. Mit értesz "az init" alatt? A SysVInit-et? Az nem "az" init, csak egy init. És egy érv ellene, nem érv a systemd mellett. > 1, ez előny Az. Ezt le is írtam. Csak a korrektség kedvéért említettem meg. > 2, az összeomlást 99%, hogy nem systemd okozza, hanem egyéb dolgok Mégis mik? Ha egyszer a systemd száműzésével abbahagyta? Valami konkrétum is van, vagy csak így látatlanban, ex-katedra kijelented, hogy nem és kész? > 3, PEBKAC, user error Micsoda? Ha az fsck futás közben lemerevedik, az user error? Ez hogy jött ki? Talán nem úgy néztem a monitorra, ahogy kellett volna, vagy WTF? > 4, PEBKAC, user error Az is az én hibám, ha szarul rakják össze a unitot? Ez nem PEBKAC, ez inkább PEIYH. > 5, nem a systemd okozza Hát mi? A mikulás? Amióta nincs systemd, azóta ez sincs. A gépem ugyanaz. Még valami? Esetleg valami, amivel ezt alátámasztod? Vagy újfennt, ez kinyilatkoztatás, amit el kell fogadni és punktum? > 6, PEBKAC, user error Az mondjuk speciel tényleg user error volt, hogy nem állítottam be az UUID-et, de az, hogy egy nem kritikus - csak adatot tároló - partíció sikertelen felcsatolásakor lerohad az egész rendszer, az systemd conceptional error. > Bonus: valami mást is kigyomláltál. Mit? Ez már a harmadik állításod, amikor látatlanban, mindennemű bizonyíték nélkül kijelented, hogy márpedig ez nem a systemd miatt volt. Bizonyítsd, ne csak állítsd. > Hogyne. Nyilván. Hát nézzük csak... Itt a topicban számos ember kritizálta a systemd-t, rajtam kívül is, sőt én most még nem is folytam annyira bele, de te rögtön engem találtál meg. Miért is? Kértél indokot, adtam egy gyűjtőoldalt, ahol minden össze van szedve. Ehhez képest közölted, hogy semmit nem találtál, mert képtelen voltál három sor szöveget elolvasni és pl. rábökni az arguments against systemd feliratra. Aztán már rögtön elővetted a szokásos tempót, hogy csak azért fikkantom, mert meg kéne tanulni. Hogy is mondtad? "Hogyne. Nyilván." Ha boldogultam a Linuxon 3-4 féle inittel, a BSD-k sajátjával, meg a Solariséval, akkor nyilván ezt nem tudom megtanulni. Azért belinkelem neked a systemd szarságainak listáját, erre lesöpröd egy akkora bullshittel, hogy a szarvasmarhaállomány tőled fog receptet kérni innentől. Aztán meg nekiállsz megmagyarázni, hogy miért nem a systemd miatt volt, az ami sem előtte, sem utána nem volt; bizonyíték nincs, csak idevágod, hogy "nem a systemd", meg "PEBKAC, user error". Hiába a systemd-vel jelentek meg a problémák és hiába szűntek meg a távoztával, ez akkor is az én hibám. Te megint csak a kötekedés végett találtál meg; valahányszor hozzámszólsz, mindig oda lyukadunk ki, hogy görcsösen azt bizonygatod, hogy nem értek semmihez, már kb. azóta, hogy megjelentem a hupon. De te aztán kurwára értesz hozzá, a 100 GB-os win10-eddel, amik a microsoft féle bundled 4k-s háttérképek, videók és ikonok miatt hízott ekkorára. Azért csak óvatosan a systemd-vel, ki tudja, abban mennyi 4k-s kép van.
Oldschool Computer - http://oscomp.hu
Nem haver, én ilyet sosem állítottam, se most, sem a múltkor, sem máskor, szóval megint hazudsz, mint az árvíz. Én nem szoktam magamat fényezni és másokat is csak akkor szoktam minősíteni, ha azt előbb ők megtették velem. Ellenben te vagy az, aki mindenkit lepancseroz, aki olyat állít, ami nem tetszik neked, holott nálad nagyobb pancsert ritkán lehet látni; szakmailag olyan nettó fasságokat vagy képes összehordani (soktíz GB-ra rúgó 4k-s képek/videók tömege DLL-ekben, vagy most, hogy a boot közben futó fsck lemerevedése a felhasználó hibája és még sorolhatnám), amiket alátámasztani sosem támasztasz alá, csak kijelented, mindennemű bizonyítás nélkül, de váltig kapaszkodsz bele, tíz körömmel és közben, személyeskedsz és fröcsögsz. Olyan sötét vagy, hogy egy szupernehéz fekete lyuk kvazárnak hat melletted és ennek ellenére akkora a pofád, hogy egy diplodocuscsorda is nehezen tudná teleszarni, hat hét alatt. Nyugodtan elmehetsz a devnullba a rosszindulatú arroganciáddal.
Oldschool Computer - http://oscomp.hu
Mint a windóz. Gond nélkül, vagy csak észre sem veszik. Lentebb szó volt egy vindózos feature-ről, ami cca. másfél évtizedig hátsóajtónak volt használható, de amúgy gond nélkül ment. Amúgy tényleg nem fogod fel, hogy vele volt, nélküle nem? 1+1=10.
Oldschool Computer - http://oscomp.hu

Sokszor azért sír a fősodratú szád, hogy nem kapsz észérveket. Most megint kaptál, és szokás szerint lesöpörted őket az asztalról.

Először azt kéred, valaki magyarázza el, mi a baj a systemd-vel. [1] Kaptál rá egy általános összefoglalót. [2] Ez neked nem elég, és inkább arról érdeklődsz, hogy mik vele a személyes problémák sőt állító kérdésben sugallod, hogy a kritizálók nem értenek hozzá, más szóval, megágyazol a személyeskedésnek. [3]

Kapsz egy jól összeszedett listát, amiből jócskán kiderül, hogy mi a baj a systemd-vel, ami az eredeti kérdésed volt. Megkapod a személyes tapasztalatokat is. [4] Ezt is lesöpröd az asztalról, immáron személyeskedéssel, user errorozással. Holott előtte még arról is érdeklődtél, hogy mik vele a személyes problémák.

Ezek után ne csodálkozz, ha minden normális ember úgy gondolja, hogy csak kötekedni jöttél. Mert ha tényleg meg akarnád érteni, hogy mi a baj a systemd-vel, akkor elsősorban te magad néznél utána, nem pedig minősítgetnéd a veled egyet nem értőket, az elit lovon ülve.

Nem tudják/akarják felfogni, hogy miért lett kitalálva/megvalósítva

Fel tudjuk fogni. Továbbá, általában nem a systemd előnyeire vagyunk kiakadva, hanem a Red Hat invazív szoftverpolitikájára, aminek a systemd az egyik ékköve.

Igaz, a legtöbb fanyalgónak a sysvinit mélyebb ismerete is hiányzik... :-)

Pont annyira, amennyire a magadfajta fősodratúak is mindent bólogatójancsiként elfogadnak, amit az ipar a Red Hat odadob eléjük. Még ha az egy darab szar, akkor is. Ugyanis a systemd a kezdeti stádiumában sokkal nagyobb bughalmaz volt, mint bármelyik klasszikus init script. A Red Hat pedig ebben az állapotában igyekezett lenyomni mindenkinek a torkán. Pedig várhattak volna vele egy-két évet, csak akkor ugye le kell normálisan tesztelni és nem használhattak volna mindenkit kísérleti nyúlnak, a Fedora és CentOS felhasználókon kívül. Más faszával könnyebb volt verni a csalánt.

Amennyi erőforrást elégettek a Linux közösségek a systemd-átállásra, annyiból bőven ki lehetett volna javítani az összes létező sysvinit script bugot. Már ha tényleg akkora bughalmazok voltak, mint amilyennek beállítod őket és nem csak arról van szó, hogy igazából te nem értettél hozzá.
 

Szerintem az a baj, hogy te máig nem érted, hogy miért a jó a systemd, mert elég sokat kellene tanulni hozzá és valamiért erre nem vagy hajlandó.

Amúgy meg pont ugyanez a rant ment volna a részedről, amikor a mindenféle vegyes init megoldásokat leváltotta az initd, de szerencsére akkor még nem voltál a közelében ezeknek a rendszereknek és ugyanaz a rant fog menni a részedről, amikor mondjuk 10 év múlva valami más leváltaná a systemd-t. Mert neked nem az a baj, hogy mi váltja le azt, ami éppen van és melyiknek mennyi az előnye vagy a hátránya, neked mindig maga a változás fáj.

https://iotguru.cloud

Ott a pont...

"Mert milyen jó is volt a bsd-style init egy scriptben mindennel, igen!  De jött a  sysvinit a maga nagy rakás könyvtárával meg csilligány bloat scriptjeivel, amiket ráadásul keresztül-kasul kellett symlinkelni, n+1 néven - katasztrófa.  Ez a bloat bughalmaz sárba tiporta a linu..., akarom mondni a UNIX-filozófiát az egyszerűségről. Mi? Hogy egy-egy szolgáltatást külön is lehetett indítani/leállítani? Hogy az indítási sorrendet egyszerű volt megváltoztatni? Hogy a futási szintekhez rendeléssel szétválasztható volt a boot több lépcsőre, vagy megoldható volt az, hogy az nfs, vagy épp a GUI csak akkor induljon el, ha azt a root egy runlevel váltással kikényszeríti? Ugyan már, a sysvinit egy csilligány bloat gányolmány, vesznie kell!"

(Hajbi a syvinit-esedés hajnalán)

:-D

Azért ebben van igazság, mire egy `ifconfig eth0 up` lefut, addigra ezeregy script hívogatta egymást, mindegyik végrehajtott valamilyen jócselekedetet, talán csak az az egy nem derült ki világosan, hogy ha én akarnék valamit spécizni (mittudomén, pl. ipx_interface add eth0 802.3 0xa9ff), azt vajon melyik disztribúcióban hová kellene tennem, hogy beilleszkedjen ennek a csodás rendszernek a "filozófiájába". (Persze azóta ez is megoldódott, nincs már olyan, hogy eth0).

Sőt: a bonyolultabb és kevésbé rugalmasoké is. De mindegy, mert mire megismered a mostanit, már jön is Legifjabb Hátulgombolós István, hogy kitalálta a dmytseS rendszert, amiben a hálózati interface-ek neve már nem is en0sp8wx23-szerű, hanem 17 CJK karakter, amiket minden bootnál véletlenszerűen oszt ki. Szerencsére addigra az UEFI is olyan fejlett lesz, hogy ROM-ból indul a Windows10, szóval a WSL és WSL2 közül lehet majd reálisan választani.

Én értem, hogy miért jó a systemd és ismerem is, amennyire kell.

Ha megfigyelted, a Red Hat arroganciája ellen emeltem szót. No meg mérnök uraságod szélsőségesen elitista, kötekedő stílusa ellen.

Kár, hogy ennyire feketén-fehéren látsz mindent, hogy aki kritizálja a systemd erőltetését, abba már azt látod bele, hogy a systemd meglétének értelmét vonja kétségbe. Amíg ezzel nem szakítasz, nem leszel képes senkivel sem értelmesen vitatkozni.

amikor a mindenféle vegyes init megoldásokat leváltotta az initd, de szerencsére akkor még nem voltál a közelében ezeknek a rendszereknek

De közelében voltam és nem ment a rant, mert az initd nem volt invazív. Tette a dolgát, amire tervezték és nem merge-eltek bele minden új főverzióval egy új rendszerkomponenst, DNS resolvert, device managert.

neked mindig maga a változás fáj

Csak akkor fáj, ha erőltetik és ezzel valami meglévő, jól működőt szétbasznak. Mint ahogy a Red Hat erőltette a systemd-t, ami nem csak nekem fájt.

Kedves balfasz úr, minden új dolog szétbassza a régit. Így volt ez, amikor az init.d bejött, szétbaszott mindent, ami előtte volt. Csak akkor még a csattogós lepkét tologattad, ezért nincsenek erről emlékeid.

Neked annyi a bajod, hogy a múltban élsz és túl gyorsak a változások. Ha visszatérünk majd erre 10 év múlva, amikor mondjuk leváltja valami a systemd-t, akkor azt látjuk, hogy a systemd lesz az etalon és bármi jön helyette, az szar lesz. Láttuk már tőled ezt a mentalitást bőven, hogy nagyjából 10 év az eseményhorizontod.

https://iotguru.cloud

Csak akkor még a csattogós lepkét tologattad, ezért nincsenek erről emlékeid.

Most is a csattogós lepkét tologatom, de ahogy most is, akkor is érdekelt a Linux és foglalkoztam is vele. Az init.d egy initrendszer volt és csak az. Nem akart több lenni. A systemd egy initrendszernek álcázott trójai faló, ami mindent is megpróbál helyettesíteni, ahogy tolják bele a commitokat, úgy egyre több mindent. Ennek az invazív fejlesztésnek pedig egyértelmű célja a Red Hat hegemóniájának és megkerülhetetlenségének az erősítése, a Linux userspace túszul ejtése a profit érdekében. Egyáltalán nem is értem, hogy képzeled, hogy az init.d-t lehetne a systemd-hez hasonlítani. Ja persze, valamivel bizonygatnod kell a "hajbazernek minden új dolog szar" nettó baromságod, ha mással nem, akkor orbitális csúsztatásokkal és nevetséges hasonlatokkal.

Ha visszatérünk majd erre 10 év múlva, amikor mondjuk leváltja valami a systemd-t

Az ilyen nevetséges előrevetítéseknél általában mindig kifelejted azt, hogy 10 év múlva valószínűleg sokkal stabilabb lesz a systemd, mint most, tekintve, hogy most is végtelenszer stabilabb, mint 2014-ben, amilyen bughalmaz volt, amikor elkezdték lenyomkodni a torkokon. Persze, hogy egy stabilabb dolog mellett fogom letenni a voksom, ha egy instabil szarral próbálják kiváltani. Az meg fejlődésmániásék szegénységi bizonyítványa, ha ebben annyit látnak, hogy nekem minden új dolog bassza a csőröm.

azt látjuk, hogy a systemd lesz az etalon és bármi jön helyette, az szar lesz

Nem feltétlenül, kivéve, ha instabil szar állapotában nyomkodják le a torkokon. Ez volt a baj a systemd-vel is és ez a baj a legtöbb új technológiával, hogy kiforratlan állapotában szeretnék adoptáltatni, kísérleti nyúlnak használva mindenkit, akit érinteni fog. Ez is a nagyvállalati arrogancia egyik mintapéldája, amikor a fejlesztés és tesztelés költségeit szeretnék kiszervezni a felhasználóknak, rosszabb esetben fizetős ügyfeleknek is (Windows 10).

Ki, de a systemd-párti urakat nem érdekli, maradnak az "a SysVInit szar" állásponton, ami lehet, hogy igaz, csak épp nem érv a systemd mellett és nem teszi semmissé a systemdben hemzsegő bugokat, koncepcionális problémákat és azt az erőszakos hittérítést, ami kíséri.
Oldschool Computer - http://oscomp.hu
A szart nem kell szó szerint venni. Akkor fogalmazzunk úgy, hogy továbbra is a SysVInit kritika a fő érve a systemd-pártiaknak, csak egy a baj, hogy az csak a SysVInit ellen érv, nem a systemd mellett. A systemd-vel meg nem az a baj, hogy többet tud, meg tanulni kell hozzá, hanem az, hogy olyat is beleöntenek, amit nem kellett volna, valamint az, hogy Poettering nem hallgat senkire sem, hanem megy a maga feje után, akkor is, ha teljes reality check error van nála. Tanulásról meg annyit, hogy volt nekem már dolgom a SysVIniten kívül is vagy féltucat initrendszerrel (runit, BusyBox, UpStart, a BSD-ké, SMF, meg még egy-kettő, amire nem emlékszem már) és egyiknél sem jelentett problémát, hogy újat kell tanulni.
Oldschool Computer - http://oscomp.hu

" olyat is beleöntenek, amit nem kellett volna  " - egyesek szerint, tedd szépen hozzá. De milyenmeglepő: a világ biza' a systemd felé halad... Még az Ubuntu is (timesyncd meg resolved vagy hogy a pékbe' hívják...).
És nem, nem a sysvinit-et, hanem a Linux-os hátulgombolósokat kritizálom,mert a sysvinit-et _sem_ tudták rendesen megtanulni/megérteni és használni. És ennek folyományaként a systemd-s unitokat is khm. hibásan/hiányosan készítik el... Mert ahhoz is tanulni kellene...

> egyesek szerint, tedd szépen hozzá. Ha neked úgy jobb... De ezek az "egyesek" közt elég komoly szakemberek is vannak. Ott van a belinkelt archívja a without systemd-nek, van rajta egy tonna cikk, amit különféle szakemberek írtak. > a Linux-os hátulgombolósokat kritizálom Én azt értem, hogy ez a Debian csomagkarbantartóit minősíti, hogy nem tudtak összerakni egy systemd unitot sem, de az, hogy ezt a micsodát adoptálniuk kellett, az nem az ő saruk. Azonfelül, fentebb adtam linket, ahol az RH is belefutott valamibe. Lehet, hogy az is a csomagkarbantartó hibája, de akkor az RH-nál hátulgombolósok dolgoznak...akkor miért kérdés, hogy miért olyan a systemd, amilyen, ha hátulgombolósok csinálják?
Oldschool Computer - http://oscomp.hu

Ki vannak húzva a javított bugok és CVE-k.

Ettől függetlenül, a Red Hat 5-7™ éve™ ezek ismeretében és ezek ellenére erőltette a systemd-t úgy, hogy akkor még jócskán mind javítatlan volt. Ez a fajta arrogancia sokkal nagyobb probléma, mint a systemd által okozott technikai nehézségek. Hogy kísérleti nyulat csináltak a  Linux közösségkből, kizárólag csak a saját önző érdekeiket szem előtt tartva.

Használjad egészséggel, föl sem merült, hogy ne használd!

Ettől teljesen függetlenül engem még dühíthet, hogy mért kell a Pötterixnek saját DNS-kliens. Vagy miért ő dönti el, hogy én indíthatok-e olyan folyamatot, ami megmarad a kijelentkezésem után. Vagy hogy miért ő mondja meg, hogy nálam hogyan hívják az Ethernet-kártyát. Vagy hogy mi a francért fut a gépemen egy bizonyos rtkit-daemon a tudtom és megkérdezésem nélkül.

Mondtunk. Lesöpörted, ignoráltad, vagy fel se fogtad. Vagy direkt csinálod. "Rég kikukázott szemét..." A 0day root privilege escalationt 3 éve nem javítják. Pedig az egy kritikus sérülékenység. De tessék, itt vannak tételesen a még nyitva lévő CVE-k. Jelen pillanatban 20 darab ismert sérülékenysége van a systemd-nek. Ennek a negyede súlyos. De ha rám hallgatsz, azt csinálsz és azt használsz, amit akarsz.
Oldschool Computer - http://oscomp.hu
Ez csak egy indok volt a sok közül. Ott van egy egész lexikonnyi adat, cikk, minden túró. Azonfelül nem is maga a sérülékenység az, ami a fő baj, hanem Poettering hozzáállása. Ehhez és még jópár abszurd hibához. De ha nem, hát nem.
Oldschool Computer - http://oscomp.hu

Na de az, hogy van más is, ami rossz, az nem mentség.

Pont azért, mert a nagy és komplex programokban szokott előfordulni mindenféle rejtett és kihasználható hiba, ezért szokás kritikus szoftverkomponenst úgy megtervezni, hogy kicsi és egyszerű legyen, ami aztán a bonyolultabb összetettebb feladatokat átadhatja más, akár nagy, komplex és hibás, viszont nem kritikus moduloknak.

Pl. egy init rendszer lehetne annyira egyszerű, hogy induláskor elindít valami scriptet valami konfig alapján. Ezt viszonylag kevés sorból meg lehet valósítani, viszonylag egyszerű átnézni és felfogni, így könnyű benne a hibákat megkeresni. Aztán az init rendszer által elindított script vagy program már lehet összetett, annak a megborulása nem borítja meg a rendszert, maximum kiesik pár funkció. Aztán az init akár újra is indíthatja a megborult programot, ha erre van igény.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nem az számít, hogy hány éves egy bug/CVE, hanem egyrészt, hogy miféle bug/CVE az, valamint, hogy javítva van-e vagy sem. Nem egy van, amit a mai napig képtelenek voltak javítani. De söpörd le őket azzal a fals érvvel, hogy több évesek. Mert ugye, ha egy javítatlan sechole több éves, akkor már biztos nem kihasználható. És ez csak az egyik fele; nem csak bugok/CVE-k vannak felsorolva, hanem cikkek is, amiket expertek írtak. De söpörd le azokat is nyugodtan.
Oldschool Computer - http://oscomp.hu

Amiknek a nagyrészéről kiderült, hogy khm. némileg több tudással felszerelkezve nemkerült volna bele a lisátba, mint ahogy elvtársanak a "mé' dobtam ki a systemd-t" problémáiról is leírtuk, hogy az bizony nem a systemd hibája ha nem jól használják... Persze hajbi begyepesedett, luddita jeleket mutató nemmérnök nemúr ezeket csak szimplán ignorálja...

tehát az, hogy a samba csomagkarbantartója nem tudta bevésni a systemd-s unit fájlba a konfig reload-ot, vagy az, hogy a rendszer indulásakor az adatintegritás fontosabb, és emiatt a "dirty" fájlrendszerekre kötelezően mefut az fsck, akkro is, ha elvtársadnak a maga alá rottyantott pécéje azonnal kéne, és nem ér rá az fsck-t végigvárni az közhely. Aha.
Persze lassanideje lenne olyan fs-t használni, ami boot _után_, rw felcsatolva is képes gatyába rázni magát egy elborulást követően (némi performanciaveszteség árán)... De tudom, az ilyen új dolgok az ördögtől valók... (Persze valójában ez nem új dolog, csak maximum a luddita begyepesedett nemmérnők nemúr és elvtársa számára...)

> tehát az, hogy a samba csomagkarbantartója nem tudta bevésni a systemd-s unit fájlba a konfig reload-ot, vagy az, hogy a rendszer indulásakor az adatintegritás fontosabb, és emiatt a "dirty" fájlrendszerekre kötelezően mefut az fsck, akkro is, ha elvtársadnak a maga alá rottyantott pécéje azonnal kéne, és nem ér rá az fsck-t végigvárni az közhely. Aha. A kontroll a felhasználó joga, nem a rendszeré. Sajnálatos, ha ezt nem érted. > Persze lassanideje lenne olyan fs-t használni, ami boot _után_, rw felcsatolva is képes gatyába rázni magát egy elborulást követően (némi performanciaveszteség árán)... Milyen FS-re gondoltál itt pontosan? > De tudom, az ilyen új dolgok az ördögtől valók... Quote pls, ilyet senki nem állított.
Oldschool Computer - http://oscomp.hu
> Az adatintegritás nem felhasználói kontroll kérdése, ezt tessék felfogni. Na, ez a nagyon nagy tévedés. Ez az én gépem és az én adataim. Ha kedvem szottyan rá, akkor ráküldöm a dd-t az sda-ra és akkor nemhogy az integritásnak, de az adatnak is lőttek. BTW, milyen FS-re gondoltál, amikor azt írtad, hogy "képes gatyába rázni magát"?
Oldschool Computer - http://oscomp.hu
> Amiknek a nagyrészéről kiderült, hogy khm. némileg több tudással felszerelkezve nemkerült volna bele a lisátba Te most a belinkelt systemd github bugreportokról és CVE-kről beszélsz? Az nem tudás kérdése, hanem bug/sechole volt a systemd-ben. Vagy a systemd kritizáló cikkekről/posztokról/emailekről? Hát az azokat író embereket tudáshiánnyal vádolni eléggé erős. Vagy úgy gondolod, hogy Linus Torvalds is tudáshiányban szenved? ("And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why.") Vagy esetleg a többi kernelfejlesztő, pl. Greg Kroah-Hartman és Ted T’so? > mint ahogy elvtársanak a "mé' dobtam ki a systemd-t" problémáiról is leírtuk, hogy az bizony nem a systemd hibája ha nem jól használják... Nem indokolt a "problémái" többes szám, mert egyedül a samba unit volt, ami valóban nem közvetlenül a systemd hibája, hanem a karbantartóé. A többinél ezt nem sikerült bizonyítani. A boot közben lemerevedő fsck-t meg user errornak minősíteni az nettó röhej. (Igen, tudom, hogy az nem te voltál.)
Oldschool Computer - http://oscomp.hu

" bug/sechole volt a systemd-ben " - És? Minden sw tartalmaz legalább egy utasítést, egy változót, egy i/o-t...és egy bugot.

Az, hogy Linux és a többi kernelpotentát kritizálja, az egy dolog, lényeges különbség van közted meg hájblézer elvtársad és köztük: ők értenek a témához, és szakmai alapon vitázak a témáról.

A boot küzben lerohadó fsck után gondolom a hardvert végigtesztelted, mert ahogy írtam volt, nekem huszonpár éve ritka kivételtől eltekintve ilyet csak a hardver és/vagy a kernel tudott összehozni, nem más. 100+ nagyságrendben üzemeltek/üzemelnek a kezem alatt systemd-s szerverek, és ha a vmware lila halála el nem viszo őket, akkor mennek, mint a Doxa.

Neked egyébként az is bajod volt, hogy kötelezően indul az fsck - ez viszont tényleg pebkac.

> És? Minden sw tartalmaz legalább egy utasítést, egy változót, egy i/o-t...és egy bugot. Na de ennyit? És ilyeneket? > Az, hogy Linux és a többi kernelpotentát kritizálja, az egy dolog, lényeges különbség van közted meg hájblézer elvtársad és köztük: ők értenek a témához, és szakmai alapon vitázak a témáról. Tedd szépen hozzá: "jobban" (értenek a témához). És ez rád is áll. Szépen elkerülted a választ, hogy vajon, ha pl. Linus szerint a systemd megbízhatatlan, akkor vajon Linus tudáshiányban szenved? > A boot küzben lerohadó fsck után gondolom a hardvert végigtesztelted, mert ahogy írtam volt, nekem huszonpár éve ritka kivételtől eltekintve ilyet csak a hardver és/vagy a kernel tudott összehozni, nem más. 100+ nagyságrendben üzemeltek/üzemelnek a kezem alatt systemd-s szerverek, és ha a vmware lila halála el nem viszo őket, akkor mennek, mint a Doxa. Ezt hívják úgy, hogy a WORKSFORME érv, ami minden csak nem érv. Volt egyébként hardwareteszt, memtest86+, hdsentinel és tsai, de nem találtak semmit. Utána repült a systemd és vele a probléma is. Ezen nincs mit magyarázni. > Neked egyébként az is bajod volt, hogy kötelezően indul az fsck - ez viszont tényleg pebkac. Nem az volt a bajom, hogy kötelezően indult, ne csúsztass. Az volt a bajom, hogy nem lehet lelőni, ha nagyon kéne.
Oldschool Computer - http://oscomp.hu

" Tedd szépen hozzá: "jobban" (értenek a témához). " - oké, sokkal-sokkal jobban értenek hozzá.

" Linus szerint a systemd megbízhatatlan " - de mégis olyan a kernel, hogy "klappol" a systemd-vel összerakott rendszerekkel... Ja, hogy a technológiai kompromisszum, mint olyan is benne van a képben...?

" Ezt hívják úgy, hogy a WORKSFORME érv " - a tied meg a !worksfome, egy darab gép és egy darab unit esetéből extrapolálva.

" Az volt a bajom, hogy nem lehet lelőni, ha nagyon kéne " - Ez technológiai, adatintegritást kifejezetten érintő döntés: igen, ahhoz, hogy _garantálni_ lehessen a fájlrendszerek épségét, ahhoz a "dirty" állapotúakat ellenőrizni kell, méghozzá úgy, hogy abba a felhasználó _ne_ piszkálhasson bele. Igen, persze, az esetek sok%-ában az fsck nem fog problémát találni, pláne egy desktop-nak (is) használt pécén, de manapság nem erre kell lőni, hanem kellemesen nagy terhelésű rendszerekre, ahol picit több nyitott fájl, illetve iops darálja a diszkeket.

> de mégis olyan a kernel, hogy "klappol" a systemd-vel összerakott rendszerekkel... Vagy nem. Ezért rantolt Linus is. > Ja, hogy a technológiai kompromisszum, mint olyan is benne van a képben...? Megint kikerülted a kérdést. Ha már a Linux kernel devek is felemelik a hangjukat, hogy amit Poettering és Sievers művel, az túlmegy minden határon, valamint egyre kevésbé tartják megbízhatónak a systemd-t, akkor most tényleg gáz van systemd háza táján, vagy Linusék tudáshiányosak? > a tied meg a !worksfome, egy darab gép és egy darab unit esetéből extrapolálva. Személyes tapasztalatot kértetek, azt kaptatok. Eddig nem tudtatok rá semmit mondani, hogy miért nem a systemd műve volt, csak azt, hogy de biztos nem az volt. > Ez technológiai, adatintegritást kifejezetten érintő döntés: igen, ahhoz, hogy _garantálni_ lehessen a fájlrendszerek épségét, ahhoz a "dirty" állapotúakat ellenőrizni kell, méghozzá úgy, hogy abba a felhasználó _ne_ piszkálhasson bele. Igen, persze, az esetek sok%-ában az fsck nem fog problémát találni, pláne egy desktop-nak (is) használt pécén, de manapság nem erre kell lőni, hanem kellemesen nagy terhelésű rendszerekre, ahol picit több nyitott fájl, illetve iops darálja a diszkeket. Ld. fentebb. Egyébként pláne nem értem, hogy miért kell egy workstationon erőltetni azt, ami szervereken, vagy szerver clustereken policy. Éles szerveren, pláne másén nem fogom lelőni az fsck-t, de a saját gépem és adataim felett had rendelkezzek már.
Oldschool Computer - http://oscomp.hu

( kleinie | 2020. 05. 21., cs – 18:06 )

Egy fura dolog jutott eszembe a hírrel kapcsolatban. Valahogy az Alien jutott eszembe. A gazdatestben növekedve, világra jöttekor elpusztítja azt. Lehet a kis pingvin belülről felemészti a májkroszoftot :-D

( Charybdis | 2020. 05. 21., cs – 18:57 )

A cikk bevezetője a legjobb:

Do you dream of being able to run your favourite Linux apps on the Windows 10 desktop? Me neither, but Microsoft is going ahead and doing it anyway.

( zslaszlo v | 2020. 05. 22., p – 10:14 )

Inkább az ms szoftvereket (pl office) portolnák linux desktopra. Kb megoldódna sok  10 ezer irodai/kormányzati gép teljes átállása linuxra. Oh wait, lehet, hogy ezért nem teszik?

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

A windows kernelt nem fogják dobni, mert azzal a rössel kinyírnák a saját teljes ökoszisztémájukat. Ennyire nem lehetnek hülyék. A windózt az emberek nem önmagáért használják, hanem a rajta elérhető szoftverekért, amit ismernek és használnak.
Oldschool Computer - http://oscomp.hu

A Windowson működő szoftverek nem az NT kernel miatt működnek. Sőt nem is kell túlnyomó részükhöz NT kernel. Jó példa a Wine, egy hasonló maga a MS által fejlesztett kompatibilitási wrapper réteg közel teljes kompatibilitást tudna. 

NT kernellel soha nem veti meg a lábát az Microsoft az ARM világban. Hiába van fél tucat ARM chip amin működik, a sikerhez kellene a többin is működni. Linux kernel már ma működik minden olyan arm chipen amin van értelme egy ilyen rendszert működtetni. Sőt MIPS, Power és egyéb archokat is támogat. 

A windows API kell nekik, amit viszont jelen pillanatban csak a windows implementál 100%-osan. A WINE a mai napig nem opció mindenkinek. A desktop világ egyik megkerülhetetlen kulcsszoftvere a Photoshop. WINE alatt ez a mai napig nem megy rendesen, a 10 éves CS5 és a 20 (?) éves 5 LE kivételével mindnek van valami nyomora (és ez a kettő is csak adott WINE-val volt jó). És ez csak egy program volt. Azt, hogy maga az ms mennyire tudna kivitelezni egy ilyen réteget, azt azt hiszem mindennél beszédesebben cáfolja, hogy egy időben volt olyan, hogy WINE for windows, mert a WINE jobban futtatta a legacy (xp, 98) alkalmazások nagyobb részét, mint a win7 és win8. Hogy jött a képbe az ARM? Az ms primer bázisa az x86-os desktop ill. szerver szegmens. Ebből élnek jelenleg. Nem arról volt szó, hogy ne dobhatnának piacra egy ARM-os Linuxot, hanem arról, hogy nem fogják kukásítani sem a windows kernelét, sem az API-ját. Se most, se máskor. Nem fognak x86-on átállni Linux kernelre. Max. ha megőrültek. Onnantól ugyanis abszolút semmi sem szól az mellett, hogy te konkrétan mikrofos Linuxon emuláld a windózt, hogy fussanak a programjaid, amikor ennyi erővel bármelyik random disztrón szophatnál vele. Arról nem is szólva, hogy az ms-nek nem csak a "lakossági" szektor a táptalaja, akiket úgy szopat le, ahogy nem szégyell, hanem a vállalati is (ms caliber corporations included), akik viszont instant versenyzongora általi halálra fogják ítélni a derék mikiszoftot, ha kirántja alóluk a platformot, amin üzemeltetnek/termelnek. Amit látunk, az nem egy paradigmaváltásnak az előkészülete, hanem egy asszimilációs kísérleté.
Oldschool Computer - http://oscomp.hu

A windows API kell nekik, amit viszont jelen pillanatban csak a windows implementál 100%-osan.
A WINE a mai napig nem opció mindenkinek.

 Nem olvastad el, mire válaszolsz, ugye?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Csak éppen senki nem beszélt arról, hogy majd Wine alatt mennek a programok. Sem arról, hogy mi a jelenlegi helyzet a windows API különböző implementációival.

Kb. azt írta Ritter kolléga, hogy az MS simán lecserélhetné a Windows kernelt, ha megcsinálnák az új kernelhez a windows API-t.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Aha. Nos ez esetben te olvastál felületesen, vagy csak elvesztetted a fonalat a posztok között. Ritter valóban azt írta, amit írtál, de a WINE-t hozta "jó" példának, én pedig erre írtam ellenpéldának, hogy a WINE maximum felemás példának jó, tehát nem érv arra, hogy lesz majd működő vindózemuláció Linuxon, hisz már most is van, mert vanni ugyan van, csak felemás. De olvashatod lentebb mrceeka véleményét, az ms szándékosan tördeli a backward compatibilityt a biztonság jegyében; na, vajon hány dolgot nem fognak implementálni (lustaságból, üzleti érdekből, balfácánságból), amit aztán a biztonságra fognak? A Linux kerneles windows egy lázálom. Ami viszont nem az, az az, hogy ha a WSL jól végzi a dolgát, akkor egyáltalán nem elképzelhetetlen az forgatókönyv, hogy az ms azzal kezd el kampányolni, hogy ne használj Linuxot, hiszen a neked szükséges kulcsszoftvereket (akár workstationod van, akár szervered) tudod futtatni windowson is a WSL segítségével. A kérdés már csak az, hogy ezúttal valóban végigtolják-e a tervet, vagy valami hülye ezt is le fogja állítani, mint anno a droidos kompatibilitási réteget, amivel pedig egy nagyon csúnya tökönlövést bevihettek volna a droidos ökoszisztémának, hiszen két szoftverparkot kaptak volna a júzerek egy helyett...dehát a mikiszoft mindig is arról volt híres, hogy ha kijönnek valamivel, amivel nagyot dobhatnának, akkor az megy a szemétbe.
Oldschool Computer - http://oscomp.hu

A Photoshop már túl van egy ilyen váltáson. Classic macOS Photoshop szintén egy gyártó saját os-ére készített kompatibilitási rétegen futott mindenki számára elfogadhatóan egy teljesen más operációs rendszeren, az OS X-en. 

Természetesen teljesen más lehetőségek vannak a Microsoft kezében ha ő csinál egy wine típusú megoldást Linux kerneles rendszerre mintha ezt külsősöknek kell megtenniük. Ahogy az Apple meg tudta ezt oldani, úgy a MS is meg tudja. 

Az ARM úgy jön ide, hogy állítólag hamarosan ARM-re vált az Apple Macintoshoknál. Az pedig szokás szerint meg fogja mozgatni a PC világot is. Az Intel mostanában hibát hibára halmoz. Ráadásul drága is a gyártóknak. Nagy érték egy OS mellett ha több platformon működik. 

A MacOS Darwin kernele forráskóddal letölthető a kezdetektől. Nem úgy tűnik, hogy ez súlyosan sértené az Apple üzleti érdekeit. 

És? Linuxon megy WINE-nal? Az ms és a backward compatibility. Ezt szerintem hagyjuk. Asszem nem ment át, hogy eddig sem jeleskedtek vele, semmi garancia nincs rá, hogy most hirtelen jobban menne nekik. Az intel nem az egyetlen x86 gyártó a világon, ott van még az AMD is, akinek mostanság egyre jobban megy. Az ARM meg tudtommal egyelőre nem tud olyan erős CPU-kat gyártani, mint a high-end x86-osok, valamint a fordítóprogramoknál is az x86 a fő csapásirány. Arról nem is beszélve, hogy az ARM CPU-kon nem fut a régi szoftverpark, amit az emberek használnak. És? Nem az volt a kérdés, hogy valaha kinyitják-e a windowst és ha igen, akkor az rossz lesz a mikiszoftnak, vagy sem, hanem az, hogy nem fogják Linxura cserélni a windowst.
Oldschool Computer - http://oscomp.hu
De itt API backward compatibilityről beszélünk, nem formátumokról. Magyarázd akkor meg, hogy miért volt kompatibilisebb a WINE a legacy (98, xp) appokkal, mint a win7 és 8. Amúgy csatlakozni akarsz az előtted szólókhoz, akik szerint az ms rövidesen Linux kernelre vált?
Oldschool Computer - http://oscomp.hu

Miért váltana Linuxra az NT subsystem? Ritter szerint mert akkor a többi ARM procit is támogatná (mármint a Windows, az appok persze nem).

Először is a linkelt oldal nem támasztotta alá az állítását - tévedhetett is. Elég sok appcompat történettel foglalkoztam, az általános kép az bennem, hogy többnyire nem szakértő próbálta életre lehelni az újabb Windows-on a régi alkalmazásokat és nem használta az erre szolgáló eszközöket. 

Az egyik legnagyobb magyar cég korabeli Vista migrációs elemzésének ismeretében állítom, hogy az appcompat sosem volt igazi show stopper, kivéve az esetet, amikor az alkalmazás szállítója kijelentette, hogy márpedig az ő X verziójuk nem támogatott az új Windowson (hiába működik), csak az X+2 verzió, amire épp kedvezményesen lehet méregdrága licencet venni.

Üdv,
Marci

> Miért váltana Linuxra az NT subsystem? Ezt tőlem kérdezed? Én végig azt mondtam, hogy ez egy marhaság, kinyírnák saját magukat, ha ezt tennék. > nem használta az erre szolgáló eszközöket. Mert ehhez külön eszköz kell? WINE on windows alatt csak duplaklikk. > Az egyik legnagyobb magyar cég korabeli Vista migrációs elemzésének ismeretében állítom, hogy az appcompat sosem volt igazi show stopper Ha már szóbahoztad a vistát, na, az is annyi kompatibilitási nyűtől szenvedett, mint égen a csillag. Tényleg nem volt showstopper, végül is csak épp megbukott az oprendszer, az emberek nem váltottak xp-ről. (Tudom, volt annak ezer más baja is, ami ezt előidézte, de ez is elég kardinális ok.)
Oldschool Computer - http://oscomp.hu

Miért nyírnák ki magukat? 

Komolyan át kellene gondolni a érveket. 

Volt egy Ballmer, aki hosszú ideig tolta a szoftver-hidegháborús mantrát de ő már szerencsére a múlt. 

Sokadjára citálom az Apple példáját, akik egy teljesen nyílt forráskódú kernelre építik az operációs rendszerüket. Ezzel nem nyírják ki magukat, semmi jele ennek. Már régen nem a Windows licencek jelentik a fő bevételi forrást. Nem mintha nem lehetne pénzt szedni egy Linux alapú Windows után. Természetesen egy Linux kernel alapú Windows nem azt jelenti, hogy onnantól skinnelt Gnome desktop, meg apt-get. :) És perdarab licencdíj szedése nélkül is lehet jó üzlet egy Linux kernel alapú OS, lásd Android. 

Érv lehetne még, hogy Linux kernel fejlesztése nem a Microsoft kezében van. Az Android példája azt mutatja, hogy ez egyáltalán nem jelent stratégiai hátrányt a Googlenek. 

Nagyon sok lépést tett a Microsoft az open-source világ felé, sőt konkrétan azon belül a Linux világ felé. Ma már szerintem nem abszurd gondolat a jövőbeli Linux alapú Windows lehetősége. Természetesen nem állítom, hogy ez az nyilvánvaló jövő a MS-nél. De a korábban elképzelhetetlen ma már szerintem egyáltalán nem lehetetlen esemény. 

> Sokadjára citálom az Apple példáját, akik egy teljesen nyílt forráskódú kernelre építik az operációs rendszerüket. Tévedés. A macOS kernel nem nyílt; csak a Darwin core az. Azonfelül még mindig nem értem, hogy hogy jön ez ide. > Ezzel nem nyírják ki magukat, semmi jele ennek. De ilyet senki nem is mondott. Még egyszer: nem az volt a kérdés, hogy kinyitják-e valaha a windows kernelét, hanem, hogy lecserélik e Linuxra. Az, hogy a kinyitás reális-e, vagy sem, rossz lenne-e a mikiszoftnak vagy sem, azt nem tudom. De az sehogy sem kapcsolódik a windows kernel Linux kernelre cseréléséhez, hogy a macOS kernele részben nyílt; cseréről volt szó, nem nyíltságról. Ha kinyitják a windows kernelt, attól még minden alkalmazás megy tovább windowson, de ha lecserélik, akkor megdöglik mind. > Már régen nem a Windows licencek jelentik a fő bevételi forrást. Ez is irreleváns. Tök mindegy, mi a fő bevételi forrás, ha nem fognak menni az alkalmazások, akkor semmilyen bevételük nem lesz. > Érv lehetne még, hogy Linux kernel fejlesztése nem a Microsoft kezében van. Az Android példája azt mutatja, hogy ez egyáltalán nem jelent stratégiai hátrányt a Googlenek. De ez is hogy jött ide? A google a kezdettől fogva Linuxra alapozott. Értsd meg: nem a nyitás ölné meg a mikroszoftot, hanem a csere. > Nagyon sok lépést tett a Microsoft az open-source világ felé, sőt konkrétan azon belül a Linux világ felé. Ja, hogy bekebelezhesse, nem azért, hogy csatlakozhasson. > Ma már szerintem nem abszurd gondolat a jövőbeli Linux alapú Windows lehetősége. Természetesen nem állítom, hogy ez az nyilvánvaló jövő a MS-nél. De a korábban elképzelhetetlen ma már szerintem egyáltalán nem lehetetlen esemény. De. Abszurd. Még egyszer, nem a nyílt windows volt a téma, hanem a Linux alapú windows.
Oldschool Computer - http://oscomp.hu

Én pont a jelenlegi Windows kódjainak nyitására nem látok nagy esélyt, mert valószínűnek tartom, hogy ott sok kód nem MS tulajdon, és így csak egy foghíjas, a kódnyitás pillanatában nem működő valamit tudnának kiadni. Kábé mint az OpenSolarisnál csak sokkal nagyobb lyukakkal. 

Nem kérdezem, ebben egyetértünk.

Igen, külön eszköz kell. A kulcsszó: biztonság. Ami wine-nál nem szempont, a Microsoftnak viszont igen: képes volt egy majdnem kész OS-t is kidobni miatta...

Vista appcompat állításra HW-compat példát hozni nem elegáns.

Üdv,
Marci

Biztonság? Az ms és a biztonság? Ez tényleg no comment. Ráadásul ez esetben még csak nem is "biztonságról" beszélhetünk, hanem "biztonságoskodásról", ugyanis ha azért dobnak ki egy legacy API interface-t, mert az nem biztonságos, akkor miért teszik lehetővé, hogy külön eszközzel ugyanúgy elérhető legyen, ezzel tökönrúgva a "biztonságot"? Ha pedig abban a bizonyos eszközben meg van oldva a probléma, akkor ennyi erővel az eredeti helyen is orvosolhatták volna... Nem mintha bármilyen szinten is érdekelne, hogy mi elegáns, de ettől függetlenül megjegyzem, hogy egyáltalán nem HW kompatibilitásos példát adtam, hanem olyat, ami azt taglalta, hogy az xp alatt futó szoftverek nem akarnak menni vista alatt.
Oldschool Computer - http://oscomp.hu
Pl. már 10 éve is minden költői túlzás nélkül ezerszer annyi vírus volt rá, mint a többiekre összesen, és anno, amikor még a vírusírtócégek nem csítelték el az eredményt, hogy a teszteken jól szerepeljenek, az ms féle vírusírtók menetrendszerűen sereghajtók voltak a biztonság szempontjából (és ez valószínűleg ma is így van, csak ma már nem lehet a tesztekkel kimutatni). Pl. az egész windows hemzseg a javítatlan biztonsági résektől (jelen pillanatban 1111 db ismert, aminek közel fele kritikus, vagy legalábbis súlyos), csak most áprilisban hét újabb kritikusat ismertek el. Pl. a SmartScreen csak az ember bosszantására jó, hogy a homebrew programodat leblokkolja, de a megfelelő aláírással bíró malware-t átengedi. Pl. az NTFS beépített titkosítóját használva, a windows újratelepítése esetén az összes adatot bukja az ember, de amúgy a BitLocker féle titkosítással sem érsz túl sokat. (Konteó: vajon az amcsi kormány hány sérülékenységet tetetett bele a titkosításba, hogy ők hozzáférhessenek?) Pl. a windows ASLR-jének egy sereg nyavalyája van. Pl. a windowsos mobilokat egy SMS-sel is meg lehetett borítani. Pl. az ms a saját internetes jelenlétét sem tudja megfelelően megvédeni (670 hijacked subdomains). Pl. ott volt az a sztori, amikor a WU eltérítésével rakosgattak malware-t az emberek gépére. Pl. itt van ez a sztori is. És végül egy saját sztori: Ismertem egy rendszergazdát, aki win10-et használt és a OneDrive-ba szinkronizálgatta a fontos dolgait. Egyszer a Defender és a SmartScreen ellenére valahogy bekapott zsarolóvírust (nem tudni, hogy hogy), ami letitkosította az adatait, ami egy dolog, de a win10 utána kérdés nélkül felszinkronizálta a letitkosított adatokat a OneDrive-ra. A srác azóta offline backupot használ.
Oldschool Computer - http://oscomp.hu
Számára el, mert nem tudja őket kicsomagolni. Azt nem tudom, hogy a techsupportot felkereste-e, de decryptelni ők sem fognak tudni segíteni. Azt sem tudom, hogy az ilyenekre kitalált Files Restore be volt-e kapcsolva, vagy, hogy egyáltalán volt-e már akkor Files Restore (nekem 2019 január 15.-én mesélte a srác, vagyis a sztori 2018-as, vagy annál régebbi, úgyhogy fifty-fifty).
Oldschool Computer - http://oscomp.hu
Ennyi? Erőletetett fölényeskedés? Ez nem válasz, ez szánalmas vergődés. 2018 februárjában reportolták a hibát, 5 hónappal később még mindig voltak, akiknek nem ment, úgyhogy ebbe simán belefuthatott. Álhír meg akkor lenne, ha nem történt volna meg a dolog, nem akkor, ha esetleg user error is közrejátszott benne. FYI: a SmartScreenen és a Defenderen átmászó ransomware és a letitkosított fájlok felszinkronizálása teljesen független attól, hogy a verzióelőzmények működtek-e akkor, vagy sem. Esetleg van valami válaszod a többi linkre is, amit összeszedtem? Vagy ennyi volt? Kiböktél egyet, amit esetleg rá lehet kenni user errorra, aztán ezen lovagolsz, mintha a többi nem is létezne?
Oldschool Computer - http://oscomp.hu

Örülök, hogy sok mindent összeszedtél, szép munka. Nem mondtam, hogy nem létezik a többi. Csak nem cáfolja azt az állításomat, mi szerint a Vista biztonsági fejlesztései törték meg a legtöbb korábbi alkalmazást és hogy ezeket alkalmazás-specifikus SHIM-ekkel jól és ráadásul biztonságosan lehetett kezelni. Továbbá ugyanezek a biztonsági fejlesztések hiányoztak és hiányoznak a wine-ból, ezért valóban duplaklikkel indulnak az ilyen alkalmazások.

Üdv,
Marci

> Csak nem cáfolja azt az állításomat, mi szerint a Vista biztonsági fejlesztései törték meg a legtöbb korábbi alkalmazást és hogy ezeket alkalmazás-specifikus SHIM-ekkel jól és ráadásul biztonságosan lehetett kezelni. Az a válasz nem is neked, hanem Tassadar "miért nem fér össze az MS és a biztonság" kérdésére ment. Én azt az állításodat egyébként nem is próbáltam cáfolni sehol sem, hogy milyen fejlesztések törték el a vistában a kompatibilitás (hol láttál ilyet?); én egyfelől azt mondtam, hogy eltört egy csomó minden - tehát az ms múltja nem éppen folttalan a backward compatibility terén (főleg, mivel ez nem egyedi eset) - másfelől meg azt, hogy felesleges a biztonságra kenni a backward compatibility szándékos eltörésének megindoklását, mert ettől nem lett biztonságosabb (ilyen memóravédelmi bugokkal, meg a fentebb belinkelt ASLR mizériákkal nem is csoda). De most komolyan, hajbazert sokan ekézik itt, hogy mindig a butítással jön, de hát hány tonna feature-t szedtek ki a vistából, ami az xp-ben még benne volt? Ezt is mind a biztonság oltárán? > Továbbá ugyanezek a biztonsági fejlesztések hiányoztak és hiányoznak a wine-ból, ezért valóban duplaklikkel indulnak az ilyen alkalmazások. Tény, a WINE ebből a szempontból ementáli. De ettől még a windows nem lesz biztonságos, azonfelül itt a seamless integration volt a kérdés: a felhasználó számára nem az a kompatibilisebb, ha a legacy appjait elméletileg biztonságosabb mechanizmusokon keresztül kell futtatnia, hanem ha rábök, mint régen és megy.
Oldschool Computer - http://oscomp.hu
Tehát a biztonság kedvéért butították rommá az xp-hez képest? Akkor mi eszik meg 15 GB-ot benne, ha a biztonság kedvéért dobáltak ki belőle egy raklap dolgot? Ugye nem azt akarod mondani, hogy a bevezetett biztonsági mechanizmusok miatt kell tízszer annyi hely?
Oldschool Computer - http://oscomp.hu
Hát végül is, tényleg azt mondtad, hogy "szerinted"...hát szerintem meg leginkább nehezményezték a hardwaregyártók, hogy az xp eldöcög egy sokéves, 64 MB-os, 233 MHz-es P2-esen is, valamit tenni kéne; az ms meg ráeresztett egy csomó világmegváltó ötletekkel tele lévő figurát, hogy csináljatok, amit akartok, írjátok meg az egészet dotnetben, vagy amit akartok. Ami hasznos - és használt! - volt, azt kihajigálták, mert az úgy nem jó, de lett benne egy tonna marhaság, ami a kutyának nem kellett, de jól mutat a CV-ben, meg a featurelistában. TL;DR: üzleti érdekből lett a vista olyan, amilyen. Vagy, B verzió, nem volt külső nyomás a hardwaregyártóktól, csak simán ráeresztették a világmegváltókat a windowsra, mert valaki a felsővezetésben kattant volt (Ballmer?).
Oldschool Computer - http://oscomp.hu
Ez nem válasz, ez személyeskedés. Az válasz, ha kifejted, mik azok a marhaságok. Vagy az is válasz, ha tudsz ellenindokot mondani, hogy mitől hízott 10x akkorára a vista az xp-hez képest (1.5 GB vs 15 GB), miközben ennyi mindent kihajigáltak belőle.
Oldschool Computer - http://oscomp.hu

tudsz ellenindokot mondani, hogy mitől hízott 10x akkorára a vista az xp-hez képest (1.5 GB vs 15 GB), miközben ennyi mindent kihajigáltak belőle.

Egy tipp:

amellett, hogy ennyi mindent kihajigáltak belőle, lehet, hogy tettek bele más egyebet?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

de lett benne egy tonna marhaság, ami a kutyának nem kellett, de jól mutat a CV-ben, meg a featurelistában.

Néhány példát kiragadva a cikkből olyan feature-ökre, ami szerinted marhaság, de jól mutat a CV-ben:

  • Remote Assistance (hadd sétáljon a helpdesk gépről gépre, úgyis ráfér a mozgás az irodistákra - rosszabb esetben vegyen repjegyet, ha éppen üzleti úton van a user, legalább megvan a nyaralás is)
  • Meeting Space (aka fájlok egyidejű multiuser szerkeszthetősége, de megmondta a cikkíró, hogy "I don't have any use for it in my daily life", szóval marhaság)
  • ReadyBoost (2006-ban ugye minden valamirevaló usernek volt már SSD-je, tök fölöslegesek ezek a trükkök, nem?)
  • Search Indexing (az igazi programozó nem keres, hanem talál, így aztán felesleges marhaság, csak a CV-nek készült)
  • Offline Files (2006-ban nemcsak SSD-je volt mindenkinek, hanem mobilinternete is, így aztán felesleges cache-elni a munkához szükséges fájlokat)

Elfogadom, hogy a te számítógéphasználati szokásaid mellett ezek nem adnak értéket neked, de így kijelenteni pl. a network share fájlok cache-elésére, hogy "marhaság, ami a kutyának nem kellett, de jól mutat a CV-ben", kicsit erős. :) Ne felejtsd el, hogy a Vista RTM 2006-ban jött, mostmár leszarom, hogy van-e local cache, mert a korlátlan mobilnetes SIM-kártya már belemegy a laptopomba, de 10+ évvel ezelőtt ez még nem volt evidens.

Kicsit kevesebb sértődött szarkazmussal talán hatásosabb lett volna... Egy kérdés, ami mindre vonatkozik: ezeknek a jelenléte tényleg indokolja a 10x-es növekedést? Aztán nézzük sorba: > Remote Assistance Ööö...te gelei...ez már az xp-ben is benne volt. Gondolom te is belátod, hogy elég érdekes lenne a vista megnövekedett rendszerigényeit egy olyan szoftver jelenlétével magyarázni, ami már előtte is része volt a rendszernek. Aztán - csak mert ugye a biztonság volt a fő téma - ezt a micsodát hátsóajtónak lehetett használni 2018 márciusáig, egészen a kezdetektől fogva. Úgyhogy igen: ezt tényleg kár volt. Megcsinálni is, meg neked felhozni is. > Meeting Space Ez ugyan tényleg egy hasznos cucc lehet, de ez pont az, amire a legtöbb júzernek tényleg nincs szüksége, tehát nincs mit csodálkozni rajta, ha a paraszt feleslegesnek ítéli és kikapcsolja. > ReadyBoost A ReadyBoost pont az a szoftver, ami egy olyan problémát old meg, ami vele együtt debütált: a vista brutális memóriaéhségéből származó belassulást, amikor elfogyott a RAM. A hatékonyságáról meg annyit, hogy jobban jártál, ha vettél még memóriát a vista alá. Sebességügyileg is, meg anyagilag is. Ez persze a többi operációs rendszerre is igaz, csak az OSX-ek, korábbi windowsok, Linuxok és egyebek nem faltak föl indulásként 2 GB RAM-ot, így náluk kevesebb memória is elegendő volt, hogy tudjanak rendesen cache-elni. Szóval leginkább nem kellett volna így elcseszni a vistát és akkor erre sem lett volna szükség; úgy könnyű valamit hasznosnak kikiáltani, ha előtte direkt teremtek egy problémát, amit megoldhatok vele. > Search Indexing Ez megint az, ami tényleg hasznos lenne, ha rendesen megcsinálták volna, ami nem sikerült, mert akkor is és még most is csak úgy belassítja a rendszert (#1, #2, #3, #4, most többet nem linkelek, találhatsz még tonnájával), valamint menetrendszerűen felzabálja a rendelkezésre álló memóriát (#1, #2, dettó lehet még keresni) és CPU időt (#1, #2, ebből is lehet még keresni), hogy az esetek többségében jobban jársz, ha kikapcsolod a francba. (Egyébként többségében direkt answers.microsoftos linkeket adtam, lehet lecsekkolni, hogy a hibabejelentőn kívül hányan bökték még be, hogy nekik is ez a problémájuk.) Úgyhogy ebben a formában ezt is kár volt. > Offline Files Ez megint csak hasznos volna...csak ez a cacheing témakör nem nagyon akar sikerülni szegény miklósszoftéknak (ebből már végképp had ne linkeljek be többet)... Szóval ebben a formában ezt is kár volt. > Elfogadom, hogy a te számítógéphasználati szokásaid mellett ezek nem adnak értéket neked, de így kijelenteni pl. a network share fájlok cache-elésére, hogy "marhaság, ami a kutyának nem kellett, de jól mutat a CV-ben", kicsit erős. :) Most kiemeltél kemény öt dolgot a vista felesleges baromságai közül (amiből egyébként négyről kiderült, hogy vagy abban a formában ahogy, vagy abszolúte tényleg feleslegesek voltak) és máris indokolva van a vista batár rendszerigénye? Azonfelül az állítás csak annyi volt, hogy belekerült egy csomó marhaság, de azt senki nem mondta, hogy minden ami bekerült a vistába, az haszontalan volt, ezt te láttad bele a nagy sértődöttségben. (Egyébként kár volt vastagon kiemelni, hogy nekem, mert én nem használok windózt, még mindig.)
Oldschool Computer - http://oscomp.hu
Itt ti vagytok a windows expertek, nem én, ezt nektek illett volna tudni, nem nekem. gelei kiemelte, én meg utánanéztem, hogy mi ez. Te egyébként mindig így vitatkozol, hogy kiböksz egy halomból egyetlen dolgot és abba próbálsz belekötni? Ráadásul mindig a legérdektelenebbe? Ez ma már a második ilyen próbálkozásod.
Oldschool Computer - http://oscomp.hu

Nem vitatkozok momentán, ezt helyesen vetted észre. A vitához szükséges a másik fél minimális nyitottsága a vitapartner érveinek megértésére, akár elfogadására. Csináltam is Veled feljebb egy darabig, de reménytelennek ítélem a helyzetet, sajnálom.

Így csak néha beletrollkodok, ha már nem bírok magammal! ;-)

Látod, magad mondod, hogy ismeretlenül, pár netes keresésből ítéled meg egy-egy technológia hasznosságát. Külön kedvenced a vele kapcsolatos hibák lobogtatása, mintha az perdöntő lenne a hasznossága szempontjából.

Üdv,
Marci

> Nem vitatkozok momentán, ezt helyesen vetted észre. A vitához szükséges a másik fél minimális nyitottsága a vitapartner érveinek megértésére, akár elfogadására. Csináltam is Veled feljebb egy darabig, de reménytelennek ítélem a helyzetet, sajnálom. Milyen érveidnek a megértésére célzol? Az ásítozásra? Nagyon nagy szavakkal dobálózol itt, csak teljesen falsul hangzik, mert érveid neked nem nagyon voltak. Fentebb sem. Éppen erről beszéltem, hogy ott is belekötöttél kb. a leglényegtelenebb pontba. A verzióelőzmények felhozása ugyan még egy értelmes megnyilvánulás volt, de a rá kapott ellenérvre már csak üres fölényeskedésre futotta. Aztán meg semmire. Semmire se. Max. arra, hogy szerinted. Meg egy kis hajbazerezésre. Erre van ekkora mellényed? Te voltál a vitaképtelen nem én. > Így csak néha beletrollkodok, ha már nem bírok magammal! ;-) Azaz nem sikerült a szerecsenmosdatás és marad a mellébeszélés, meg a görcsösen erőltetett lazaság, leszaromság, meg a vitapartner fikkantása, ha már az érveit nem sikerült kikezdeni. > Látod, magad mondod, hogy ismeretlenül, pár netes keresésből ítéled meg egy-egy technológia hasznosságát. Én nem ezt mondtam, ezt te próbálod belemagyarázni. > Külön kedvenced a vele kapcsolatos hibák lobogtatása, mintha az perdöntő lenne a hasznossága szempontjából. Hát ha valami annyira hemzseg a hibáktól, hogy használhatatlan, az hogy lehetne hasznos?
Oldschool Computer - http://oscomp.hu

Milyen érveidnek a megértésére célzol? Az ásítozásra?

A múltkor belinkelt Bill Gates utálók klubja, vagy mi a fene után bocsánat, de talán érthető, hogy feleslegesnek érzem a vitára fordított időt, és gondolom Marci is hasonlóan van ezzel, azért ásítozik. Egyezzünk meg abban, hogy te utálod a MS-t, mások meg nem, és ezzel a világon semmi probléma nincs. Én is rühellek egy csomó olyan dolgot, ami mások szerint jó, pl. a seafood minden formáját, de ettől még nem megyek oda másokhoz az étteremben leszarozni, amit esznek. :)

szerk: amúgy a félreértések elkerülése végett, szerintem a reverse-fanclubbal sincs semmi baj, valamennyire szórakoztató is, csak teljesen felesleges arra pazarolnunk az időnket, hogy egymást próbáljuk meggyőzni. További szórakoztató tartalom a témában: https://www.youtube.com/watch?v=7SSOCabqCKI

> A múltkor belinkelt Bill Gates utálók klubja, vagy mi a fene után bocsánat, de talán érthető, hogy feleslegesnek érzem a vitára fordított időt, és gondolom Marci is hasonlóan van ezzel, azért ásítozik. Ez. Egy. Nagyon. Láma. Kifogás. Továbbá személy elleni érvelés, ami a lámaság legbiztosabb jele, amikor nincsenek ellenérveid és inkább a vitapartner személyét próbálod támadni, az érvei helyett. Eléggé szánnivaló... Marci meg azért ásítozik, mert megpróbálja azt a képet kelteni, hogy ő kurwára leszarja, meg csak röhög az egészen, holott ismét csak az történt, hogy sikertelenül megpróbálta megvédeni azt, amin nincs mit védeni, aka. szerecsenmosdatott és felsült. Aztán megpróbálja megmagyarázni, hogy ő csak trollkodik. Persze...és ezt mindenki el is hiszi. > Egyezzünk meg abban, hogy te utálod a MS-t, mások meg nem, és ezzel a világon semmi probléma nincs. Én is rühellek egy csomó olyan dolgot, ami mások szerint jó, pl. a seafood minden formáját, de ettől még nem megyek oda másokhoz az étteremben leszarozni, amit esznek. :) Egy: Nem én mentem oda leszarozni, hogy ti mit esztek, hanem ti jöttetek ide; hát nem tűnt fel, hogy ez az én topicom, nem tűnt fel, hogy ti szóltatok először hozzám? Ti jöttetek ide, nem én mentem oda. Más szemében a szálkát, magadéban az Endort se. Kettő: Nem tudom, feltűnt-e, hogy most már - ismételten - a szakmai rész - itt pl. a vista fals biztonsága, vagy az elhízottsága, ill. annak oka - kiveszett a szálból és most már megint a sokadik poszt arról szól, hogy én ilyen, meg olyan vagyok és megpróbáljátok ezt megideologizálni azzal, hogy én ez, meg az vagyok. Ti vagytok, akik személyeskedtek és engem vádoltok haterkedéssel? Mi ez az alpári kettős mérce? Kit minősít ez szerinted? Három: Nagyon megható ez a teamwork, ahogy egymás posztjait lájkolgatjátok a nagy sértődöttségben, hogy "dejó'megaszontaneki" (ebből is látszik, hogy mennyire fals ez a nagy lazaság, amit mutatni próbáltok; ha leszarnátok a fejem, már rég itthagytatok volna), mert érveitek nem nagyon vannak; egy-két értelmesebb meglátáson, vagy információmorzsán túl leginkább kerestek valamit, amibe bele lehet kötni, aztán azon lovagolni, vagy csak megpróbáltok rámsütni valamit, hátha hiteltelenné lehet tenni vele mindent amit mondtam, vagy linkeltem. (Szerinted ettől semmis lesz a tény, hogy több, mint 1100 biztonsági rés van a windowsban, amiből több, mint 500 kritikus vagy súlyos? Vagy az, hogy az xp 1.5 GB volt a vista meg 15 GB?) Feltételezem, hogy te +1-ezted le mrceeka fentebbi "észrevételét" (bár ha nem, az is mindegy a továbbiak szempontjából), miszerint 'Az előbb még azzal linkelted a cikket, hogy "lett benne egy tonna marhaság", most meg rájössz, hogy "ez már az xp-ben is benne volt."', hát fordítsuk már meg a dolgot: én - a köcsög UNIX-os - legalább rájöttem, ti meg - a nagy windows expertek - nem. Még utólag sem. Te csak becitáltad, hogy de mekkora jóság debütált vele a vistában, mrceeka meg belájkolta. Kinek égő ez inkább, szerinted? Szerintem nézzetek egy kicsit tükörbe.
Oldschool Computer - http://oscomp.hu

Ez. Egy. Nagyon. Láma. Kifogás. Továbbá személy elleni érvelés, ami a lámaság legbiztosabb jele

Nem. Kifogásnak. Szántam. Ezek szerint nem tetszett a YT videó sem? Pedig szerintem vicces, pár exkollégának is átküldtem már az MS-es időkből. 

hát nem tűnt fel, hogy ez az én topicom

Őszintén? Nem. Nem szoktam nézni, ki az OP, csak ha valamiért releváns.

Nagyon megható ez a teamwork, ahogy egymás posztjait lájkolgatjátok

Ebben a threadben asszem egyetlen lájkot nyomtam, szarok rá, hogy állnak a lájkok. Mi vagyok én, Instagram celeb?

> Ezek szerint nem tetszett a YT videó sem? Utólag szerkesztetted hozzá, amikor már írtam a posztot. Most lecsekkoltam, jópofa, csak semmi köze ahhoz, amiről szó volt. Az még mindig egy nagy nulla, mint ellenérv, hogy "nincs kedvem mshaterrel vitatkozni". Főleg, ha érvei is vannak, ugye? > Őszintén? Nem. Nem szoktam nézni, ki az OP, csak ha valamiért releváns. Ez nem változtat a tényen, hogy nem én mentem oda a ti asztalotokhoz kötekedni, hanem fordítva. Ha az OP-ot nem is nézted, azt csak vissza lehet nézni, hogy minden egyes subthreadben ti szóltatok először hozzám. > Ebben a threadben asszem egyetlen lájkot nyomtam, szarok rá, hogy állnak a lájkok. Mi vagyok én, Instagram celeb? Nem tudom, hogy mi vagy. De mondtam, hogy igazából mindegy is, hogy ki volt az, mert ez nem változtat azon, hogy nektek kellett volna tudni, hogy a RA miben debütált, nem nekem, de ennek ellenére az orrom alá lett dörgölve, hogy "most jössz rá?", holott ti rá sem jöttetek. Mondom, egy kicsit magatokba nézhetnétek.
Oldschool Computer - http://oscomp.hu

Nem mondtam, hogy "vitaképtelen" vagy. Azt mondtam, hogy "A vitához szükséges a másik fél minimális nyitottsága a vitapartner érveinek megértésére, akár elfogadására." Ezt tartom. Az alábbiak miatt mondtam:

Három beszélgetési szálba kapcsolódtam be:

  • Az elsőben mutattam egy 27 éven átívelő bináris, API és file-formátum backward compatibility példát.
  • Te ezt csak file-formátum kompatibilitásnak értelmezted (tévesen) és hoztál egy soha-meg-nem-valósult projekt oldaláról egy légből kapott állítást appcompatra, hogy magyarázzam meg.
  • Érdemben válaszoltam neked, saját tapasztalatokat beleszőve, bemutatva a leggyakoribb inkompatibilitási szcenáriót (amikor is a 3rd party vendor direkt nem tette kompatibilissé a régi verziót). Szándékosan a Vistát hoztam elő, mert appcompat kérdésben az volt a hiedelem szerinti "sötét ló".
  • Te rákérdeztél, miért kell Windowson erre eszköz és linkeltél egy cikket, amiben hw-compat példa volt meg olyan appcompat, amilyenről én már korábban írtam.
  • Elmondtam, hogy a biztonság miatt kellett külön eszköz ehhez - bizonyos régi képességek használatát biztonsági okokból korlátozta a rendszer, speciális eszköz kellett ahhoz, hogy alkalmazás-specifikusan ezt a korlátozást feloldja valaki.
  • Erre Te "Biztonság? Az ms és a biztonság? Ez tényleg no comment."
  • Itt kiszálltam, Részedről ugyanis végetért a vita.

A másodikban (vesztemre):

  • Írtál egy irdatlan listát válaszul arra, hogy "miért nem fér össze az MS és a biztonság", benne például azzal az érvvel, hogy nem lehet Windowson visszaállítani a titkosított file-okat, ha nincs lementve a titkosítókulcs... (Más rendszeren se...) A végére írtál OneDrive sztorit, amit egyik részről eleve viccesnek találtam, mert a OneDrive nem backupra való, másik részről meg erősen azt sejtette, hogy se az illetőnek, se Neked nincs tudomásotok a verzióelőzményekről.
  • A sejtésemet igazolandó, rákérdeztem erre: "És elvesztek az adatai?"
  • "Számára el" mondtad te
  • Ezzel beigazolódott a sejtésem, ezt meg is írtam Neked, hozzátéve, hogy ez a sztori így, sajnos álhír.
  • Erre Te elővettél egy üzemzavarról szóló bejelentést, hogy biztos neki sem működött - erről eddig szó sem esett.
  • Mivel ennek pont semmi köze nem volt az eredeti történethez (ahol is valaki nem arra való eszközt használt úgy, hogy nem is ismerte), ezért jeleztem, hogy nagyon fárasztó és unalmas a reakciód: "*ásít*"
  • Ezt persze félreértetted és fölényeskedésnek vetted.
  • Bánva a dolgot érdemben válaszoltam újra.
  • Te pedig kezdtél átnyergelni a Vistából kiszedett funkciók kérdésére
  • Erre is érdemben mondtam el a véleményemet.
  • Erre jöttél, hogy mi eszik 15GB-ot benne
  • Mondtam, hogy nem tudom. 
  • Erre jött a Vista bloatról szóló okfejtésed.
  • Ez a téma már számtalanszor túl volt rágva hajbazer környékén, ezért a témát (nem Téged!) hajbazerinek minősítve kiszálltam a szálból.
  • Te személyeskedésnek minősítetted, miközben személyedre semmit sem mondtam.

A harmadikban (még inkább vesztemre) Mérges és csalódott voltam, mert az összes válaszomat negligáltad vagy tovább csúsztattad, a bennük foglaltak szemmel láthatóak kíváncsiságot nem keltettek benned, csak azon dolgoztál (érzésem szerint), hogy találj valamit a kezed ügyében (alkalmas vagy alkalmatlan dolgot), amivel visszavághatsz. Ezért, amikor Te magad igazoltad korábbi állításomat ("ritka sok marhaság van a linkelt cikkben"), ezzel: "Ööö...te gelei...ez már az xp-ben is benne volt.", erre felhívtam a figyelmedet.

Sajnálom, hogy így alakult.

Üdv,
Marci

> Azt mondtam, hogy "A vitához szükséges a másik fél minimális nyitottsága a vitapartner érveinek megértésére, akár elfogadására." Ezt tartom. Ez csak eufemizálás, de legyen. Az viszont elég visszás, hogy pont te voltál, aki a becitált linkeket en-bloc letojtad és ezek után engem osztasz ki nyitottság kérdésében.
  • Az elsőben mutattam egy 27 éven átívelő bináris, API és file-formátum backward compatibility példát.
  • Te ezt csak file-formátum kompatibilitásnak értelmezted (tévesen) és hoztál egy soha-meg-nem-valósult projekt oldaláról egy légből kapott állítást appcompatra, hogy magyarázzam meg.
 Ezt hogy érted, hogy soha meg nem valósult? Mi az, hogy légből kapott? Ez a projekt létezett. Vagy szerinted a linkelt archivált WINEHQ oldal kamu?
  • Érdemben válaszoltam neked, saját tapasztalatokat beleszőve, bemutatva a leggyakoribb inkompatibilitási szcenáriót (amikor is a 3rd party vendor direkt nem tette kompatibilissé a régi verziót). Szándékosan a Vistát hoztam elő, mert appcompat kérdésben az volt a hiedelem szerinti "sötét ló".
  • Te rákérdeztél, miért kell Windowson erre eszköz és linkeltél egy cikket, amiben hw-compat példa volt meg olyan appcompat, amilyenről én már korábban írtam.
  • Elmondtam, hogy a biztonság miatt kellett külön eszköz ehhez - bizonyos régi képességek használatát biztonsági okokból korlátozta a rendszer, speciális eszköz kellett ahhoz, hogy alkalmazás-specifikusan ezt a korlátozást feloldja valaki.
 Először is, nem csak HW-compat példa volt, fel volt benne sorolva többféle inkompatibilitás is. Ezt mondtam is, de nem reagáltál rá. Azonfelül utána kaptál olyan linket is, ahol tételesen fel volt sorolva, hogy mi lett kiszedve a vistából. De "szerinted" az is csak a biztonság kedvéért.
  • Erre Te "Biztonság? Az ms és a biztonság? Ez tényleg no comment."
  • Itt kiszálltam, Részedről ugyanis végetért a vita.
 Véget ért? Igen? Ezt így te döntöd el, hogy nekem mikor ér véget a vita? Az nem jutott eszedbe, hogy egyszerűen csak magától értetődött számomra, hogy ez így egy vicc? Tassadarnak eszébe jutott, rá is kérdezett, válaszoltam is neki. Érdekes, hogy pont akkor "szállsz ki", amikor utána beküldtem azt a tonnányi linket...
  • Írtál egy irdatlan listát válaszul arra, hogy "miért nem fér össze az MS és a biztonság", benne például azzal az érvvel, hogy nem lehet Windowson visszaállítani a titkosított file-okat, ha nincs lementve a titkosítókulcs... (Más rendszeren se...) A végére írtál OneDrive sztorit, amit egyik részről eleve viccesnek találtam, mert a OneDrive nem backupra való, másik részről meg erősen azt sejtette, hogy se az illetőnek, se Neked nincs tudomásotok a verzióelőzményekről.
  • A sejtésemet igazolandó, rákérdeztem erre: "És elvesztek az adatai?"
  • "Számára el" mondtad te
  • Ezzel beigazolódott a sejtésem, ezt meg is írtam Neked, hozzátéve, hogy ez a sztori így, sajnos álhír.
 Ezt már mondtam, hogy akkor "álhír", ha nem történik meg, nem akkor, ha esetleg a user is vétkes. Hovatovább, te meg egy-az egyben letojtad azt az "irdatlan listát" és csak arra válaszoltál, amibe bele bírtál kötni. De most komolyan, biztonságos az, amiről ilyen "irdatlan listát" lehet írni? Mert szerintem nem.
  • Erre Te elővettél egy üzemzavarról szóló bejelentést, hogy biztos neki sem működött - erről eddig szó sem esett.
  • Mivel ennek pont semmi köze nem volt az eredeti történethez (ahol is valaki nem arra való eszközt használt úgy, hogy nem is ismerte), ezért jeleztem, hogy nagyon fárasztó és unalmas a reakciód: "*ásít*"
  • Ezt persze félreértetted és fölényeskedésnek vetted.
  • Bánva a dolgot érdemben válaszoltam újra.
 Nem volt róla szó, mert ő sem mondta. Egyszerűen csak bevertem a kugliba a verzióelőzményeket (mert ugye én nem foglalkozok azzal amit írsz, így nem is nézek utána, hogy mit írtál, ez logikus) és rögtön ez jött velem szembe. Rengetegn jelezték az ms-nek hónapokon át, hogy baj van. Ebbe a srác is belefuthatott. Az ásítozás meg meg sosem érv. Akkor sem, ha nem is fölényeskedésnek szántad, mert annak sikerült. Ennyi erővel én is mondhatnám, hogy nagyon fárasztó és unalmas a folyamatos szerecsenmosdatásod. Többek között megint ignoráltad a sztori másik felét, hogy a zsarolóvírus átment a Defender/SmartScreen kombón; még mindig az ms és a biztonság relációjáról értekezünk, nem baj? Mint mondtam: amibe bele tudsz kötni, azon lovagolsz.
  • Te pedig kezdtél átnyergelni a Vistából kiszedett funkciók kérdésére
 Könyörgöm összecitáltam neked a fél internetet, kaptam én arra érdemi választ? Egy túrót. Annyit írtál, hogy "Örülök, hogy sok mindent összeszedtél, szép munka. Nem mondtam, hogy nem létezik a többi." Aztán pedig azt írtad, hogy "Csak nem cáfolja azt az állításomat, mi szerint a Vista biztonsági fejlesztései törték meg a legtöbb korábbi alkalmazást és hogy ezeket alkalmazás-specifikus SHIM-ekkel jól és ráadásul biztonságosan lehetett kezelni. Továbbá ugyanezek a biztonsági fejlesztések hiányoztak és hiányoznak a wine-ból, ezért valóban duplaklikkel indulnak az ilyen alkalmazások." Úgyhogy nem is én nyergeltem át oda, hanem te. Te kezdted el terelni a témát affelé, hogy a vistából mit dobtak ki a biztonság miatt, már bocs.
  • Erre is érdemben mondtam el a véleményemet.
  • Erre jöttél, hogy mi eszik 15GB-ot benne
  • Mondtam, hogy nem tudom.
  • Ez a téma már számtalanszor túl volt rágva hajbazer környékén, ezért a témát (nem Téged!) hajbazerinek minősítve kiszálltam a szálból.
  • Te személyeskedésnek minősítetted, miközben személyedre semmit sem mondtam.
 Hát ezt lehet, hogy félreértettem és nem nekem akartál beszólni. De ha egy másik emberrel minősítesz egy adott témát, úgy, hogy ahhoz negatív jelentéstartalmat csatolsz, az szintúgy személyeskedés, csak max. nem velem, hanem hajbazerrel. Az jobb? Hozzád se szólt, minek kellett ez a kiszúrkálás a sorok közül? > A harmadikban (még inkább vesztemre) Mérges és csalódott voltam, mert az összes válaszomat negligáltad vagy tovább csúsztattad, a bennük foglaltak szemmel láthatóak kíváncsiságot nem keltettek benned, csak azon dolgoztál (érzésem szerint), hogy találj valamit a kezed ügyében (alkalmas vagy alkalmatlan dolgot), amivel visszavághatsz. Én? Már bocs, de pont te voltál, aki nem reagált a becitált cuccokból szinte semmire, csak amibe bele bírtál kötni. > Ezért, amikor Te magad igazoltad korábbi állításomat ("ritka sok marhaság van a linkelt cikkben"), ezzel: "Ööö...te gelei...ez már az xp-ben is benne volt.", erre felhívtam a figyelmedet. Ezt is megválaszoltam már: én becitáltam egy cikket, amiben valaki leírta, hogy miféle "marhaságokat" kapcsolt ki. Nem csekkoltam le egyesével, hogy mindegyik megállja-e a helyét, ez tény. (A jelek szerint ti sem. Mindezt úgy, hogy nektek szakterület a windows. Mint mondtam: kettős mérce.) Viszont gelei volt az, aki kiemelt belőle egy feature-t, hogy ez miért lenne marhaság? Na, ha én letojnám, amit írkáltok, ahogy te itt állítod, akkor nem kerestem volna rá egyáltalán, hogy mi is ez. De nem tojtam le és rákerestem. És egy kicsit meghökkentett, hogy pont sikerült becitálni belőle egy olyat, ami nem is a vistában debütált. Még egyszer: ti vagytok a windows expertek, ezt nektek kellett volna tudni. Ha úgy emeli ki, hogy az RA már az xp-ben is benne volt, tehát a cikk hülyeségeket beszél vele kapcsolatban, egy szavam nincs, mert igazatok van. De nem, úgy emelte ki, hogy ez milyen jó, hogy bekerült. De most komolyan, ha nekem az lenne a célom, hogy titeket bántsalak, akkor nem gondolod, hogy kaptam volna az alkalmon és leoltottam volna a francba? Ehhez képest csak annyit mondtam, hogy ez benne volt az xp-ben, tehát nem lehet a vista új feature-jei között. Ja és ami igazán gáz, hogy megint sikerült a dolog másik felét ignorálnotok, hogy ez a fasza cucc, amin már sokadjára lovagolunk, usque 15 évig egy batár nagy hátsóajtó volt az összes windowsban. Erre sem reagáltatok. Minden ami kínos volt az ms-nek és nem volt rajta fogás, az mind ignorálódott és a végére csak annyi maradt, hogy én ez meg az vagyok. > Sajnálom, hogy így alakult. Legalább ne próbáld meg magadat áldozatnak beállítani, mert irtó fals. Mint fentebb leírtam, ti jöttetek be egy topicba amit nyitottam és ti szóltatok hozzám először. Én benneteket nem bántottalak, viszont ti a nektek nem tetsző válaszaim nyomán nekiálltatok személyeskedni és - saját bevallásod szerint - "trollkodni". És akkor még meg is ideologizálod, hogy ezt azért, mert én ez, meg az vagyok. Bocs, de - ahogy mondtam - ez nem engem minősít.
Oldschool Computer - http://oscomp.hu
> Örülök, hogy erre ennyi energiád és időd van, megtisztelőnek is gondolom, hogy ilyen terjedelemben válaszoltál. Pedig CFS-ben HPAAD-ben szenvedek. :P De most komolyan, ha nem válaszolok, azt írod, hogy nem foglalkozok a válaszaiddal, ha meg igen, akkor meg ezt? > Tanultam az esetből. Annyit még megkérdezhetek, hogy mit?
Oldschool Computer - http://oscomp.hu

mit?

Például azt, hogy ami nekem elsőre kellemes csevelynek tűnt, ahol relatíve pongyolán megoszthatom a saját gondolataimat, tapasztalataimat - az Neked ennél sokkal komolyabb dolog volt.   

Például Szerinted "folyamatos szerecsenmosdatás"-t csinálok. Idézz kérlek egyetlen mondatot a topikból, amiben a Microsoftot mentegettem.

Üdv,
Marci

> Például azt, hogy ami nekem elsőre kellemes csevelynek tűnt, ahol relatíve pongyolán megoszthatom a saját gondolataimat, tapasztalataimat - az Neked ennél sokkal komolyabb dolog volt. Nem annak indult, de ahogy bepipultatok, ti kezdtétek el komolyan venni. Mit vártatok? (Főleg ennyi pénzért.) > Például Szerinted "folyamatos szerecsenmosdatás"-t csinálok. Idézz kérlek egyetlen mondatot a topikból, amiben a Microsoftot mentegettem. Mindjárt azzal nyitottál, hogy "ne vicceljek", mert ők aztán nagyon backward compatible-ek. Aztán "postafordultával" már arról értekeztél, hogy a backward compatibility nem showstopper, tehát nem baj, ha eltörik. Aztán meg a biztonsággal próbáltad megmagyarázni, hogy muszáj volt eltörni.
Oldschool Computer - http://oscomp.hu

A brutális backward compatibility a Microsoftnál sima tény, olvass utána.

Sosem mondtam, hogy a backward compatibility hiánya nem showstopper. Azt mondtam, hogy mindig is meg lehetett oldani az appcompatot (pont a létező backward compatibility miatt), így az appcompat sosem volt igazi showstopper. 

És igen, az ok a Vista esetében túlnyomó részt a biztonság volt (nem, most nem beszéljük végig a történetet a DEC-től jövő RPC-ről, az RPC-DCOM-on, Longhornon és XP SP2-n át a Vistáig). Ha meg szeretnél róla győződni, találomra (mondom találomra! ;) ) válassz néhány funkciót, ami ki lett hagyva a Vistából és olvass utána. Valószínűleg igazolva fogod látni az állításomat.

És most: meglepetés! Egyik sem mentegette a Microsoftot. Száraz tényeket és személyes tapasztalatokat írt le, amitől a Microsoft semmitől sem került jobb pozícióba, legfeljebb a látóköröd tágult valamelyest.

Üdv,
Marci

> A brutális backward compatibility a Microsoftnál sima tény, olvass utána. A saját tapasztalatom is mást mond, meg amiket a neten találtam, az is. Egy részét be is linkeltem. Nem foglalkoztál vele. Egyébként ezt írtátok a biztonságra is. Annak is utánaolvastam. Úgy kb. negyed óra alatt összeszedtem azt az "irdatlan listát". Azóta is válaszoltok rá... Érdemes volt. > És igen, az ok a Vista esetében túlnyomó részt a biztonság volt (nem, most nem beszéljük végig a történetet a DEC-től jövő RPC-ről, az RPC-DCOM-on, Longhornon és XP SP2-n át a Vistáig). Ha meg szeretnél róla győződni, találomra (mondom találomra! ;) ) válassz néhány funkciót, ami ki lett hagyva a Vistából és olvass utána. Valószínűleg igazolva fogod látni az állításomat. Oké, akkor ahhoz, hogy biztonságossá tegyék az xp-t, a saját kódbázisának a tízszerese kellett, pluszban. Ha te mondod én elhiszem. Csak akkor miért nem lett biztonságos? :( > És most: meglepetés! Egyik sem mentegette a Microsoftot. Száraz tényeket és személyes tapasztalatokat írt le, amitől a Microsoft semmitől sem került jobb pozícióba, legfeljebb a látóköröd tágult valamelyest. Hát ha megmagyarázod, hogy nem... De összefoglalom egy mondatban: egy olyan operációs rendszer irdatlan felfúvódását és backward-compatibility issue-jait akartad megindokolni a biztonsággal, ami minden csak nem biztonságos. Ez mi, ha nem szerecsenmosdatás?
Oldschool Computer - http://oscomp.hu

Csak a tenyek kedveert.
Egy frissen telepitett Vista Business igy nez ki: https://imgur.com/a/wHlRje4
Windows konyvtar tartalma: https://imgur.com/a/09RxjgA

Felhivnam a figyelmet a c:\pagefile.sys-re ami 2.2G (2G ramot adtam a VM-nek). mindenki tudja mi ez
Aztan a c:\windows\system32\driverstore 1G, pontosan az van benne, ami varhato a neve alapjan.
A c:\windows\winsxs-re 4.6G-t hazudik a totalcommander. Hazudik (illetve teved), mert tele van hard linkkel. Utana lehet olvasni, hogy ez a mappa mire valo. Roviden: minel tobb cuccot telepitesz, annal nagyobb lesz. Kb mint egy /var vagy /opt mappa linuxon.

Lenyeg a lenyeg: A Vista nem foglal 15G-t. A windows mappa valos merete kb 6.5G

Ja, es a fentiek x64-re vonatkoznak.

x86:
https://imgur.com/a/oPCQoU9
c:\windows\system32\driverstore 1G
c:\windows\winsxs 2.8G a TC szerint

> Egy frissen telepitett Vista Business igy nez ki És egy vista ultimate? > Aztan a c:\windows\system32\driverstore 1G, pontosan az van benne, ami varhato a neve alapjan. És? Akkor annak nem kell tárhely? > A c:\windows\winsxs-re 4.6G-t hazudik a totalcommander. Hazudik (illetve teved), mert tele van hard linkkel." Teljesen mindegy, hogy hardlink-e, vagy sem, mert a szabad kapacitásból levonódik és része a windowsnak, az ms álmodta így meg, nem más. BTW: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/determine-the-actual-size-of-the-winsxs-folder Így megmérve mennyit ad? > Lenyeg a lenyeg: A Vista nem foglal 15G-t. A windows mappa valos merete kb 6.5G Hogy jött ki az a 3 GB levonás? Amúgy egy windows nem csak a windows mappából áll, hanem mindenből, amit a windows feltelepít. (BTW, az megvan, hogy a 15 GB-ot az ms adta meg hivatalos igényként?) Másnak egyébként ugyanúgy ~10GB-ot evett a friss telepítés, pedig ő másik partícióra száműzte, amit lehetett. Egyébként ha 6.5 GB, ha 9-10, ha 15, ez mindenképpen a többszöröse az xp-nek, úgy, hogy kihajigáltak belőle egy raklap dolgot.
Oldschool Computer - http://oscomp.hu

Most ebben a konkrét esetben, hogy felszinkronizálta a ransomware által tönkretett dolgokat a OneDrive-ra, tényleg nem hiszem, hogy a Microsoftot lehet hibáztatni.

Én Google Drive-ot használok, ha a Linuxomon véletlenül felülírom a fontos fájlomat, ugyanúgy felszinkronizálódik.

Ez a normális és elvárt működés.

Annyi a különbség, hogy tartok offline backupot is, amibe a Google Drive tartalmát is időnként beszinkronizálom.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ez nem hit kérdése. Már ott bukó a dolog, hogy a SmartScreen/Defender kombón átment a vírus; az kinek a hibája, ha nem az ms-é? A felszinkronizáláson ugyan lehet vitatkozni, de ha az ms úgy gondolta volna, hogy jól van ez így, akkor nem vezette volna be a Files Restore-t, ami pont az ilyesmit hivatott kiszűrni, ami azt jelenti, hogy a srác esete baromira nem egyedi eset lehetett, hanem tömeges, mert egy ember nyomorával aligha foglalkozott volna az ms. Az offline backup hiánya valóban a srác hibája (tanult belőle), de ez csak a fájljai elvesztésének kérdésében releváns, az ms cuccainak biztonságosságának kérdésében nem.
Oldschool Computer - http://oscomp.hu

" Ez nem hit kérdése. Már ott bukó a dolog, hogy a SmartScreen/Defender kombón átment a vírus; az kinek a hibája, ha nem az ms-é? "
 

Nyilvánvalóan lépéselőnyban vannak a ransomware írok a virusirtókkal szemben, a többi virusirtót sem kárhoztatnám azért, mert egyetlen ransomware átment a rostán.

Nagyon sok technológiát szolgáltat a Microsoft a Defenderen felül is by default, hogy ezek kivédhetőek legyenek: tiltva vannak az aláíratlan makrók és scriptek, administrator esetén sem kap felhasználói interakció nélkül admin hozzáférést (UAC).
Ezen felül lehetőség van path-ra, aláírásra szűrni a végrehajtható binárisokat (AppLocker), sőt path-ra is szabható ilyen kritérium (controlled folder access).
Microsoft 365 esetén pedig számos más lehetőség van az organizáció védelmére.

Ezek közül mi áll rendelkezére egy tetszőleges desktop-linuxon?

Mit nyújt egy desktop Linux a ransomware támadások kivédésére?

> Nyilvánvalóan lépéselőnyban vannak a ransomware írok a virusirtókkal szemben, a többi virusirtót sem kárhoztatnám azért, mert egyetlen ransomware átment a rostán. Egy? Napi szinten zabálják fel az emberek gépét a vírusok. Ott van ez is benne a fenti listában, amit a kérdésedre kaptál tőlem; ezerszer annyi malware van windowsra, mint a többi platformra összesen. > Nagyon sok technológiát szolgáltat a Microsoft a Defenderen felül is by default, hogy ezek kivédhetőek legyenek: tiltva vannak az aláíratlan makrók és scriptek, administrator esetén sem kap felhasználói interakció nélkül admin hozzáférést (UAC). Tapasztaltam. A saját programunkat is blokkolta, ki kellett kapcsolni. Sok értelme van így, hogy ki kell lőni, hogy dolgozni tudjon az ember... Bár mondjuk vele sem vagyunk nagyobb biztonságban... > Ezen felül lehetőség van path-ra, aláírásra szűrni a végrehajtható binárisokat (AppLocker), sőt path-ra is szabható ilyen kritérium (controlled folder access). Microsoft 365 esetén pedig számos más lehetőség van az organizáció védelmére. Igazán örülök neki. Valami a fenti listához, amit kértél? > Ezek közül mi áll rendelkezére egy tetszőleges desktop-linuxon? > Mit nyújt egy desktop Linux a ransomware támadások kivédésére? Idéznélek téged: "Miért releváns ez a Windows-ra nézve?" A windows biztonsága a téma, nem a Linuxé. A windows biztonságosságának mértékét semmiben sem befolyásolja az, hogy mi van, vagy mi nincs Linuxra. És a windows biztonságossága illúzió. Ld. a fentebbi listát. Te kérted, megkaptad.
Oldschool Computer - http://oscomp.hu

Szerinted olyan sokat nyerne a többi ARM chip támogatásával, hogy azért 30 évnyi alkalmazáskompatibilitást és hekkelést megérné újrafejleszteni? Szerintem sose: az ARM támogatás nem erőforrás, hanem akarat kérdése. De mivel alkalmazások nincsenek Windows ARM-ra és ebbe már belefutottak korábban, miért tennék?

MIPS? Az már NT4-ben is volt. Meg PowerPC, DEC Alpha is.

Üdv,
Marci

Valós példát hoztam arra, hogy egy NT kernel > Linux kernel alapú rendszer váltásnál több tekintetben is problémásabb váltásra is volt már példa. Azt akkor sikerrel vette az Apple. Illetve a korábbit is. 

De látom ez csak félreértésekre adott okot. 

Valóban elég lenne annyi érv is, hogy a Wine ma éppen eléggé jól működik. Teszi ezt annak ellenére, hogy nulla Microsoftos támogatással fejlesztik jelenleg. A Microsoft saját Windows kertjén belül egy wine-típusú megoldást bőven meg tud oldani annyira kompatibilisre amit a valós piac igényel. 100%-os örök visszafele kompatibilitás pedig soha nem volt és nem is lesz. 

Itt 2 váltás is szóba került. A Photoshop esetét eredetileg a klasszikus macOS és unixos OS X közötti váltásra hoztam fel. Legalább akkora változás mint egy mai Windowsról való Linux alapú Windowsra való váltás lenne. Akkor a PowerPC hardverplatform nem változott. 

Majd később maradt a OS X de a PowerPC cserélődött Intelre. Ezt az akadályt is jól vette az maces Photoshop. Bár ez inkább az Apple érdeme volt mindkét esetben. A másodikat azért említettem, mert egy erről szóló cikket linkeltél. 

A kettőt nem lehet egy lapon említeni. Ha CPU-t cserélsz, akkor jó eséllyel csak újra kell forgatni a programjaidat, max endian fixekre, meg az ASM betétek újraírására van szükség. Ha a kernelt cseréled le egy teljesen másfélére, akkor írhatsz újra majd' mindent.
Oldschool Computer - http://oscomp.hu

Márpedig ez történt az első esetben. A Classic macOS egy teljesen más OS volt mint az OS X. Eljárt az idő felette, például még cooperative multitask volt, és teljesen más OS mint a utód OS X. Egyetlen közös dolog a kettőben, hogy mindkettő az Apple rendszere. Mégis működtek az régi classic macOS binárisok az új OS X-en újrafordítás nélkül. Egészen a Tigerig megvolt ez a kompatibilitás. 

Különben később a PowerPC - Intel váltásnál sem kellett újrafordítani a Photoshopot, hogy működjön Inteles Macen. Nem adott forráskódot az Adobe, hogy fordítsuk le magunknak az új platformra. Működött a PowerPC bináris az Inteles OS X-en. 

ASM betétek már szerintem elég ritkák. Szoptunk vele egy félévet, de azóta sem kellett soha semmihez assemblyben írnom bármit. Ha valaminek nagyon gyorsnak kell lennie, arra ott a C++. 

> Márpedig ez történt az első esetben. A Classic macOS egy teljesen más OS volt mint az OS X. Eljárt az idő felette, például még cooperative multitask volt, és teljesen más OS mint a utód OS X. Egyetlen közös dolog a kettőben, hogy mindkettő az Apple rendszere. Mégis működtek az régi classic macOS binárisok az új OS X-en újrafordítás nélkül. Egészen a Tigerig megvolt ez a kompatibilitás. Nem, nem ez történt. A Classic Mac OS programok futtatása teljesen más tészta, mint a windowsos programoké. Két okból is. Egyfelől a Classic Mac OS egy a 80-as évekből ittrekedt, minden a korszerűbb OS-eket jellemző feature-t (memóriavédelem, SMP, valódi (preemptive) multitask) nélkülöző őskövület volt. Azért ezt gyorsan be lehet látni, hogy sokkal egyszerűbb megoldani az olyan programok futtatását, amik erre épülnek, mint egy bonyolultabb rendszerre: pl. OSX emuláció - mármint használható (nem, a Darling nem az) - van Linux alá? Nincs? Pedig a Darwin nyílt, ráadásul UNIX-UNIX felállás, nem windows-UNIX, azaz elvileg jóval egyszerűbb kéne, hogy legyen; hogyhogy nincs ez rendesen megoldva? Másfelől pedig - és ez a fontosabb - kevered a fogalmakat: a WINE nem emuláció, hanem API-wrapping, azaz a windows API hívásokat wrappeli a host OS API-jára, míg a Classic Environment valódi emuláció volt, egy sandboxolt környezetben felhúzta a Classic Mac OS kernelt és ott futtatta a célprogramot; nem wrappelt semmit, hanem futott a Classic Mac OS kernele N példányban és mindegyik sandboxban egy-egy Classic Mac OS program. Ugyanezen elvek mentén a Linux alatti windows kompatibilitást úgy lehet megoldani, hogy felhúzod a windows kernelt egy sandboxba és ténylegesen futtatod alatta a programjaidat. Ez ugyan valóban működik, de ez nem API-wrapping, hanem virtuális gép és ami még fontosabb: kell hozzá a windows kernel, tehát nem tudják lecserélni. > Különben később a PowerPC - Intel váltásnál sem kellett újrafordítani a Photoshopot, hogy működjön Inteles Macen. Nem adott forráskódot az Adobe, hogy fordítsuk le magunknak az új platformra. Működött a PowerPC bináris az Inteles OS X-en. Az Adobe magától leforgatta intelre, függetlenül attól, hogy ment-e a usereknek, vagy sem, ugyanis a Rosetta - lévén emuláció - elég erős performance impactot csinált, azaz a PowerPC-s Photoshop töredék sebességgel futott - ha egyáltalán futott - az inteles Mac-eken. > ASM betétek már szerintem elég ritkák. Szoptunk vele egy félévet, de azóta sem kellett soha semmihez assemblyben írnom bármit. Ha valaminek nagyon gyorsnak kell lennie, arra ott a C++. Nem tettem semmilyen állítást a gyakoriságukra, annyit állítottam, hogy CPU váltáskor át kell írni őket, ha vannak.
Oldschool Computer - http://oscomp.hu

"amikor a W10 alatt is Linux kernel fog futni"

Microsoft Announces Direct3D 12 For Linux / WSL2

"Why DX12 on linux? Looking at this feels like classic divide and conquer (or well triple E from the 90s)..."

https://lists.freedesktop.org/archives/dri-devel/2020-May/266642.html

„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”
"Az Antikrisztus ledarálja Mészáros Lőrincet."

Gyakorlati tapasztalatok érdekelnének: Ha Office365 online Wordben elkészítek egy dokumentumot, az offline wordben is jól fog kinézni?

Kérlek, ne gyertek azzal, hogy természetesen, mert ez sajnos egyáltalán nem természetes. Az offline Word különböző verziói között is volt olyan eltérés régebben, hogy az egyikben elkészített dokumentum szétesett a másikban. Word ugyanazon verziói között is simán szét tudott esni egy dokumentum, ha különböző nyomtató volt a rendszerben alapértelmezettként telepítve.

Persze ez mind évekkel ezelőtt volt, nem tudom, mennyire robusztus most a rendszer, de mondjuk úgy, hogy nem bízom 100%-ig még abban, hogy gond nélkül megy a különböző verziók között a cserebere.

A nyílt fájlformátum se garancia erre, pl. a LibreOffice 3 oldalra szétpakolva mutatja meg azt a doksit, ami Wordben 2 oldalon látszik. Szóval nem a formátum, hanem a formátum írása és értelmezés a kulcs.

Konkrétan azt szeretném, hogy ha néha Word formátumú doksit kell küldenem és fontos a kinézet, akkor a LibreOffice-ban elkészített tartalmat az online Wordben véglegesre formázva készíteném el a fájlt, amit továbbküldök.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Valóban láttam már olyat, hogy LibreOffice doksi másként nézett ki Google Docs-ban. 

Ha viszont egy doksi nem úgy néz ki webes O365-ben mint natív Wordben, illetve másként néz ki különböző word verziókon az nem jelent semmit. Ezért úgysem fognak 10 különböző Office verziót tartani. 

Szóval ha garantáltan jó megjelenés kell akkor Google Docs és link küldése. 

Szóval ha garantáltan jó megjelenés kell akkor Google Docs és link küldése. 

Cseszhetem, ha konkrétan word .docx formátumot kérnek.

Korábban pdf-et küldtem, mert az ugyanúgy nézett ki mindenhol, akár LibreOffice-ban akár másban készült. De több helyről visszapattant, mert náluk csak a Word jó.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Akkor nincs mit tenni. Te használod a legfrissebb Word verziót. Ha a másik oldalon probléma van az általad küldött doksival kompatibilitási okokból, az ígyjárás esete. 

A Google Docs egy jó lehetőség arra, hogy ne legyenek doksi kompatibilitási problémák, tekintve mindegyik fél ugyanazt a szolgáltatást használja. Természetesen nem kötelező élni a lehetőséggel.

( neutrino v | 2020. 05. 24., v – 09:15 )

Szóval az MS elkezdte szögelni a Linux koporsóját.

 

Elvégre, ha már Windowson is tudok majd Linux appokat futtatni, mi a bánatért kellene Linux?

Good job MS! Good job!

1904.04.08.
RIP Jákub.
neut @

Mintha desktopon eddig nem lett volna meg minden linuxos, vagy inkább opensource keresztplatformos program windows portja!

Gimp, LiberOffice, Firefox, Blender, Kdenlive, Krita... csak egészen apró toolokból nincs win-es de azokra van száz másik windows alternatíva. 

Szerver világ meg egészen más. Ott már ma is inkább a Linux a jelentősebb. 

Várjunk még azokkal a szegekkel. 

> csak egészen apró toolokból nincs win-es de azokra van száz másik windows alternatíva. Mi számít aprónak? A Rapid Photo Downloader az kicsi vagy nagy? Alternatíva meg lehet, hogy van, csak kérdés, hogy jó-e a felhasználónak. Itt nem arról beszélünk, hogy át lehet-e szokni valamire, hanem arról, hogy ha a WSL működik, akkor a Linux usereknek nem kell átszokniuk, hanem futtatják a régi programjukat, windows alatt. > Szerver világ meg egészen más. Ott már ma is inkább a Linux a jelentősebb. Lehet, hogy az ms szeretne ezen változtatni?
Oldschool Computer - http://oscomp.hu

Nem tartom valószínűnek, hogy a desktop Linux felhasználók többsége ilyen programok miatt használ Linuxot Windows helyett. 

Szerveren legfeljebb annyit változtat a Microsoft, hogy szép csendben maga is Linux szerverekre vált. Szerver világban sokkal fontosabb szempont a sok-platformúságnak minimum a lehetősége. Ott a WSL nem érv semmire. Az összes nagy felhőszolgáltató Linux szerverekre építkezik a Microsoft kivételével. De még az Azure-nál is lehet változás a jövőben. 

> Ott a WSL nem érv semmire. Ha működik? Dehogynem érv. Kapsz egy hibrid környezetet, ahol mindkét platform cuccait tudod futtatni. Ez elég jelentős érv. A választásnál szerinted mi a fő szempont? A pénz. Az idő pedig pénz. Szerinted, ha van egy adott feladat, aminek az egyik felére windows alatt van kiforrott technológia (mert mondjuk IIS specifikus cuccokat igényel), a másik felére meg Linux alatt (mert mondjuk WebScaleSQL kell hozzá), akkor mit fog választani a cég? Kiszenvedi a saját megoldását az első felére Linux alatt, vagy vice versa on windows? Vagy WSL on windows és használja az egyik felére a kész windowsos megoldást, a másik felére a kész Linuxost, csak össze kell kapcsolnia valahogy a kettőt. Ehhez persze az kell, hogy a WSL jól működjön, továbbá, hogy ne lőjék le, mielőtt befutna.
Oldschool Computer - http://oscomp.hu

Ez nem érv, mert nem akarja kicsiktől egészen óriásokig semmilyen szerverben érdekelt fél mindkét platform cuccait, ha eddig teljesen jól elvolt Linux alapú szervereivel. Amazon, Google, a kisebb OpenSTACK felhős szolgáltatók soha nem fogják Windowsra cserélni a Linux szervereiket, legyen bármilyen WSL csoda rajtuk. Nem fogják mert totál felesleges. Nem fogják mert elvesztik a gyártófüggetlenségüket. Nem fogják mert azzal Intel platformhoz láncolnák magukat. Többször szóba került már a szerverpark ARM-re, POWER-re cserélése. Azért mert eddig erre nem került sor nem jelenti azt, hogy a felhős és szerverszolgáltatók örökre be akarják zárni ennek a lehetőségét maguk előtt. ARM szerverek szvsz nem túl távoli jövőben nagyobb szerepet fognak kapni. Technológiailag a POWER már ma is bőven alkalmas, itt inkább az IBM elkötelezettsége kérdéses abban a tekintetben, hogy mennyire is gondolják ők komolyan azt a nyílt OpenPOWER és mennyire marketinges porhintés a dolog. 

Szóval legyen példa az Amazon a felhős szolgáltatásával. Ők konkrétan semmit nem kapnának ha Windowsra migrálnának. Lenne egy jó nagy költség már az elején. Utána Microsoft függőség. És  a csodás mindkét platform lehetősége aminek az értéke az Amazon számára itt egészen pontosan nulla. Semmivel sem működne jobban az Amazon felhő ha a host gépeken el tudnának indulni a Windowsos szerver programok. Csak több erőforrás kellene minden host alá. 

A guesteken sem valószínű, hogy az ügyfeleket nagyon vonzaná az ilyen cserelehetőség. Tegyük fel hogy van egy Amazon ügyfél, akik a felhősített és webes Linux alapú ügyviteli rendszerét működteti az Amazon felhőjén. Mit nyer azzal, ha kéretlenül kap windows kompatibilitást? Nem túl életszerű, hogy hirtelen a webes ügyviteli szerveréről szeretne mondjuk MS Office csomagot tolni remote desktopon át. Viszont magasabb időalapú díjat kellene fizetnie, mert a Windows guest licencdíja így van beépítve az árba és cserébe nem kapna semmit. Vagy ha MS ingyen kezdené osztogatni felhőkre a Windows licenceket még akkor sem érné meg Amazonos ügyfelünknek, mert a WSL-es csodás Windows szervere több ramot és egyéb erőforrást igényelne ugyanarra a feladatra, és ez újra csak magasabb díjhoz vezetne. 

Linux szerverekre kész megoldások vannak amik évekig jól működnek minimális adminisztrációs igény mellett ha azok jól lettek megtervezve, márpedig aki ezt nem hobbiból csinálja a szerver szolgáltatásait jól megtervezi, ill megtervezteti. Nem kell IIS mert eddig sem kellett. Akinek valamiért Windows-függő szerverei vannak, annak pedig a Linux rész felesleges. 

A desktop oldal találgatás terepe. De a szerver az nem. Legfeljebb fejlesztésnél jön jól ha WSL lehetősége ha Linuxos szerverekre fejlesztünk. Ott egyébként valóban hasznos. És itt véget is ér a WSL Linux szerveres potenciálja. Maga a Microsoft sem számít itt semmi többre. 

> Ez nem érv, mert nem akarja kicsiktől egészen óriásokig semmilyen szerverben érdekelt fél mindkét platform cuccait, ha eddig teljesen jól elvolt Linux alapú szervereivel. Amazon, Google, a kisebb OpenSTACK felhős szolgáltatók soha nem fogják Windowsra cserélni a Linux szervereiket, legyen bármilyen WSL csoda rajtuk. Nem fogják mert totál felesleges. Miért lenne felesleges? Ezt a feladat dönti el. > Nem fogják mert elvesztik a gyártófüggetlenségüket. Tehát, ha eddig pl. kizárólag RHEL alapokon futottak, innentől meg választhatnak az RHEL és a WSL+windows között, akkor elvesztették a gyártófüggetlenségüket és szűkebb lett a mozgásterük? Ezt nem nagyon értem... > Nem fogják mert azzal Intel platformhoz láncolnák magukat. Mármint az x86-ra gondolsz, gondolom, mert x86-ot nem csak az intel gyárt. Egyébként ez sem igaz. Most x86-centrikus a windows, de volt annakidején az minden platformra. Ma is portolhatják. > ARM szerverek szvsz nem túl távoli jövőben nagyobb szerepet fognak kapni. Technológiailag a POWER már ma is bőven alkalmas, itt inkább az IBM elkötelezettsége kérdéses abban a tekintetben, hogy mennyire is gondolják ők komolyan azt a nyílt OpenPOWER és mennyire marketinges porhintés a dolog. Ebben egyetértünk. > Szóval legyen példa az Amazon a felhős szolgáltatásával. Ők konkrétan semmit nem kapnának ha Windowsra migrálnának. Lenne egy jó nagy költség már az elején. Utána Microsoft függőség. Semmivel sem működne jobban az Amazon felhő ha a host gépeken el tudnának indulni a Windowsos szerver programok. Csak több erőforrás kellene minden host alá. > A guesteken sem valószínű, hogy az ügyfeleket nagyon vonzaná az ilyen cserelehetőség. Tegyük fel hogy van egy Amazon ügyfél, akik a felhősített és webes Linux alapú ügyviteli rendszerét működteti az Amazon felhőjén. Mit nyer azzal, ha kéretlenül kap windows kompatibilitást? Nem túl életszerű, hogy hirtelen a webes ügyviteli szerveréről szeretne mondjuk MS Office csomagot tolni remote desktopon át. Akkor álljunk meg egy pillanatig. Én nem azt mondtam, hogy a meglévő, már működő megoldásokat fogják migrálni, azt minek? De ha újat építenek valamiből és a feladat ezt követeli meg? A virtualizált gépek piacára szerintem az ms nagyon is szeretne betörni és nem az ms office-szal. > Viszont magasabb időalapú díjat kellene fizetnie, mert a Windows guest licencdíja így van beépítve az árba és cserébe nem kapna semmit. Vagy ha MS ingyen kezdené osztogatni felhőkre a Windows licenceket még akkor sem érné meg Amazonos ügyfelünknek, mert a WSL-es csodás Windows szervere több ramot és egyéb erőforrást igényelne ugyanarra a feladatra, és ez újra csak magasabb díjhoz vezetne. Az erőforrások oroszlánrészét sosem az oprendszer, hanem a célszoftver viszi el. TFH a windows mondjuk (hasraütés) 50%-al többet zabál, mint egy random vállalati Linux. So? A Linux mondjuk megette a rendelkezésre álló erőforrások 0.001%-át (felhőről, clusterekről beszélünk, nem egy gépről), akkor a windows megeszi a 0.0015%-át. > Linux szerverekre kész megoldások vannak amik évekig jól működnek minimális adminisztrációs igény mellett ha azok jól lettek megtervezve, márpedig aki ezt nem hobbiból csinálja a szerver szolgáltatásait jól megtervezi, ill megtervezteti. Nem kell IIS mert eddig sem kellett. Akinek valamiért Windows-függő szerverei vannak, annak pedig a Linux rész felesleges. Again: te váltásról beszélsz. Én új feladatokról. Sosem állítottam, hogy már működő infrastruktúrákat vernének ezért szét, te valamit nagyon félreértettél. Arról beszéltem, hogy az újakat már esetleg erre alapozzák. > A desktop oldal találgatás terepe. De a szerver az nem. Legfeljebb fejlesztésnél jön jól ha WSL lehetősége ha Linuxos szerverekre fejlesztünk. Ott egyébként valóban hasznos. És itt véget is ér a WSL Linux szerveres potenciálja. Maga a Microsoft sem számít itt semmi többre. Ezt elég nagy magabiztossággal állítod és feleslegesen: a szerveroldali részről is nyugodtan lehet spekulálni. Te azt mondod, hogy no way. Én azt mondom a hibrid rendszerek vonzóak lehetnek új projektek kivitelezéséhez, mert kétszer annyi választási lehetőséged lesz, ami a technológiákat illeti. Az idő majd ítél, hogy kinek volt igaza...
Oldschool Computer - http://oscomp.hu

A már Linuxon is elérhető .NET Core (ki gondolta volna még 5 éve?! ) arra enged következtetni, hogy szerver oldalon natív Linuxot lát már a MS is. Szerver szoftver fejlesztésére ma már elég jó a Core Linuxra is. Ha valami desktop szoftverről van jó, akkor viszont a Core is Windowsos inkább. 

Ezért gondolom, hogy No way. 

Mert a Microsoft utóbbi lépései is erre utalnak. 

Ez egyáltalán nem biztos, hogy azért van dotnet for Linux, mert oda is Linuxot vizionál az ms. Akik kaptak az alkalmon és dotnetet használtak Linuxon, azok onnantól így vagy úgy, de függenek az ms-től. Következő lépésben mondjuk Linuxra már nem adják ki a dotnetet, vagy durván lekorlátozzák, így aki arra építette fel a Linuxos szoftvereit, az vagy meg van lőve, vagy átmászhat windows + WSL-re, ahol továbbra is futhat a Linuxos cucca, de van dotnet is.
Oldschool Computer - http://oscomp.hu

Nem tartom valószínűnek, hogy a mai Microsoft visszalépne a .Net Core-ral. Az előfordul, hogy nem mennek tovább az úton úgy ahogy várnánk ilyen új kezdet után. De vissza nem fordulnak már szerintem értelmesen belátható jövőben. Hosszú távra meg lehetetlen bármit mondani. 

Nem kapnak sokan az alkalmon mert a múlt is kísért, illetve nem fognak átszabni évek óta futó Java projekteket. Itt a Microsoftnak kell bizonyítania sokáig, hogy megbízható és kiszámítható partner. Olyan fordulat amit te írtál csak vinne jó sokat és alig hozna valamit. 

Még egyszer: én nem már futó projektek felesleges átmigrálásáról beszélek, hanem újakról. A dotnetet pedig rengeteg Linuxos fogadta szívesen, mert a technológia érdekelte őket és építkezni akartak rá. Ha ezt most visszaveszi az ms, akkor vagy leragadnak a régi dotneten, vagy windows + WSL. De ez is csak egy lehetőség. Mindegy, ez szerintem meddő vita, majd az idő eldönti, hogy az ms a szerverpiacon is próbál-e teret nyerni ezzel, vagy sem. Vagy, hogy egyáltalán lesz-e hosszútávon bármi a WSL-ből és nem nyírják ki ezt is.
Oldschool Computer - http://oscomp.hu

ha már Windowson is tudok majd Linux appokat futtatni, mi a bánatért kellene Linux?

Mert kényelmesebb és jobban kézre áll mint a Windows?

Eddig sem a Linux appok miatt futtattunk Linuxot, hanem a jobb hardver támogatottság, a kevésbé ordító biztonsági hibák, adott hardveren gyorsabb működés, kényelmesebb DE, könnyebb hibakeresés, használható csomagkezelés, stb.-stb. miatt (ezek az én szempontjaim voltak, azóta változtak dolgok, pl. a Windows sem annyira lukas már, mint egy ementáli sajt, (emlékeztek még arra az időre, amikor egy Windows telepítést nem lehetett úgy végigvinni egy internetre kötött gépnél, hogy a telepítés vége előtt ne törték volna már fel a frissen települő OS-t?), a hibakezelés Linux alatt is nehezebbé vált, amióta egy csomó nagy és komplex userspace program vett át funkciókat kicsi és egyszerű programoktól és a nagyok nem logolnak, vagy nem hasznosan).

Inkább a kérdés úgy merült fel sokaknál, hogy mi a bánatért kellene Windows?

És persze erre is van válasz. Szintén egyénfüggő. Nekem is van dualbootban Windows, kb. 6 hónaponta el is indítottam.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Jobb a hardver támogatás :D Wat?

Kevésbé ordító biztonsági hibák: hogyne, amikor pl egy Debian stable repoban  3 éve elavult "supportált" csomagok vannak.

Hibakeresés: van ám egy olyan tool a Windowsban, hogy "Event viewer". Lehet sokként hat, de pongyolán fogalmazva ez a /var/log. Jó böngészést.

Régi idők: Hja, XP korában még ez volt a helyzet.

1904.04.08.
RIP Jákub.
neut @

Persze.

Az en tapasztalatom viszont az, hogy a laptopom ~30-40%-ban hajszaritova valtozott miutan felkerult a linux. Ennyivel csokkent az akkuido linux alatt, mikozben erezhetoen lassult a gep.
Ennyi alapjan nem altalanositanek, de az en laptopomon a windows sokkal hatekonyabban dolgozik mint a "linux desktop".

Azt bizonyára láttad, hogy azt írtam feljebb, hogy az én szempontjaim voltak azok, amiket felsoroltam.

Az en tapasztalatom viszont az, hogy a laptopom ~30-40%-ban hajszaritova valtozott miutan felkerult a linux.

Nálam ez pl. úgy működik, hogy a laptop általában Windows és Linux alatt is gond nélkül elviseli a szokásos nem túl nagy terhelést.

Viszont havonta néhány alkalommal nézek egy webinart, amit látok, azt rögzítem, plusz egy böngésző fut egy konkrét weboldallal, ami adatokat elemez és rajzol, plusz egy program, ami szintén adatokat elemez és rajzol.

Windows alatt, ha kint melegebb van, rendszeresen elődordul, hogy a gép túlmelegszik annyira, hogy kikapcsol.Windows alatt az ablak kinyitása mellett kb. az a taktikám, hogy a programot bezárom és nem nyitom meg, a böngészőt meg csak rövid időkre indítom el. Linux alatt is meleget fúj, de nem annyira meleg, hogy kikapcsolna.

Sőt, olyan is előfordult, hogy egy tömörítést elindítottam Linux alatt, és mellette ment a webinar és a rögzítés meg a böngésző. Nem kapcsolt ki váratlanul.

A hw támogatásról nem írtál: A laptopomon Windows7 jött eredetileg. A Win7 már nem támogatott, Win10 alatt meg nem minden hw-hez van a cég által biztosított driver. OK, megy a videokártya meg a hálózat, de pl. a laptop speciális billentyűit nem kezeli, fényerőt nem tudok állítani (csak jobb gomb az asztalon, tulajdonságok és ott). Linux alatt is volt pár verzióváltás, ami ment régen, az megy most is. Nekem ez jól jön.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

>Gyártó által hivatalosan Linux támogatott laptopot vásároltál?

Ubuntu certified, jelentsen az barmit is.

>Akkor ott kell hibajegyet felvenni. 

Mit irjak nekik? Hogy a gnome-shell es xorg processek megesznek egy magot csak hogy az amugy tok ures kijelzon odebb tegyenek egy terminalt 4cm-rel, vagy azt, hogy a bongeszoknek ugyanazt a wiki oldalt atlag 2x annyi ideig tart megjeleniteni Ubuntu allat, mint windows alatt.

Elebe mennek annak, hogy a Linux nem tehet arrol, ahogy a bongeszok mukodnek. Nyilvan nem. De ettol meg szar az "elmeny", mert az akksimat megzabalja, a CPU-t elpocsekolja es hatekonytalanna teszi a munkamat. Sajnos ez a tapasztalatom.

"Ubuntu certified, jelentsen az barmit is."

Ha ez a notebook gyártó oldalán van, akkor igen, nála kell felvenned a hibajegyet hasonló szöveggel. 2020-ban egy desktop célú gépnél ez már nem fogadható el. Oldják meg a hibát, vagy cseréljék ki a másik notebook modellre, amin ez a hiba nem jelentkezik. Természetesen a hivatalos Ubuntu desktopnál kell jelentkeznie a hibának és nem Kubuntu vagy egyéb nem hivatalos Ubuntu variánsoknál. 

Ha nem a notebook gyártó oldalán hanem az Ubuntu oldalán láttad csak az Ubuntu certified szöveget, akkor ha fizetsz hivatalos Ubuntu supportért náluk kell erre hibajegyet felvenned. Ebben az esetben természetesen akkor sem kérheted a cserélt a notebook gyártójánál ha történetesen nem tudja megoldani a Canonical a problémádat. 

Már régen elmúltak azok az idők, hogy a gyártótól hivatalosan Windowszal vásárolt notebookra a user maga oldja meg okosban a Linux telepítését mert ez a hobbija. 2020-ban iparban használt Linuxok mellett teljesen elvárható, hogy a hivatalos Linux notebookot előretelepített Linuxszal ad oda a vásárlójának a gyártó, forgalmazó és jótáll annak megfelelő működéséért. 

>Ha ez a notebook gyártó oldalán van

Igen

> Oldják meg a hibát, vagy cseréljék ki a másik notebook modellre

Szoval szerinted a gyarto hibaja az, hogy a Gnome meg a Chrome/Firefox megeszi a procit. Annak ellenere, hogy windows alatt elvarhato modon mukodnek.

>Már régen elmúltak azok az idők, hogy a gyártótól hivatalosan Windowszal vásárolt notebookra a user maga oldja meg okosban a Linux telepítését

Ezzel azt akarod mondani, hogy a mai idokben csak a laptopok ~10%-atol varhato el,  hogy normalisan fusson rajta a Linux?

> [...] forgalmazó és jótáll annak megfelelő működéséért.

Hahaha. Szerintem te is tudod nagyon jol, hogy ez nincs igy. Nem hogy linux eseten, windows-on se. Max HW szinten fognak torodni veled, mar a FW/Bios is szurke zona.
Na de visszaterve az eredeti problemara: Egyaltalan nem arrol van szo, hogy hasznalhatatlan a gep Linux alatt. Ha nem tudnam hogy megy windows-zal, lehet fel sem tunne. Pl az emlitett oldalbetoltes windows-on ~0.5 sec, Ubuntu alatt 1.2-1.5 sec. Lassuk be, 1.5 sec nem a vilag vege. El lehet vele lenni. Csak ha atmegyek windowsra akkor egybol feltunik, hogy bakker ez rohadt gyors.

Ugyanez a fajlbongeszore. Mikor feltettem az Ubuntu-t nem kezdtem el egybol nezegetni, hogy hogy alakul a CPU terheles ablakrancigalasra. Pont nem erdekel. Csak amikor mar 5. alkalommal jott a gondolat, hogy ez mi a szarert ilyen lassu, akkor neztem.

Ilyenre nem lehet hibajegyet felvenni. Mukodik. Egyaltalan nem hasznalhatatlan. Csak nem hozza azt a teljesitmenyt, amit a windows. Ez nyilvan nem a gyarto hibaja.

"Szoval szerinted a gyarto hibaja az, hogy a Gnome meg a Chrome/Firefox megeszi a procit. Annak ellenere, hogy windows alatt elvarhato modon mukodnek."

2020-ban elvárható a tökéletesen működő böngésző. Amennyiben hivatalosan Firefoxszal jött a gyári Linux azzal, ha Chrome vagy más böngészővel akkor azzal. Nem azért vásárol valaki többszázezerért egy fejlesztésre szánt notebookot, hogy egy alsó-közép gép teljesítményét hozza, amit harmad vagy negyedannyiért is megkapott volna. 

https://www.phoronix.com/scan.php?page=article&item=windows10-linux-browsers

Általában jobb jelenleg Windows 10 alatti böngészőteljesítmény, de a különbség nagyságrendileg nincs közelében annak a többszörös eltérésnek amit te tapasztalsz. Reprodukálható teszteket kell csinálni, dokumentálni, majd hibajegyet felvenni ha irreális eltérést tapasztalsz. 

2020-ban nem magyarázat az, hogy "működik így is". Nem ezért fizet extrát a vásárló a drágább modellért. Vagy tessék visszafizetni az ár egy részét kompenzációként. 

Te sírod össze a hup-ot azzal, hogy a Linux "kiforratlansagaval es/vagy eroforras pazarlasaval csokkenti a hatekonysagomat" (sic) márpedig ez tényszerűen nem igaz. Ezek a sommás megállapítások objektivitást nélkülöző pebkac -gyanús frusztrációidra utalnak. 

Már nem a vadkelet világában élünk szerencsére Magyarországon sem, ahol kasszától való távozás után így jártál ha bajod van. Linux szerverek több évtizedes múltja után ma már a Linux dekstop is a professzionális it világ része, ahol a pénzéért a vásárlónak lehetnek jogos elvárásai. 

Ahogy a felső-kategóriás PC-t nem lehet Celeronnal odavágni az ügyfélnek azzal, hogy működik az is, úgy egy felső-kategóriás hivatalos Linuxos notebookot sem lehet elvárhatónál jóval gyengébben teljesítő Linuxszal adni. Nem véletlenül jelent például a Dell neve valamit a szakmában, szemben a Karcsika PC-vel. Rajtad kívül számtalan elégedett ügyfele van a Dell-nek, akik okkal vették ettől a gyártótól a hivatalos Linuxos desktop gépüket. 

Ha egy csúcskategóriás mobilt vásárolsz, amin az optimalizálatlan Android rosszul teljesít, ott sem mondhatja a gyártó, hogy "mi csak a hardverért felelünk, szoftveres problémákkal tessék a Google-höz fordulni." Az a mobilgyártó aki sokáig ad többszáz ropiért olyan mobilokat amik 100 alatti budget mobilok teljesítményét hozzák "csak" szoftver oldali problémák miatt, az a gyártó nem fog sokáig felső-kategóriás mobiljaival megmaradni a piacon. 

>de a különbség nagyságrendileg nincs közelében annak a többszörös eltérésnek amit te tapasztalsz. 

en nem futtattam kulonbozo szintetikus teszteket, mert nem erdekel. Egyszeruen feltunt, hogy joval lassabban toltenek be oldalak. Letoltottem egy bongeszo plugint, ami meri a betoltesi idot, annak kimenetet posztoltam.

Lehet, hogy ha lefuttatnam ugyanazokat a teszteket, nekem is hasonlo szamok jonnenek ki. De engem ez tokre nem erdekel, marmint a szamok. Ami erdekel, hogy erezhetoen lassabbak a bongeszok linux alatt es ez komoly gond szamomra, mert kellenek a munkamhoz.

> Reprodukálható teszteket kell csinálni, dokumentálni, majd hibajegyet felvenni ha irreális eltérést tapasztalsz.

Egyszeruen nem tudom elhinni, hogy te ezt komolyan gondolod. A laptop gyarto megis mihez kezdene egy lassu bongeszovel linux alatt, foleg ha windows-on meg megy? 

>Te sírod össze a hup-ot azzal, hogy a Linux "kiforratlansagaval es/vagy eroforras pazarlasaval csokkenti a hatekonysagomat" (sic) márpedig ez tényszerűen nem igaz. Ezek a sommás megállapítások objektivitást nélkülöző pebkac -gyanús frusztrációidra utalnak.

Ha arra a blogpost-ra gondolsz, ahol leirtam a tapasztalataimat, akkor igen. En sirom ossze a hup-ot. Az egeszet. De keszulj, mert sorozatnak szanom.

> [...] márpedig ez tényszerűen nem igaz.

Az, hogy tenyszeruen mi igaz a sajat laptopom vonatkozasaban, azt ugye csak en tudhatom. Mast meg nem allitottam. Ha nem hiszed amit leirtam, en ugyan nem banom, szived joga. Kulonosebben nem hat meg.

>Ezek a sommás megállapítások objektivitást nélkülöző...

Nem ertem milyen objektivitasrol beszelsz. Eleve szubjektiv volt az egesz poszt. Sajat tapasztalat, sajat nezopont, egy adott laptop es distro.

>...pebkac -gyanús frusztrációidra utalnak.

Az en gyanum viszont az, hogy meglatasod szerint, ha a linux desktop nem ugy muzsikal egy gepen, hogy arrol csak szuperlativuszokban lehessen beszelni, akkor nyilvan vagy Karcsika PC-n fut, vagy hozza nem erto hasznalja, de biztosan nem a linux hibaja. En ezt a velemenyedet elfogadom, csak akkor nekunk nincs mirol beszelgetni a tovabbiakban.

>...pebkac -gyanús frusztrációidra utalnak.

Az en gyanum viszont az, hogy meglatasod szerint, ha a linux desktop nem ugy muzsikal egy gepen, hogy arrol csak szuperlativuszokban lehessen beszelni, akkor nyilvan vagy Karcsika PC-n fut, vagy hozza nem erto hasznalja, de biztosan nem a linux hibaja. En ezt a velemenyedet elfogadom, csak akkor nekunk nincs mirol beszelgetni a tovabbiakban.

Az lehet a különbség, hogy sokan mások nem tapasztalják ezt, amit írsz. Így nem valószínű, hogy "a Linux" hibája lenne, mert akkor valószínű mindenkinél jelentkezne.

Szóval mik szoktak lenni a tipikus hibák? 1) valami hardver nem megfelelően van támogatva, és ezért valami faladatot nem a megfelelő sebességgel hajt véget a gép, 2) valami beállítási hiba van (gondolom ezért írta, hogy PEBKAC), 3) még az is lehet, hogy fut pár olyan dolog, ami erőforrásokat zabál és felesleges (ezt is hívhatjuk PEBKAC-nak, ha akarjuk). 4) Lassú és erőforrászabáló DE (Gnome3 szevasz),

Én valószínű azt próbálnám a helyedben, hogy kipróbálnék egy másik disztribúciót (valamit, amit ismerek és tudom, hogy más gépeken jól szokott muzsikálni), amit magam telepítenék (mert láttam már bután telepített Linux disztribúciót is meg egy számomra ismeretlen disztribúcióról nem tudom, hogy hogyan szokott működni, lehet, hogy mindig mindenkinél lassú valami miatt). És feltétlenül valami más DE-t választanék Gnome3 helyett. Én konkrétan KDE-t vagy az LXDE, XFCE és hasonló vonalról valamit, ha valami nagyon gyenge gépről van szó.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

> de biztosan nem a linux hibaja Mondjuk tényleg nem a Linux kernel hibája, hanem használt a software-stacké. Régebbi gépeken jobban kijönnek a különbségek, ott lehet látni mi az ami tényleg baromi lassú. Pl. 2x1.25 GHz-es PowerMac G4 MDD, a buguntu 10.04, régebbi GTK 2-es Xfce-vel valamivel gyorsabb volt, mint az OSX Tiger, viszont a Debian Jessie a GTK3-as Xfce-vel nagyságrendekkel lassabb a Tigernél. A króm emlékeim szerint még támogatja a GTK2-őt is (legalábbis a nálam lévő relatíve friss 73.0-át még le tudtam forgatni GTK2-vel), csak minden csomagkarbantartó már a 3-assal fordítja és csomagolja. Ki kéne próbálni a gépeden, hogy mennyit gyorsul a rendering, ha GTK2-vel használod.
Oldschool Computer - http://oscomp.hu
> Mit irjak nekik? Hogy a gnome-shell es xorg processek megesznek egy magot csak hogy az amugy tok ures kijelzon odebb tegyenek egy terminalt 4cm-rel, vagy azt, hogy a bongeszoknek ugyanazt a wiki oldalt atlag 2x annyi ideig tart megjeleniteni Ubuntu allat, mint windows alatt. > Elebe mennek annak, hogy a Linux nem tehet arrol, ahogy a bongeszok mukodnek. Nyilvan nem. De ettol meg szar az "elmeny", mert az akksimat megzabalja, a CPU-t elpocsekolja es hatekonytalanna teszi a munkamat. Sajnos ez a tapasztalatom. GTK3 still at large. :(
Oldschool Computer - http://oscomp.hu

Egy CentOS/Debian/Ubuntu nemfog neked "nincs aktiválva, vagyis nem fizettél érte, úgyhogy coki" üzeneteket dobálni, szóval maradjunk annyiban hogy nem a Linux-ért és annak funkcionalitásaiért fizetsz, ha fizetsz, (mert nem kötelező fizetni érte), hanem a támogatásért, ha szeretnéd harmadik féllel kötött szerződéseel védeni a valagadat.

nem játék a szavakkal, ugyanis aze gygikért fizetned _kell_, és mellé ugyanúgy kell üzemeltetői csapatot fenntartanod, a másikért meg ha "gyártói" támogatást szeretnél, akkor kiválasztod a szimpatikus linux disztribúciót, megnézed, ki ad rá supportot, és fizetsz neki (ha akarsz), és mellérakod a saját üzemeltetői csapatodat.

Láttam elég méretes forgalmú webes szolgáltatásokat, illetev az azokat kiszolgáló infrastruktúrát. Volt pár, ahol fizetős RHEL-t használtak, és volt egy rakat egyéb, ahol meg Ubuntu/Debian vagy épp CentOS alapon ment a core business!) is - bízva a cég saját, jól felkészült üzemeltetői gárdájában, harmadik félnek fizetett supportdíj nélkül.

Érdekes, nekem itt van a 6.x, 7.x meg 8.x ISO-ban, igaz, ez developer account-ról jött még le:
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-su…

persze a "mire használhatod" részt érdemes átnézni, illetve átgondolni - nem véletlen, hogy RHEL/CentOS vonal esetén a költséghatékony megoldás keresése a CentOS irányba tolja a használókat.

A "nagyon akarom" csak annyi, hogy regisztrálsz egy developer-es accountot, és készen is vagy. Mivel egy szál desktopról van szó, ott a "mit nyújt" gyakorlatilag megegyezik azzal, amit a CentOS tud - mert szerintem kicsi az esélye annak, hogy a RedHat oldalán szeretnéd nyomon követni a hardver- és szoftverinventory-t, meg azt, hogy az egy géped közül melyikre milyen patch érhető el, milyen besorolsát kapott, stb.

" a teljes IT költéshez képest " - hááát... Azért a ~250USD/VM/év az opex oldalon szépen ki tud nőni az "elhanyagolható" kategóriából... Merthogy nagyjából ennyibe fáj a support, akár a Canonical, akár a RedHat árait nézem (nagyjából azonos szolgáltatáscsomagot véve).