Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 208. brněnský sraz, který proběhne v pátek 25. dubna od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1.
Ve svém článku Getting Forked by Microsoft popisuje autor programu Spegel svoji nepříjemnou zkušenost s firmou Microsoft. Firma ho kontaktovala a zpočátku to vypadalo, že by mohlo jít o oboustranně prospěšnou spolupráci, autor tedy ochotně odpovídal na jejich otázky ohledně architektury programu a pomáhal jim ho zprovoznit. Následně komunikace ze strany Microsoftu utichla. Autor předpokládal, že zřejmě došlo ke změně priorit a firma
… více »Společnost Notion Labs stojící za softwarovou platformou pro spolupráci Notion (Wikipedia) oficiálně představila (YouTube) poštovního klienta Notion Mail. Aktuálně funguje pouze nad Gmailem.
Byla vydána nová verze 9.12 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Ubuntu 25.10 bude (𝕏) Questing Quokka (pátrající klokan quokka).
Ubisoft uvolnil zdrojové kódy softwaru Chroma pro simulaci barvosleposti pro vývojáře počítačových her. K dispozici jsou na GitHubu pod licencí Apache 2.0.
Defold (Wikipedie) je multiplatformní herní engine. Nejnovější verze je 1.10.0. Zdrojové kódy jsou k dispozici na GitHubu. Licence vychází z licence Apache 2.0.
Správa služeb hlavního města Prahy se potýká s následky kyberútoku. Hackerská skupina začala zveřejňovat na internetu některé z ukradených materiálů a vyzvala organizaci k vyjednávání. Ta zatím podrobnosti k případu sdělovat nechce. Případem se zabývá policie i Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB).
OCCT je oficiálně k dispozici na Linuxu (YouTube). Jedná se o proprietární software pro zátěžové testování a monitorování hardwaru.
(server tldp.org doporučuji pozornosti)LDP se dá stáhnout celé (ty linkuješ pouze druhou kapitolu - správu systému, dobrá je i první - uživatelské prostředí) česky např. tady.
/
na oddíl šifrovaný AES v módu XTS, při debuggování se naučíš, jak vlastně systém bootuje atd. (můj případ).
+1. K tomu druhé PC pro otevřenou wiki při instalaci a bez problému zvládnutelná instalace systému. Tak nějak jsem začínal při přechodu z Ubuntu
K tomu jenom poznámka: při instalaci Arch Linuxu je dostupná z instalačního média official_installation_guide_en v adresáři /arch/docs. Pro základní instalaci tato příručka bohatě postačuje.
+1. Mě uchvátily svou jednoduchostí jenom dvě distribuce: Slackware a právě výše zmiňovaný Arch Linux. Přičemž jednoduchostí mám na mysli "odlehčenou základní strukturu bez zbytečných přídavků, změn, nebo komplikací, což dovoluje konkrétnímu uživateli změnit systém tak, jak sám potřebuje". Více viz The Arch Way.
Slackware … bez zbytečných přídavků
Když jsem se naposledy díval, tak takovými zbytečnými přídavky byly např. package management, PAM nebo ACL…
Dobrý nápad. Linux From Scratch člověka hodně naučí. Jenže aby tazatele neodradilo to, že LFS je prostě víc "hard-core".
Chápu, že dotazů na distra jsou tu tuny, ale ...Žádné ale. Položil jste dotaz na distribuci a odpovědí je rozdělení odpovídající preferencím místních uživatelů. Jinými slovy, pod kapotu se můžete podívat každému distru a pravděpodobně tam najdete velmi podobné věci.
Rozdíl je ale v tom jestli se může podívat nebo musí.
Pro jeho případ bych radši zvolil něco kde se musí podívat, tedy arch nebo gentoo.
Pro jeho případ bych radši zvolil něco kde se musí podívat, tedy arch nebo gentoo.Ne, to není pravda. Ani arch ani gentoo nemá nic nezbytně nutného.
Nevím jestli jste mě pochopil, protože já vás nechápu, každopádně jsem to myslel tak, že například v archu nebo gentoo se toho naučí víc než v ubuntu, protože bude muset - je to součástí toho systému a vyhnout se tomu nemůže.
A čtete vůbec co píšu?
arsik:~#Řekl bych, že tady asi bude nutné přečíst si minimálně něco o správě balíčků…
arch nebo gentoo
Přidal bych ještě Slackware.
Ono je taky důležité, jak moc je těžké tu "podkapotu" pochopit. Více viz The Arch Way.
www.pclinuxos.cz
Jestli ti ale jde o pochopeni a chces hodne dokumentace tak jedine Debian
Ono je to prakticky jedno.
Pro zacatek si zvolte treba Ubuntu. Shell je vsude stejny, terminal ma kazdy graficky rozhrani. Na grafickem rozhrani nikterak nezalezi - je to jen veci zvyku, vkusu libi vs nelibi ...
Mozna budete chtit provadet nejake "psi kusy" tak zde se hodi live distribuce - pokud neco zmastite tak jen reboot a muzete znovu.
Zacinat s distribuci jez se konfiguruje ciste jen editaci textovych souboru je pro zacatek mozna moc hardcore ac se teda samozrejme timto naucite nejvic.
Já zase tvrdím, že pokud nebude všechno tupě opisovat z wiki … prostě bude muset tohle podstoupit. U klikacích distribucí ta motivace není taková.
Tady je vidět, jak si sám sobě odporujete. Začnete formulací "pokud nebude všechno tupě opisovat z wiki", ale pak najednou z nějakého záhadného důvodu usoudíte, že to vlastně nejde a že se v každém případě bude muset naučit, jak systém pracuje. Ve skutečnosti jste ale právě v té první větě uhodil hřebíček na hlavičku: buď má uživatel zájem systému porozumět a věnuje tomu svůj čas a úsilí, a pak je jedno, jestli používá "klikací" distribuci (což je sám o sobě nesmyslný pojem) nebo "hardcore". Nebo ten zájem nemá, a pak je opět jedno, jestli "kliká" nebo "tupě opisuje z wiki" (váš vlastní výraz); rozdíl bude jen v tom, jestli si pocvičí práci s myší nebo s klávesnicí. :-) Prostě je to o člověku a jeho přístupu, ne o distribuci.
tak to přeháníte..já k Archu přesedlal asi po měsíci či dvou na ubuntu tedy jako laik (ubuntu mě tehdá skutečně nic moc nedalo)..ale mám kladný vztah k IT, programování, hw, elektru, prostě mě to baví..instalace základu byla na pár dní ale naučit se to všecko dá docela rychle..další reinstal je pak otázkou odpoledne..cups mi dal kdysi taky zabrat ale to bylo před rokem..teď když jsem onehdá instaloval na novo tak i cups s brother laser tiskarnou byla otázka asi 10min..s xorgem jsem před rokem taky válčil, ale teď za rok je Arch zase někde jinde (respektive xorg apod), člověk nemusí řešit oprávnění na mount přes HAL, xorg nepotřebuje konfigurák atd. atd. Prostě nevidím na Archu nic tak složitého..Problémy jsou všude ať je to debian testing, či Arch či něco jiného
já měl před rokem s intel grafikou přesně opačný problém..v ubuntu katastrofa a v archu jela pěkně pokud se bavíme o firemním pracovním stroji co mě bude živit, tak to potom máte pravdu..Arch je dobrý pro nadšence na domácí PC či studenty jako já a jejich NB
když už jsme u toho pulseaudia tak přepínám 3 zvukovky..měl jsem pulse i alsu a teď jsem zase u alsy..pulseaudio je vážně moc fajn věc co se týče toho přepínání, ale nepřišel jsem u pulseaudia na jednoduchý způsob ovládání hlasitosti v openboxu..jediné provázané prostředí je gnome při užití upraveného gnome-media (multimedia klavesy a aplety)
to bohužel nefunguje tak krásně jak bych si představoval..respektive když připojím kartu, pulse přepne na ni, ale aplet nepřepne ovládání hlasitosti na danou kartu..mám pocit že tohle mi v gnome chodilo, ikdyž jsem teď teda nahodil gnome-volume-control-applet-pulse a nechodi to .ještě by se mi pak líbilo kdyby pulse dovolovalo zvolit pro každou kartu resampling na jinou hodnotu, ale asi jsem tu hodně OT
což přesně dělá pulseaudioZa cenu vykašlání se na jakýkoliv zvukový hardware který jsem si koupil?
A osobně neznám ve svém okolí nikoho, kdo by pořádně ovládal tyto nové technologie (řada lidí je nazve ptákovinami, proč ne, nepotřebují je).To ale není tím, že by se to lidi odmítli učit z vlastní pohodlnosti nebo že by to bylo příliš nové nebo tak něco. Naopak lidi co tomu rozumí se učí rádi a mají poměrně vysokou asimilační schopnost. Pravý důvod je ten, že všechny ty HALy, *kity, atp. prostě jsou ptákoviny. Tj. software pro software, výplod chorého mozku, trpícími snad všemy neduhy, které může software mít, počínaje nulovou dokumentací, nulovou orientací na use-case, přes absolutně šílené rozhraní ke konfiguraci nebo API a konče obtěžováním uživatele svými chybami a pojistkou stylu "vždycky to jde vypnout".
Proto oceňuji, že si někdo z týmu ubuntu dal tu práci to nastudovat a nastavit. Samozřejmě je to pak pekelně složité, nepřehledné, spoustu vrstev na sobě.Viděl bych to tak, že jim asi nic jiného nezbylo. A když se podíváte pořádně, tak ti distro lidé si už dnes hledají způsoby jak to obejít.
Pro pochopení UNIXu? OpenSolaris.
Trváte-li na Linuxu, já nejraději používám (a doporučuji) ArchLinux. Není to klikací distribuce a pro pochopení principuů se hodí znamenitě.
Všechny superlativy, které si vymyslíš, Debian splňuje. Nemůžeš udělat chybu.
Tak takovou ptákovinu jsem ještě nežral. Tady je seznam hlavních superlativů Debianu:
Fosilní a stokrát amatérsky patchované balíčky nejsou kec, ale každodenní realita všech distribucí typu Debian.
Ve snaze o pochopení základních principů Debian zásadně překáží, protože je porušuje. Jeden ze základních principů: Buď centrální správa software, nebo rolling updates. (To první funguje například u OpenSolarisu, to druhé například u ArchLinuxu.) Princip Debianu: Zkombinovat nevýhody obou přístupů.
Přístup shut up, be happy odpovídá spíš Microsoftu. Uživatel Linuxu má naštěstí vždy možnost volby.
# Fosilní, často víc než rok starý software, patchovaný amatérskými správci k nepoznání.O větvi unstable jsi někdy slyšel?
# Tu a tam, když to někdo s patchováním přežene nebo je na drogách, pouze 32768 šifrovacích klíčů.Něco podobného lze napsat o libovolné distribuci, namátkou třeba o Archu.
# Trochu ošklivé, trochu nelogické, trochu zastaralé — nemůžeš udělat chybu.Tam popsané věci týkající se apt-get už neplatí, alespoň pět let je i ve stable aptitude.
Bezpečnostní update má dělat ten, kdo danému software perfektně rozumí, tedy autor. Snaha o nějaký backport, který provádí správce balíčku — amatér, který danému projektu nerozumí, práci dělá ve volném čase a balíčků má na starost několik — spěje pomalu ale jistě k pořádnému karambolu.
Chyby v software se objevují neustále. Řešením je okamžitý přechod na novější verzi, která chybu opravuje.
Chyby v software se objevují neustále. Řešením je okamžitý přechod na novější verzi, která chybu opravuje.
Zkuste o tom povyprávět nějakému systémákovi z větší firmy, nejlépe takovému, který má na starosti mission critical servery. Opravdu si myslíte, že ty firmy utrácejí za enterprise distribuce se sedmiletou podporou a backporty jen proto, že nevědí, co s penězi?
Kdybyste se podíval o pár příspěvků výše, zjistil byste, že centrální správu software (což asi budou ty enterprise distribuce, ať už to divné slovo znamená cokoliv) považuji za jedno ze dvou schůdných řešení a v zásadě nic proti nim nenamítám.
U nějakého OpenSolarisu mi nevadí, že tam je rok starý software. Protože mám jistotu, že o základní sadu balíčků se stará někdo, kdo rozumí tomu, co dělá, a kdo tu práci dělá full-time.
Debian je past. Tváří se jako enterprise řešení a přitom je to snůška amatérských a neprověřených backportů. Hodí se podle vás něco takového na nějaké mission-critical (ať už to znamená cokoliv...) nasazení? Já si myslím, že ne. A o tomhle ta diskuse původně byla. Nikde jsem nepsal nic proti distribucím s placenou podporou, jako je RHEL nebo SUSE.
Hodí se podle vás něco takového na nějaké mission-critical (ať už to znamená cokoliv...) nasazení?
Některé firmy si to myslí. Nevím, zda je Seznam dobrý příklad, ale třeba tam Debian běží.
Tak tady si neodpustím vtipnou historku. Na jednom jejich stroji měl běžet nějaký můj kód. (Jak se tam dostal, to je složitá historie, takže půjdu přímo k věci.) No, zkrátka neběžel, protože místní C knihovna netušila, co znamená konstanta AF_INET6
, jak vypadá struct sockaddr_in6
, nemluvě o flagu AI_V4MAPPED
.
No, ještě před pěti lety bych to chápal. Jenže tohle se stalo letos. Jasně, na anti-IPv6 fanatismus má každý právo. S tím se nedá nic dělat. Ale aby byl systém nastavený tak, že naschvál nepodporuje „dual-stack“ „future-proof“ binárky... Přitom byl ten program už dobrých pár měsíců běžně používaný na IPv4 i IPv6, takže nikoho nenapadlo, že by to celé mohlo na takové prkotině ztroskotat. Nakonec nezbylo než ten program zmrzačit a zkompilovat IPv4-only verzi.
Zpět k věci: Jasně, Debian na Seznamu běží, ale takhle velká firma de facto sama sobě zajišťuje profesionální komerčí podporu. Sehnat tam větší farmu (i s traktorem) na rychlé překompilování celého distra by asi nebyl větší problém. Stručně řečeno, IT firmy se většinou o své počítače postarají samy.
Kde jsem psal, že je nějaký patch neveřejný? Kdyby tomu tak bylo v nějaké linuxové distribuci, šlo by pravděpodobně o porušení GPL.
Pokud jde o OpenSolaris, tam sice CDDL neukládá Oracle povinnost zveřejňovat své patche, nicméně faktem je, že naprostá a drtivá většina kódu je veřejná.
Ani slovem jsem netvrdil, že closed-source software je bezpečnější než open-source. A ani náhodou si to nemyslím.
Pravda, idea backportu jako taková se mi vskutku moc nezamlouvá. Nicméně je velký rozdíl mezi backportem, který dělá full-time odborník za účelem minimalizace počtu změn, které musí provést správci systémů, a backportem typu Debian „stable“, který je provádědný amatéry a navíc v podstatě samoúčelný, protože Debian není centrálně spravovaná distribuce komerčního typu. (Někdy se tak tváří, ale prostě není.)
Tu a tam, když to někdo s patchováním přežene nebo je na drogách, pouze 32768 šifrovacích klíčů.Něco podobného lze napsat o libovolné distribuci, namátkou třeba o Archu.
V Archu nikdy nebylo 32768 klíčů. Tudíž se o něm nedá napsat nic podobného.
Před opravou OpenSSL nebo po ní?
Já si myslím, že nějaká „bezpečnost distribuce“ neexistuje ani u Archu, ani u Debianu. Ani jedna z těch distribucí není monolitický celek. Jsou to spousty balíčků a každý je na tom s bezpečností jinak.
Zabezpečení systému jako celku lze srovnávat jen u centrálně spravovaných řešení — OpenSolaris, RHEL, SUSE, Windows, AIX... U komunitních distribucí to prostě funguje jinak. Tam každý kus software existuje zvlášť a sám za sebe. (A čím méně ho ta distribuce mění, tím lépe.)
Rozhodně netvrdím, že komunitní distribuce jsou v nějakém smyslu rizikovější než centrálně spravované. (Dokonce si to ani nemyslím.) Jen tvrdím, že „bezpečnost Debianu“ nebo „bezpečnost Archu“ je oxymoron.
Jen tvrdím, že „bezpečnost Debianu“ nebo „bezpečnost Archu“ je oxymoron.V Debianu lze celkem jednoduše rozchodit SE-Linux; v Arch ne.
Jasně, Podpora pro SELinux v Archu není nic extra, protože její existence závisí na balíčcích z AUR. Tohle ale nijak nesouvisí s nějakou „bezpečnostní koncepcí“ té či oné distribuce. Jde prostě o to, že Debian má mnohem víc uživatelů a tudíž poskytuje (celkem logicky) v některých oblastech mnohem širší možnosti.
Jestli ono těch lidí z Debianu nebude nesrovnatelně víc než lidí z Archu... Jinak je to samozřejmě pravda — žádná obdoba security teamu v Archu není.
Dodavatel software ví ze všech nejlépe, jak je to s bezpečností, a zpravidla je schopen poskytnout nesrovnatelně rychlejší dobu odezvy než nějaký security team. Při vzniku chyby je to v Debianu asi takto:
V Archu je to asi tak:
Dodavatel software ví ze všech nejlépe, jak je to s bezpečností
Jak kdy… Jestli je to pravda, kde se berou ta hlášení o bezpečnostních dírách a exploity? :-)
Jinak ten váš scénář sice vypadá přesvědčivě, ale některé otázky nechává nejen nezodpovězené, ale i nevyřčené:
Tohle nejsou žádné hypotetické konstrukce, to všechno se běžně stává.
Nejedno hlášení se tak nějak vzalo přímo od maintainerů Debianu, zejména to nejznámější výše odkazované.
Když se autor balíčku nemá k tomu, aby balíček udržoval, nejspíš někomu brzy dojde trpělivost a začne pracovat na forku. A pokud k forku nedojde, většinou už je k dispozici alternativa a původní projekt umře.
U druhé otázky si myslím, že odpověď není jednoznačná a liší se balíček od balíčku. Nicméně u technicky náročných projektů (kompilátor, kryptografie) podle mého názoru backportování prostě nemůže vyhrát.
S vaší třetí poznámkou zcela souhlasím. Samozřejmě je těžko myslitelné, aby správce (který má těch serverů na starosti třeba desítky) musel po bezpečností aktualizaci překopat stovky řádků konfiguračích souborů. Proto existují centrálně spravované distribuce. (Mezi ně ovšem Debian (přísna vzato) nepatří.)
1. Tu poznámku jsem myslel hlavně jako rýpnutí do formulace, že autor rozumí bezpečnosti svého projektu vždy nejlépe (nebo jak to bylo). Kdyby to totiž mělo platit doslova, nebylo by možné, aby bezpečnostní díru objevil jako první někdo jiný než autor, ať už dotyčný kope za světlou nebo temnou stranu Síly.
2. Nemyslel jsem to až tak dramaticky, že by autor balíček vůbec neudržoval. Spíš jsem měl na mysli situaci, kdy kritickou bezpečnostní chybu (např. kategorie vzdálený root při jakékoli nebo jakékoli funkční konfiguraci + známý nebo snadno napsatelný exploit) opraví třeba až za týden nebo dva. Pak bych si dokázal představit, že u Red Hatu a SuSE nebudou čekat, až se autor vrátí z líbánek nebo z nemocnice, ale opraví to sami a Debian od nich patch převezme.
Nikdo jiný tohle udělat nemůžeBlbost. U hodně hlášení chyb je k dispozici i opravný patch od "objevitele". U dalších není situace tak komplikovaná aby bylo potřeba zásah shůry. Dokonce si dovolím tvrdit, že software, do kterého umí bezchybnatě hrabat pouze pan autor patří na smetiště dějin.
Místo aby prostě použil novou verzi, snaží se provedené změny backportovat do stávající verze.Obvykle jen vezmou patch nebo commit z SCM a přeloží balík. Opravy tohoto druhu nejsou nějak sáhodlouhé.
Počká se, až dodavatel software tu chybu odstraní.Což může trvat libovolně dlouho. Ne každý dodavatel se obtěžuje s novým release při každém bugu, i když jde o bezpečnost. Například ani kernel se tak nevydává.
Ihned po vydání opravy je dostupná nejnovější aktualizace balíčku.Ne. Ještě se to žene přes testing.
Software, který je komplikovaný z pohledu teoretické informatiky (OpenSSL), rozhodně nepatří na smetiště dějin. A přesto je na této planetě relativně málo lidí (desítky? stovky?), kteří do něj dovedou hrabat tak, aby z toho nevypadl naprostý průser.
Patch od „objevitele“ musí vždy nakonec zkontrolovat a schválit autor. Vzpomínám si na slavné „objevitele“ z projektu ZEN patchset, kteří si mysleli, že dovedou opravit Reiser4 tak, aby se zkompiloval s novou verzí kernelu. Výsledkem byla (v mém případě) ztráta dat. (Oddíl se sice podařilo obnovit, ale počet ztracených souborů byl poněkud zdrcující.) A pak přišel Phoronix, který s tímto zničeným patchem dělal benchmark! Děsivá to historka...
Myslím, že dobře zdokumentovaný a dobře strukturovaný software je o tom, že ho běžný programátor dovede (s vynaložením dostatečného času a úsilí) nastudovat a pochopit. Nicméně správce balíčku nemusí být dobrý programátor, nemusí mít dostatek času a jeho úsilí může být roztříštěno do velké spousty činností a mezi spoustu balíčků.
To s tím testingem je pravda. Ale vsadil bych se, že Debian má obdobný „schvalovací“ mechanismus. Tedy jsem ani jedné „straně“ v celkovém součtu nekřivdil.
Software, který je komplikovaný z pohledu teoretické informatiky (OpenSSL), rozhodně nepatří na smetiště dějin. A přesto je na této planetě relativně málo lidí (desítky? stovky?), kteří do něj dovedou hrabat tak, aby z toho nevypadl naprostý průser.OpenSSL není komplikované teorií ale praxí. Většina útoků na krypto je proti konkrétní implementaci SW nebo HW. A většinu z nich objeví někdo jiný než autoři.
Patch od „objevitele“ musí vždy nakonec zkontrolovat a schválit autor. Vzpomínám si na slavné „objevitele“ z projektu ZEN patchset, kteří si mysleli, že dovedou opravit Reiser4 tak, aby se zkompiloval s novou verzí kernelu. Výsledkem byla (v mém případě) ztráta dat.Jak nepříjemné. V kontrastu s tím autor pravděpodobně sežral šalamounovo hovno a takový přehmat se mu stává maximálně třikrát za deset let.
Myslím, že dobře zdokumentovaný a dobře strukturovaný software je o tom, že ho běžný programátor dovede (s vynaložením dostatečného času a úsilí) nastudovat a pochopit. Nicméně správce balíčku nemusí být dobrý programátor, nemusí mít dostatek času a jeho úsilí může být roztříštěno do velké spousty činností a mezi spoustu balíčků.Dobrý software je opatřen jasně danými pravidly jak má fungovat a automatickými testy, které chrání již funkční části před neúmyslným rozbitím. Dobrý software nemusí být do detailů pochopen aby v něm byla provedena oprava a ani nemusí být člověk polobůh aby byl schopen takové akce.
To s tím testingem je pravda. Ale vsadil bych se, že Debian má obdobný „schvalovací“ mechanismus.Schválení ano, ale s velkým rozdílem. Debian security team testuje pouze tu malou změnu kterou sami zavedli namísto testování celého nového release. A navíc testují aktivně s cílem minimalizace času (odezva je obvykle týž den) a né stylem "dáme to na pár týdnů na testing a když se nikdo neozve tak asi dobrý".
V kontrastu s tím autor pravděpodobně sežral šalamounovo hovno a takový přehmat se mu stává maximálně třikrát za deset let.
To nevím. Zatím se mu nestal.
Je mi pět.
Ale jsou i jiné důvody, proč to fakt nevím. Hans Reiser je někdy od roku 2006 zavřený. A jsem příliš líný zjišťovat, od kterého roku přesně pracoval Edward Shishkin u firmy Namesys. Kromě toho, projekt Reiser4 podle mě ještě nemá deset let.
Tiskni
Sdílej: