Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
No hlavně je zoufalé od Debianu, že tam ten Tomboy přidává ve chvíli, kdy je zbytečný (gnotes).
Asi si myslel gnote, apt-cache search gnotes nenaslo nic. Gnote som nainstaloval a idem vyskusat, vdaka za typ :)
Prvy krat suhlasim s RMS.
Inac proti c# pod woknami nic nemam. Keby aj linuxova implementacia sa volala c# a microsoft ho prezentoval ako multiplatformove, tak by to bolo ok. Inak si to polofunkcne Mono moze Miguel nechat ;) Som rad, ze este nikoho nenapadlo puzivat Mono v spojeni s Qt.
Qyoto využívá např. http://synapse.im/
Já to teda nechápu... mohl by mi někdo vysvětlit jak to vlastně je? Já myslel, že C# je sice vyvinutý Microsoftem, ale přijatý jako standard a Mono je jeho svobodná implementace... nebo ne?
Ale MS má v súvislosti s tým niekoľko patentov, ktoré by mohol v budúcnosti proti monu použiť.To je právě ta nějvětší potíž - i když je celé Mono "microsoftuprosté", je v důsledku patentů na ne-EMCA části pořád pod kontrolou Microsoftu, viz Mono and Microsoft’s patents na Wikipedii.
ja mam takove tuseni, ze uplne cele C# rozhodne neni standardizovane, napr. winforms.
cele C# rozhodne neni standardizovane, napr. winformsVy si myslite, ze knihovna pro psani GUI je soucasti jazyka?
Chcel povedat asi, ze win.forms nepatri do frameworku .NET .
Neviem, nevyznam sa do toho. Ale napriklad toolkity SWING a AWT su sucastou java API, kdezto SWT nie. Takze predpokladam, ze to bude nieco podobne.
Ale napriklad toolkity SWING a AWT su sucastou java API, kdezto SWT nie.Jsou součástí platformy Java SE, ale už ne třeba Java ME. Součástí jazyka Java tedy rozhodně nejsou.
Chceš říct CLIBlbě čtu, tu první větu si odmyslete
"Ono dneska se v Gnome dost používá Python, který má paměťovou náročnost vyšší"
To si delate srandu ? Je to podobne jako srovnavat pametovou narocnost javy a pythonu ... coz je zcela zcestne, jelikoz pametova narocnost javy je skoro o rad vyssi.
Podobne plati pro MONO. Samozrejme pokud neberu v potaz nove se zakorenujici technologie ruznych JIT implementaci pro python. Bavime se zde o klasickem P2.5C.
už len kvoli x264, na 32 bit je optimalizované - časť je napísaná v assembleriNějak extra do toho nevidím, ale:
./configure --enable-asm
Platform: X86_64
System: LINUX
asm: yes
A výhodou by mohlo být na 64-bitové architektuře kapánek rychlejší kódování. Když už jsme u toho, tak to klidně můžu vyzkoušet.
Nevim jestli je beagle zrovna dobry priklad .net aplikace. mono ale zase neni tak zrave, prave naopak. Rychlost nabihani aplikaci a rychlost kompilace je urcite lepsi nez u ELFu a gcc. Rychlost odezvy GUI aplikaci je minimalne dostatecna. A ze to zere vice RAM? Pamet je dneska levna.
RS je pro mě archetyp "linuxáka" kterej musí vymřít. Vpodstatě bojuje proti všemu co může skutečně pomoci linuxu k získání těch uživatelů, kterým pro jejich práci linux stačí (jenom to zatím většinou neví).
Ač v tomto konkrétním případě s RMS souhlasím, jinak je otázka za co vlastně RMS vůbec kope. A otázka je, zda v řadě (jiných) případů věci spíše RMS věci neškodí, než pomáhá. Jsem přesvědčen, že řada aktivit RMS byla užitečná, ale větší řada aktivit spíše škodí.
Jinak ale se zaváděním Mona do Linuxu bych byl velmi opatrný. A to velmi zdůrazňuji.
Podle mě je celý .NET a C# parchant, se kterým budou problémy. Ono je sice něco standardizováno přes ISO a ECMA, ale problém je, že Microsoft jsem vložil pár ale:
1) Některé části použité ve standardu jsou patentované Microsoftem. To je bez debaty, a je to Damoklův meč, který může (samozřejmě také nemusí) Microsoft kdykoli vytáhnout.
2) Microsoft se nesnaží používat standardní věci, i když je sám stvořil. Ve své implementaci používá i v základní knihovně mnoho věcí, které ve standardu nejsou. Vzhledem k tomu, že Windows je hlavní platforma vývoje programů na této technologii, znamená to, že programy a jejich přenositelnost bude vždy problémová.
Podle mého se .NET neměl na Linuxu vůbec objevit.
To, že se v .NETu dělají věci a programátoři .NET rádi používají je zase důsledek Javy. Java funguje tak, že vše v ní je dosti překomplikované. Zkuste se naučit programovat GUI v Javě a v .NETu v pojetí MS a nebudete chtít dělat v Javě. Celkem ty lidi chápu. Je to politika Sunu – všichni se nám přizpůsobí do posledního detailu.
Z druhé strany zklamal nadějný Python, který umí také velmi rapidní vývoj aplikací a dost vyplňoval mezeru, do které se teď .NET vecpe. V okamžiku, kdy Python byl na raketovém vzestupu jej jeho autor totálně pohřbil změnou syntaxe a vyvoláním nekompatibilit. Je to totéž asi jako v době, kdyby v době, kdy turisté právě začínají objevovat Váš hotel (který byl tehdy stranou zájmu), a o celém světě se o Vašem hotelu píše jako o nejlepším na světě, a tvoří se veřejné mínění o tom, jak kvalitní je Vás hotel, jste naplánovali rozsáhlou rekonstrukci a náívštěvníci viděli jen staveniště, bordel, rámus, špínu.
Ale jednoduchost .NETu je lákavá, rozhodně se to nedá srovnávat s Javou, a proto jakmile tu pandořinu skříňku zvanou .NET někdo na Linuxu rozšíří, máte Linux zamořený těmito programy v cukuletu. On totiž dost dobře nemá (srovnatelnou) alternativu, je jednoduchý i pro začátečníky (není třeba složitě studovat doktorát, abyste napsali dobře GUI v Javě), ani nehrozí nekompatibilní změnou syntaxe. Navíc, a to se sakra počítá, s podorou velké firmy, dokonce dvou (Microsoft a Novell), kteří jej opravdu hodlají natvrdo prosadit.
otázka zní - a stojíme o takové uživatele?Za sebe můžu říct jednoznačné ne. Současná stav mi víc než vyhovuje.
stejně jako teď, byť čistě KDEčkař, tahám tunu GTK balastuTunu GTK balastu? Pořád o ní někteří mluví, ale někdy bych ji opravu chtěl vidět. Neplete si to náhodou s tunou GNOME balastu?
Tunu GTK balastu? Pořád o ní někteří mluví, ale někdy bych ji opravu chtěl vidět. Neplete si to náhodou s tunou GNOME balastu?a GNOME není postaveno nad GTK? jinak než vznikne mýlka, slovo "balast" nemíním hanlivě na GTK+ a věci ji využívající, nýbrž jen a pouze jako vyjádření faktu, že o tyto věci na KDEčkovém systému nestojím, neboť KDE a aplikace nad Qt moje potřeby uspokojují ... zdůrazňuji "KDEčkovém systému", mohlo by to být i naopak, příležitostně používám XFCE, a tam bych zase vesměs nestál o věci nad Qt, jenže ke vší smůle, na to si stěžovat jaksi nemůžu, neb nic jako "Qt balast", tedy nechtěné závislosti na Qt, jaksi nepozoruju ...
neboť KDE a aplikace nad Qt moje potřeby uspokojují
A můžeš mi poradit něco místo Gimpu a Firefoxu?
Jsem taky KDEčkař, ale bez těchto aplikací se neobejdu. Firefox jsem si zkoušel zkompilovat pro Qt, ale výsledek byl dost špatný (šel spustit, ale byl prakticky nepoužitelný). Nejde mi až tak o místo na disku nebo knihovny, ale spíš o rozdílný vzhled* a integraci s prostředím (např. kllíčenka nebo asociace souborů).
*) jasně, jsou pokusy jak nastylovat GTK aplikace aby vypadaly jako Qt nebo naopak, ale nic dokonalého jsem zatím neviděl, vždycky jde poznat, že se nejedná o nativní Qt/GTK.
A můžeš mi poradit něco místo Gimpu a Firefoxu?těžko, neznám zadání, proč ti nevyhovuje Konqueror, a co potřebuješ dělat právě s Gimpem ... pointa nebyla o tom, že máš vyházet všechny aplikace "z druhého tábora", nýbrž o tom, že když už je vyházím a mám systém s K*, z G* se mi stejně něco nacpe (což naopak neplatí, když vyházím K* a mám systém s G*, tak nic K* už se mi do něj necpe)
což naopak neplatí, když vyházím K* a mám systém s G*, tak nic K* už se mi do něj necpeSkoro až mám chuť si rýpnout.
Firefoxu?Konqueror, Arora? V SuSE s KDE jsem nejraději používal Epiphany, protože to mělo docela dobrý skin.
rozdílný vzhledGTK+ má zakompilovaný určitý výchozí vzhled a ten se dá před kompilací samotnou změnit. Bohužel je různě rozházený po zdrojácích. Ptal jsem se proč k tomu vzhledu neudělají nějaké rozhraní(při kompilaci samozřejmě) a proč nevymění ten příšerný výchozí vzhled a odpověď byla, že to není priorita.
integraci s prostředím (např. kllíčenka nebo asociace souborů).Už jsem si též párkrát zaklepal na čelo, proč obě prostředí dělají své vlastní knihovny pro takové věci a nesnaží se nějak na tom spolupracovat, ale očividně než se stane z GNOME a KDE pejsek a kočička, tak to dřív rozmrzne peklo(Hlavně že na projekty jako GNOME Woman a podobné cipoviny se vždycky najde dost času a zdrojů).
Hlavně že na projekty jako GNOME Woman a podobné cipoviny se vždycky najde dost času a zdrojů
Já bych hned věděl o další (podobné) cipovině, ale zdržím se…
... KDE a kompletně jsem ho z kompu vykopal tak cca před půl rokem.tím ovšem jen potvrzuješ to, co jsem napsal - KDE se zbavit dá, G* nikoliv
G* je příliš velká množina.nerozumím ... co je jako kriteriem pro "příliš velká"?
A GTK nevyuužívá jen Gnome (které jsem rovněž vykynožil) ale také XFCE, Synaptic, Geany, Geeqie, Pitkin a Meld. Abych zmínil přinejmenším aplikace které užívám nejčastěji.když nic z toho nepoužívám, proč mám G* v systému mít? konkrétně:
# rpm -qa | grep gnome gnome-keyring-0.6.0-1.fc6 gnome-mime-data-2.4.2-3.1 libgnome-2.16.0-6.el5 gnome-python2-2.16.0-1.fc6 gnome-python2-gnomevfs-2.16.0-1.fc6 gnome-python2-gnomekeyring-2.16.0-3.el5 libgnomecanvas-2.14.0-4.1 gnome-doc-utils-0.8.0-2.fc6 gnome-python2-gconf-2.16.0-1.fc6 gnome-python2-canvas-2.16.0-1.fc6 gnome-python2-bonobo-2.16.0-1.fc6 gnome-python2-desktop-2.16.0-3.el5 rhn-setup-gnome-0.4.20-7.el5 gnome-vfs2-2.16.2-4.el5 libgnomeui-2.16.0-5.el5 gnome-mount-0.5-3.el5... strom závislostí tu radši vypisovat nebudu
konkrétně: …Jo, přesně to je ten
GNOME bastlo kterém jsem mluvil. Jen tak pro zajímavost doporučuji srovnat s KDE(hlavně v MB, protože tyto menší knihovny jsou tam nacpané do pár větších) a kolik společné funkcionality ty knihovny z obou prostředí mají. By to chtělo nějakého mesiáše, který by dovedl oba tábory usmířit a donutit k spolupráci.
Jo, přesně to je ten "GNOME bastl" o kterém jsem mluvil.to ovšem asi někde jinde s někým jiným ... balast nebo bastl, hodinky nebo holínky ... já jsem původně mluvil o věcech postavených nad GTK, bez ohledu na to, do kterého projektu patří - výše uvedený seznam je reakcí na tvrzení, že se kolegovi povedlo zbavit se GNOME, už jsme v diskusi jakso kousek jinde ...
balast nebo bastl, hodinky nebo holínky ...To je snad jedno, ne?
á jsem původně mluvil o věcech postavených nad GTK, bez ohledu na to, do kterého projektu patří - výše uvedený seznam je reakcí na tvrzení, že se kolegovi povedlo zbavit se GNOME, už jsme v diskusi jakso kousek jinde ...Dobrý, já jen ukazuju, že přesně toto je ten balast o kterém je výše řeč. A že ani jeden z těch balíčků nenáleží GTK+, nýbrž GNOME.
Mluvíš z hladu.Nebudu vyvracet.
Ne všechno co má v názvu gnome musí být nutně vázáno na gnome.Tak nějak samozřejmě automaticky předpokládám, že pokud už aplikace použije nějakou z knihoven GNOME, že už je to závislost samotné aplikace (z.B. Epiphany má nádherný strom závislostí a je výbornou ukázkou která si sebou táhne ten "GNOME baslast") takže by mě ani nenapadlo něco takového tvrdit. Jen se prostě snažím poukázat na to, že to co je zodpovědné za to co je vidět na obrazovce(gtk,gdk,cairo,pango a glib ať nežeru) je jen pár knihoven o velikosti pár MB a že ty tuny všelijakých GNOME knihoven co si sebou některé aplikace sebou nemá absolutně nic společného s GTK+. Prostě GTK+ je malá, nenáročná část, která dělá přesně to k čemu byla určena a nic víc. Snad o tom někdy napíšu blogový zápisek.
Kdybych chtěl only Qt desktop. Tak by to také šlo - prostě bych se přeorientoval na aplikace které využívají Qt.problém je, že to nejde (alespoň ne jednoduše v rámci standardních možností běžných distribucí) jsem silně orientován na KDE aplikace, potažmo aplikace které využívají Qt - přesto mám v systému spoustu "G*" věcí, které nechci, viz výše, které tam mám jen proto, že si někdo myslel, že závislost na tom je dobrý nápad ... ... a jak už jsem řekl, když si postavím systém s XFCE, tedy "G* only", tak Qt věc tam nebudu mít ani jednu a to vše bohužel nijak moc nesouvisí s otázkou, co uživateli připadá, že je lepší :-/
Depends: ${shlibs:Depends}
a závislosti se doplňují dynamicky podle toho které balíky v systému zrovna obsahují to co balík vyžaduje. ( Pozor, jiná věc jsou Build-Depends
, tedy závislosti pro sestavení balíku.)
Pokud tedy používáš aplikace, které obsahují - podle tebe - zbytečné závislosti, tak si je můžeš překompilovat s jinými balíčky, pokud obsahují to co aplikace vyžaduje. Možná pak zjistíš, že ty závislosti zase tak zbytečné nejsou a měl bys své nářky adresovat spíše autorovi aplikace, aby ji předělal k obrazu tvému, tedy tak aby tyto věci nepoužívala.
jistě, oboje se to natahuje ... ... jenom si jaksi někteří, kteří těm slovům pozornost nevěnují, ještě nestihli všimnout, že GTK+ samo o sobě nijak nehaním, a neustále se ho nesmyslně zastávajíbalast nebo bastl, hodinky nebo holínky ...To je snad jedno, ne?
Dobrý, já jen ukazuju, že přesně toto je ten balast o kterém je výše řeč.tak jinak:
jarmilka qpitch # euse -i gtk global use flags (searching: gtk) ************************************************************ [- cD ] gtk - Adds support for x11-libs/gtk+ (The GIMP Toolkit) local use flags (searching: gtk) ************************************************************ [- cD ] gtk (app-misc/beagle): Enables the GTK+ Beagle Search UI for showing search results. This is the default GUI for Beagle. [- cD ] gtk (dev-util/git): Include the gitview contrib tool. [- cD ] gtk (media-libs/libcanberra): Enables building of gtk+ helper library, gtk+ runtime sound effects and the canberra-gtk-play utility. To enable the gtk+ sound effects add canberra-gtk-module to the colon separated list of modules in the GTK_MODULES environment variable. [- cD ] gtk (media-libs/libgpod): Enables ArtWorkDB support (including Photos and album covers) [- cD ] gtk (media-libs/swfdec): Enable GTK+ convenience library while is necessary for all GTK+ apps using swfdec (gnome-extra/swfdec-gnome and www-plugins/swfdec-mozilla) [- cD ] gtk (media-libs/xine-lib): Build the gdkpixbuf-based image decoder plugin. [- cD ] gtk (media-video/mplayer): Build gmplayer, a GTK+ MPlayer gui (UNSUPPORTED) [- cD ] gtk (net-dialup/ppp): Installs GTK+ password prompting program that can be used by passprompt.so PPP plugin for reading the password from a X11 input terminal [- cD ] gtk (net-print/hplip): Enable GTK+ dependencies, currently only the scanner GUI with USE=scanner. jarmilka qpitch # equery d gtk+ * Searching for gtk+ ... app-admin/usbview-1.1 (>=x11-libs/gtk+-2:2) app-cdr/dvdisaster-0.72_rc1 (>=x11-libs/gtk+-2.6:2) app-crypt/pinentry-0.7.5-r1 (!static & gtk ? x11-libs/gtk+:2) app-emulation/fuse-0.10.0.2-r2 (gtk ? >=x11-libs/gtk+-2) app-misc/tangogps-0.9.3 (x11-libs/gtk+) app-office/dia-0.97 (>=x11-libs/gtk+-2.6.0) app-office/openoffice-3.1.0 (gnome ? >=x11-libs/gtk+-2.10) (gtk ? >=x11-libs/gtk+-2.10) app-text/aiksaurus-1.2.1 (gtk ? >=x11-libs/gtk+-2) app-text/ghostscript-gpl-8.64-r3 (gtk ? >=x11-libs/gtk+-2.0) app-text/gtkspell-2.0.15-r1 (>=x11-libs/gtk+-2) dev-cpp/gtkmm-2.16.0 (>=x11-libs/gtk+-2.15.5) dev-libs/poppler-glib-0.10.7 (cairo ? >=x11-libs/gtk+-2.14.0:2) dev-python/pygtk-2.14.1 (>=x11-libs/gtk+-2.13.6) dev-python/wxpython-2.8.10.1 (>=x11-libs/gtk+-2.4) gnome-base/gconf-2.26.2-r1 (>=x11-libs/gtk+-2.8.16) gnome-base/libglade-2.6.4 (>=x11-libs/gtk+-2.8.10) gnome-base/librsvg-2.26.0 (>=x11-libs/gtk+-2.6) media-gfx/gimp-2.6.6 (>=x11-libs/gtk+-2.12.5) media-gfx/graphviz-2.22.2-r1 (gtk ? >=x11-libs/gtk+-2) media-gfx/inkscape-0.46-r5 (>=x11-libs/gtk+-2.10.7) media-gfx/vuescan-8.4.16 (>=x11-libs/gtk+-1.2.10-r11) media-libs/gegl-0.0.22 (>=x11-libs/gtk+-2.14.0) media-libs/libquicktime-1.1.2 (gtk ? >=x11-libs/gtk+-2.4.0) media-libs/mlt-0.4.2 (gtk ? >=x11-libs/gtk+-2) media-libs/xine-lib-1.1.16.3 (gtk ? =x11-libs/gtk+-2*) media-sound/denemo-0.8.2 (>=x11-libs/gtk+-2:2) media-sound/easytag-2.1.6-r1 (>=x11-libs/gtk+-2.12:2) media-sound/freebirth-0.3.2-r1 (>=x11-libs/gtk+-2) media-sound/lingot-0.7.6 (x11-libs/gtk+:2) media-sound/timidity++-2.13.2-r10 (gtk ? >=x11-libs/gtk+-2) media-video/avidemux-2.4.4-r2 (gtk ? x11-libs/gtk+:2) media-video/kino-1.3.3 (>=x11-libs/gtk+-2.6.0) media-video/kmplayer-0.10.0c-r1 (npp ? >=x11-libs/gtk+-2.10.14) media-video/kmplayer-0.11.1a (npp ? >=x11-libs/gtk+-2.10.14) media-video/lives-0.9.8.12 (>=x11-libs/gtk+-2.2.1) media-video/mjpegtools-1.9.0 (gtk ? x11-libs/gtk+:2) media-video/mplayer-1.0_rc2_p20090530 (gmplayer ? x11-libs/gtk+:2) media-video/realplayer-11.0.1.1056 (!amd64 & X ? >=x11-libs/gtk+-2.2) net-analyzer/nmap-4.90_rc1 (gtk ? >=x11-libs/gtk+-2.6) net-analyzer/wireshark-1.2.0 (gtk ? >=x11-libs/gtk+-2.4.0:2) net-libs/xulrunner-1.9.0.11 (>=x11-libs/gtk+-2.8.6) sci-visualization/gnuplot-4.2.5-r1 (wxwindows ? >=x11-libs/gtk+-2.8) sys-apps/lshw-02.14b (gtk ? >=x11-libs/gtk+-2) sys-devel/distcc-3.1-r4 (gnome ? >=x11-libs/gtk+-2) (gtk ? >=x11-libs/gtk+-2) sys-devel/gcc-4.3.3-r2 (!build & gcj & gtk ? >=x11-libs/gtk+-2.2) www-client/seamonkey-1.1.17 (>=x11-libs/gtk+-2.8.6) * Missing digest for '/root/portage/media-fonts/freefont-ttf/freefont-ttf-20051206.ebuild' * Missing digest for '/root/portage/media-fonts/freefont-ttf/freefont-ttf-20060126.ebuild' www-plugins/adobe-flash-10.0.22.87 (x11-libs/gtk+:2) x11-libs/qt-gui-4.5.2 (gtk ? x11-libs/gtk+:2) x11-libs/wxGTK-2.8.10.1 (X ? >=x11-libs/gtk+-2.4) x11-terms/mlterm-2.9.4-r3 (gtk ? >=x11-libs/gtk+-2)... ze seznamu si vyhoď dia, tangogps, gimp a vuescan, což jsou věci, které (vědomě) nad GTK používám
A že ani jeden z těch balíčků nenáleží GTK+, nýbrž GNOME.hm, ale to nikdo nepopírá ... vytváříš si slamáka (čili straw-man argument) - již v první reakci na tebe upřesňuji na "postaveno na GTK", "GTK+ a věci ji využívající", přesto tady neustále i přes několikáté ujasnění bojuješ proti nějakému fiktivnímu tvrzení, že ty věci patří do samotného GTK+
Ne, v tomto se pleteš, přesně takto jsem to nemyslel.než půl dne jemně popichovat. Proto jsem to také psal, abych si potvrdil, že jsme na stejné vlně(což jsme očividně nebyli). Ušetřilo by to nějaké místo i čas.
balastjako spousty nepotřebných věcí zabírajících místo na disku a v paměťi i když zrovna nejsou 3x potřeba. A sažím se upozornit, že naopak všechno co je potřeba pro provoz GTK+ aplikací je pár knihoven(2-5, záleží na aplikaci, které funkce používá) a zabírají pár mega(skoro se divím, že to všechno někdo nevzal a neosekal to všechno do jediné binárky po vzoru busyboxu. nějaké GTK-tiny). S Qt se to určitě nedá dost dobře srovnávat. A to co Vy nazýváte GTK+ balast je ve skutečnosti GNOME balast.
"otázka zní - a stojíme o takové uživatele?"
Nie nestojime.
Nie som nazoru ze by sme mali vecne niekomu nieco prisposobovat, aby on nemusel vynalozit ani stipku namahy. Nech sa prisposobi on a potom zisti ze si ten system vlastne moze prisposobit sam uplne na mieru.
Cílem Microsoftu je zisk, nic jiného. Zbytek jsou jen prostředky k tomuto cíli. Pokud by Microsoft podporoval jen Windows a přitom by mohl zjevně podstatně zvýšit své zisky podporou i další platformy, akcionáři vykopou managery z firmy, pokud to neudělají.
Microsoft podporoval v minulosti i jiné platformy, například Internet Explorer a Microsoft Office vycházely (možná ještě vycházejí) i na Mac OS.
Já naopak velmi souhlasím s tím předřečníkem. Linux tříští síly a hledí si víc ideologie než nějakého postupu Linuxu. Stejně Linux nemá žádný jednotný cíl, žádný jednotný názor, žádný jednotný kodex, čeho se bude držet, takže je to sranda. Linuxová komunita se pouze domnívá a každý člen linuxové komunity si domýšlí, co a kam by měl vlastně Linux jít. Není žádný cíl, směrování Linuxu určuje víceméně náhoda a občasné aktivity aktivnějších jednotlivců a firem, které samozřejmě nejsou nikterak výrazněji propojeny.
Proti tomu je Microsoft, který plánuje a jednotně se řídí. Proti tomu je Apple, který dělá totéž. Není celkem divu, že v poslední době povyšuje hlavně Apple, ne Linux.
Osobně si myslím, že jednou přijde čas a Linux bude mít obrovský problém. Nadšení kolem Linuxu nevydrží věčně, a pak se ta roztříštěnost, neřízenost a neefektivita vývoje Linuxu projeví naplno (neefektivnost = kolik lidí se podílí na vývoji Linuxu, a jaký je poměr (celkový počet člověkoroků práce) / (výsledek)). On Linux jaksi tak nějak počítá s tím, že bude pořád v kursu, pořád v módě, a že lidé se mu budou věnovat i za cenu, že nebude tak dobrý, že bude roztříštěný, že bude nedotáhnutý, bez podpory výrobců hw a právně problematický.
Z Mona nemám radost, ale stejně tak ho vnímám jako důsledek situace Linuxu.
Vy vidíte GNU/Linux jako jeden OS, kterému chybí cíl. Já vidím GNU/Linux jako platformu pro dosažení mnoha cílů mnoha různých lidí a organizací.
Já psal o Linuxu, ne o GNU.
Ano, jednota má svoje výhody, ale i nevýhody, jako všechno.
Ano, jednota má svoje výhody, ale i nevýhody, jako všechno. To, co vy nazýváte roztříštěností, já vidím jako manifestací svobody této platformy a schopností lidí této svobody využít k dosažení svých cílů.
Ale já s Vámi na 100% souhlasím.
Mimochodem, pokud je cílem Linuxu manifestace svobody (pomiňme, že ne celá komunita tento názor sdílí), pak není podstatné, že ho používá zlomeček lidí, ani to, že ho výrobci hw nepodporují, ani to, jestli je vůbec Linux použitelný, nebo nepoužitelný – to vše jsou nepodstatné věci na kterých nezáleží. Tedy pokud je prioritní svoboda.
Drobný problém je ale, že si pod tou svobodou v Linuxu každý představuje něco úplně jiného.
Já jen vidím, že řada lidí se Linux snaží prakticky používat. A pro praktické použití Linuxu je pouhý požadavek na svobodu docela málo. Ale zase je to otázka, zda lidé stojí více o svobodu za každou cenu, a nebo také o použitelný Linux.
Cílem Microsoftu je zisk, nic jiného.No právě. Z toho mám strach největší. Ono totiž krom přímých cest k ziskům existují také cesty nepřímé(znáte seriál Las Vegas? Chodí to odpoledne na Nově).
a hledí si víc ideologie než nějakého postupu Linuxu.Nechci do toho kecat, ale GNU je především ideologii, takže se nejde divit, že to i tak trochu ovlivňuje i GNU/Linux.
právně problematickýS tím souhlasím, jenomže co s tím?
No právě. Z toho mám strach největší. Ono totiž krom přímých cest k ziskům existují také cesty nepřímé.
Existují. A jedna z dvou cest jsou nedostatečný a roztříštěný Linux a naivita linuxové komunity ohledně zanášení systému právně problematickými technologiemi (jako .NET) a právně problematickými licencemi (jako třeba nadužívání GPL). To obojí je velkým přítelem zisku Microsoftu.
Samozřejmě existují i cesty pololegální, či nelegální.
Nechci do toho kecat, ale GNU je především ideologii, takže se nejde divit, že to i tak trochu ovlivňuje i GNU/Linux.
Všechno co děláte děláte s nějakou ideologií, čili myšlenkou. Ale někdy je namístě otázka, zda některé ideologie není moc.
S tím souhlasím, jenomže co s tím?
Nic.Není vůle to řešit, ba vůle většiny komunity je právní sešněrování Linuxu ještě více utižit (vic více restrikcí v GPL3 oproti GPL2, a další aktivity).
Všechno co děláte děláte s nějakou ideologií, čili myšlenkou. Ale někdy je namístě otázka, zda některé ideologie není moc.Kde je jí moc?
Moc je jí všude, kde zabraňuje praktickému použití.
Například: Jestliže výrobci hw obecně nechtějí podporovat Linux, a nebo jen v malé míře, je na místě otázka proč a co jim nabídnout. Ale ideologie velí co tak vidím, že linuxová komunita se snaží spíše výrobcům hw nařizovat, aby sdíleli stejnou ideologii, jako Linux komunita. Napadlo třeba někdy linux komunitu, že hw výrobci nechtějí sdílet ideologii Linuxu, a proto to nedělají? A že pro ně není tato nabídka přijatelná? (Jako GPL a open source kódy a nestabilní nijak nezaručené API Linuxu, které prodražuje vývoj bez patřičné vyhlídky na zisk?)
Jako GPL a open source kódy a nestabilní nijak nezaručené API Linuxu, které prodražuje vývoj bez patřičné vyhlídky na zisk?Já už jsem asi přišel v čem je problém našeho sporu. V různých úhlech pohledu na věc.
OK, pak se ovšem smiřte s mizernou podporou výrobců hardwaruNechápu jak by takovýto uživatelé mohli být přínosní větší podpoře HW na jiných než Windowsových platformách. Jako že ty ovladače reversnou a naprogramují? To asi těžko. A nebo že bude slyšet větší křik? Co já měl zkušenosti s takovýmto uživateli, tak většinou při první nefunkční věci či pádu odsunuly GNU/Linux do kolonky nepoužitelný shit a přešli tam kde jim vše funguje, nehledě na to, že některé chyby jsou pěkně zapeklité a s nVidií očividně nehne ani stádo řvoucích buvolů.
svobodnými ovladači, které často fungují ne napůl, ale jen tak cca na 1/5Co Nouveau? Zkoušel jste? A většinou mám zkušenost takovou, že ty ovladače fungují jen tak napůl, protože jsou reversnuté a HW výrobci jim mění prostředí přímo pod nohama.
smiřte se také s ignorancí řady firem, produkujících profi softwareNa to je snad také potřeba něco jiného než armády BFUček, ne?
dodělej doma to co dříve fungovalo, ale teď to nějaký dynamický hošík rozbil, protože si hrajeNo tak to snad ani komentovat nebudu.
pak by MS třeba přišel s vlastní verzí .NET pro jinou platformu a nemuselo existovat patentově sporné a i jinak problematické MonoNo to určitě. A radši 3x Mono od Novellu než jednou nativní .NET od Microsoftu, protože pokud už odhlédnu od technické stránky věci, tak by to určitě nebyl jen patentově sporný bastl, ale ještě by na tom vysely všelijaké licence, intelektuální vlastnictví a bůh ví vůbec co a že by to bylo otevřené si také moc iluze nedělám.
Ti co chtějí věci na .NET by si ten runtime prostě nainstalovali, ostaní by na něj mohli kašlat a žádné patentové hrozby by neexistovaly.Jasně, pokud by si to uživatelé nainstalovali z nějakých jejich oficiálních zdrojů. Ale chtěl bych vidět toho kdo by si to cpal do repositářů. Mono je nepochybně menší peklo a když už to musí být tak nech je to takto.
Fungovalo by to úplně jinak a naprosto přirozeně
Přirozeně, to mi připomíná jednu scénku z Closeru:
- We're not gonna get in anybody's way, trust me.
- I stopped believing boys who said, "trust me, " when i was 16.
výrobci by viděli poptávku po svém hardwaru i na jiné platformě a vyplatilo by se jim do programování ovladačů investovat.A to poptávku by registrovali jak? Průzkumem trhu? A nebo by snad uživatelé posílali e-maily s dotazy na nějaké sales centrum? O tom už na ABC byl flame několikrát. A já se hrdě hlásím do tábora skeptiků.
Bohužel to takto dosud nefunguje, protože jsou Linuxové distribuce pomocí umělých, mnohdy ideologických, překážek udržovány ve stavu, který uživatele mnohdy odrazuje - neustále změny, nekompatibilita mezi verzemi, závislost na repozitářích pro danou konkrétní verzi distribuce, pro mnohé komerční firmy obtížně přijatelná filosofie tvorby ovladačů atd...Počkat, ovladače do toho výroku pasují jak?
Nechápu jak by takovýto uživatelé mohli být přínosní větší podpoře HW na jiných než Windowsových platformách. Jako že ty ovladače reversnou a naprogramují?
Tím, že budou Linux používat. Výrobci hw se budou jinak chovat k Linuxu, který má 1% uživatelů a jinak k Linuxu, který má 40% uživatelů. Už samotným používánim /dokonce i občasným) uživatelé zvyšují šanci na větší podporu hw. Žádná firma si nebude chtít nechat ujít trh se 40% podílem na trhu, a pokud ano, tak konkurence to zařídí.
Na to je snad také potřeba něco jiného než armády BFUček, ne?
Viz výše. Ona i kvantita je potřeba.
A radši 3x Mono od Novellu než jednou nativní .NET od Microsoftu
Tak já raději nativní .NET od Microsoftu, když na to přijde. Určitě bude kvalitnější, poběží lépe (nic proti tomu, ale MS ho udělá určitě kvalitnější a rychlejší, než Mono) a pokud jej uvolní pro Linux, není problém.
Ale chtěl bych vidět toho kdo by si to cpal do repositářů.
Myslím, že repositáře a současný systém linuxových distribucí je věc, která se bude muset jednou předělat. Chca nechca, protože to jednou bude problém.
Tím, že budou Linux používat. Výrobci hw se budou jinak chovat k Linuxu, který má 1% uživatelů a jinak k Linuxu, který má 40% uživatelů. Už samotným používánim /dokonce i občasným) uživatelé zvyšují šanci na větší podporu hw. Žádná firma si nebude chtít nechat ujít trh se 40% podílem na trhu, a pokud ano, tak konkurence to zařídí.
Viz výše. Ona i kvantita je potřeba.Na tom něco bude. No na druhou stranu většina lidí (co znám já) je už v takové prostředí kde jim vše funguje. Zkusí, něco nejede(a to zcela nezávisle na důvodu), odsoudí, zanadávají si, přejdou a smažou. Nejhorší je právě ta hranice mezi současným stavem a stavem kdy kdy bude trh zajímavý pro výrobce. A pokuď jde o mě, tak dokud se to nedostane do stavu zajímavého pro výrobce, tak nech už neroste, protože mě určitě nedělá radost přizpůsobovat se.
Tak já raději nativní .NET od Microsoftu, když na to přijde.Kdyby Microsoft něco takového vydal, tak by to bylo určitě včetně zdrojových kódu, když už na to přijde, že?
Určitě bude kvalitnější, poběží lépe (nic proti tomu, ale MS ho udělá určitě kvalitnější a rychlejší, než Mono)A právě proto nemám rád takovéto obecné používání slova kvalita. Ale dobře, budu hrát s Vašimi kartami. Pokud by to vydali jako closed-source, jak by to mohli potom obyčejní uživatelé debugovat a hlásit chyby? A jak by to mohlo být
kvalitnější, kdyby uživatelé nemohli hlásit chyby, opravovat je, apod. a záviselo by to jen a pouze na tom jak se vývojáři z Microsoftu vyspí?
Kdyby Microsoft něco takového vydal, tak by to bylo určitě včetně zdrojových kódu, když už na to přijde, že?
Já osobně, ani většina lidí zdrojové kódy nepotřebuje.
Pokud by to vydali jako closed-source, jak by to mohli potom obyčejní uživatelé debugovat a hlásit chyby?
Hlášení chyb je možné i pro closed source.
A jak by to mohlo být kvalitnější
, kdyby uživatelé nemohli hlásit chyby, opravovat je, apod. a záviselo by to jen a pouze na tom jak se vývojáři z Microsoftu vyspí?
Valná většina uživatelů není schopna ani zdrojový kód pochopit. Troufám si říci, že 99% lidí, ne-li více není schopno jakkoli do zdrojáku smysluplně zasáhnout.
A navíc, sám jsem leccos jako open source vydal. Nezažil jsem, že by do toho někdo smysluplně kdy zasáhnul. Řada lidí, kteří dělají open source též fakticky zásah od lidí zvenčí z hlediska zdrojových kódů nepamatuje. Takže jsem v tom dál nepokračoval.
Už řadu let dělám na projektu Complex Web Server (ponkrac.net/complex-web-server). Nijak jsem se nikdy nebránil vydat to včetně zdrojových kódů, ale za celých téměř 10 let, co projekt existuje neexistovala jediná žádost, či otázka na zdrojové kódy. Přitom se používá v mnoha státech světa a počet uživatelů je dosti vysoký.
Naopak mám pocit, že jednou z chyb Linuxu je stavění pouze na zdrojových kódech. Obecně použitelný systém běžně musí počítat pouze s binárkami.
Nezažil jsem, že by do toho někdo smysluplně kdy zasáhnul. Řada lidí, kteří dělají open source též fakticky zásah od lidí zvenčí z hlediska zdrojových kódů nepamatuje.To já jsem to zažil, a to nejednou. Například poslední vydaná verze incronu obsahuje 2 patche od lidí, kteří do toho smysluplně zasáhli (byly to sice drobnosti, ale sám jsem se prostě nedokopal to řešit). Nějaké patche jsem přímo začlenil nebo jinak využil i u přechozích verzí, jeden nezačleněný patch (nezačleněný proto, že jsem na něj zapomněl) ještě čeká. Celkem jsem pro tento jediný vcelku jednoduchý program obdržel asi 10 patchů. Na druhou stranu je pravda, že incron je trochu něco jiného než většina aplikací. Je určen pro velmi pokročilé uživatele, kteří rozumí systému a obvykle mají i programátorské znalosti. Proto srovnání s jinými aplikacemi není až tolik na místě.
Možná je to tím, že to jednoduchý program – tedy jeho zdrojové kódy jsou snadno uchopitelné pro úpravy. Navíc jak píšete je určen pro pokročilé.
Ale nechtěl jsem psát, že zdrojové kódy jsou zbytečné. Je to príma, pokud jsou. Jen jsem chtěl napsat, že by pro systém neměl být problém pracovat jako s open source, tak s closed source programy.
Přiznám se, že mě fascinuje, jak většina lidí požaduje zdrojové kódy, ale přijde mi to spíše jako náboženství, než praktický požadavek. Pro mě není problém zasáhnout i do složitých zdrojových kódů na hranici hackingu (divili byste, co člověk občas musí nad cizími zdrojovými kódy po předchozích programátorech někdy zvládnout, aby si vydělal na chleba a obhájil tak právo na výdělek). Valnou většinu programů co používám i na Windows jsem alespoň mírně upravil ve zdrojácích. Přesto nepožaduji nutně zdrojové kódy. Nejsou pro mě nutné, proč taky?
Pokud projekt dobře funguje, nebo s minimálními chybičkami, nepotřebuji zdroják. Navíc také vím, že zkompilovat a sestavit dobře větší projekt není sranda (ve firmách u velkých projektů jsou na to dokonce specializovaní pracovníci a speciální programy). Proto věřím, že autor programu je nejpovolanější k tomu dobře sestavit a zkompilovat projekt, pokud není prase. Proto se mi příliš nelíbí praxe balíčkování programů v Linuxu. Dokonce vím o řadě chyb v programech, které se v oficiální verzi binárky nevyskytují, ale přebalené v distribučních balíčcích ano.
Dokonce vím o řadě chyb v programech, které se v oficiální verzi binárky nevyskytují, ale přebalené v distribučních balíčcích ano.Na druhou stranu, právě správci balíčků často najdou některé záludné chyby. Autor programu obvykle nemá možnost (a hlavně by to bylo dost zdlouhavé) zkoušet program kompilovat a používat v různých distribucích různých verzí a na různých hardwarových architekturách.
Já osobně, ani většina lidí zdrojové kódy nepotřebuje.Samozřejmě, pokud plánujete/plánují používat a pak nadávat tak jsou k ničemu. Jinak jsou ale při debugingu naprosto neocenitelné(50% smysluplnosti otevřenosti programů se ukáže při ladění). A to je také jedna z mála věcí čím je/může být komunita velmi cenná (Teda ještě společně s bugzillou).
Hlášení chyb je možné i pro closed source.Nebudu vyvracet. Ale doufám, že Vy se naopak nebudete snažit vyvracet rozdíl mezi takovýmto hlášeními. Skoro až se mi chce říct, že to lze jen velmi těžko srovnávat.
Valná většina uživatelů není schopna ani zdrojový kód pochopit.To není třeba. Stačí když uživatelé dovedou co nejpřesněji za pomoci
gdb
(a jiných nástrojů) určit místo chyby a tím tak třeba vývojáři ušetřit spoustu času lokalizováním bugu.
Troufám si říci, že 99% lidí, ne-li více není schopno jakkoli do zdrojáku smysluplně zasáhnout.Ani nemusí, ale snad nechcete opravdu srovnávat hlášení o chybějícím vykřičníku na řádku 205 v tom a tom souboru s obecnou chybou číslo 0x2874 na adrese 0xa45264212 a rozzuřeným buvolem s neodpustitelnými hláškami kolem toho. Min. když už nic je to perfektní výmluva.
A navíc, sám jsem leccos jako open source vydal. Nezažil jsem, že by do toho někdo smysluplně kdy zasáhnul. Řada lidí, kteří dělají open source též fakticky zásah od lidí zvenčí z hlediska zdrojových kódů nepamatuje.Samozřejmě se bavím o některých více frekventovaných projektech než je zrovna Ponkrác-favorite-web-server.
Nijak jsem se nikdy nebránil vydat to včetně zdrojových kódů, ale za celých téměř 10 let, co projekt existuje neexistovala jediná žádost, či otázka na zdrojové kódy. Přitom se používá v mnoha státech světa a počet uživatelů je dosti vysoký.Bohužel, zmrdové jsou všude. A asi máte se zaměřením Vašeho projektu na ně větší štěstí než je obvyklé.
Naopak mám pocit, že jednou z chyb Linuxu je stavění pouze na zdrojových kódech. Obecně použitelný systém běžně musí počítat pouze s binárkami.No tak to už si ale fakt musíte dělat srandu.
Samozřejmě, pokud plánujete/plánují používat a pak nadávat tak jsou k ničemu. Jinak jsou ale při debugingu naprosto neocenitelné(50% smysluplnosti otevřenosti programů se ukáže při ladění). A to je také jedna z mála věcí čím je/může být komunita velmi cenná (Teda ještě společně s bugzillou).
Kolik uživatelů debaguje programy, které používají?
Navíc já nejsem proti open source, ale proti vyžadování open source jako jediné možné varianty a zatracování closed source.
To není třeba. Stačí když uživatelé dovedou co nejpřesněji za pomoci gdb
(a jiných nástrojů) určit místo chyby a tím tak třeba vývojáři ušetřit spoustu času lokalizováním bugu.
He? Tedy já programuji už 20 let. Ale nějak si připadám jako z Marsu. Jestli mi někdo bude schopen věnovat spousty časy a lokalizovat hodiny pomocí gdb (přiznejme, že toto umí jen velmi zanedbatelný zlomek lidí), pak jsou to fakticky spoluprogramátoři. Protože ten někdo musí projít zdrojový kód, dost přesně mu porozumět, být zdatný programátor, a věnovat mnoho času ladění a chytání chyby. U jednodušších chyb to totiž vůbec není potřeba – stačí popis a okolnosti vyvolání chyby, to stačí k rychlému nálezu.
U složitějších projektů je to téměř nemožné v rozumné časové investici. Navíc, pokud mi někdo nalezne pomocí gdb místo chyby, tak se na to nedá spolehnout, protože těch míst může být několik. Skoro jsem v pokušení říci, že pokud se nejedná o super známý velký projekt (linux kernel, …), pak pro velký projekt je to co píšete pro externistu téměř nemožné.
Ani nemusí, ale snad nechcete opravdu srovnávat hlášení o chybějícím vykřičníku na řádku 205 v tom a tom souboru s obecnou chybou číslo 0x2874 na adrese 0xa45264212 a rozzuřeným buvolem s neodpustitelnými hláškami kolem toho. Min. když už nic je to perfektní výmluva.
Chytrý a zkušený programátor se pozná tak, že na možnosti chyb myslí od prvního řádku programu. Například já každý projekt začínám tak, že píšu zachytávání, ošetřování a logování chyb ještě dříve, než napíše první řádek řešící funkčnost programu. Všiml jsem si, že ostřílení borci tak postupují rovněž. Je to takové moje malé tajemství jak poznat zdrojové kódy skutečného programátora, který opravdu umí a leččíms prošel.
Programování je primárně o chybách. Nad tím strávíte nejvíce času – zajištění hlášení chyb, demaskování chyb, testy, ladění. Pokud nejste s to zajistit, aby Vám uživatel programu byl snadno schopen podat více informací i bez zdrojáku, tak je to nanic. Ono totiž nejvíce chyb odhalí uživatelé, kteří Váš program používají velmi často, a Ti často neumí gdb. A jejich hlášení jsou většinou nejcennější a postřehy nejlepší.
Samozřejmě se bavím o některých více frekventovaných projektech než je zrovna Ponkrác-favorite-web-server.
O některých. Na světě jich moc není, kteří mohou požívat důvěry uživatelů s gdb. Obávám se, že když škrtnu linux kernel, bash a příslušné utility, možná jeden, dva další projekty tak jsme skončili. Zbytek je na úrovni statistické chyby.
A asi máte se zaměřením Vašeho projektu na ně větší štěstí než je obvyklé.
Nikoli, můj projekt prostě funguje. Jsem puntičkář, a za 10 let v něm nikdo nenašel chybu, kterou by jim sám program neohlásil dříve, než se stane. A projekt je neproblematický, prostě není to projekt typu dodělej doma, ale projekt, který jsem dotáhnul.
No tak to už si ale fakt musíte dělat srandu.
Snad vypadlo spojení a psal jsem moc rychle: „Obecně použitelný systém musí umět pracovat i v případě pouze binárek.“ Zatímco linuxová komunita s tímto případem moc nepočítá a hluboce jej odsuzuje.
Já osobně, ani většina lidí zdrojové kódy nepotřebuje.
To ještě nic neznamená -- i když jsem zdrojáky většiny opensourcu, který používám, ani neviděl, smysl to má -- dostupné zdrojové kódy beru jako záruku stability. Člověk ví, že ten software může používat napořád, pokud se na něj autor vykašle, bude program rozvíjet někdo jiný, pokud ani to ne, můžu se ho ujmout sám... Nemusím se bát zvyšujících se cen za licence nebo podporu, funguje tu konkurence, pokud by autor chtěl příliš vysokou cenu, bude podporu dělat někdo jiný, nebo udělá vlastní fork.
Valná většina uživatelů není schopna ani zdrojový kód pochopit. Troufám si říci, že 99% lidí, ne-li více není schopno jakkoli do zdrojáku smysluplně zasáhnout.
Jaký je ale důvod ty zdrojáky nezveřejnit? Přináší to nějaké náklady autorovi? Beztak musíš zdrojáky udržovat v nějakém verzovacím systému -- vystavit to na web je jen detail. Osobně si myslím, že freeware je dnes mrtvý -- pokud člověk dělá software zadarmo, měl by ho dát i se zdrojovými kódy, dělat freeware nemá smysl.
Nijak jsem se nikdy nebránil vydat to včetně zdrojových kódů, ale za celých téměř 10 let, co projekt existuje neexistovala jediná žádost, či otázka na zdrojové kódy.
IMHO trochu výjimka potvrzující pravidlo -- ten, kdo by byl schopný ty zdrojáky číst a upravovat pravděpodobně WAMP používat nebude -- použije Linux/BSD/Solaris a Apache a MySQL instalované pomocí nějakého balíčkovacího systému.
Ten chlap vi, co rika... Cim jsem starsi, tim vic ocenuju, ze je tu nekdo, kdo na tyhle veci upozornuje.
Teraz, keď už patenty očividne nie sú problémom, mohol by Debian zaradiť do videosystému všetky dôležité kodeky? Bez MP2, MP4, H264, je FFMPEG dosť oničom. Aj MP3 by potešil.
Teraz, keď už patenty očividne nie sú problémom?
Myslené ironicky. Keď sa už neboja patentov (zaraďujú Mono s nejasným statusom), tak prečo rovno nevyriešiť aj veci, ktoré ma ako používateľa trápia viac - zablokované kodeky vo FFMPEG.
Tiskni
Sdílej: