Vlákno názorů k článku Tichá aktualizace moderních prohlížečů se obejde bez uživatele od anti-eHealth - Automatické aktualizace a volání domů jsou od výrobců...
-
Článek je starý, nové názory již nelze přidávat.
-
anti-eHealth (neregistrovaný)
Automatické aktualizace a volání domů jsou od výrobců přinejmenším neslušné! Narušování soukromí, možnosti rozhodování a vytváření kultůry strachu jsou velmi nebezpečný fenomén doby.
O cookies na webech máme vyjadřovat vědomý a informovaný souhlas, ale na souhlas s nahráváním software a odesíláním nekontrolovatelných dat výrobcům software se nikdo neptá.Takový software má mít předem danou, dostatečně dlouhou, expiraci. Po vypršení má software uživatele uzpozornit, že „záruka“ padla a v rámci ochrany zdravý počítače a dat si má nainstalovat novou verzi/software. Čistě bezpečnostní aktualizace stejné verze, bez čehokoliv jiného, se mají jen kontrolovat a to po náhodném čase na náhodném mirroru na stejný dotaz pomocí http GET bez hlaviček jako je user-agent. takže např. http://public-mirror-example.org/firefox-current vrátí seznam všech aktuálních verzí firefoxu a všech jeho doplňků. Je to tak těžké?
Ale to by vydavatelé přišli o nejcennější informace na prodej, tak co z toho.Na aktualizace má být jeden software přímo v systému, zajišťující anonymitu a bezpečnost. Ani o linuxových repo, ale nejsem přesvědčen, že to dělají.
Před lety jsem chtěl takový soft udělat, ale… co bych z toho měl :-) Tak mám pokaždé hromadu práce povypínat aktualizace a nastavit pravidla output firewallu, aby nic takového nepustil.Myšlenka, že když lidi vědomě nechtějí souhlasit s instalací aktualizace, tak se jich na to nezeptáme a uděláme jim to za zády, je do nebe volající.
-
Lael Ophir (neregistrovaný)
Automatické aktualizace jsou praktická nutnost. SW obsahuje řadu chyb, protože ho píšou lidé. Když uživatelům SW neaktualizujete, tam to sami neudělají, jejich děravý počítač nachytá spoustu malwaru, a způsobuje pak problémy jim i všem ostatním (spamování, zatěžování linky, DDoS útoky atd).
Aktualizace pomocí jediného SW přímo v systému přinášejí problémy s odpovědností za ty aktualizace, a právní tahanice když "diskriminačně" odmítnete zařadit aktualizaci například na nějaký spyware nebo malware.
-
A. S. Pergill (neregistrovaný)
spočívá v tom, že zejména na windows (ale setkal jsem se s tím i na linuxu) nejí zajištěna zpětná kompatibilita. Tj. po "aktualizaci" přestanou některé věci fungovat. U windows (končil jsem s XP) jsem měl všechny aktualizace zakázány a neaplikoval jsem ani service-packy, protože na 95 i 98 to vždy vedlo k totálnímu rozhašení systému, někdy až k nutnosti instalovat původní (neopravenou) verzi z disket či CD (později přibyla možnost systém po instalaci a rozchození uložit a v případně nezdařené aktualizace backupovat).
Já prostě mám systém na to, aby pracoval, ne na to, aby byl "aktuální" a polovina věcí tam nejela. Bez ohledu na to, jestli to byly windows nebo jestli je to nyní linux.Pokud vývojáři budou poskytovat nekvalitní aktualizace, které znefunkční systém nebo program (což se děje prakticky pořád a lidé už jsou naučení že "aktualizace = znefunkčení počítače"), tak se prostě uživatelé budou automatickým (i jiným) aktualizacím bránit.
Je to mj. i rozdílný pohled uživatele, který má počítač na práci, a pubertálního rybízka z vývojářské firmy, kterému ke spokojenosti stačí, když jednou denně kompletně přeinstaluje systém. -
pwo (neregistrovaný)
Cituji: "Aktualizace pomocí jediného SW přímo v systému přinášejí problémy s odpovědností za ty aktualizace ..."
Hmm, vidím, že tohle zásadní nepochopení je třeba vysvětlit. Uvedu příklad z praxe: R (www.r-project.org) je mocná aplikace (a jazyk) pro statistické výpočty. Instalovat a updatovat se dá různými způsoby. Mě osobně se jako nejjednodušší osvědčilo zařazení jejich repozitáře pro openSUSE balíky do seznamu repozitářů balíčkovacího systému. Ten systém mě automaticky upozorní, pokud se objeví nová verze a je na mě, jestli ji nainstaluji nebo ne. Instalační soubory jsou tahány ze serverů, které nemají s openSUSE vůbec nic společného. Takže ty právní tahanice, o kterých píšete, jsou v tomhle případě zcela irelevantní.
Vývojáři poskytují 3 varianty balíků: (1) základní, neměnná verze, (2) balík s opravenými chybami, (3) vývojová verze. Takže odpadají spory, že někdo chce stabilní verzi, jiný chce vývojovou - každý si může vybrat podle svého gusta.
Co je ale nejdůležitější z bezpečnostního hlediska: Vlastní instalaci provádí balíčkovací systém, který prošel bezpečnostním auditem. Nikoliv nějaká aplikace třetí strany, která kvůli instalaci na víceuživatelském systému musí běžet s právy administrátora! Absolutně bezpečná metoda instalace SW neexistuje. Počítačová bezpečnost je o velkém množství malých opatření, které ji zvyšují. A balíčkovací systém je jedním z nich.
Proč se balíčkovací systémy tolik nevyužívají v praxi, když mají tolik výhod? Protože se vývojáři musí ty systémy naučit používat. A to zabírá čas. Vývojáři odkojení Windows si stěží sami začnou studovat, jak připravovat .rpm nebo .deb balíky. Prostě tu svojí aplikaci udělají tak, jak jsou zvyklí z Windows. Všechny ty právní, praktické ... důvody, které uvádíte, jsou vycucané z prstu. Jen aby bylo čím Linux pošpinit, že?
-
Lael Ophir (neregistrovaný)
R je open source šířený pod licencí GPL, takže bych ho nepovažoval za dobrý příklad. Nicméně podobně můžete postupovat i ve Windows. Stačí když si aplikace ověří dostupnost patchů, a nechá je nainstalovat přes Windows Installer nebo (na něm postavený) InstallShield. Ty právní tahanice by nastaly v případě, kdyby byl SW šířený přes repozitář distra.
Ve Windows provádí instalaci Windows Installer. Samozřejmě když se Oracle nebo Adobe rozhodne provádět instalaci jiným způsobem, na otevřené platformě jim v tom nikdo nemůže bránit. Nakonec instalátor Oracle pro Linux je psaný v Javě, a s balíčkovacím systémem distra nemá nic společného. Jak v tom Oraclu zabráníte? Asi nijak.
Samozřejmě pro autora aplikace není nic jednoduššího než vytvořit pár balíčků: Debian deb, Slax LZM, PiSi, Pacman, PUP/PET, RPM, SuperDeb, a samozřejmě tarball. A samozřejmě v některých případech (deb a rpm) pro různá distra. A samozřejmě pro různé verze těch dister. Proč oni to nedělají? ;)
-
pwo (neregistrovaný)
R-project je ukázkový příklad přístupu "Když se chce, tak to jde". Komerční firmy by se od toho projektu mohly učit.
Uzavřené binární drivery distribuuje přes vlastní repozitáře třeba NVIDIA. Za jejich stažení se neplatí. Příkladem repozitářů, kde se za možnost stahování platí, jsou třeba repozitáře SLESu nebo SLEDu. Tyhle repozitáře jsou přístupné jen po zakoupení servisní podpory (zákazník dostane aktivační klíč, jehož platnost je časově omezená).
Oracle má vlastní distribuci Linuxu (Oracle Linux). Nemá proto žádný zájem na tom, aby instalaci vlastního software na jiných distribucích zjednodušil.
Je jasné, že výrobci SW budou podporovat jen několik platforem. V době cloudů a virtualizace ale není velký problém automaticky generovat software pro několik distribucí z jednoho zdrojového kódu.
-
Lael Ophir (neregistrovaný)
To máte pravdu, 32- a 64-bitové verze vyžadují vlastní instalační balíček. Pokud ale verze pro WinXP neběží na Win7/8, tak asi autor něco doprasil, a chce to patch.
"distribuce [se] dynamicky vyvíjí a není možné zachovat binární kompatibilitu" - fakt nelze? Já myslím že binární kompatibilitu lze udržet. Jenže autoři linuxového kernelu ABI nechtějí, a distra se vyvíjejí poněkud chaoticky. To pak potřebujete ke každé aplikaci hromady balíčků, build servery a podobné nesmysly. Generovat balíčky pro více distribucí není zadarmo, minimálně z hlediska úsilí.Netvrdím že aktualizace musí probíhat přes centrální kanál. Tvrdím že *když* tak probíhá, tak přináší to jisté problémy.
Fakt nevím jestli MS okopíroval store od Applu. MS totiž měl dlouhá léta Marketplace, a ani ten nebyl první na trhu. Apple to prostě jen udělal lépe.
-
pwo (neregistrovaný)
A zase ta demagogie! Spousta Linuxových distribucí má jednoúčelové zaměření. Jsou to třeba rescue systémy určené pro bootování z CD nebo USB, systémy pro firewally, live distribuce, ... Je nesmysl pro tyhle systémy R připravovat. Pak je zde spousta dister, kde si nějaký studentík změnil defaultní plochu třeba Ubuntu a vydal to jako vlastní distro. R na těchle systémech bude fungovat.
Cituji: "... build servery jsou nešikovným řešením zbytečného problému." Nesmysl. Linux podporuje spoustu HW architektur (IA, PowerPC, ARM, ...). V takovém prostředí není možné binární kompatibilitu zajistit. Build service nedělá nic jiného, než že automatizuje věci, které by se jinak musely dělat ručně.
Verze Windows pro Itanium, PowerPC, ... také existovaly. Kdyby je Microsoft nadále podporoval, tak by s s nějakým build serverem dřív nebo později také přišel.
-
Lael Ophir (neregistrovaný)
R bude asi fungovat na většině systémů, pokud nad tím strávíte dost času.
Binární kompatibilitu je možné zajistit i napříč platformami, vizte fat Binary například u Applu. Jenže Linux nemá binární kompatibilitu ani mezi distry na jedné platformě, nemluvě o dalších odlišnostech dister, případně různých prostředí (za všechny zmíním odlišnosti v registraci deamonů a položek ve Start Menu).
Na Windows není moc důvodů provozovat build server. Stačí projekt prostě přeložit pro danou cílovou platformu. Samozřejmě je ho před tím potřeba na každé platformě optimalizovat a testovat, ale to je jiný příběh.
-
pwo (neregistrovaný)
Cituji: "Jenže Linux nemá binární kompatibilitu ani mezi distry na jedné platformě ..." Ano, Linux binární kompatibilitu neměl, nemá a v dohledné době mít nebude. Tohle se ví a dokonce se i ví proč: protože spousta distribucí funguje jako test bed pro nové přístupy, a protože autoři distribucí se chtějí odlišit. Když dáte lidem svobodu, tak si dělají, co je baví. Ti vývojaři nechtějí, aby jim někdo mocný předepisoval, jak musí pracovat. Proč to pořád lidem prezentujete jako nevýhodu Linuxu?
Úplná anarchie ale v Linuxu není. Komerční (Red Hat, SUSE, ...) a některé nekomerční distribuce podporují LSB (Linux Standard Base, http://www.linuxfoundation.org/collaborate/workgroups/lsb). Programy využívající LSB jsou (v principu) přenositelné mezi verzemi a distribucemi. Informace pro vývojáře, jak takové aplikace psát, jsou na uvedeném webu. V praxi ale mnoho aplikací LSB nevyužívá, a tak je tam ještě co dohánět.
-
Lael Ophir (neregistrovaný)
Ano, je pravda, že Mandriva, OpenSuSE a podobná distra jsou test bed/beta verze pro komerční distra Red Hatu a Novellu. Nicméně binární kompatibilita je technicky možná i tam.
"[vývojáři] si dělají, co je baví. ...nechtějí" - ano, a to je velký problém. Komerční firmy dělají na tom, co zajímá jejich zákazníky, a co jsou ti zákazníci ochotni zaplatit. U Linuxu nějaký vývojář třetí strany nebo uživatel vlastně nikoho nezajímá. Přesně jak píšete: vývojáři Linuxu/dister si dělají co baví je, a ne to co je dobré pro vývojáře aplikací a uživatele. Bohužel co baví vývojáře, není nutně dobré pro uživatele. Výsledný stav je ten, že jde o nevýhodu Linuxu pro vývojáře aplikací i pro uživatele. Jestli to někoho baví, tak tyhle dvě skupiny zjevně ne. Nakonec proč myslíte, že je pro Linux minimum aplikací a má minimum uživatelů?
LSB je pěkná snaha, ale málo a pozdě. Málo proto, že LSB řadu oblastí vůbec neřeší. Pozdě proto, že podobný přístup měl přijít už při designu OS. Dnes je nejrozšířenějším distrem údajně Ubuntu, které v současných verzích není na seznamu certifikovaných dister. A na LSB 4.1 z února 2011 jsou k dnešku certifikovaná celá dvě distra, z toho jedno dokonce 64-bitové. Wow. Vašimi slovy: "je tam ještě co dohánět".
-
nickname (neregistrovaný)
Nevím o co se tu snažíte. LSB není žádný etalon ani meta, ke které tvůrci vetšiny linuxových distribucí míří. Možná by stálo vyndat si tu hlavu z p*ele nebo kde si ji schováváte ;)
LSB is an illusion. Something designed to get people to ask the wrong questions so nobody has to worry about the right answers. Simple sleight-of-hand to fool less knowledgeable people. Red Hat is first and foremost a business and the people working under that legal fiction are focused on business. That implies intensive marketing. Marketing, by nature in the modern world, involves deception and sleight-of-hand. People behind LSB are acting like peacocks to show the colors of their feathers during courtship.
If a primary criterion of enterprise usage is LSB, then Red Hat will always satisfy those requirements. Yet if one realizes that LSB is a proverbial red herring, then that criterion disappears like the dew on a hot sunny morning.
