Hlavní navigace

Linux Mint stále hazarduje s bezpečností

22. 12. 2016

Sdílet

Přestože má zde Linux Mint dost pozornosti a i přesto že prošel několika aférami s bezpečností (a jeho tvůrci tvrdili, že ji zlepší), vše je zřejmě stále při starém… :-( Autor článku doporučuje jeho tvůrcům, aby vytvořili svoji distribuci tak, aby ji updaty nepoškozovaly, zapnout automatické aktualizace a přestat svým uživatelům doporučovat, aby systém neaktualizovali. Vše začíná a končí u citátu použitém autorem distribuce (Clement Lefebvre) “If it ain’t broke, don’t fix it”, který byl jím zřejmě špatně pochopen a je dnes velmi nebezpečný.

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 22. 12. 2016 10:19

    Prezdivka (neregistrovaný)

    “If it ain’t broke, don’t fix it”, který byl jím zřejmě špatně pochopen a je dnes velmi nebezpečný.

    To se neda takto obecne rici, ze je dnes velmi nebezpecny. Kontext je vzdycky dulezity.
    Co ja bych dal za to, kdyby ten citat "takhle spatne pochopil" Microsoft pote, co vytvorili WIN7 a premysleli co dal ...

  • 22. 12. 2016 10:24

    kdokoliv (neregistrovaný)

    no jo hlavne si plivnout na microsoft a je klid, koukam ze komplex menecenosti z linux komunity stale nevymizel

  • 22. 12. 2016 10:48

    Rad (neregistrovaný)

    mylim, ze doslo k nepochopeni 'predrecnika':
    win7 se propracoval na docela stabilni a vyladeny system, nacez jeho upgrade nasilnou formou v dobe, kdy nastupujici system jednak neni plne stabilni, ani neobsahuje odladene aplikace, druhak nektere custom aplikace na nich nebezi vubec, to je cesta do pekel, nebo minimalne dobre slapnuti do exkrementu

    linux mint prave umoznuje nedelat upgrade, pokud uzivatel nechce. prave z duvodu vyladeni systemu, ktery funguje.
    treba pochopit, z ne kazdy je geek a hracicka, co miluje si pohravat s nejnovejsi verzi vseho mozneho, ale jsou cele mraky lidi, pocitac a jeho OS + aplikace pouzivaji jako nastroj. vi kde a jak funguje, vi kde se co nachazi.
    posledni roky upgrade znamena hlavne prozit kolecko instalaci, vyladovani, zmen, uceni se zmenam chovani vyzoru, umisteni, nacez frustrace z nefunkcnich aplikaci ... a pocas tech nekonecnych hodin skutecna prace stoji.

  • 22. 12. 2016 11:00

    Milan Keršláger

    Od toho jsou bezpečnostní aktualizace, které by měly pouze opravovat daný problém (známe "oneliners"). V opensource je to běžné. Některé distribuce (RHEL/CentOS/U­buntu) umožňují instalovat automaticky jen takové (a dokonce i na nějaký čas "přeskočit" desetinkové verze). Mint by měl taky alespoň tohle dělat implicitně.

  • 22. 12. 2016 11:24

    Filip Jirsák

    Podle mne jsou naopak ty bezpečnostní aktualizace v linuxových distribucích velký problém. Pokud vytvoří bezpečností aktualizaci autor programu a vydá po verzi 1.2.3 verzi 1.2.4, kde je jen ta bezpečnostní aktualizace, je to správně. Ale pokud autor vydá po verzi 1.2.3 novou verzi se spoustou oprav, vylepšení i bezpečnostních oprav verzi 1.3.0, a po té se na to vrhnou správci balíčků v distribucích, vytáhnou si z toho patche, o kterých si myslí, že jsou důležité z pohledu bezpečnosti, a nějak je naroubují na svou verzi 1.1.6-r6, je to špatně - a je s podivem, že z toho zatím byly jenom "drobné" průšvihy jako vylepšený generátor v Debianu, který generoval předvídatelné náhodné klíče. Problém je v tom, že tyhle úpravy dělá někdo, kdo tomu programu zpravidla moc nebo vůbec nerozumí a nezná kontext toho patche, vznikne takhle unikátní verze programu, která není nikde jinde, než v dané verzi distribuce (takže to nikdo neotestuje), navíc administrátor pořádně neví, které opravy tedy v té aplikaci má - na webu se dočte, že vyšla nová verze 1.3.0 s bezpečnostními opravami, ale on má verzi 1.1.6-r6 a musí pátrat, jestli tu opravu, která jeho zajímá, obsahuje (a klidně se může stát, že v té verzi 1.3.0 je oprava, kterou potřebuje, jak pozná z popisu na webu - jenže v distribuci je jen její část). Jediné štěstí je, že tím, jak takhle vznikají unikátní verze programů, které používá jen hrstka uživatelů, nevyplatí se na to nějak hromadně útočit.

    Doufám, že v tomhle bude dostatečně silný tlak z cloudových řešení, kde se neplýtvá zdroji na udržování spousty různých "aktivních" verzí, ale je jen jedna verze, která se udržuje a testuje pořádně. Protože ten systém "stabilních" distribucí založených na unikátním a netestovaném softwaru není dlouhodobě udržitelný a nepřináší žádné skutečné výhody.

  • 22. 12. 2016 11:38

    Franta Ruzicka (neregistrovaný)

    No a není tedy řešením používat distribuce, které jsou maximálně upstream?

  • 22. 12. 2016 12:19

    Jarda_P

    Neni. Uz treba i v Debianu testing, ktery je pomerne stabilni, muze clovek narazit na problemy. Tu neco prestane fungovat, tu aplikace na par mesicu zmizi a pak se zase objevi... Neni to caste, ale muze to byt dobry opruz. Hracickum to treba nevadi, ale nekdo jiny da prednost spise funkcni stabilite.

  • 22. 12. 2016 12:30

    Franta Ruzicka (neregistrovaný)

    Tak z pohledu problému, který popsal p. Jirsák, je upstream asi řešením.

    Navíc třeba upstream Slackware je slušně funkčně stabilní. Na desktopu mám několik let Arch, který je bezpochyb funkční a dostatečně stabilní.

  • 22. 12. 2016 12:57

    Milan Keršláger

    Aktuální Linux Mint je IMHO založen na Ubuntu 16.04 LTS a na LTS verzi právě kvůli minulému velkému průšvihu. Takže aktualizace by měly být v pohodě včetně bezpečnostních (a jejich selektivní instalaci). Problém je, že vývojáři Mintu dělají svoje balíčky nekorektně a aktualizace nemusí kvůli konfliktům fungovat...

    Letošní špinavá kráva asi taky vývojáře Mintu moc netankuje... ale už se to neprobírá tak jako minule... asi si všichni už zvykli, což je špatně.

  • 22. 12. 2016 13:31

    pedro (neregistrovaný)

    S tim se neda nesouhlasit, je to dlouho znamy problem. Na druhou stranu, autori SW se ridi pravidlem "release early, release often" a jejich SW proste obsahuje minimalne v posledni verzi mnoho bugu (treba i z oblasti bezpecnosti).

    Druha vec je, ze nektere distribuce na mne pusobi jako dostihovy kun. Jestli distro vyjde s programem ve verzi 1.2.3, tak tam proste v zajmu stability verze 1.2.3 zustane, prestoze v case zivota distra vysla jedna nebo nekolik minor verzi bez vetsiho potencialu neco dalsiho rozbit...

  • 22. 12. 2016 14:02

    Filip Jirsák

    Na druhou stranu, autori SW se ridi pravidlem "release early, release often" a jejich SW proste obsahuje minimalne v posledni verzi mnoho bugu (treba i z oblasti bezpecnosti).
    Jenže tenhle problém se nevyřeší tím, že vezmu sadu patchů, některé z nich víceméně náhodně vylosuju a naroubuju je na starší verzi. Tím docílím nanejvýš toho, že moje aplikace bude mít jinou sadu chyb, než upstream - ale v žádném případě to neznamená, že těch chyb bude méně nebo že budou méně závažné.

    Tohle má jediné řešení - že ty bezpečnostní aktualizace bude udržovat upstream. Jenže to je samozřejmě náročné. Dělají to tak třeba vývojáři jádra, ale i tam bych byl na pochybách, zda longterm jádra opravdu mají správně opravené všechny bezpečnostní chyby, které jsou opravené v aktuálním jádru, a zda nemají nějaké nové chyby.

    Druha vec je, ze nektere distribuce na mne pusobi jako dostihovy kun. Jestli distro vyjde s programem ve verzi 1.2.3, tak tam proste v zajmu stability verze 1.2.3 zustane, prestoze v case zivota distra vysla jedna nebo nekolik minor verzi bez vetsiho potencialu neco dalsiho rozbit...
    Problém je, když je v těch minor verzích nějaká bezpečnostní oprava - a ještě větší problém, když je tam bezpečnostní oprava, aniž by to bylo známo (třeba proto, že vývojář opraví nějakou chybu, aniž by si uvědomil, že by tu chybu bylo možné zneužít).

    To, že distribuce nemusí mít poslední verzi programu, je sice pravda (moc nechápu nářky uživatelů, že program už je ve verzi X, ale oni mají v distribuci pořád verzi Y - když používám nějakou distribuci, mám ty verze programů, které má k dispozici ta distribuce, a nezajímá mne, že na nějaké jiné platformě a jiném systému mají stejný program v novější verzi). Problém je, že to předpokládá, že se změny v programu dají rozdělit do dvou disjunktních množin - na vylepšení a nevýznamné opravy na straně jedné a na bezpečnostní a jiné důležité opravy na straně druhé. Jenže tak to v reálném světě nefunguje.

  • 22. 12. 2016 14:29

    pedro (neregistrovaný)

    v žádném případě to neznamená, že těch chyb bude méně nebo že budou méně závažné

    Teoreticky ne. Prakticky to nekteredistribuce dlouhodobe provozuji s relativnim uspechem a obcasnym prusvihem.

    bezpečnostní aktualizace bude udržovat upstream

    Ano, to by bylo idealni reseni. Zase vyhrada praxe - nefunguje to ani u velkych projektu, to vlastne i sam priznavas,,,

    Problém je, když je v těch minor verzích nějaká bezpečnostní oprava

    Tady si nerozumime. Ja jsem tim prirovnanim k dostihovymu koni mel na mysli, ze distra ve svoji politice "stability" vubec nezkoumaji a nerozlisuji mezi minor (=bezpecnosti opravy a bugfixy) a major updaty. Pak kdyz je velky prusvih (napr. znama bezpecnostni chyba), vyresi to po svem aplikaci nejakeho podivneho patche, presne jak pises... Prijde mi to nestastne...

  • 22. 12. 2016 14:54

    Filip Jirsák

    Prakticky to nekteredistribuce dlouhodobe provozuji s relativnim uspechem a obcasnym prusvihem.
    Relativním vůči čemu? Podle mne je jediným "úspěchem" to, že daná distribuční verze má tak málo uživatelů, že se nikomu nevyplatí to zkoumat.

    nefunguje to ani u velkych projektu, to vlastne i sam priznavas
    Jenže ono to nefunguje ani v těch distribucích. A výsledek je podle mne ještě horší, protože tak vznikají unikátní málo testované verze programů.

    Myslím, že není náhoda, že se všichni autoři nejpoužívanějších webových prohlížečů snaží, aby uživatelé měli stále nejnovější verzi a nesnaží se udržovat v provozu staré verze. Přitom webový prohlížeč je na desktopu z hlediska bezpečnosti nejexponovanější program.

  • 22. 12. 2016 15:37

    pedro (neregistrovaný)

    Ano, tim relativnim meritkem je zajem uzivatelu, "uspesnost"

    Dokud upstream nezacne oddelovat bugfixy a bezpecnostni opravy od nove funkcionality, tak je to prave otazka poptavky. Nemuzes proste rict, ze distributor, ktery se snazi resit problem upstreamu releasem vlastnich patchu je pricinou problemu. On jenom resi existujici potavku uzivatelu a nedostatek ve vyvoji v upstreamu.

    Skutecny problem distributora vidim, pokud si baliky zijou uplne vlastnim zivotem ve stylu udrzby verze 1.2.3, prestoze upstream mezitim vydal minor verze 1.2.4 az 1.2.6. To skutecne nema vysku, ale relativne casto to tak je...

  • 22. 12. 2016 15:51

    Filip Jirsák

    Nemuzes proste rict, ze distributor, ktery se snazi resit problem upstreamu releasem vlastnich patchu je pricinou problemu. On jenom resi existujici potavku uzivatelu a nedostatek ve vyvoji v upstreamu.
    Poptávka uživatelů je po softwaru, který má co nejméně chyb a co nejvíce funkcí (u některých uživatelů to může být i v opačném pořadí, ale ti budou už dnes používat rolling distra). Backportování patchů není něco, co by uživatelé chtěli, je to výmysl distribucí, jak ten výše uvedený požadavek zajistit. A je otázka, zda je to opravdu nejlepší způsob (i když vynecháme možnost, že by to řešil upstream).

    Já si nemyslím, že by to byl problém upstreamu. Podle mne je problém v představě, že stabilní software získám tím, že z prováděných změn vyberu jenom některé a ty použiju samostatně. Myslím, že webové prohlížeče jsou důkazem toho, že jedna udržovaná a testovaná aktuální verze je lepší řešení.

  • 22. 12. 2016 16:12

    pedro (neregistrovaný)

    To je super teorie, ale mizerna praxe. Spousta opensource programu nema zadnou stabilni verzi a rozhodne to neni ta posledni verze. Upstream vyvojarum je v rade opensource projektu do znacny miry jedno, co si mysli uzivatel nebo ze uzivatele mozna preferuji postupny vyvoj proti revolucnim zmenam. Podivej se, co se v posledni dobe deje i kolem velkych projektu - vyvojari jedou nejaky "program", kterymu osobne veri, hromada uzivatelu je nasr* a hleda alternativni reseni, odchazi. Priklady - KDE4, Gnome 3, Akonadi + Kmail, systemd atd.

    Priklad webovyho prohlizece mi nepripada uplne dobry. Dneska existujou dva oss prohlizece nebo enginy, ktery nejak stihaji s dobou - Firefox/Gecko a Chrome/Blink. Vsechno ostatni je beznadejne pozadu a v podstate nepouzitelny. Ty dva jmenovane jsou obrovske projekty, stoji za nima firmy a velke penize. Proste to nejsou zadny typicky predstavitele OSS sveta.

  • 22. 12. 2016 16:21

    Milan Keršláger

    Jenže rolling je špatně (to je jen eufemismus pro testování na uživatelích). Vede to k nepredikovatelným výsledkům u uživatelů takové distribuce. Ve firemním/produkčním prostředí je to nepřípustné, protože vám příchod novější verze rozbije další věci okolo. Správce, který to má v hlavě srovnané, pouští bezpečnostní aktualizace a jednou za čas (když vyjdou) otestuje novější revize (bugfixy, tj. tečkové verze LTS distribucí) a přijme je ve vhodnou chvíli taky.

    Proto RHEL drží v distribuci původní balíčky a přidávají k nim bezpečnostní záplaty. Ty bezpečnostní záplaty by měly být dobře vidět v revizním systému který používá upstream a měly by tam být izolované a označené. A ideálně by samozřejmě měl upstream sám backportovat svoje opravy do svých vlastních starších verzí vlastního softu, které ohlásil jako LTS (a LTS distribuce je používají).

    Takhle funguje třeba i Mozilla/Firefox nebo LibreOffice proti RHEL.

  • 22. 12. 2016 17:02

    Filip Jirsák

    A aplikace patchů z úplně jiné verze snad není jen eufemismus pro testování na uživatelích? Výsledky jsou ještě nepredikovatel­nější, protože tak vznikají unikátní verze programů, které jsou poprvé testované až v rámci testů té distribuce.

    Správce, který to má v hlavě srovnané, pouští bezpečnostní aktualizace [...] Ty bezpečnostní záplaty by měly být dobře vidět v revizním systému který používá upstream a měly by tam být izolované a označené.
    Jenže to je právě ta iluze, že existuje něco jako "bezpečnostní aktualizace", která jenom opraví bezpečnostní chybu a nic jiného nedělá. Takové aktualizace sice existují, když třeba opravují nějaké buffer overflow, které je způsobené jednou zjevně chybnou řádkou v programu. Jenže některé bezpečnostní chyby jsou záležitostí třeba architektury programu nebo nějaké komponenty, nebo se chyba projevuje v komplexním prostředí, třeba při spolupráci dvou nebo tří komponent. Takové chyby mohou upravovat patche, z jejichž kódu ani nepoznáte, že jde o opravu bezpečnostní chyby. A upravit tu samou chybu ve starší verzi programu může znamenat dost podstatné úpravy, ke kterým je potřeba programu docela dobře rozumět. Ne že by nemohli distribuční balíčky spravovat lidé se stejnými znalostmi programu, jako jsou vývojáři upstreamu, ale nebude to zrovna častý případ.

  • 22. 12. 2016 17:11

    Milan Keršláger

    Bezpečnostní team pro RHEL/SUSE/Ubuntu asi nýmandi nebudou.

    V každém případě je pro reálné nasazení nejvhodnější to, co jsem popsal. Tedy pokud si správce se své místo udržet na delší dobu. Nepočítám tedy s tím, že by takový správce byl lepší analytik/kodér/QA/au­ditor, než co má k dispozici ta konkrétní distribuce. Proto taky Mint je klon Ubuntu a to je (víceméně) klon Debianu. A uvnitř toho máte tolik člověkohodin, že na to nějaký správce (nebo vývojáři určitého programu) nikdy nebude mít, a proto je tento model nejvýhodnější a hlediska stability. Ale neuspokojivý pro hračičky.

    Absolutní a ideální řešení IMHO neexistuje.

  • 22. 12. 2016 18:20

    Filip Jirsák

    Pochybuju, že u běžného balíčku správce v Debianu nebo RHELu věnuje zdrojákům spravovaného programu víc času, než jeho upstream programátor. A co vím, je u takových balíčků problém, aby se o to vůbec někdo staral. Představa, jak upstream vývojář stráví čtyři hodiny opravou nějaké chyby, a pak se na to vrhnou správci a QA jednotlivých distribucí, backportují to a otestují a věnují tomu řádově víc času, než ten upstream vývojář, je sice hezká, ale nemyslím, že by byla z tohoto světa. Ona by pak byla otázka, proč by se ti správci nevěnovali přímo upstreamu, a také jestli by bylo efektivní, aby se menšina energie vynakládala na vývoj a údržbu samotného programu, a většina energie by se vynakládala na vytváření dočasných upravených verzí toho programu.

    Nepočítám tedy s tím, že by takový správce byl lepší analytik/kodér/QA/au­ditor, než co má k dispozici ta konkrétní distribuce.
    Jenže stejně tak většinou platí, že správce distribučního balíku zpravidla není lepší analytik/QA/au­ditor, než co má k dispozici upstream. Předpokládám, že takové OpenSSL bude mít od distribučních správců spíš dost nadprůměrnou péči, přesto žádný distribuční analytik/odér/QA/au­ditor za celou dobu neodhalil, jaký průšvih OpenSSL je. Takže se nezdá, že by ta distribuční péče byla výrazně lepší, než jakou tomu věnoval upstream.

    Že je to nejvýhodnější z hlediska stability, o tom právě pochybuju. Vznikají tak unikátní verze programů a unikátní kombinace, které testuje a používá méně lidí - to jde proti stabilitě. Navíc často vznikají ve spěchu - upstream může opravu chyby, která ještě není známá, ladit třeba týdny, ale když opravu vydají, distribuce ji potřebuje backportovat co nejdřív. Mohou už dříve spolupracovat s upstreamem, ale také nemusí. A jisté není ani to, jak moc se ty patchované verze používají - jestli se u těch stabilních distribucí nedrží původní verze většiny softwaru i se známými bezpečnostními chybami a neaktualizuje se jenom pár vybraných komponent, případně zda se pro důležité věci nepoužívají vlastní sestavení.

  • 22. 12. 2016 18:31

    Filip Jirsák

    Už kolikrát mi třeba až s odstupem došlo, že by se dala zneužít chyba, na kterou jsem přišel nebo i opravil - takže o rozdělování oprav na "běžné" a "bezpečnostní" si myslím své. Nehledě na to, že když vám nějaká chyba brání v něčem, co potřebujete udělat, je jedno, zda je to chyba běžná nebo bezpečnostní, prostě potřebujete mít verzi, kde je ta chyba opravená.

  • 23. 12. 2016 10:42

    pedro (neregistrovaný)

    Na tom neni vubec nic vhodnyho. I kdyby v idealnim svete upstream vytvoril ciste bezpecnostni a bugfixovy update, tak tito nazzi distribucni "vyvojari" ho proste nenabalickuji. Nechci se dohadovat, proc to tak je, ale mam proste takovou zkusenost...

  • 23. 12. 2016 11:44

    Milan Keršláger

    Komunikace musí fungovat oběma směry. Pokud správce distribuce/balíčků označujete "nazi", pak chyba nebude jen u nich.

    Zaměstnanci Red Hatu mají za úkol pracovat s upstreamem, což také dělají (i v současnosti), protože je to z dlouhodobého pohledu výhodné (a navíc se zároveň učí). V SUSE to tak nebývalo, jak je to dnes, to nevím.

    Pokud vývojář najde chybu a chtěl by, aby se projevila v distribuci, měl by nějakým vhodným způsobem s balíčkářema spolupracovat. Myslet si, že "se to udělá samo", není dobrý přístup. Také je důležitá politika distribuce - například RHEL víceméně zamrzne v době vydání. Opravy i upgrady balíčků se dělají, ale jen u věcí u kterých to má význam (resp. prioritu). Taky musí být poptávka (otevřený bugreport na abugzilla.red­hat.com nebo otevřený ticket, jste-li platící zákazník). U Fedory je naopak poměrně velká vstřícnost k povyšování verzí i po vydání distribuce.

    Celé opensource je kolektivní dílo, takže nelze předpokládat, že někdo něco udělá za vás. Když něco chcete, předpokládá se že přiložíte ruku k dílu. Pokud ruku k dílu nepřiložíte, neměl byste nadávat a měl byste se spokojit s tím, co je k dispozici.

  • 23. 12. 2016 13:27

    Filip Jirsák

    Pokud vývojář najde [opraví] chybu a chtěl by, aby se projevila v distribuci, měl by nějakým vhodným způsobem s balíčkářema spolupracovat.
    To mi připadá poněkud zvrácené. Distribuce snad má přidávat nějakou přidanou hodnotu, ne přidělávat práci vývojáři, který se bude doprošovat každého distribučního správce extra, jestli by byl tak laskav a zařadil opravu chyby.

    Celé opensource je kolektivní dílo, takže nelze předpokládat, že někdo něco udělá za vás. Když něco chcete, předpokládá se že přiložíte ruku k dílu. Pokud ruku k dílu nepřiložíte, neměl byste nadávat a měl byste se spokojit s tím, co je k dispozici.
    Já nenadávám a nepoužívám distribuce, které pod pojmem „stabilní“ dodávají unikátní netestovaný zastaralý software. Akorát si myslím, že je tenhle model přežitý, protože už nastává doba, kdy bezpečnost se zastaralým softwarem prostě nezajistíte, i když budete patchovat sebevíc. A že by možná stálo za to tu energii, která se věnuje na vytváření unikátních málo testovaných verzí, věnovat raději na testování a opravování aktuálních verzí.

  • 22. 12. 2016 13:37

    Rony (neregistrovaný)

    Áno. S takýmto prístupom sa dá len súhlasiť. S bezpečnostnou aktualizáciou existujúcej verzie systému by nemala pribúdať nová funkčnosť a iné fičúry, ale len oprava konkrétnej chyby resp. viacerých chýb. Nová verzia s novou funkčnosťou by však mala mať automaticky odladené tie chyby, pre ktoré bola v nižšej verzii bezpečnostná záplata. Debian k tomu konverguje.

  • 22. 12. 2016 11:24

    Jiří Eischmann

    Nedělat upgrade, pokud to uživatel nechce, umožňuje prakticky každá distribuce. Nikdo vás nenutí upgradovat, můžete si používat konkrétní vydání třeba Fedory klidně 10 let. Znám lidi, kteří mají pořád Fedoru 14... Nicméně pokud distribuce něco takového uživatelům oficiálně doporučuje, tak má také zajistit, aby to pro uživatele bylo bezpečné. Pokud to není schopná zajistit, tak něco takového doporučovat nemá.

  • 22. 12. 2016 11:15

    Prezdivka (neregistrovaný)

    @kdokoliv
    "no jo hlavne si plivnout na microsoft a je klid, koukam ze komplex menecenosti z linux komunity stale nevymizel"

    1) Prominte, ale vubec jste me nepochopil.
    2) Vubec me neznate a uz me radite do linux komunity. Mozna bych mohl byt i primo vyvojar kernelu, ze jo?
    3) Oznacovat automaticky veci s kterymi nesouhlasim za plivnuti, je jeden z prikladu manipulativni "argumentace" a muze znacit "zavirani oci pred realitou".
    4) Celkove mi vase reakce pripada jako kdyz bych na ulici pristoupil k Romovi a rekl, "Dobry den, mohl byste ..." "Hele gadzo, zazaluju te za rasistickou urazku."

  • 23. 12. 2016 6:55

    brk (neregistrovaný)

    No pozor, to není o plivání na Microsoft. Windows 7 býval dobrý systém a Microsoft ho nehorázným způsobem sabotuje.

    Čistá instalace se stává pro domácího uživatele víceméně nemožná a je to bezpečnostní hazard. Windows update je rozbitý takovým způsobem, že neuvěřím, že to je náhoda.

    Dva týdny tomu jsem jsem měl na instalaci 3 originál z fabriky downgradované notebooky na Windows 7. Nakonec jsem tam musel dát Windows 10, protože jsem na to neměl čas. Jeden notebook hledal aktualizace tři dny a nenašel nic. Na zbylých dvou jsem chvílemi zkoušel různé návody z internetu, ale nefungoval žádný.

    Internet je zavalený diskusemi o rozbitých Windows Updatech a tipy, co je třeba nainstalovat ručně, akorát to nefunguje. Problém je, že snad každý měsíc jde o jinou aktualizaci, kterou je tak potřeba doinstalovat a nyní patrně už ne jen jedenu.

    Včera jsem řešil stejný případ, jen už jsem nakonec dobral k cíli. K oživení aktualizací bylo potřeba stáhnout a nainstalovat ručně _9_ aktualizací. U části z nich ještě záleží na pořadí. Pak se to rozjelo normálně.

    Totální sabotáž. Windows 7 jsou podporované do ledna 2020, ale udělat teď čistou instalaci, nebo recovery, znamená, že to zařízení už je neaktualizované.

    Po tomhle by si Microsoft nezasloužil plivání, ale kopání.

  • 22. 12. 2016 11:04

    anonym (neregistrovaný)

    Ja mam tiez taky dojem, ze ten (slavny?) vyrok je trocha nepochopeny. Vytrhnuty z kontextu je samozrejme nafigu, ale ved bol jasne pouzity v spojeni s upgradom systemu - nie z beznymi aktualizaciami! Ak sa vyda verzia LM, predurci sa dlzka podpory, tento system sa nainstaluje a aktualizuje (beznymi aktualizaciami, nie povysenim na vyssiu verziu) pocas celej doby podpory, nemyslim si, ze by mal byt problem - je predsa beznym zvykom, ze sa bezpecnostne opravy backportuju do podporovanych starsich vydani, nie? (Vsak o tom vlastne aj je vztah upstream <--> downstream - a LM to ma pekne vysvetlene v prirucke.) V takom pripade clovek nema potrebu prechadzat na vyssiu verziu, pricom system ma zabezpeceny rovnako ako novsie verzie systemu.

    Co sa automatickych aktualizacii tyka, to je cisto vec osobnych preferencii. Ja osobne by som automaticke updaty nechcel - je pre mna vyhovujuce updatovat vtedy, ked mam na to cas. Iste je fajn, ze system na dostupnost updatov upozorni (co aj LM robi) - to je pre bezneho uzivatela site tak akurat - to je totiz pre neho znamenie, ze nejaka chyba (hoci aj bezpecnostna) bola opravena a update aplikuje vtedy, ked bude na to mat cas. Je to lepsie ako Windowsy - vsak to pozname, skoda reci...

    Spominany vyrok dalej velmi dobre vystihuje podstatu - ide totiz o to, ze upgrade systemu moze VZDY nieco rozbit. O tom su predsa verzie OS - kazdemu je totiz jasne, ze pri beznom update sa nic nerozbije (rozumej funkcnost zostane zachovana), zatial co pri upgrade na vyssiu verziu toto neplati - a logicky ani nemoze platit. Preto sa udrzuje jedna verzia OS nejaky cas a bezpecnoostne opravy sa iba backportuju - aby bola zachovana stabilita a funkcnost. To sa vsak neda donekonecna udrzovat, preto sa raz za cas vyda nova verzia, kde uz funkcnost zachovana nemusi byt.

  • 23. 12. 2016 1:34

    volani.tk (neregistrovaný)

    A není lepší model oddělení systémů a programů u windows?
    Když by měl windows svobodnou licenci a aktualizační program, který by udržoval programy v aktuální verzi jedním démonem, tak by to fungovali suprově :) Alá: https://en.wikipedia.org/wiki/List_of_software_package_management_systems#Windows

    Nebo něco na způsob anddroidu (aniž by byl problém upgrade na novou versi androidu.. A nejlépe root práva s možností odinstalovat systémové aplikace..
    Možná že ten android je docela systémem budoucnosti i pro PC, nebo ne?

  • 23. 12. 2016 3:24

    nobody (neregistrovaný)

    aneb, "neni lepsi jizda trabantem? kdyz by mel zlate ravky a centralni zamykani, tak by to bylo super" ;)

    tech veci co je na Windows spatne je tolik ze hypoteticka zmena licence a nezprasene aktualizace na vse to rozhodne nevyresi ;)

    clovek co ma zajem o reseni "problemu s aplikacema" u GNU/Linuxu ma uz ted (resp. davno) ruzne moznosti:
    - muze pouzivat rolling distro kde jsou vzdy dostupne nejnovejsi verze vseho, sytemu i programu (Arch, Gentoo)
    - muze pouzivat LTS verzi systemu a novejsi verze programu dodavat pres PPA repositare (*buntu/Mint)
    - muze pouzit stable repositar pro system a unstable(neznamena nestabilni, ale neustalene verze, tedy obdoba rolling) jen pro urcite aplikace (Debian)
    - lze pouzit kontejnery jako Docker, LXC, LXD nebo OpenVZ...
    - lze pouzit pripravovane uni-napric-distro kontejner-like balicky Snap nebo Flatpak
    - lze pouzit kompletni QEMU/KVM virtualizaci
    - pokud jde o oddeleni programu souborove a od systemovejch knihoven, tak distribuce GoboLinux

    ad Android pro PC, rozhodne si to nemyslim, ale muzes si sam vyzkouset: Android x86 nebo jeho nadstaveni "vice jako desktop" RemixOS, nebo open versi ChromeOS v podobe ChromiumOS

Byl pro vás článek přínosný?