Názory k článku
Nové Ubuntu má vážné problémy s grafikami Intel

Hodne znatelne zpomaleni je i ve 2D (je to znat hlavne kdyz si clovek pusti video)

Mam taky x3100, jede mi to docela v pohodě, glxgears dávaj cca 780, což je průměr. Compiz mi zapnout nejde. Stejně jsem se ale vrátil po dvou dnech zkoušení na Mandrivu, ta nová mi taky nesedla, používám 2009.0 od jejího vydání, glxgears mi dávaj 1000 fps, což je zatím nejlepší výsledek z distribucí, které jsem zkoušel.

Ahoj, mam tu samou zkusenost. Po upgrade na x3100 narust v q3demo v timedemo cca o 30%, plus prestala se mi v PrBoomu v akcelerovane verzi rozpadat grafika (prechod na novejsi verzi ovladacu, ktere toho vic podporuji), takze zatim spokojenost.

2D spatne, vcera jsem presel na Karmic Koala Alfa a problemy jsou fuc, rychlost flash v firefoxu byla tak spatna, ze nesel vubec fullscreen. Sice to neni zavratne rychle, ale plynule video na full to zvlada. Krome toho nove jadro vyresilo zrejme neprijemny problem se zatuhavanim wifi a celeho ntb (x301)

jeste update, ted vsecho v KK v poradku vykon dobry, tuxracer najednou hratelny a flash bez problemu

mne karmic koala daily build vobec nenastartoval... takze asi tak ;)

To nie su problemy, to su len neprijemnosti. Problemy su s kartami ATI ... Clovek poradi niekomu kupu HW, aby mu to aj s linuxom slapalo, a potom toto. Aj ked v tomto pripade by som vinu canonicalu nedaval, napriek tomu je to cele neprijemne...

ano ano... ati... presne! radsej si zaskripem zubami pretoze by som bol veeelmi vulgaarny... v strucnosti: NEJDE!

a len tak mimochodom, nahravanie zvuku robi tiez riadny bordel, a detekcia specialnych klaves sa len zhorsuje.. nehovoriac o stave baterie na natebooku = to uz je fakt hruuza.

najhorsie na tom je to, ze predtym tam bolo iba zopar problemikov, ktore sa dali manualnou konfiguraciou odstranit, ale teraz k nim pribudli dalsie ;)

paaani z Xsov tomu dali tiez... nefunguje opicii trojhmat ctrl+alt+backspace, takze ked nahodite zly ovladac grafiky a zamrzne to... tak mate smolu.

jeden krok vpred (aj ked neviem aky) a tri dozadu :D

ctrl-alt-bakpase není nefunkční, jen se přestal být defaultně zapnut. Také jsem nadával když jsem na to narazil (asi dvě minuty po instalaci nového X serveru), ale překvapivě to píšou třeba v manuálové stránce pro X server. Musíš to povolit. Zkus hledat, nepamatuji si volbu.

abych tu jen nenadaval: sudo gksudo gedit /etc/X11/xorg.conf Section “ServerFlags” Option “DontZap” “false” EndSection ten argument, že to zakázali kvůli náhodnému stisknutí mne dostal, nevím co ostatní, ale nikdy jsem to nezmáčk náhodou...

abych tu jen nenadaval: sudo gksudo gedit /etc/X11/xorg.conf
Section “ServerFlags”
Option “DontZap” “false”
EndSection

ten argument, že to zakázali kvůli náhodnému stisknutí mne dostal, nevím co ostatní, ale nikdy jsem to nezmáčk náhodou...

souhlasim. je to paskvil. ubuntu 9.04 totiz pouziva xorg-server-1.6. ten ovsem funguje pouze s novymi ovladaci fglrx. No a ati se rozhodla v novych ovladacich nepodporovat stare modely karet. Jednou z nich je i m300 na mem notebooku. Vysledek je - bud opensource ovladace ktere funguji prijatelne pro 2D akceleraci a vubec pro 3D, nebo downgrade. Myslim ze by si panove z canonical meli hodit popel na hlavu a odejit kanalem. Takze mou staro-novou distribuci je gentoo.

takze problemy s kartami intel nejsou tak fatalni jak by se mohlo zdat :)

Každé vydanie Ubuntu já fixný kernel? Ak teda nepočítame mikro (2.x.y.z kde z je mikro) verzie..

diskutuje sa o tom uz dlho, riesenia su zname uz dlho, nic nove tento clanok neobsahuje, podla mojho skromneho nazoru... phoronix sa tym zaoberal dost podrobne a mam pocit, ze i na roote o tom boli spravicky...

ano, taky myslím, že se zase zbytečně plaší... jo, trošku to zazlobilo, ale prd se stalo.

Souhlas, zase tak moc se nestalo...
Funguje mi tahle konfigurace.


Section "Device"
Identifier "Configured Video Device"
Option "MigrationHeuristic" "greedy"
EndSection

Asi by to šlo nastavit. Načítání xine configu: http://bazaar.launchpad.net/~me-tv-development/me-tv/stable/annotate/head%3A/src/xine_engine.cc
A pak asi libxine min. 1.1.14, která by měla umět načítat xv port z konfigu. http://209.85.129.132/search?q=cache:L8ICTM3pD8wJ:rpmfind.net/linux/RPM/opensuse/factory/i586/libxine1-1.1.16.1-4.5.i586.html+libxine+xv+port&cd=7&hl=en&ct=clnk

WPA a Windows 2000? Kde jsi to viděl? Tenhle systém pokud vím podporu WPA nikdy neměl a mít nebude. To umí možná část wifi managerů dodávaných se síťovými kartami. Což je záležitost ovladačů a ne systému. Moje zkušenost je spíš opačná, síťovky které bych kvůli absenci podpory WPA v ovladačích pod Windows mohl vyhodit jsou v linuxu ještě použitelné. Problémy s klávesnicí jsem taky nezažil, kromé kontrolky num lock (čert to vem), i když je pravda že Gnome nepoužívám. Ad network manager a probuzení, zkus si třeba Dell X300 uspat a spustit wifi ve Windows XP a začneš snít o funkci rmmod a modprobe. A vykrádání linux x windows snad nemá smysl komentovat.

Hoj,

není tady místo na výcuc věcí které nefungují (leta) ve WIN tak jak byly zamýšleny. Nevešel by se sem ani výčet bezpečnostních chyb.

Nepouštěl bych se do tak silných slov jako "amaterismus", nic z toho o čem píšeš mě nepotkalo a věřím, že běžného uživatele ani nepotká, snad jen vyjma:
- přestane mít NVidia problémy s vypadáváním textur (zejména v compiz?)

prosim vsetkych aby nereagovali na zatrpknutost tohoto uzivatela.. ja som niekedy tiez pekne vytoceny..

ked tak mu prosim poradte s konkretnymi problemikmi, ktore spominal.

jasneeeee, ved to mas zadarmo.. preto napr dell dava i do svojich novych notebookov 8.04

http://www.root.cz/zpravicky/dell-predstavil-levne-netbooky-s-ubuntu/

Používám ubuntu a od 6.06 jsem si u dalsích verzí myslel, ze 6.06 je nejlepsi. Mylil jsem se, dalsi verze byly o neco horsi do 8.04, tudiz hodnotit zhorseni Ubuntu chce jen z LTS verzi.
9.04 pouzivam na laptopu Asus eee pc 701 a nejake zavaznejsi problemy jsem nezaznamenal, dokonce na tento stroj jej hodnotim lepe, neza 8.04 a 8.10 (neb nemusim pridavat repozitar z array.org).

Přes všechno negativní co píši níže si myslím, že ve vašem případě není na vině ani tak Linux jako spíš to, že si hledáte důvody proč si zanadávat.
Používám jak domácí tak pracovní počítače s Linuxem(vždy dobře vybraná verze distribuce po nějakém čase od vydání - aby už byly opravy) dlouhá léta celkem spokojeně. Sice mě vytáčí to o čem píši v jiných příspěvcích, ale lidi jako vy znám. Dlouhá léta do vás hustili, že nic jiného než software od jisté nejmenované firmy neexistuje a teď vás zase okolnosti nutí to přehodnotit. A vy hledáte důvody proč je to špatné a proč to nejde...

To se mýlíte. Já jsem člověk, který se snaží počítače používat k práci a ke zjednušení života. Nepotřebuji si s počítači hrát, není tedy mojí nirvánou si denodeně kompilovat jádro a onanovat nad tím, jak jak moje sestava zvýšila výkon o další desetinu procenta.
Nemám čas řešit problémy vyskakující po každé aktualizaci systému.

Mám udržovat počítač aktuální, abych zabránil virům a bezpečnostním problémům, zároveň ale nesmím aktualizovat tak často, aby se mi do počítače nedostal nefungující software?

Co je lepší?

nenechajte to skoncit hadkou... naco?

rieste a odporucajte! citim sa tu potom ako na forach kde sa hadaju feministky so sovinistami ;)

Proboha, já kernel nekompiluju(to dělám jen výjímečně při nějakých pracovních experimentech na serverech...dejte pokoj s tím mýtem o kompilacích) ani nemám potřebu nad tím sedět dlouhé noci, abych zvýšil výkon o 1%. Prostě nainstaluju, nastavím a používám. Hry mě nezajímají, profesionální grafik s potřebou Photoshopu (kterých je v těchto diskusích občas nějak podezřele mnoho :-)) taky nejsem, takže mně nic nechybí. Na domácích PC jsem prostě spokojený uživatel distribuce OpenSUSE 10.3 a 11.0 s perfektně fungujícími multimédii včetně DVBT tuneru a vším co potřebuji...Takže není pravda, že by to nebylo použitené. Je a to velmi dobře, mnohdy lépe než konkurence. Ale občas jsem pochopitelně vytočen. Hlavně neustálé vydávání nedovařených verzí distribucí mě rozpaluje doběla. Chápu, že to méně zkušené může otravovat a notorickým potížistům dává důvody.

Kdyby to bylo jednou, tak nic neřeknu. Ale ono je to pokaždé.

A to nechci rozvíjet flame na téma vnitřnosti linuxu, do kterých jako programátor linuxových aplikací trošku vidím.

Pokaždé určitě ne.
Používám starší verze OpenSUSE, kde obzvlášť verze 10.3 byla výborná. Ano, 11.1 je shit...
Prostě je třeba výběru distribuce a její verze věnovat pozornost - netvrdím, že je to dobře.

Omlouvám se za prostořekost, ale dovolím si o tom pochybovat.

Jednak Linux je hybridní kernel (tedy kombinuje vlastnosti několika typů kernelů, mám takový dojem, že v případě Linuxu jde o kombinaci vlastností mikrojádra a modulárního jádra). Za další, pokud vím tak se oficiálně nedoporučuje kernel rekompilovat (ovšem to neznamená, že by jste to dělat nesměl - chcete-li), pokud vše funguje jak má. Jsou samozřejmě případy kdy je to nutné. Například oficiální ovladače od NVidie stažené z jejich stránek, vyžadují zkompilované zdrojové kódy kernelu. Jenže to jsou operace které neděláte každý týden a v mnoha případech ani každého půl roku a sedět u toho opravdu nemusíte. Standardně postupuji tak, že si v X-ech provedu přípravné práce (pár minut, pokud se nerozhodnu měnit konfiguraci jádra danou tvůrcem distra) a zbytek, včetně instalace jádra probíhá na textové konzoli. A na dalších konzolách mohu nerušeně pracovat.

Čímž se dostávám k další věci. Nemohu tvrdit, že by problémy s Linuxem čas od času nebyly. Ale, alespoň podle mé zkušenosti platí, že jakmile je jednou vyřeším, pak už to problém není (a z drtivé většiny to neplatí jen v Linuxu). Mám už za tu dobu co Linux používám (řekl bych) vypracovaný model, podle něhož postupuji snad při každé instalaci, a potom už s ním léta nerušeně pracuji, popřípadě jej jen mírně dolaďuji ke svým potřebám.

Mimochodem, nevšim jsem si (za cca deset let), že by standardní aktualizace nějak narušovaly stávající stav systému. To se mi opravdu ještě nestalo.

Moc by mě zajímalo, co mají všichni s tou omletou kompatibilitou. Na binární úrovni (rozumím-li Vám dobře, tedy na úrovni aplikací, jinak mě opravte) je to z drtivé závislé na knihovnách. Protože v Linuxovém systému může vedle sebe existovat několik verzí jedné knihovny tak v tom není problém. Je to možná trochu složitější operace než ve Widlích, ale máte podstatněji vyšší šance na úspěch.

Já osobně používám počítač, aby my ulehčoval život (a nebudu lhát i pro zábavu. Vy si na něm nespouštíte hry, video, nepřehráváte hudbu, atd..? Jestli tvrdíte, že ne tak si dovolím pochybovat o pravdivosti těchto slov), všechny (řekněme pokročilejší) operace dělám jen proto, abych si ulehčil práci s počítačem, ne pro zábavu a nedělám je pokaždé...

Mimochodem, už pěkných pár let používám Debian GNU/Linux.

Binární kompatibilita znamená, že mohu vzít přeloženou verzi knihovny nebo aplikace a spustit ji s novou verzí te druhé knihovny nebo aplikace.

Například, valná většina pluginů do photoshopa jsou binárně kompatibilní skoro s každou verzí (nezkoumal jsem). Podobně je to pluginama do mayi (zkoumal jsem asi, 3 verze za sebou, u té poslední už to chtělo drobnou úpravu pluginu, ale byla kompatibilní s tou první). Kupodivu, plugin do IE je binárně kompatibilní jak s IE6, IE7 i s IE8.

Winamp DSP plugin, který jsem psal pro WinAmp 1.14 funguje i ve WinAmpu 6.

Takhle si představuju binárni kompatibilitu.

Ovšem modul na wifinu z jádra 2.6.28-11 neni kompatibilní s jádrem 2.6.28-15, prostě ho nenaloaduju.

oprava, ty cisla jader jsoi
2.6.28-11.42
a
2.6.28.11.15

upřímě to číslování nechápu, ale to druhé je prý novější.

Člověče, vždyť vy libovolně zaměňujete hrušky z jabkama. Ještě chvíli mi tvrďte, že jste programátor.

Jádro je operační systém a Photoshop, IE, May a podobně jsou aplikace. Zatímco nekompatibilita mezi moduly pro různé verze jádra je dána jejich přímou vazbou na herdware, a implementaci jádra(i ve Windows. Nemůžete využít ovladač - modul - na Wifi pro 2K a dát je do Vist, v nejlepším se Vám to nepovede a pokud ano tak to nebude fungovat), v typické aplikaci jde rozdíly implementace aplikace odstínit jejím rozhraním. V jádru to už prostě nejde.

Erata: V jádru to už prostě nejde. > V jádru je to nesrovnatelně obtížnější. Možné to asi je také, ale potom je nutno přistupovat při instlaci k rekompilaci jádra (viz třeba ty ovladače NVidia).

Nevidím rozdíl mezi jádrem a aplikací, rozdíl je pouze jen v tom, že jádro běží v privilegovaném režimu. Jádro není svaté, je to program stejně jako každý jiný. A pokud jde o stejný HW a stejný ovladač, nevím, proč by měl být problém s binární kompatibilitou. Vždyť i ta rozhraní jsou stejná. Kupříkladu pokud máte disk, na jedné straně máte souborový systém, na druhém straně máte ovladač disku. Zatímco jádro si hraje se souborovým systémem, ovladač disku dostává jednoduché příkazy ve formě zapiš na sektor, přečti sektor. Tohle rozhraní už existuje přes 20 let! Přesto bych si troufnul tvrdit, že ovladač disku z předchozí verze ubuntu, nepůjde použit v nové verzi ubuntu.

A kde bych viděl problém? V monolitickém návrh celého jádra, v jeho naprosté nemodularitě, která je maskována tím, že všichni bez důkazů tvrdí, že tím dosahují vyšší výkon. Přitom nikdy to není problém řešit, vždycky existuje možnost, při změně rozhraní, stará rozhraní emulovat. I za cenu ztráty výkonu, protože uživatel si pak umí rozhodnout, zda potřebuje výkon, nebo kompatibilitu.

Viděl jsem mnoho fragmentů zdrojových kódů jádra a vždycky jsem měl tu smůlu na tu část, kterou psalo nějaký prase.

Navíc handicap, že dodnes se jádra píšou v C (všichni papouškují Linusův nesmysl, že v C++ nelze programovat kernel) je přesně ten důvod, proč to vypadá tak jak to vypadá.

Ale tohle je problém i Windows.

PS: Ze začátku mé programátorské dráhy jsem se věnoval programování HW a psaní ovladačů (tehdy pro DOS), Ten svět HW se až tak nezměnil, základní postupy jsou stejný, tak mě nezkoušejte školit!

Co ma C++ navic oproti C? Nic, co by se nedalo poresit makry v C (pretizene "funkce", sablony, polymorfismus). Navic v C to muzete lepe zoptimalizovat.

Co má C navíc oproti assembleru? Nic, co by se nedalo pořešit makry a navíc to můžete lépe zoptimalizovat. Přesto raději píšu v C++.

No a někdy ty překladače C++ dokáží optimalizovat ještě lépe než překladače v C, jednoduše proto, že mají víc informací o tom, co ten kód vlastně má dělat.

Pro mě rozdíl v zápisu zanedbatelný není. Ale možná to bude tím, že hodně používám polymorfii (třeba s vícenásobnou bych v C asi moc nepochodil) a šablonování, pro základní OOP je ten rozdíl opravdu minimální.

C++ neni STL!!!!!

STL je součást ISO C++ standardu.

Docela by mě zajímalo, jak v C uděláte částečnou specializaci šablon nebo nějaké složitější metaprogramování? A nebo ten vícenásobný polymorfismus?

Kompilátor C++ může optimalizovat lépe než kompilátor C, protože zná spousty vztahů, které kompilátor v C nezná (třeba při vícenásobné polymorfii více následných volání virtuálních funkcí potřebuje jenom jeden přístup do RTTI). Samozřejmě si to můžete zoptimalizovat v C ručně, ale proč bych to dělal, když už to udělal někdo za mě a navíc portabilně?

STL je hodne pomale, existuji mnohem rychlejsi varianty.

C++ ma vice informaci o tom co je const, takze verim tomu ze ma sanci prekladat lip.

A hlavne dobre napsane C++ je bud lip udrzovatelne jak C (pokud projekt tezi z OOP a jinych vlastnosti C++), nebo stejne dobre (protoze to de facto jde napsat v nejhorsim pripade jako v C).

A hlavne Linuse pokud si vzpominam trapi spis prenositelnost a citelnost kodu. Je pravda ze chytre napsane C++ je pristupne mnohem mensi skupine lidi nez chytre napsane C, prece jen na C neni potreba az tolik programatorske inteligence.

Povidacky... prakticky clovek vzdy vyhra .. pokud teda umi programovat v ASM, ne kazdy kdo umi napsat MOV umi v ASM programovat.

Ale jeste jsem nevidel C/C++ kompilator ktery by mi udelal vnitrni cykly ve stejne kvalite jak to umim rucne.

A to jeste nemluvim o MMX/SSE, tam uz gcc/mscc absolutne nema sanci. (s jinymi nemam dost zkusenosti)

Přesto raději píšu v C++. To já taky. Vypadá to lákavě, ale nějak si nedokážu představit jádro napsané v C++. Jednak by asi bylo nutné spoustu vlastností, kterými C++ disponuje řešit přímo v jádře (nebo alespoň na jeho úrovni) a jednak si myslím, že by to mohlo vyvolat neuvěřitelné zmatky v dalším vývoji, včetně spousty nechtěných závislostí a vedlejších vlastností celých tříd (nedej bože šablon).Mám takový pocit, že na takové úrovni je mnohem jednoduší uhlídat sadu jednoúčelových funkcí, než celé třídy. Četl jsem, však že jaderné moduly je prý možné v C++ vytvářet, ale moc se to nedoporučuje.

Mohl bys prosím vyjmenovat ("jednak by asi bylo nutné spoustu vlastností, kterými C++ disponuje řešit přímo v jádře"), které to jsou? Já vím asi o dvouch, bez kterých se ale C++ obejde, pokud od toho nechceš extrabuřty a připadně se dají vyřešit zvláštním setupem při startu jádra.

Zase mi vychází nejlépe ten assembler :) sten@Kass Dokumenty $ ls -l hello-asm -rwxr-xr-x 1 sten sten 906 2009-05-19 16:05 hello-asm sten@Kass Dokumenty $ ls -l hello-c -rwxr-xr-x 1 sten sten 11092 2009-05-19 15:59 hello-c sten@Kass Dokumenty $ ls -l hello-cc -rwxr-xr-x 1 sten sten 11639 2009-05-19 15:59 hello-cc

Kua, lepší formátování:

sten@Kass Dokumenty $ ls -l hello-asm
-rwxr-xr-x 1 sten sten 906 2009-05-19 16:05 hello-asm
sten@Kass Dokumenty $ ls -l hello-c
-rwxr-xr-x 1 sten sten 11092 2009-05-19 15:59 hello-c
sten@Kass Dokumenty $ ls -l hello-cc
-rwxr-xr-x 1 sten sten 11639 2009-05-19 15:59 hello-cc

No ten by v tom kernelu byl jen jednou, tak co řešit :-D

Kdo řiká, že musíte mít tak velký runtime? Nikdo přece netvrdí, že musíte použít molocha, jménem STL. Samotné C++ žádný runtime nepotřebuje, pouze standardní zavaděč.

Staticky? hello-c má 696993, hello-cc má 1417752, po stripnutí 621568 a 1154040. Fakt si myslíte, že tahle čísla o něčem vypovídají a že kernel opravdu obsahuje těch 6 MiB, co obsahuje ten céčkový Hello, World?

Mohl bys prosím vyjmenovat ("jednak by asi bylo nutné spoustu vlastností, kterými C++ disponuje řešit přímo v jádře"), které to jsou?" Hmm... teď nevím. Buď jste Vy špatně pochopil co jsem napsal, nebo špatně chápu Váš dotaz. Já jsem se nikde nezmiňoval o tom, že některé vlastnosti C++ v jádře už jsou. Já jsem tou větou pochyboval o tom, že by to bez určitých zásahů a implementací přímo v samotném jádře vůbec sám kompilátor C++ zvládl.

No právě, a já se ptal, které zásahy máte na mysli. Jestli víte, které by to byly a kolik by jich bylo a jak jsou komplikované.

On neví. Je to D.A.Tiger, žádné konkrétní informace od něj nečekejte. A když už z něj něco vyždímáte, tak typicky zjistíte, že zase někde něco nepochopil.

No od lháře vašeho kalibru to sedí ;)

LOL. Informace k věci jste ani v této diskuzi nenapsal.

LOL! Zato vy jste k věci ohromě. Zase začínáte šaškovat, co?

Pokud jste si nevšiml, tak výhrady byly opět k vaší nekonkrétnosti. A nebyly to výhrady jen z mé strany. Ale vy jste OK, to jen ostatní vám nerozumí ;)

Pokud jsem si všiml, tak výhrady k vám tu jsou z nepoměrně širšího spektra čtenářů, nejen z mé strany. Ale vy jste OK, to jen ostatní vám nerozumí ;)

Polymorfizmus řeší překladač statickou tabulkou. Tabulka je implementovaná přímo v kódu. Je to na stejné úrovni jako udělat staticky alokované pole adres.

C++ nepotřebuje nic připravovat. To akorát knihovny, které se na to nabalují občas obsahují balast vyžadující zvlášní inicializaci. Moderní programátor ani nepoužívá statické proměnné, pouze singletony alokované při prvním použití. K tomu si vystačí jen se statickým ukazatelem v datovém segmentu inicializovaný na NULL.

Opravdu, nevěřte c++skeptikům, jednímž z nich je i sám Linus. Sic si toho člověka vážím, ale jako systémáře a podle toho co jsem četl, C++ nikdy moc nepochopil. Z toho pramení různé míty a pověry, které se šíří mezi programátory kernelu.

"Moderni programator ani nepouziva staticke promenne, pouze singletony alokovane pri prvnim pouziti."

... a az na takovy singleton sahnete v preruseni a bude ho potreba alokovat a nebude pamet, tak co?

Vratit chybu nesmite, to, ze v jadre docasne dojde pamet (nez se neco odswapuje), je normalni situace, se kterou se ovladac musi vyrovnat bez ztraty funkcnosti.

Už jste někdy viděl alokaci ve statický alokovaném bufferu?

static MyObject *singleton = 0;
char buff[sizeof(MyObject)];

MyObject getSingleton() {
  if (singleton == 0) singleton = new(buffer) MyObject();
  return singleton;
}

Tohle se dá samozřejmě napsat i šablonou, pak se deklarace takového singletonu provede na jedné řádce. Opravdu tomu nerozumíte!

Tohle ma jakou vyhodu proti?

static MyObject singleton;

MyObject getSingleton(){
return &singleton;
}

--- bud ten konstruktor zadnou pamet nealokuje a pak se klidne muze cely objekt inicializovat pri zavedeni programu. Nebo sam konstruktor neco dalsiho alokuje a pak si nijak nepomuzeme, kdyz objekt inicializujeme ve statickem bufferu.

( BTW. v tom kodu chyby __alignof__(MyObject) )

No té inicializaci při zavedení programu jsem se chtěl vyhnout, právě z důvodu výše popsaných (námitka, že C++ vyžaduje nějaké běhové prostředí jen kvůli tomu, aby inicializovala staticky alokované objekty).

Špatně čteš.

Align by tam mohl být. Nicméně myslím že třeba MSVC zaručuje, že vše co je delší než align bude vždy alignováno, i když je to buffer charů. Nevím jak GCC.

Jinak v C++ lze programovat stejně jako v C :-) Míra použití objektů je na jedné straně posilována jejich výhody, na druhé straně tlumena mírou technických komplikací. Každopádně vždycky budu tvrdit, že jakákoliv technická komplikace se dá snadno zabalit do nějakého objektu :-D. A to ať tou komplikací je nějaká systémová záludnost, komplikovaný hardware, vzdálená nespolehlivá služba, nebo uživatel ve věku 3 let :-D

No C++ je skoro plně převeditelný do C, jak tu někteří dokazují. Kompilátor opravdu udělá spoustu věcí, protože na konci sedí úplně obyčejný linker, který linkuje normálně kusy kódů a překládá symboly na adresy. Na rozdíl od vývoje překladačů C a C++, linkery (aspoň v základě) jsou stále stejně hloupé.

C++ potřebuje v runtime jen následující support
1) volání konstruktorů a destruktorů staticky alokovaných objektů
2) výjimky
... a o ničem dalším nevím.
Ad 1) bez toho se dá snadno obejít, prostě nebudeme nic alokovat staticky :-) (pro Cčkaře naprosto nepřekonatelná záležitost). Pokud by měl kernel tohle podporovat, musí umět funkci atexit a musí umět zavolat inicializaci každého objektu po jeho bootstrapu. Ale, kdo říká, že musíte tohle používat

Pozn: Alokace se provádí přes operátor new, který se dá předefinovat, aby prováděl klidně kernelovské alokace a dealokace.

Ad 2) Výjimky jsou velice zásadním a často nepochopeným nástrojem standardních C programátorů. A přitom výjimky vyžadují jen jeden TLS (Thread Local Storage) ukazatel, který si každá funkce pracující s výjimkamy sama spravuje. Při vzniku výjimky, která vznikne v zásadě vždy pouze voláním příkazu throw totiž přejde program do alternativní verze dané funkce, ve které už překladač připravil kód vedoucí k destrukci všech doposud vytvořených objektů. Následně funkci opustí, s tím, že místo na návratovou adresu skáče na obsluhu výjimky uloženou právě v té TLS proměnné. A opět pokračuje ve výkonu již připraveného programu. Nic víc to není. Opět, kernel nemusí výjimky používat, na druhou stranu, v dnešní době už zdržují minimálně a přináší velice robustní stabilizační prvek do celé aplikace.

A to je celé, vše ostatní lze nyní převést do C. Ať už jde o volání virtuálních metod (tabulka funkcí) nebo RTTI (statická tabulka popisovčů tříd). Šablony mají blíže spíše k makrům a nepotřebují žádnou podporu ze strany runtime. Schválně, vemte jakoukoliv oblast z C++ a napíšu, co by to vyžadovalo v kernelu. STL prosím vynechte, nikdo nikoho nenutí používat STL v kernelu, klidně lze napsat nějakou vlastní verzi kSTL (kernel STL)... je to jen knihovna.

Ano, tomu rozumím. :)

Jenže v tom případě přicházíte o výhody C++ a navíc to není nijak v rozporu s tím co píšu. Defacto vám zůstane jen syntaxe C++ a hromada dalších problémů, které se navíc budou muset řešit při startu systému (protože sice kompilátor to může nachystat, ale problém je v tom, že samo o sobě to fungovat nebude). Sice možná získáte něco jako třídy, dědičnost, polymorfizmus (možná i šablony), ale za jakou cenu? Vemte v potaz také tu věc, že Linuxový kernel je tvořen tak, aby byl v daných možnostech co nejmenší. tím, že do něj přidáte tyto mechanismy, převedené ještě do C by se mohlo klidně stát, že se neuvěřitelně nafoukne. A to nechávám stranou, jaký by to mohlo mít dopad na celkový výkon systému, nebo jak nakonec zajistíte kompatibitu mezi moduly (napsané v standardním C, popř. C++) a jádrem.

Navíc paměť vždycky nakonec přiděluje jádro, takže redifinicí new by jste žádnou novou výhodu nedostal. A je otázkou zda by v tomto případě možnost přetížit operátor new byla vůbec žádoucí, protože by se snadno mohlo stát, že si s pamětí bude každý dělat co jej napadne. Spolehlivost a kompatibilita by pak mohla jít hezky rychle do háje již přímo v jedné verzi jádra.

Myslím, že než podstupovat takovéto problémy bych se klidně spokojil s jádrem v C (i přes svou náklonnost k C++) :)

- Defacto vám zůstane jen syntaxe C++
V zásadě je to jen syntaxe, nikdo nikdy netvrdil nic jiného. Syntaxe a některé zautomatizované úkoly, které byste stejně dělal

- hromada dalších problémů, které se navíc budou muset řešit při startu systému
Jak jste si všiml, vyjmenoval jsem jeden, s tím, že jej nemusíte používat. OOP programátor to taky nepoužívá nikdy. Takže to je kec.

- že do něj přidáte tyto mechanismy, převedené ještě do C by se mohlo klidně stát, že se neuvěřitelně nafoukne.
Jenže tyto mechanismy tam přidáváte stejně tak jako tak. Polymorfismus Cčkaři nahrazují callback funkcemi. Chybějící destruktory... otevřený prostředek stejně musíte zavřít, akorát už na to nemusíte myslet. A pokud Vám nějaký automatický prostředek vadí, prostě ho vypněte, dejte příslušné funkci prázdné tělo, překladač bývá chytrý a pochopí to.

- (napsané v standardním C, popř. C++)
Dá se. Třeba C moduly zawrapovat do objektů. Překladač stejně vetšinou ten wrap interně rozbalí, takže výsledkem je totéž, jako by to bylo v C. Opačně se to dá udělat tak, že na C rozhraní propagujete pouze funkce s extern "C", interně si pracujete s objekty dle potřeby.

- Navíc paměť vždycky nakonec přiděluje jádro, takže redifinicí new by jste žádnou novou výhodu nedostal.
To jsme si nějak nerozumeli. Jak přiděluje? Jako sám? To modul nemůže kernel požádat "půjč mi kus paměti", a posléze "vracím kus paměti?". A myslíte si, že by byl takový problém nadefinovat new, aby dělal totéž?

- A je otázkou zda by v tomto případě možnost přetížit operátor new byla vůbec žádoucí, protože by se snadno mohlo stát, že si s pamětí bude každý dělat co jej napadne
To jsem nějak nepochopil. Pokud jsi půjčím kus paměti, asi by mi do ni nikdo neměl sahat, ne?

" Syntaxe a některé zautomatizované úkoly, ..."
Dík, dlouho jsem hledal ten pojem a nemohl jsem si za boha vzpomenout... A jsme u toho. Právě toto všechno je to co bych v jádře nechtěl mít(přesně podle filozofie Torvaldse - nic co tam nepatří). Volání callback funkcí je jednodušší než ošetřování tabulky funkcí s tím, žemusíte dokonce brát ohled na to, zda daná fukce je přetížena (a jak) či ne, a zda objekt ke kterému se váže je pointer či nikoliv. Spousta práce navíc a pochybuji o tom, že by bylo výhodnější to takto zanést kompilátorem přímo do jádra. Nehledě na to, že jak už jsem psal, kompilátor tu zas tolik možností nemá, jako u klasické aplikace, kde počítá s tím, že při startu aplikace je všechno už nachystané a může se vyřádit (konec konců, start programu zase řídí jádro).

"Jenže tyto mechanismy tam přidáváte stejně tak jako tak..." Ano, ale jsou pouze tam kde je opravdu potřebujete, což samozřejmě znamená, že na to musíte myslet. C++ vám sám nezavře zdroj (právě nekontrolovatelná ztráta zdrojů je jedním z velkých strašáků u C++) ani neuklidí paměť (to spíš Java). Většinu z toho - pokud si ještě něco pamatuji - dělá zase systém při ukončování aplikace. A destruktory volá buď operátor delete, nebo jsou atomaticky volány při ukončování aplikace (což je v případě jádra na nic).

"Dá se. Třeba C moduly zawrapovat do objektů". Ano, ale já měl spíš namysli pravděpodobnou spětnou nekompatibilitu (nebo alespoń zbytečnou složitost) Vámi navrhovaným řešení jádra a standartním C++.

" A myslíte si, že by byl takový problém nadefinovat new, aby dělal totéž?" Ne nebyl, ale nějak mi nedochází ty výhody pro jádro, oproti stávající implementaci, nehledě na to myslíte, že by potom byl až takový problém pro zkušenějšího programátora přetížit new s filozofii "tady si urvu kus paměti..."?

Pardon, ale tento příspěvek je jeden obrovský kec člověka, který tomu vůbec nerozumí

-volání callback funkcí je jednodušší než ošetřování tabulky funkcí

volání callback funkce se zpravidla dělá ukazatelem na funkci. Tabulka funkcí má tu výhodu, že s objektem většinou stěhujete jeden ukazatel, nikoliv celou (callback) tabulku (pokud je těch callbacků víc). Když narvete callbacky do struktury, uděláte to přesně tak, jak to dělá C++

-žemusíte dokonce brát ohled na to, zda daná fukce je přetížena (a jak) či ne

To nemusí nikdo, to se řeší při překladu. Program už jen koukne do tabulky a volá (výpočet má složtitost O(1))

-že při startu aplikace je všechno už nachystané

Proč pořád opakujete tuhle pitomost!!!!!!

Ale tohle je fakt síla:!!!

"C++ vám sám nezavře zdroj,ani neuklidí paměť (to spíš Java), Většinu z toho pokud si ještě něco pamatuji dělá zase systém při ukončování aplikace"

Proboha člověče, nekecejte do něčeho, čemu nerozumíte! Tohle je úplný blábol! Svatá dobroto!

:-DDDDDDD

že by potom byl až takový problém pro zkušenějšího programátora přetížit new s filozofii

To jsem nepochopil

Opravdu? To je velmi zajmavé, protože mě vždycky učily, že každé new musí mít své delete. Jinými slovy mohl by jste mi říci, který standart říká, že C++ má autonomní zprávu paměti a systémových zdrojů?

RAII znáte?

Ano. Vím, že kompilátory C++ tenhle model zprávy paměti podporují. Mám však takovou obavu, že přímo o standart se nejedná.

Nebo Loki.

Ale tak či tak, tvrdím, že v standardně si v C++ musí člověk zprávu zdrojů ohlídat sám.

Nebo jinak. Automatickou zprávu paměti si můžete implementovat např. pomocí inteligentních ukazatelů. určitě není zas až tak velký problém napsat něco ve stylu garbage collektoru. Ale moje otázka se týkala standartů C++ (tedy závazný pro všechny překladče).

Tohle není model správy paměti, ale stylu programování. Pokud ho někdo nedodržuje, tak je prase a stejně jako v C si musí ohlídat, aby ke každému new (malloc) bylo i delete (free). S tím rozdílem, že pokud není prase a RAII používá, tak nic hlídat nemusí.

Přímo ve standardu je akorát std::auto_ptr, což je úplně debilní typ (např. nefunguje s kontejnery), ale naštěstí máme Boost a nové C++0x bude podporovat i lepší chytré ukazatele.

No pokud to správně chápu, tak k tomu potřebujete podporu kompilátoru, protože ten tu dealokaci hlídá (popř, mechanismy vložené kompilátorem do aplikace) statických objektů, ne? Jinak to, že pokud si alokaci a dealokaci zdrojů hlídám sám, znamená to, že jsem prase? Od toho je přece konstruktor a destruktor...

No pokud to správně chápu, tak k tomu potřebujete podporu kompilátoru, protože ten tu dealokaci hlídá (popř, mechanismy vložené kompilátorem do aplikace) statických objektů, ne?

Ano, potřebujete k tomu podporu kompilátoru, aby vložil na správná místa stack unwind (kde se provede volání destruktorů a tedy i dealokace). Ale to je součástí ISO C++. Žádnou extra podporu nepotřebujete.

Jinak to, že pokud si alokaci a dealokaci zdrojů hlídám sám, znamená to, že jsem prase? Od toho je přece konstruktor a destruktor...

A přesně to je RAII.

Asi si pořád nerozumíme. Jednak kolega "novačisko" četl-li jsem jeho příspěvky pozorně, navrhoval jako součást svého modelu vyloučení statických proměnných. A jednak uvažme následující (jen příkladový !!!) kód :

class X;

class A {
  X *my_object;

public :
  A( ) { my_Object = new X; }
  ~A( ) { }
};

Takže pokud si dobře vzpomínám tak standarty pro C++ jasně říkají, že destruktor třídy a bude volán, vždy, když bude instance této třídy odstraněna z paměti. Ale už nikde neříkají nic o tom, že se C++ musí automaticky postarat o odstraňovaní jejich prvků. Což tedy znamená, že při vytvoření instance třídy A se zavolá konstruktor, který alokuje paměť pro vnořenou instanci my_Object typu X. Při odstranění třídy A je sice zaručeno, že se musí zavolá její destruktor, ale už se nebude automaticky starat o proměnou my_Object !!! Jinými slovy tohle je už na vaše starost. Pokud nezavoláte v destruktoru operátor delete, aby "uklidil" proměnou my_Object, tak vám zůstane v paměti. Ale nejen to, vy k ní už nemáte (v tomto konkrétním případě) korektní přístup... A přesně toto mám celou dobu na mysli.

Já nevím, to si hrajete se slovíčky? Nebo jste to nepochopil? V C++ lze programovat jako v C, takže nejde o to, zda můžete dělat prasečiny, ale zda máte možnost je nedělat. V uvedeném příkladu to my C++ programátoři spíš píšeme takto:

class A {
std::auto_ptr<x> my_object;
public:
A():my_object(new X) {}
};

Už proto, že to je i exception_safe. Místo auto_ptr by se hodil jiný chytrý ukazatel (viz důvody, proč je auto_ptr občas nevhodné - prostě je hloupé a primitivní), ale na principu se nic nemění.

A právě tady už máte zajištěnou správu paměti a vůbec nemusíte nic dalšího řešit. A tady právě nehrozí, že ve svém programu uděláte memory leak.

Ve své praci jsem rok pracoval na jednom softwarovém balíku v C++. Před vydáním jsem provedl kontrolu na memory leaky. Našel jsem v celé aplikaci 1 a ten byl způsoben zapomenutým uvolňováním nějaké ikony. Tu ikonu spravoval OS, takže v místě, kde k tomu docházelo byl lehce nedodělaný objektový wrapper. Stačilo to místo opravit a memory leaky zmizely.

"Já nevím, to si hrajete se slovíčky? Nebo jste to nepochopil" LOL, výborně. Vraťme se hned na začátek tohoto vlákna ( http://www.root.cz/clanky/nove-ubuntu-ma-vazne-problemy-s-grafikami-intel/nazory/271810/ ). Jistá část mé otázky zněla takto "Jinými slovy mohl by jste mi říci, který standart říká, že C++ má autonomní zprávu paměti a systémových zdrojů? (Jako např. Java? NEPOČÍTÁM inteligentní ukazatele a pod)." Dokonce jsem se tu i zmiňoval o tom, že pomocí inteligentních ukaztelů a pod si zprávu paměti udělat můžete (To ovšem nemusí znamenat, že to všichni musí považovat za řešení pro jádro, a že to musejí asgerechnet použít. A už se vám to líbí nebo ne) Ta otázka byla směřována na vás, jako rekce na váš přihlouplý smích. O odpověď se pokusil Sten. A vy to ještě takhle blbě zakončíte. Tak nevím...

Dokonce jsem se tu i zmiňoval o tom, že pomocí inteligentních ukaztelů a pod si zprávu paměti udělat můžete

Ne můžete, musíte! Jinak si zaděláváte na problémy! Po silnici taky můžete jezdit jak chcete, ale přeci jen je výhodnější dodržovat nějaká pravidla silničního provozu!

(To ovšem nemusí znamenat, že to všichni musí považovat za řešení pro jádro, a že to musejí asgerechnet použít. A už se vám to líbí nebo ne)

Samozřejmě, debilové se najdou i na silnici. Ale ani tady nejste na holičkách. Pokud někdo nějaké prostředky uvolňuje jinak, než pomocí new a delete, máte šanci upravit chytrý ukazatel a přizpůsobit se tomu. Na opačně straně rozhraní, pokud vy poskytujete chytrý ukazatel, můžete také poskytnout jeho raw verzi s tím, že dáte uživateli vašeho kódu i funkc na destrukci toho objektu. Ale ztratíte výhodu automatické správy zdrojů. Ovšem to co se snažím tady celou dobu říct a zřejmě mě nebylo stále pochopeno. C++ není jen jazyk a navazující knihovna STL. Ale taky soubor vzorů (patternů) a mnoho doporučení, jak v C++ programovat. Za velice zdařilou stránku věnující se této problematice považuji tuto: c++ Faq Lite. C programátoři budou prskat, oni si programují, jak jim "zobák narostl". Pak ten kód vypadá jak vypadá!

Takže suma sumárum, v C++ si programujte jak chcete. Ale nesmíte se divit, že budete za prase. A protože přemíra prasat v C/C++ je neudržitelná, nikdo si nelajzne přecházet s jádrem do C++. V tom vidím celý problém. Technické, či výkoností problémy jsou jen virtuální chimérou sektářského popíračtví, že jádro nelze psát v C++. Jde a bez problémů! Dokázal bych si představit celý OS v C++, od zavaděče až po ovladače, správu paměti a GUI. Bohužel nemám čas se tomu věnovat

Ne můžete, musíte! ŘÍKÁ KDO? Když budou všichni skákat ze střech, musím taky? Kdo přinutí programátora aby to použil, přesto, že on to ve svém projektu využívat nechce? Samozřejmě, debilové se najdou i na silnici Aha, takže všichni kdo nesdílíme tento pohled na věc jsme debilové podobní těm na silnicích? Pokud někdo nějaké prostředky uvolňuje jinak, než pomocí new a delete, máte šanci upravit chytrý ukazatel a přizpůsobit se tomu. No a? Od toho přece C++ ručí za volání destruktoru instance, aby správným způsobem ošetřila uvolnění všech prostředků, které alokovala. Na to nepotřebuji ausgerechnet inteligentní ukazatele a podobné techniky. Pokud chcete něco na čtení, tak třeba literatura z moji knihovničky : Moderní programování v C++, Pasti a propasti jazyka C++, a ještě Jádro systému Linux. No, jestli mě někdo považuje za prase jen proto že, nesouhlasím s jeho názorem, to už je mi celkem putna. Koneckonců už jsem vyděl spoustu návodů jak napsat správně program. Správně napsaný program jsem však ještě neviděl (Není to z mé hlavy, ale dokanale to vystihuje myšlenku ;) ) Jak už jsem jednou řekl, já osobně Linux kernel v C++ nechci. Jakmile se jednou k něčemu takovému uchýlíme, tak můžeme Linux rovnou zahodit a koupit si Widle. Asi tak.

Ano, po tom co píšete Vás považuju za prase. Howg. Máte pravdu, nemusíte... Ještě že nepíšete nějaké životně důležité aplikace!

LOL! Člověče vy se mi snad zdáte! :D Měl by jste vidět jak mi ten váš příspěvek trhá žíly :)

Reagovat netřeba ;)

Je otázkou proč psát kernel v C++. Výhod je minimum. Naopak kernel v C# (Singularity) nebo Javě může přinést výhod velkou hromadu.

Už asi vidím váš problém: Ondra doporučoval se vyhnout statickým proměnným (s tím bych i souhlasil), ale to nejsou proměnné na zásobníku. Na zásobníku jsou lokální (automatické) proměnné.

Samozřejmě. RAII také říká, že new máte volat v konstruktoru (nebo těsně před ním u chytrých ukazatelů) a delete v destruktoru, případně při nějaké realokaci s tím, že se provede delete v destruktoru. Jenže jsou prasata, co RAII nedodužují a volají new i delete kdesi uvnitř funkcí a pak to leakuje (např. pokud zapomenou ošetřit to, že tam může vyletět výjimka).

ano, přesnější název by byl "globální proměnné", omlouvám se pokud to nebylo pochopitelné. Opravdu globální proměnné do objektového návrhu nepatří a pokud už je nějak potřebuju, tak formou nějakého singletonu. V krajním příapadě se i ze singletonu snadno udělá obyčejný objekt, zatímo od tradiční povahy globální proměnné těžko.

Zásobník je mocný! :-)

Me tenhle pohled na vec tedy pripada pekne prasteny. Globalni promenne ne, singleton ano. Jaky je v tom rozdil?

To co totiz vetsinou potrebujete je oddelit nejakou cast globalnich promennych do objektu. A pak vam fakt, ze jsou v singletonu, nepomuze.

No je vidět, že vysvětlovat je třeba neustále.

Valná většina aplikací má singleton CApplication. V tom drží kontext aplikace, který by se jinak držel v globálních proměnných. Jakou to má výhodu? Vyrobím nový CApplication a mohu jej použít jako objekt a mám dvě aplikace v jedné! Tohle strategické rozhodnutí může přijít ze dne na den a neznamená to, že musí předělat celou aplikaci....

Spousta funkcí například používá logovací objekt z bonzování své činnosti. Logovací objekt je singleton. Jednou nastala potřeba logy přesměrovat. Jak to udělat? Jednoduše, pro určitou oblast ten singleton na chvíli vyměním za jiný!

Podívejte se třeba na řešení GC v C++. Nejde mi ani o vlastní princip, ale o způsob, jak to udělat, abych nemusel při alokaci sebou tahat ukazatel na instanci vlastní GC. Samotný způsob nabízí víc řešení na problém "co když budu chtít víc GC instancí v rámci jedné aplikace?".

http://bredy.novacisko.cz/?Garbage-collector-v-C-Popis-API-trid-kolekce-LightSpeed-GC/241

Výhoda singletonu je většinou i v tom, že vzniká až při prvním použití. Tedy odpadá komplikovaná inicializace během startu aplikace. A běda, pokud při inicializaci vyletí výjimka!!! Pokud singleton vzniká při prvním použití, výjimka se dá už celkem solidně zpracovat.

Ad Ondra) Ok...

ad Uklid)
Přesně, o tohle mi šlo, když jsem psal, že C++ za Vás úklid neudělá. Ten si programátor musí udělat sám. C++ pouze Vám pouze nabídne prostředky a možnosti, jak se postarat, aby byl uklid vždy a řádně proveden (i při výjímce). RAII, nebo inteligentní ukazatele jsou dle mého pohledu jedněmi z nich. :)

Inteligentní ukazatele jsou jedním ze způsobů RAII. Ano, C++ za vás neuklidí, protože neví vztahy ve vašich datech (dobří programátoři se zajímají o data, ne o kód, jak prohlásil Linus). Java nebo Python se ty vztahy snaží odhadovat, ale ne vždy jim to vyjde (celkem snadno se tam dá - nebo alespoň dal, když jsem to zkoušel - udělat leak, tzn. taky si musíte dávat pozor, co děláte) a na druhou stranu někdy trvá, než se garbage collector pustí do uklízení a uvolní to, co se má uvolnit co nejrychleji (třeba zámek na mutexu).

- Navíc paměť vždycky nakonec přiděluje jádro, takže redifinicí new by jste žádnou novou výhodu nedostal.

Příklad vytvořený podle popisu man pages:

void *operator new(size_t sz, int flags) {
   return kmalloc(sz,flags);
}
void operator delete(void *ptr, int flags) {
   return kfree(ptr);
}
void operator delete(void *ptr) {
   return kfree(ptr);
}

{
  Object *x = new(GFP_KERNEL) Object(...);
  ...
  ...
  delete x;
}

No a co to mění? Tahle verze new stejně volá interně kmalloc( ). Takže mimo toho, že budu místo klasických jaderných funkci kmalloc() a kfree() volat new a delete a mám ještě abstrakci navíc (což v tomto případě znamená i volání funkcí navíc). Mimo to přetížit to potom mohu defacto kdekoliv. jediné snad, že se vyhnu přímému volání operátoru sizeof( ). Jenže to se stejně udělat musí (a nebo určit velikost požadované paměti explicitně). Nevidím v tom moc praktický účel.

což v tomto případě znamená i volání funkcí navíc

Ale kdepak, tyhle funkce kompilátor inlineuje

Nevidím v tom moc praktický účel.

STl kontejnery, Boost, polymorfní ukazatele... Ono je toho poměrně dost, co ty operátory využije a může se i v jádře hodit.

"Ale kdepak, tyhle funkce kompilátor inlineuje"
To je fakt, neuvědomil jsem si to.

"STl kontejnery, Boost, polymorfní ukazatele... Ono je toho poměrně dost, co ty operátory využije a může se i v jádře hodit."
Ano, nemám nic proti používání operátorů new a delete kdekoliv v úrovni nad jádrem. Možná i v interní IMPLEMENTACI samotných jaderných modulů - rozhodne-li se tak jeho autor, ale rvát to přímo do core jádra bych opravdu neviděl jako naději pro budoucnost...

"STL kontejnery, Boost" --- pak zapomente na to, ze tyto datove struktury pouzijete z preruseni nebo z ovladacu provadejicich operace s diskem (operace s temi strukturami, napr. pridani prvku do stromu, do seznamu, do pole, alokuje pamet a v preruseni nikdo spolehlivou alokaci pameti nezajisti --- v ovladacich disku se to taky nesmi, protoze prave ovladac disku se pouziva ke swapovani a k uvolnovani pameti).

Takze nakonec skoncite tak, ze tam budete mit dve implementace datovych struktur, jednu pomoci STL pouzivat na miste, kde se smi alokovat pamet, a druhou bez STL pouzivat na miste, kde se to nesmi. Neni to o nic jednodussi nez mit jen jednu implementaci datovych struktur, ktera je v C a pamet nealokuje.

A o tom, že si můžete nechat šablonou vyrobit dvě různé varianty pro dva různé alokátory jste věděl? Je samozřejmě možné napsat alokátor, který pozná, kdy je volán (jestli v přerušení, nebo normálně). A samozřejmě je také možné mít určitou paměť předalokovanou a alokátor napsat tak, aby alokoval v téhle paměti bez nutnosti volat nějaký kmalloc. To všechno v STL jde. Jen si to chce nastudovat a ne krafat nesmysly, kterým nerozumíš.

A? A v tom vidíš problém?

Nehledě na to, že new se dá přetížit libovolným množtvím dalších parametrů

new(param1, param2, param3,....) Objekt;

Oni ti návrháři C++ nebyli blbý.

Kdyz se teda zeptam, kolik pameti sezere strom obsahujici max. 100 polozek, da se to z toho STL nejak dostat? 100*velikost objektu to asi nebude, protoze ty pointery mezi objekty taky neco sezerou.

To záleží na implementaci toho stromu. Může sežrat 100 × velikost objektu, pokud bude kopírovací; pokud bude používat ukazatele nad Rb stromy a objekty alokovat bokem, tak 100 × velikost objektu + (∑_i=0^{⌈log(100)⌉}2ⁱ) × velikost pointeru (což není problém nechat spočítat při překladu nějakou šablonou). Stejně jako kdyby ten strom někdo napsal v C.

Anebo jednoduše někde na začátku, kde můžete alokovat, řeknete tree.reserve(100) a máte hotovo.

Treba by se muselo zajistit, ze v ovladacich na mnoha mistech neni mozno alokovat pamet. Takze na standardni C++ knihovny (retezce, datove struktury...) muzeme zapomenout, nebot ty si alokuji pamet kdy se jim zlibi a programator nad tim nema zadnou kontrolu.

BTW. jednou jsem se C++ programatora ptal, jak by udelal, ze jeden objekt patri do nekolika dvojite-slinkovanych seznamu. Nedokazal to (bez toho, aniz by alokoval dalsi pomocne struktury, ktere do tech seznamu bude ukladat).

A v C to jde pomoci vhodny maker. (no, v C++ by to slo taky, kdybychom se na seznamy pomoci standardni knihovny vykaslali a programovali si v nem jako v C, ale pak je otazka, proc vubec C++ pouzivat).

Hezký. Doufám, že ten programátor nebyla tvoje přítelkyně :-D, nebo ještě lépe tchýně.

Samozřejmě to co píšeš není v C++ problém. Dokonce jsem schopen i jednoduše uhlídat kolika těm seznamům patří a kdy už nepatří nikomu a okamžitě jej uvolnit.

Jak jsem psal výše, v STL můžete libovolně implementovat vlastní alokátory, které alokují tehdy, kdy ty chceš. Takže zase kecáš.

Tak ukaz :-)

Cilem je pridat objekt naprikad do tri ruznych dvojite-slinkovanych seznamu, s zadnym pridanim se nesmi alokovat pamet, moznost prochazet vsechny objekty v danem seznamu, idealne by to melo byt stejne efektivni jako include/linux/list.h Linuxu.

(a taky predpokladam, ze neudelas s/struct list_head/class list_head/ a nechas tam puvodni kod :)

std::list<boost::shared_ptr<object> > l1,l2,l3;

Případně

std::list<shared_ptr<object>, MujAlokator > l1,l2,l3;
(a další alokaci prvků kontejneru list si vyřeší v MujAlokator sám, třeba alokací v nějakém již staticky předalokovaným polem)

Ale to vymýšlím z fleku. Dalo by se to napsat i na míru, záleží jak moc lpíš na optimalizaci verzus univerzálnosti. Základem je shared_ptr, který si samozřejmě zajistí hlídání vlastnictví objektu (třeba čítačem).

O problematice sdílení zdrojů obecně jsem napsal na svůj blog jeden článek, který řeší sdílení ještě jinak.

http://bredy.novacisko.cz/?Jak-sdilet-prostredky-resources-v-C-/224

A pritelkyni nemam, protoze mam poruchu osobnosti, jsem psychopat.

Jadra nejsou binarne kompatibilni kvuli jednotlivym volbam. Zapnete SMP pri kompilaci --- z prazdnych spinlocku se stanou neprazdne 4-bytove hodnoty, posunou se polozky ve strukturach, a offsety v ovladaci a jadre nesouhlasi. Nejsou kompatibilni ani na urovni zdrojovych kodu (coz je horsi), proste programatori Linuxu urcili, ze budou rozhrani mezi zastmi jadra neustale menit, aby byla "lepsi". Taky se mi to nelibi, ale holt to tak rozhodli.

To s tim C++ asi nemyslite vazne, v C++ napsat binarne-kompatibilni kod je mnohem tezsi nez v C. Autori C++ s dynamickym linkovanim nepocitali vubec.

priklad:
knihovna.h: class c { int a, b, c; public: c(); ... }
program.c: void funkce() { c trida; ... }

... kdyz do tridy za to a,b,c nejakou dalsi polozku pridate a program dynamicky slinkujete (bez kompilace) s novou verzi tridy, tak vam znici zasobnik a spadne.

Já chtěl binární kompatibilitu aspoň na úrovni mezi jednotlivými updaty, takže tvoje námitka nahořé padá, protože je úplně mimo.

V c++ se binární kompatibilita řeší pomocí interface. Každý vlastník interface si spravuje své implementační objekty, které neprezentuje vně interface, takže uživatel interface nepotřebuje znát jejich strukturu. Stačí mu, když volá příslušné funkce.

Při rozšiřování interface se postupuje buď tak, že se rozšiřuje "dolů" (funkce se přidávají na konec), ale tohle je nestandadní řešení. Standardnější řešení je každé rozhraní dopředu obohatit o funkci umožňujíc získat rozhraní novější verze (které nový ovladač dokáže poznat).

Nastuduj si třeba COM+. Tam mají kompatibilitu vyřešenou podobně. Třeba pomocí funkce QueryInterface se lze doptávat na různé verze téhož rozhraní.

> Zatímco nekompatibilita mezi moduly pro různé verze jádra je dána jejich přímou vazbou na herdware.

Ne, to neni pravda. Nekompatibilita je tu proto, ze neni explicitni rozhrani mezi driverem a zbytem systemu. Oproti tomu Novacisko nema pravdu v tom, ze by takove rozhrani nezpomalovalo - uz treba jen nemoznost inlinovat funkce ci pristupovat primo k polozkam struktur by zpomalovala. Ale hlavni duvod, proc to explicitni rozhrani neexistuje, je to, ze o nej vetsina jadernych vyvojaru nestoji, protoze az na par okrajovych pripadu jsou vsechny dulezite drivery soucasti zdrojaku jadra a prekladaji se spolecne s jadrem. Takze by to bylo spousta prace a minimalni prinos.

Pokud používáte jen definované interfacy, a máte funkcionalitu vhodně rozdělenou do modulů, tak to není problém.

Většina vývojářů hodně moc stojí o zdrojáky veškerých driverů, takže dělají maximum proto, aby vývojářům i uživatelům znepříjemnili psaní modulů/driverů mimo zdrojáky kernelu. Dokonce neváhají jít tak daleko, že označují drivery pro Linux za dílo odvozené od kernelu.

To je spolu nějak v rozporu? Pokud vím, tak vývojáři jádra vedli na téma ABI vášnivé diskuze, a výsledkem bylo odmítnutí ABI právě z politických důvodů. Články jsou jistě k dohledání i tady na rootu.

Souhlasíme či nesouhlasíme přece v závislosti na faktech a argumentech. S kým člověk souhlasí, to je nepodstatné. Ale vašemu pocitu rozumím. Jednou jsem četl něco od Hulána, a také jsem s ním zrovna souhlasil ;)

Drivery neobsahují části kernelu. Nejvýše volají některé funkce kernelu, a nabízejí interface volaný kernelem.

Ty údajné důvody pro odmítnutí stabilního ABI jsou směšné. Ve skutečnosti je za tím chaotický návrh, a snaha protlačit otevřené ovladače házením klacků pod nohy každému, kdo by chtěl jít jinou cestou. Pro uživatele to znamená velkou řadu komplikací, ale proč nepoložit uživatele na oltář otevřeného kódu.

Jak podle vás reaguje nebo nereaguje většina vývojářů kernelu, to je celkem nezajímavé.

Pobaví to "pod GPL nebo za peníze". Prakticky celý kernel Linuxu je pod GPL, ale napsaný za peníze. Viz Linux Foundation.

Drivery nemusí obsahovat žádný kód kernelu. Samozřejmě pokud použijete cut and paste kus kódu z jiného driveru, je to jiná. Jenže vývojáři jádra tvrdí, že podle nich KAŽDÝ kernelový modul pro Linux musí být uvolněn pod GPL.

*Ex a Ex* funkce prostě rozšiřují API. To přece není nic špatného. Nebo byste chtěl místo toho rozbít zpětnou kompatibilitu? Já zapomněl - už jste ukázal, že takový koncept je vám cizí.

Rozdíly v chování starších API oproti starším verzím Windows - několik jich opravdu existuje. Najdete jich ale alespoň 10? Uvědomte si, že na Windows Vista dnes můžete spustit programy psané pro Windows 2.0, Windows 3.x, Windows 95 a Windows NT 3.1. Taková zpětná kompatibilita nemá na Linuxu obdobu ani náhodou. Každá aplikace se muís balit pro každou verzi každého distra. A pro novou verzi distra znovu kompilovat, znovu balit...

Za práci se platí. To fakt nevíte?

Drivery nemusí obsahovat žádný kód kernelu. Samozřejmě pokud použijete cut and paste kus kódu z jiného driveru, je to jiná. Jenže vývojáři jádra tvrdí, že podle nich KAŽDÝ kernelový modul pro Linux musí být uvolněn pod GPL.

To někteří fanatici skutečně tvrdí, ale někteří fanatici tvrdí, že Windows jsou vzor zpětné kompatibility :) Většina nemá s proprietárními ovladači problémy, pokud opravdu nejsou odvozené dílo.

*Ex a Ex* funkce prostě rozšiřují API. To přece není nic špatného. Nebo byste chtěl místo toho rozbít zpětnou kompatibilitu? Já zapomněl - už jste ukázal, že takový koncept je vám cizí.

Zpětná kompatibilita uvnitř jádra mě opravdu moc netrápí a argumenty proti mi připadají vhodné (samozřejmě jiná je situace u Windows, kde MS hodil tvorbu ovladačů jen na výrobce). Zpětná kompatibilita v user space je zachovávána.

Taková zpětná kompatibilita nemá na Linuxu obdobu ani náhodou. Každá aplikace se muís balit pro každou verzi každého distra. A pro novou verzi distra znovu kompilovat, znovu balit...

To jste asi nepochopil, jak funguje zpětná kompatibilita v Linuxu. Linux je založen na POSIX a tam je explicitně uvedeno, že kompatibilita je zaručena jen pro zdrojové kódy, ze kterých se vybuildí aplikace pro příslušný systém a hardware, což je to výhodně, můžete ten program jednou napsat a přeložit na deset různých platforem a může být lépe optimalizován při překladu pro určený systém nebo přímo hardwarovou konfiguraci (což je extrémně důležité pro embedded systémy).

Za práci se platí. To fakt nevíte?

Vám někdo platí i za koníčky?

Co si pamatuju jen tak z hlavy a stalo se to me osobe:
Win98 - Win XP spousta her pro 98 v nem nesla spustit. Prechod na Visty byl o neco mene bolestivy, jenze predevsim proto, ze pro systemy 98 a mladsi jsou vsechno emulovana prostredi..
Takhle rozchodim na linuxu i win aplikace (wine) bez kompilace. Neco takoveho pro win?

Spousta aplikaci pro Win (dokonce i ty od MS) si sebou radeji ty knihovny tahaji s instalatorem, pak neni problem rozchodit spoustu veci, kdyz ta aplikace ma skoro vsechny knihovny u sebe.

Myslim ze jste zaslepen svym ruzovym videnim MS. Linux neni dokonaly, to priznavam, ale Win maji spoustu jinych problemu, na ktere pod linuxem nenarazite a naopak.
Ale ze byste musel vypoustet takovehle 3.14-coviny. Chcete rict ze jste schopen rozchodit nativne(bez emulace) aplikaci ze 3.11 na Vistach (nedej boze na Win 7)

Ano za praci se plati. Ale to neznamena, ze musim platit za kazdou *** kterou mam na svem PC (nebo to krast, coz je mozna jeste o neco horsi).

Chcete mi tvrdit, že díky volání funkce jádra jde o odvozené dílo? Hlavičky nepotřebujete (resp. nemusí být originální). Navíc hlavičky spadají v českém právu pod zajištění interoperability, a tím do autorského práva nezasahujete (v řadě zemí to bude jistě obdobné).

Ale houby, pod NDA nejsou zdrojové kódy výrobce, ale specifikace, bohužel často nekompletní a neaktuální. Zase hlášky bez praktických zkušeností, jako vždy.

Ještě jedna věc. Greg Kroah-Hartman jako příklad uvádí, že USB bylo v Linuxu 3x přepracováno. A já se ptám: proboha proč? Copak to neumíte napsat jednou a slušně? Naplánovat, případně zkusit alternativy, a pak vydat hotovou věc? Ne, ono je potřeba něco rychle splácat, vydat, zjistit že je to na nic, rychle přeplácat a znovu vydat, a opakovat znovu.

Správně navrhnutý interface je třeba měnit velmi zřídka. A když dojde po X letech na změnu interface driverů USB zařízení, není to až taková katastrofa. Katastrofa ale je, když je odfláknutý design, nepřemýšlí se, a vydávají se neotestované věci. Nakonec problémy Ubuntu s grafikami Intel (a nVidia, a ATI) jsou ze stejné kategorie.

Pak se ale nedivte tomu "rozšíření" Linuxu. 1% po 18 letech je vážně málo, a když vývojáři kašlou na uživatele, nebude to lepší.

"Ale hlavni duvod, proc to explicitni rozhrani neexistuje, je to, ze o nej vetsina jadernych vyvojaru nestoji, protoze az na par okrajovych pripadu jsou vsechny dulezite drivery soucasti zdrojaku jadra a prekladaji se spolecne s jadrem. Takze by to bylo spousta prace a minimalni prinos."

Predstavme si, ze pokud uzivatel upgraduje jeden driver, tak s pravdepodobnosti 99% dostane funkcni system a se zbyvajici pravdepodobnosti 1% mu ta nova verze zpusobi novy bug. 99% pravdepodobnost je dobra.

Pokud upgradujeme dva drivery, dostaneme funkcni system uz jen s 98%. Pokud tri, tak s 97%. Pokud upgradujeme 20 driveru, bude system fungovat uz jen s 81% pravdepodobnosti.

A to neexistujici rozhrani prave nuti uzivatele, aby upgradoval bud vsechny jaderne ovladace nebo zadne :-(

Pokud je uzivatel BFU a neumi si jadro zkompilovat, pak kvuli novemu ovladaci musi instalovat novou distribuci a prepsat cely userspace, a pak dostane funkcni system s velmi mizivou pravdepodobnosti (0.99^pocet_programu).

Taky se mi to nelibi. A protoze vyvojari nikdy nedokazi to rozhrani mezi ovladaci zakonzervovat, tak ani nikdy nevytvori Linux, kde by vsecka zarizeni fungovala. Porad to bude ve stylu "opravime 3 bugy a pridame 3 dalsi" :-(

Nesmysl. Jádra nejsou kompatibilní i mezi aktualizaci. Během Ubuntu 8.10 se jádro změnilo snad 5x a pokaždé to znamenalo rebuildnout moduly dodané z třetí strany, zejména u vmplayeru to většinou znamenalo jeho reinstall. Vím to, protože jsem vždycky u to prskal.

Jste dobrej teoretik, ale nikdy jste to prakticky nepoužíval.

Samozřejmě. O tom mluvím.

To se mýlíte. Já jsem člověk, který se snaží počítače používat k práci a ke zjednušení života. No vidíte, vy se snažíte a já už to naopak léta dělám. Vy se snažíte s Windows, já toho dávno dosáhl s Linuxem :P

Důvod proč si zanadávat? Mě to naopak přišlo jako samé celkem dobré důvody k nespokojenosti. Mě spíš překvapuje, že řada čtenářů roota obhajuje zmetky a nedodělky. A k tomu ještě většinou obhajují půlroční release cycle, který prakticky vylučuje testování. Výsledem jsou pak tyhle beta verze vydávané za finální verze. Ovšem nedivme se tomu, když beta verze Windows používá zřejmě více lidí, než kolik jich používá "ostrý" Linux (natož konkrétní distro).

Jestli někdo hovoří o tom, že Windows se dají používat až po prvním SP, tak ať se podívá na tenhle článek. Canonical o problému ví už před vydáním, ale kašle na to, a klidně vydá systém, který na velkém procentu počítačů bude běhat velmi špatně (pokud vůbec). Každý release je polotovar, a uživatelé se vlastně účastní permanentního beta programu. Pak je tu ovšem těch zbylých 99% populace, které se nechtějí účastnit beta programu, a chtějí používat počítač produktivně.

Vy nechapete jednu zasadni vec, a to tu, ze toto je dan za nejnovejsi verzi jadra. Windows maji prinejmensim 3-lety (nebo kolika) vyvojovy cyklus, takze jsou (zdanlive) daleko stabilnejsi.

Mozna by vam vic vyhovoval Debian stable nez Ubuntu.

To cemu rikate "modularnost jadra" je stabilni jaderne ABI. A vedla se o tom diskuse, a vetsina vyvojaru to odmitla, protoze opet, Windows maji stabilni ABI za cenu vyssich nakladu na pomalejsi vyvoj.

Ono je to trochu jinak. ABI vývojáři odmítli proto, že chtějí "svobodné drivery". Jinými slovy chtějí házet vývojářům (a uživatelům) klacky pod nohy, a tlačit je tak k zařazení driverů do kódu jádra.

Stabilní ABI není problém. Jen to chce na začátku dobrý návrh. Protože při tvorbě Linuxu žádná návrh hodný toho slova neproběhl (viz link níže), má Linux řadu omezení. Ty se pak jen velmi pomalu a těžko odstraňují. Například navrhnout OS s multithreadingem na začátku je minimální problém. Ovšem dodělávat threading později, to je spousta práce, a výsledek je rozpačitý. Vždyť Linux má použitelný threading (Linuxthreads byla příšernost) až od jádra 2.6.

"Design" Linuxu:
http://groups.google.co.uk/group/comp.os.minix/browse_thread/thread/76536d1fb451ac60/b813d52cbc5a044b

Linux: Student s minimální praxí při psaní terminálového emulátoru nakonec napsal primitivní kernel podle dokumentace starých unixů.
Windows NT: Autoři systému VMS, jedni z nejlepších vývojářů na světě, zúročili léta své praxe, a provedli kvalitní návrh.
Kdo z nich myslíte, že udělal kvalitnější návrh OS?

Samozřejmě. Jak jsem psal: kde je špatný návrh na začátku, stojí pozdější opravy konceptu nepřiměřené úsilí. Proto má Linux použitelný multithreading až od kernelu 2.6, proto má dodnes tragický I/O stack, proto dodnes není kernel preemptivní (resp. ho nikdo nepoužívá kvůli problémům se stabilitou a výkonem), proto má kernel hrozivou latency.

Také by bývalo na začátku daleko snadnější místo X11 zvolit něco generačně novějšího. Představte si, že byste chtěl X11 nahrazovat až dnes. Myslíte že by to bylo snadnější, než kdysi na začátku?

A tohle říká člověk, který se ohrazuje zpětnou kompatibilitou?

Zpětná kompatibilita je jedním z důvodů, proč je třeba dobře plánovat už na začátku. Fakt tohle nevidíte?

jj, zatimco navrh mixovat kod OS a aplikaci je k nezpalaceni, stejne tak nejaka rozumna implementace uzivatelu a prav potreba neni...

ad VMS - jedna vec je navrh, druha vec je konkretni implementace - tu uz Cutler a jeho tym nedelal - takze davat NT a VMS kernel do stejne ligy bych opravdu nedaval

On ve Windows někdo mixuje kód OS a aplikací? A NT že nemají rozumnou implementaci uživatelů a práv? Na rozdíl od Linuxu mají Windows například prakticky všude ACL. Na rozdíl od unixů také už od první verze NT používají rozumnou autorizaci, a ne plain text FTP/telnet, nebo UID/GID jako NFS.

Dave Cutler a jeho bývalí kolegové z Digitalu pracovali samozřejmě i na implementaci. NT kernel je lepší, než kernel VMS? protože byl navržen o dost později. Například správa paměti z VMS by byla na desktopu či malém serveru nepoužitelná.

ad michani kodu os a aplikaci... proc kazdy druhy soft potrebuje po instalaci restart? proc se win adminove boji dat na server cokoliv co neni MS only? Pojem DLL HELL asi vznikl jen tak, ze?

ad uzivatelska prava... ACL je sice pekne ale narazel jsem na to, ze velmi malo aplikaci bylo mozno provozovat pod normalnim uzivatelem, dokonce to zaslo tak daleko, ze ve viste (ktera je prvni verze, kde se s tim neco snazi aspon trochu expost udelat) se tohle prihlaseni pod administratorem emuluje, aby se zajistila kompatibilita.
A to, zee je FTP plaintext souvisi s protokolem FTP a ne s OS to byste moh vedet.

Jinak co se tyka historie NT Kernelu - myslim, ze netreba komentare:
-- In August 1988, Bill Gates hired Cutler. One of Cutler's conditions for moving to Microsoft was that he could bring around 20 former Digital employees with him, including several Prism hardware engineers.
-- From 1990 to NT's public release in August 1993, Cutler's team was in a mad dash to complete NT, and the project grew to involve more than 200 engineers and testers. Gates decided that compatibility with the 16-bit Windows API and the ability to run Windows 3.x applications unmodified were NT's paramount goals, in addition to support for portions of the DOS, OS/2, and POSIX APIs.

Jak cokoliv z toho co píšete souvisí s mícháním kódu OS a aplikací?

Ve Windows nemůžete přepsat soubory, které jsou v užívání. Resp. můžete to vynutit, ale on to není dobrý nápad. Může to totiž vést k závažným problémům. Na Linuxu to ale nikoho netrápí. Proto ve Windows musíte po modifikaci sdílených komponent restartovat, kdežto v Linuxu můžete přijít k problému.

Na server si můžete dát prakticky cokoliv, je to na vás. Čeho se kdo bojí, to je trochu mimo diskuzi.

Pojem DLL hell vznikl díky nekompatibilitám knihoven. Obecně nová verze té samé knihovny musí mít stejné funkce, jako stará verze. Pokud má nová verze bug, může se to projevit ve staré aplikaci.

Aplikace je obecně možné provozovat pod normálním uživatelem. Výjimkou jsou aplikace psané prasaty. Například autor Total Commanderu "inteligentně" psal konfigurák s uživatelským nastavením do adresáře, kde měl binárku. Samozřejmě neodděloval nastavení pro různé uživatele, protože o oddělení uživatelů zřejmě nikdy neslyšel. Ve Windows 9x mu to fungovalo, ve Windows NT to pod adminem šlo, tak co řešit. Bohužel MS nemůže autorovi TC zlomit malíček, aby si zapamatoval, že takové prasárny jsou fuj. Vista tohle u *starých* aplikací řeší přesměrováním zápisů do vyhrazené části profilu uživatele, aby aplikace fungovala i bez práv admina. Až tak daleko došla snaha MS o uchování zpětné kompatibility.

Plain text u FTP a telnetu souvisí s protokolem. Prakticky všechny unixy ty protokoly používaly ještě v době vydání Windows NT.

Co se týká historie NT kernelu, tak jste to zjevně komentoval. Ano, NT navrhovali profíci. Vždyť je ten návrh také výrazně lepší, než návrh (i realizce) kernelu Linuxu.

Nicméně soubor v adresáři smažete. A k čemu to vede? Aplikace otevře soubor /dir/file, a začne z něj číst threadem A. Uživatel smaže /dir/file, a na místo umístí úplně jiný soubor toho samého jména. Aplikace threadem B otevře soubor /dir/file, a začne do něj zapisovat data, které čte threadem A. Hm, všechno je v háji, data zničená...

Podobně pokud aktualizujete knihovu, ale necháte starou verzi zavedenou v paměti, tak máte dva problémy.
1. Stará verze knihovny je pořád zavedená, a pokud měla třeba bezpečnostní problém, tak máte pořád děravý systém.
2. Pokud zavedete najednou novou i starou verzi knihovny, může to vést k závažným problémům. Představte si třeba DB engine, který pomocí knihovny přistupuje k databázovým souborům. Spustí nový worker proces (na unixech tradiční věc), ten zavede novou knihovnu, a průšvih je na světě.

Tohle lze dnes řešit jediným způsobem. Restartovat všechny části systému, kterých se změny souborů dotkly. Ve Windows navíc při instalaci můžete běžící aplikaci říci, že má uložit svůj stav (u Office otevřené soubory, stav oken apod), a po restartu aplikace či celého stroje se má obnovit v posledním stavu.

Od Windows tuším 2000 lze tento problém řešit přejmenováním souboru s knihovnou a pak normálně zápis nové verze. Ale způsobuje to problémy podobně jako na linuxu, tedy, že pak je jeden proces schopen mít v paměti zavedené obě verze knihoven.

Našetěstí, Windows v tomto směru funguje trošku jinak než Linux, pro něj jsou DLLka trošku jako aplikace, akorát sdílí adresový prostor a vlákna. Když takto Windows natáhnou novou verzi knihovny, je to pro aplikaci prostě další knihovna. A je na ní, jak se s ní vypořádá.

To co v linuxu hrozí je po přeforkování se v novém procesu mápnou stejné binárky jako v původním procesu. Jenže podle aktualizovaných dat na disku. A pokud je tam nový verze knihovny, tak ma zpravidla funkce na jiných adresách a průšvich je to obrovský. Vlastní zkušenost.

Zamykání mapovaných souborů ve Windows má podle mne dneska zejména význam ochrany knihoven proti náhodnému smazání.

"every task has a 64Mb segment for code & data - max 64 tasks in 4Gb. Anybody who needs more than 64Mb/task - tough cookies"

Heh :) To treba na OS/2 ten limit udelali 512MB na proces, ale bohuzel kvuli kompatibilite tam zustal dodnes :-( [udelali novy parametr syscallu, ktery umi alokovat nad hranici 512MB, ale vetsina programu ho stejne nepouziva]

S prepinanim klavesnice jsem nemel problem na linuxu nikdy, zato na windows me vytaci, ze je klavesnice pro kazdou aplikaci zvlast, pokud sednu k serveru od zakaznika do par minut ma anglickou jako defaultni.
jinak podle klavesnice poznas odbornika, firma, ktera zamestnava odborniky ma vzdy zapnutou anglickou, firma, kde je to tak nejak divne ma temer vzdy ceskou a nekdy i ceske windows ....

Jinak ja pouzivam Linux uz hodne dlouho a no problem, pouzival jsem Unixy, MacOS, OS/2 a windows hodnotim jako spatny OS, delalo se mi s nim nejhure ze vsech.

Na linuxu me stve jenom to, ze se snazi lezt do pr* windows uzivatelum a libi se mi na nem to, ze si muzu vzdy zvolit alternativu, ktera mi vyhovuje, necham lidi at si hraji s KDE/Gnome, ale ja zustanu i IceWM a RAM/CPU si radeji necham na aplikace.

Jinak to ze windows jsou dobry OS je usmevne, si vzpominam, ze jsem si rikal, ze neco sestriham z kamery a ze to udelam rychle bud v AdobePremiere, nebo Pinnacle, rekl jsem si ze premiere je profi program a tak jsem z DV kamery zgraboval video jako RAW. .... OUHA
Ac jsem donutil windows to prehravat, ac jsem dodal DV kodeky a vse potrebne, bud to ani neotevrelo, nebo to jen prehravalo, ale needitovalo, dokonce na tom i padaly windows, testoval jsem i virtual dub.

Pak jsem to dal do linux, zjistil jsem, ze Avidemux2 umi i strihat v prostred videa a tak jsem to dal tam, video se sice nazetlo, ale synchr. zvuku a videa nesla, pouzil jsem tedy mencoder, prevedl jsem pouze do AVI kontejneru, tedy bezztratove a sestrihal v Avidemux2
Tahle historka me uz definitivne vyvedla z omylu, ze je ve windows neco jednodussi a hlavne ze neco funguje, uz davo jsem prisel nato, ze je lepsi fungujici program s manualem (a to klidne i textovy), nez nefungujici, ktery ho nepotrebuje. Dale uz chapu, pros profi filmari pouzivaji IRIX, Linux a jine unixy, nez windows, taky jim z kamery leze RAW, tam doknce ne RAW video (bez kontejneru) ale rovnou RAW snimky, ze kterych je treba video nasledne udelat ...

To znamená, že čím déle programuju, tím jsem horší programátor. Začínal jsem s anglickou klávesnici, pak jsem přešel na českou qwerty a nakonec na českou qwertz. Nebavilo mě se stále dokola rozčilovat, že všechny počítače pokolo mají špatně nastavenou klávesnici, tak jsem se naučil používat pravý alt.

Je probém si přepnout defaultní klávesnici? Tedy pod Windows. Pod Linuxem se z toho může celkem lehko stát problém.

> Suhlasim, ze narodna klavesnica je jedna z najotravnejsich a najbugovejsich oblasti Linuxu, odjakziva

Nemyslim. Ceskou klavesnici jsem si nastavil jednou, pred asi 8 lety, a od te doby jsem na ni prakticky nesahl a funguje spolehlive (akorat v pripade tech nekolika reinstalaci (kvuli vymene disku ci celeho pocitace) jsem pretahl konfigurak).

Klávesnici doma na L klávesnici nepřepínám. Mám mapu cz a anglický a speciální znaky píšu přes AltGr. A v práci na W2k nadávám, protože nezanedbatelná část zažitých zkratek tam prostě nefunguje. Takže čas od času prostě musím přepnout na EN. To se pak ale zase rozčiluju s rozložením QWERTY - pro člověka který se všemi deseti naučil ve škole na klasickém psacím stroji to je dost nepříjemná věc.

Další drobnost, která mi na W chybí, je podpora třítlačítkové myši: označím text a bez čehokoliv dalšího ho prostředním tlačítkem vložím kam potřebuju. Je to totální prkotina, ale velmi návyková.

Jediné, co mi na L chybí, je podpora "výrobci" proprietárního SW. Ano, pokud mám možnost volby, dám přednost SW otevřenému, ale na prvním místě pro mě je funkčnost. Uvedu příklad: trochu fotím. Na W bych měl na výběr z téměř nepřeberného množství aplikací na zpracování RAWů i finální úpravy a adjustaci. Na L mám jenom Gimp s UFRaw pluginem (samostatné RAW editory mě moc netáhnou - sice se mi líbí unixová filosofie aby jeden program dělal jednu věc pořádně a dobře spolupracoval s ostatními, ale na fotky mám raději něco all-in-one). To jsou sice výborný nástroje, ale pro moje potřeby to je jako jít s kanónem na vrabce. Stačí mi vyvolání RAWu, srovnání horizontu, křivky/úrovně, mixér kanálů, ořez, resize, unsharp-mask. Zapoměl jsem na něco? Asi ne.

Dobrý pokus o flame, jen je potřeba opsat z Internetu některé sofistikované problémy na rozproudení debaty, nebo rozhoření flamewaru.
Ne každý výcuc informací který opíšete na Internetu od nějakého studenta který si pořídil Acera, je založen na objektivních problémech. Bohužel ten bodový výcuc obsahuje pár základních neznalostí a technických nepřesností.


Takže znovu a lépe, někdo se té pohádky snad chytí.

Mýlíte se. Smůlou je, že jsem tenhle článek objevil při povyšování NB na verzi 9.02. Bohužel už se to nedalo zvrátit a nyní vidím, že jsem udělal blbost. Odsoudil jsem tak svůj NB na kompletní reinstalaci (čili celý den v pr....)

Škoda že to nevyšlo dýl. Povýšení na 9.02 mi update manager nabízí už čtrnáct dní, a říkal jsem si, že chvíli počkám.

Jo a jinak, problém s grafikou na intelu potvrzuji. Ale to naštěstí až tak nebolí, compiz jsem stejně měl na NB vypnutý, protože neuměl dvoumonitorový režim.

"Tohle není ovladačem, to je nastavením. Když to nenastavíš správně, jak to může umět? nenastavuješ to někde jinde, než předpokládá instalace?"

Díváte se na to špatně. Jako uživatel klikám na indikátoru klávesnice, kde se mi nabízí určitý dialog s volbami. Nechtějte po mne, abych to dělal v konzoli!

"Jen na okraj, pokud cheš zažít WoW večer, pokud se vyladit vlastní klávesnici pod widows."

Proč bych si měl hrát s klávesnicí. Potřebuju jen přepínat mezi českou a US. Ve Windows to mám za 10 sekund a funguje to (od W95)

"Proč se nezeptáš výrobců? Intel vytváří ovladače i pro linux"
iwl3945 - ta značka má na internetu svou pověst :-D (nemusím řikat jakou)

"dpkg nemá grafickou verzi"
Kdo nepochopil, že se jedná o synaptickovou nadstavbu má IQ 90. Nebo neví o čem mluví.

"Jádro nevyžaduje nové verze ovladačů, jádro linuxu obsahuje nové verze ovladačů, pokud je někdo napsal."

Ale jděte. Proč tedy VmPlayer neustále dokola překládá nové ovladače pro každou novou aktualizaci jádra? Proč po poslední aktualizaci jádra mi modul pro iwl3945 z předchozí verze nejde nahrát s chybou "Invalid Kernel Module"

Zkuste někdy zcela vážně svůj počítač používat k práci. Hrát hry je větší zábava, než si hrát se systémem.

Nevšim jsem si, že by se windows ovladače překládaly při aktualizaci kdejakého servicepacku.

Mě jde o binární kompatibilitu, která v Linuxu chybí a je to obrovský handicap. Když už je problém udržet kompatibilitu (binární) mezi distribicemi a platformami, tak by bylo možné jí udržet v rámci jedné platformy a jedné distribuce a jednoho jádra.

Ve Windows zapnu wifi čudlíkem na NB. Tohle naštěstí už začíná fungovat i v Ubuntu, jen ve verzi 8.10 to často znamenalo /etc/init.d/NetworkManager restart, protože po zapnutí už nebyl schopen wifinu najít.