Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Většina chybového chování, na které narazím ve F/OSS programech, se týká Openoffice, Gnome nebo Ubuntu. A tyto projekty mají jedno společné: chyby, které najdu buď nahlásil někdo už léta přede mnou, nebo tam po mém nahlášení hnijí další týdny, měsíce a roky, aniž by se je někdo snažil řešit, nebo je označil jako won't fix. Jediné, co z toho vybočuje, jsou chyby v kernelu, ty se řeší v případě klasických bugů promptně, v případě nedostatků v návrhu sice řádově pomaleji, ale i tak docela aktivně.
Tak mě napadá, jestli se OOo, Gnome a Ubuntu už dávno nepohybují nad "kritickým" počem reportujích uživatelů na (aktivního) vývojáře, a tedy jestli jsou dotyčné projekty vůbec schopné dělat něco nad rámec nového vývoje a oprav kritických bezpečnostních chyb...
Tiskni
Sdílej:
3.5.2009 00:48
Fluttershy, yay! | skóre: 93
| blog:
3.5.2009 00:53
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
2) Periodicky prudit. Měsíc co měsíc, u zvlášť hnusných bugů týden co týden, psát komentáře jako "Any news?", "Ping", "Can I help?" (znám i lidi, co píšou "Meow" a jiné, divnější věci). Ono to vývojářům furt posílá maily
3) Zkontroluj, jestli je bug někomu přiřazen a jestli to není něco jako devnull@gnome.org nebo tak. Bug, který nemá žádného vlastníka nebo jeho vlastník neexistuje, se přehlédne mnohem snáz. Nejlépe je, pokud sám znáš člověka, který by měl bug řešit - můžeš ho kontaktovat osobně.
4) Přidávat do CC různé lidi, kteří na bug také narazili, nebo mají jiný zájem na jeho odstranění.
5) Pokud bugzilla umožňuje hlasování, hlasovat pro bug jako zvlášť otravný.
Samozřejmě, nic z toho, bohužel, není samospasitelné 
taky mám pár bugů (ale žádný v OOo, ani v GNOME), které považuju za zásadní a vývojáři se rafinovaně vyhýbají jejich řešení. To je prostě život, nenech se tím znechutit.
1) Úplně nejlepší je najít ten bug sám, eventuálně napsat patch a přidat ho k tomu bugu.Malokdy pomuze.
2) Periodicky prudit. Měsíc co měsíc, u zvlášť hnusných bugů týden co týden, psát komentáře jako "Any news?", "Ping", "Can I help?" (znám i lidi, co píšou "Meow" a jiné, divnější věci). Ono to vývojářům furt posílá mailyDobry zpusob jak rychle dostat ban.
3) Zkontroluj, jestli je bug někomu přiřazen a jestli to není něco jako devnull@gnome.org nebo tak. Bug, který nemá žádného vlastníka nebo jeho vlastník neexistuje, se přehlédne mnohem snáz. Nejlépe je, pokud sám znáš člověka, který by měl bug řešit - můžeš ho kontaktovat osobně.Pomerne nerealne u vetsich nez miniaturnich projektu. Docela velkym problemem jsou bugy prirazene nekomu kdo proste Bugzillu nepouziva a na emaily neodpovida. Uzivatele nemaji sanci nejak zmenit prirazeni bugu a bug nikdy nebude opraven.
5) Pokud bugzilla umožňuje hlasování, hlasovat pro bug jako zvlášť otravný.Totalne a naprosto zbytecne.
4.5.2009 09:45
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
4.5.2009 08:04
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Samozřejmě, nic z toho, bohužel, není samospasitelné taky mám pár bugů (ale žádný v OOo, ani v GNOME), které považuju za zásadní a vývojáři se rafinovaně vyhýbají jejich řešení.Jiste, ze se reseni vyhybaji. Pro ne bug zavazny neni a jeho nevyresenim ztrati mozna tebe, jako uzivatele, ale ne tebe jako platiciho zakaznika...
3.5.2009 02:18
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Celé to naráží na nedostatek lidí tomu se věnující.
Sice nemám přehled, co se děje uvnitř těchto projektů a ani to vědět nechci, ale počet vývojářů je omezený.
Navíc každý velký projekt naráží na špatně zvolenou architekturu, na řadu prasečin uvnitř (tomu se nevyhnete, odhad architektury chce křišťálovou kouli, pokud máte odhadovat mnoho let dopředu, jaké asi projekty budou, a to vůbec nemluvím o tom, že řadu OSS programů, či částí navrhují nekompetentní, nebo nezkušení lidé – zejména lidé typu hlavně sedni a piš a něco dělej, což je pro architekturu budoucího velkého projektu naprostá katastrofa).
Řada špatně odhadnuté vnitřní architektury, či prasečin uvnitř pak způsobuje, že některé bugy, které se u mladého, či dobře odhadnutého projektu velmi svižně, rychle a hezky opravují mohou u velkého projektu být těžko opravitelné. To, co u mladého projektu, nebo dobře navrhnutého opravíte za 10 minut, může u velkého, starého, nebo špatně architektonicky navrženého projektu být řehole na týdny s následným nutným testováním a zjišťováním, zda oprava bugu nepodělala něco někde jinde.
Pokud si někdo myslíte, že práce na velkém projektu je zajímavá, či nějak inspirující, je tomu přesně naopak. Práce na velkých projektech je ta nejnudnější, nejbyrokratičtější a nejzoufalejší práce, která v programátořině existuje.
Jediné, co je jisté je, že bude ještě mnohem hůře. Programátoři jsou čím dál méně kvalitnější, čím dál více se povznášejí nad teorii (názory typu je zbytečné se něco učit, či studovat vysokou školu, vše potřebné se naučím v praxi bude mít na kvalitu dalších sw projektů velmi zdrcující vliv).
Je to zlé, ale není to až tak zlé.
Všechny sw projekty, nejen ty OSS mají určitou životnost - a pak chtějí z gruntu přepsat - říká se, že ideální jsou tři verze :). Osobně vím o jednom velkém uzavřeném projektu, kde se o kompletním přepsání mluví už devět let. Jinak je jasné, že čím je projekt starší a má víc uživatelů, tak jaké koliv zásahy jsou určité riziko. Navíc, málo kdo udrží v hlavě přehled o kódu opravdu velkých aplikací (nad sto tisíc řádků). Tudíž větší změny se musí důkladně testovat a navíc uživatelé zpravidla jsou velice hákliví na jakoukoliv nekompatibilitu.
Jako jeden z programátorů PostgreSQL můži říci, že prace na takhle velkém projektu je opravdu někdy flustrující - hlavně se člověk musí obrnit opravdu velkou trpělivostí - pokud chcete některou funkci v core, tak to znamená půl roční, roční pedantskou práci, a pak další půl rok čekání, vysvětlování, lobování. Stále je to ale zajímavá práce - kdo v běžné praxi navrhuje implementaci SQL příkazů :).
Zavedený OSS projekt těží z globalizace - po světě se ještě najde pár dobrých programátorů. Problémy s rádoby programátory se spíš dotkne uzavřeného sw. Firmy musí vybírat z toho, co mají v okolí - což, uznávám, může být docela problém. Bohužel - velké komerční IT firmy preferují kodéry - přeloženo laciné cvičené opice - a pak programátorů s nadhledem a rozhledem zákonitě ubývá.
Velké firmy zase mají na velkých projektech zkušené analytiky, kteří navrhnout architekturu, navrhnou technologie, styl programování – a pokud se tohle dobře trefí, pak už toho programátor moc nezkazí, a pokud ano, škoda je minimální.
Není třeba držet v hlavě přehled o kódu, to u dobře navrženého projektu s dobrou architekturou není vůbec třeba. Ale zase: kolik projektů má dobrou architekturu?
Jenom aby nedošlo k mýlce, já to nevysvětluji jako kritiku, ale jen, aby si lidé uvědomili skutečný stav.
Problém se zkušenými programátory se IMHO spíše dotkne OSS. Proč? Zkuste být zkušeným programátor a protlačit svůj kód řekněme do kernelu, nebo do toho Vašeho PostgreSQL? Je a bude čím dál těžší se tam dostat, a něco prosadit – často to bude znamenat mnoho měsíců i rok práce jen na přesvědčování druhých. A bude to jenom horší. Takže se do těchto projektů budou spíše dostávat ambiciózní, nebo mladí lidé bez zkušeností – a zkušení programátoři (kteří už nejsou etablovaní v projektu) se na to spíše vykašlou a najdou si zajímavější projekt, kde mohou dělat co je baví a ne přesvědčovat a lámat byrokratické ledy.
Obávám se, že ohledně zkušených analytiků je ještě větší nouze nez zkušených programátorů. Těch dobrých je fakt málo. Navíc opravdu důsledná analýza ve výsledku znamená neskutečně byrokratický projekt a po pravdě řečeno, nezaručuje úspěšný projekt. Platí to, co jste napsal - pokud se to dobře trefí. A já jsem docela velký pesimista - ještě jsem nezažil projekt, kde by se to 100% trefilo na první pokus.
Řekně te mi, kolik je zajímavých ne OSS projektů v ČR? Pokud člověk chce dělat zajímavou práci, tak mu více-méně nezbude dělat než OSS, který je globální nebo se odstěhovat mimo republiku. Programování na úrovni Linux kernelu nebo PostgreSQL se v ČR dělá možná v pěti-šesti firmách.
A ohledně byrokratických ledů - obávám se, že kromě startup firem se dnes ve všech etablovaných firmách přechází na projektové řízení. Kdo zažil na vlastní kůži, tak se mnou souhlasí, že té byrokracie je mnohonásobně více než v OSS projektech. OSS má jednu výhodu - nejsou tam lidé, kteří předstírají práci.
Těch dobrých analytiků je fakt málo, a většinou se o nich neví – protože obrovská řada lidí jejich roli velmi podceňuje. A to přesto, že oni mohou způsobit, že projekt na stejný výsledek potřebuje třeba setinu času a nákladů a výsledkem je jako bonus lepší projekt, spolehlivější a užitečnější.
Analýza je neskutečně byrokratická věc u většího projektu, s tím souhlasím. Já jsem zažil dost projektů, kde se to trefilo na první pokus a funguje to i přes deset let.. Mimochodem, některé analýzy mám sám na svědomí. Ale okamžitě jsem odcházel tam, kde jsem viděl, že počet řádků kódu a počet hodin prosezených programátory je hlavní měřítko, kdo se jak zasloužil o projekt. A to je bohužel nejvíce u OSS projektů – tam se to stává nejvíce.
O dobrých projektech s dobře trefenými analýzami nevíte, protože zkrátka jedou neproblematicky, nejsou kolem nich žádné skandály, nic zajímavého, o čem je potřeba mluvit, psát, nadávat, či stěžovat si – zkrátka nuda, takže se zdá, že nejsou. Ale je jich dost.
Programování kernelu je věc, kterou bych označil za typický příklad špatně vedeného projektu. Proč? Srovnejte si jenom náklady / výsledek. Počet člověkoroků práce / výsledný efekt – bude to hodně těžko obhajitelné číslo. A porovnejte totéž číslo třeba u BSD systému. Celkem se nedivím, že BSD měl obrovskou spoustu let třeba lepší síťování a je otázka, zda nemá dodnes.
S tou byrokracií ve všech etablovaných firmách naprosto souhlasím. Pokud se zavede opravdu skutečné komplexní projektové řízení se vším všudy podle nějaké metodiky, je to papírování až nad hlavu. S čím ovšem nemohu souhlasit je to, že v OSS nejsou lidé, co předstírají práci.
Já si myslím, že u tak velkého projektu jako je Linux kernel se nedají používat komerční měřítka - při tak velkém rozsahu se musí určitá neefektivita akceptovat - jinak by Linux musel přejít opravdu na klasické projektové řízení, a to by byl asi jeho konec. Na rootu teď v jedné diskuzi padl celkem zajímavý argument - OSS sw nyní jako jediný v určitých oblastech dokáže konkurovat velkým firmám - ať už je to Linux, jako jeden z mála životaschopných systémů nebo gcc. Ostatní nedokázali držet krok a odpadli. BSD není nejlepší příklad - pokud si vzpomínám, tak BSD vývojářů je řádově méně a BSD je mnohem konzervativnější. Viz např. česká 602.
Možná v OSS budou lidé předstírající činnost - co by z toho ovšem měli? Tam se to prostě nevyplatí. V OSS, když vás přestane bavit práce, tak se rozloučíte a popřejete si vzájemně štěstí. Samozřejmě nejsou tam jenom vývojáři (přiznám se, že je tam minimum analytiků - ale to je dáno tím, že většina vývojářů jsou programátoři (za komunistů se používal termín programátor/analytik), kteří jsou schopní analýzy a důležitým věcem se dává hodně prostoru v diskuzích, a před diskuzemi se preferuje kód - tj. důležitý je prototyp), nicméně těch lidí bude asi minimum.
Proč by se nadala používat komerční měřítka? V každém větším projektu určitá neefektivita vzniká a je jí nutno akceptovat – je to stejný efekt, jako v paralelních programech se tomu říká „cena za paralelizaci“ – v zásadě nejde o vůbec nic jiného, jen přeneseno do organizačních a lidských měřítek.
Já si naopak myslím, že Linux nevyužil ani desetinu svých možností právě proto, že není dobře řízen. Myslím si, že za pár let se to jasně ukáže. On je to vlastně jenom průnik svou křivek v grafu. Jedna je klesající počet vývojářů a prostředků do vývoje Linuxu (protože nadšení obecně klesá s časem, na začátku je největší a stejně tak na začátku je největší efektivita práce nadšeneckých a živelně plánovaných týmů, ale s časem to klesá) a druhá křivka je stoupající kvalita konkurenčních projektů klasickou cestou. Ať se na mě nikdo nezlobí, ale BSD je vynikající ukazatel neefektivnosti vývoje Linuxu. Myslím si, že nakonec se ukáže, že klasický model je efektivnější, a že s tím za cca 5 let bude mít Linux velké problémy a bude to muset nějak řešit – otázka je, jestli už bude mít jak.
OSS jako jediný v určitých segmentech dokáže konkurovat komerčnímu sw. Jenže to není argument. Vzhledem k tomu, že v programování je tisíce nik, tak pokud tam najdete pár desítek oblastí, kde OSS konkuruje, je to slabý výsledek – prostá statistika k tomu stačí. A pak je otázkou, jestli ten OSS, který konkuruje není právě vyvíjen a plánován klasickou, osvědčenou, neživelnou metodou, a proto to dobrý. Protože já diskutuji spíše o tom, že můj názor je, že způsob vývoje ála linux kernel je neefektivní a jediné proč funguje je, že se na něm podílí obrovský přetlak lidí, ale na celém světě není více lidí, peněz a kapacity, než na takové dva, v krajním případě tři podobné projekty, pak už na to na planetě Zemi nebudou lidi, peníze ani prostředky. A že věřím v konzervativní vývoj, jako má BSD – a čím dál více vidím z výsledků, že tento názor se mi jeví jako správný. A je úplně jedno, jestli vzniká OSS, nebo komerční sw – model konzervativní vývoj na zkušených lidech plodí o několik řádů lepší výsledky, než neefektivní model linux kernel (což je až extrémní případ neefektivity).
Ohledně OSS a předstírání práce – lidé se nerozhodují racionálně, ale 85% všeho co dělají má emocionální důvody. Z toho je potřeba vycházet. Mohou z toho mít pocit, že jsou někdo, když se účastní projektu, kterým se rádi chlubí. Mohou mít pocit, že něco řídí, vedou, že někde mají moc, či tahají za nitky – a to i když o projekt samotný jim nejde, ale o tu prestiž s tím spojenou ano. A samozřejmě tisíce dalích motivací.
Pokud chcete něco řídit, musíte mít autoritu, která to bude řídit. V tom počtu zainteresovaných stran v Linuxu je dohledání všeobecně respektované autority minimálně obtížné. Podívejte se, jak dopadly společné sw projekty na kterých se třeba podílel Microsoft, a HP a IBM.
Linux zatím funguje - je otázkou na co by se vývojáři, pokud by nepracovali na Linuxu měli soustředit? Na jiný podobný projekt? Na co? Jako protiklad Linuxu mohu uvést operační systém, programovací jazyk Oberon. Díky tomu, že vývoj probíhal v malé komunitě je Oberon očekávaně efektivní - jenomže se neujal, ačkoliv jej navrhl a realizovat tým elitních programátorů z ETHZ vedených prof. Wirthem. Ujal se chaotický vývojový systém Linuxu, který lépe vyhovuje té roztříštěnosti. Konzervativní model totiž od jistého počtu vývojářů přestává fungovat - viz klasická poučka ze sw inženýrství - zdvojnásobením počtu programátorů nezkrátíme vývoj na polovinu, ale naopak můžeme je i prodloužit.
V OSS pokud se někdo chlubí cizím peřím, případně blokuje ostatní je vyškrtnut z projektu. Pokud mluvíme o dospělých projektech. Nědělám www projekty, takže znám trochu jinou bandu lidí . Mezi lidmi, kteří píší v Cčku se to nenosí. Potěší, když mi commitnou patch, ale když se tím chlubím doma nebo v práci, tak je to ve smyslu hrách na stěnu házeti :). Ve většině projektů fungují samozáchranné prvky - pokud jsou lidé, kteří škodí projektu, tak jsou z projektu vyloučeni. Přiznám se, že za 8 let, co dělám na pg, jsem žádného škodiče nepotkal. Potkal jsem pár spammerů, pár lidí, kteří si myslelo, že komunita bude pro ně dělat zadarmo, ale žádného vysloveného škodiče.
Souhlasím, že Linuxu jednou dojde dech - a bude zralý na totální refaktoring. Zatím, to ale nevypadá. Reinkarnaci má za sebou KDE, Gnome se na ní připravuje. Co vím, tak lidé okolo MySQL dávali najevo, že by bylo třeba začít znovu a lépe a přepisuje se v projektu Drizzle.
Určitě máte pravdu v tom, že zkušení vývojáři lépe povedou projekt - jak ale v tom davu vybrat ty zkušené? A i zkušení vývojáři po pár letech zleniví a pak to chce ty mladé a zapálené, kteří udělají špinavou práci, do které se nikomu z těch zkušených nechce.
Počet člověkoroků práce / výsledný efekt – bude to hodně těžko obhajitelné číslo. A porovnejte totéž číslo třeba u BSD systému.Když mluvíte o číslech, kdepak jsou?
</pssst>
Jenže nebylo to tak nastaveno ohledně celého Linuxu? Nebylo počítáno s tím, že všichni si budou dělat, co je baví, případně co potřebují sami pro sebe a vznikne tak ten nejkvalitnější, nejbáječnější soft, který navíc bude zadarmo? A komerční vývoj sw tak v této konkurenci padne do kytek?
Problém je, že dotáhnutí projektu je mravenčí a nudná práce. A čím větší ten projekt je, tím je to horší. Celý Linux, programy kolem něj i vize FSF jsou postaveny na nikdy nekončícím nadšení. Na nekonečném množství ochotných vývojářů, jejichž počet roste v čase, protože se musí věnovat čím dál většímu množství projektů. Všichni Ti vývojáři samozřejmě budou zkušení a budou mít mnoho času na vývoj, opravy a další.
Realitu neošidíte.
Jenže nebylo to tak nastaveno ohledně celého Linuxu?Spis ne. Linux vnikl (resp. vyrostl na uroven kde je) pomerne zivelne a shodou mnoha pomerne velkych nahod. GNU vnikalo jako protiklad silne uzavrenych Unixu z ciste praktickych duvodu (vytvareni kompatibilnich programu ve svete kde kazdy pocitac ma svuj vlastni system se svym vlastnim kompilatorem, utilitami, etc...)
Nebylo počítáno s tím, že všichni si budou dělat, co je baví, případně co potřebují sami pro sebe a vznikne tak ten nejkvalitnější, nejbáječnější soft, který navíc bude zadarmo?Tohle si muze myslet fakt jenom idiot
A komerční vývoj sw tak v této konkurenci padne do kytek?To je fakt dost mimo. Komercni vyvoj SW je velmi dulezity pro OSS. Nicmene tady prevazuje programovani urcitych funkci pro nekoho kdo si tyto funkce (v ramci nejakeho OSS) objedna.
Problém je, že dotáhnutí projektu je mravenčí a nudná práce. A čím větší ten projekt je, tím je to horší. Celý Linux, programy kolem něj i vize FSF jsou postaveny na nikdy nekončícím nadšení.Kdepak. Cela zakladni organizacni kostra je posklada z lidi, kteri to delaji full time.
Linux vnikl (resp. vyrostl na uroven kde je) pomerne zivelne a shodou mnoha pomerne velkych nahod.
Živelně a na nadšení. Živelně a bez koncepce. Jenže s LInuxem je to stejné jako s firmami. Často je založí vizionář, který jim dá směr, nosnou myšlenku, ideu, ale ten musí být po čase vystřídán běžnějším, pečlivějším a na výsledky zaměřeným člověkem. Stalo se tisíckrát a ještě mockrát stane. Vlastnosti, které potřebuje firma/člověk/projekt při startu a létech rozjezdu jsou téměř opačné, které potřebuje v době, kdy se stabilizuje. A Linuxu stále chybí přechod do té druhé části, a proto se po mnoha mnoha letech stále nemůže uchytit třeba na desktopech a když si lízne jedno procento na počítačích, tak jsou všichni opilí štěstím a považují to obrovské štěstí a úspěch oproti Windows, které má kolem 90%.
Nic nejde postavit jenom na nadšení, ani Linux to nevydrží věčně. Pokud to bude chtít zkusit, stane se učebnicovým příkladem, jak poslat pěkný projekt do háje.
Tohle si muze myslet fakt jenom idiot
Mnohokrát prezentovaný názor v linuxových diskusích, který když si aspoň 5× do měsíce od někoho nepřečtu, honem se dívám na mapu, jestli jsem stále v realitě a na planetě zemi. Díky propagandě je takových „idiotů“ (já těm lidem nenadávám, vážím si jich, také jsem se mnohokrát v životě mýlil, jen přejímám označení) v linuxové komunitě velmi mnoho. Po zvýšené aktivitě Stallmana minulý rok těchto lidí dokonce výrazně přibylo a prezentují své názory s daleko větší jistotou.
Kdepak. Cela zakladni organizacni kostra je posklada z lidi, kteri to delaji full time.
Já si to uvědomuji. Nicméně ty lidi také někdo platí, a něco od nich očekává. Ale to už není vždy o nadšení, ale o normální práci – občas zajímavé, občas nudné. Já si uvědomuji, že celý OSS je vlastně schizofrenní, neustále zastánci OSS brojí a útočí proti firmám, ovšem na firmách a jejich penězích vlastně celý Linux a OSS fakticky stojí. A to nemluvím o tom, že firmy do OSS přinášejí reálné myšlení, bez čehož by se to zhroutilo ještě rychleji.
5.5.2009 18:24
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
3.5.2009 10:55