Portál AbcLinuxu, 1. května 2025 03:28
Vyšla první RC verze chystaného KDE SC 4.4. Oficiální oznámení o vydání hovoří hlavně o změnách v Nepomuku, Plasmě a přidání nových aplikací Cantor a Rocs a autorizačním frameworku KAuth. Pokud vás zajímají chystané vlastnosti nové řady, prohlížejte stručný a vyčerpávající seznam změn. V současné verzi plánu je ještě vydání druhé RC verze, finální KDE SC 4.4 by mělo být vydáno 9. února. Vizte seriál o KDE 4.4.
Tiskni
Sdílej:
8.1.2010 17:00
belisarivs | skóre: 22
| blog: Psychobláboly
9.1.2010 12:32
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
) Omlouvám se, ale nemohl jsem to prostě nechat bez reakce - tak mě ten půvab nechtěného zaujal.
9.1.2010 12:37
LukynZ | skóre: 2
| blog: status_quo
| Ostrava
9.1.2010 15:45
LukynZ | skóre: 2
| blog: status_quo
| Ostrava
, ale jistě uznáte, že to už je vrchol...
10.1.2010 08:28
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
A rozhodně to nebyl problém KDE4. K tomu jsem se ani nedobral.
Toto ma zaujalo, Vam ide synchronizovat E51 a Linux (hocjaky desktop alebo app) ???petris napsal:
Synchronizace kontaktu a kalendare funguje ... v KDE3.5 to jde cele naklikat v KitchenSync.
10.1.2010 08:39
LukynZ | skóre: 2
| blog: status_quo
| Ostrava
10.1.2010 08:43
LukynZ | skóre: 2
| blog: status_quo
| Ostrava
10.1.2010 12:02
LukynZ | skóre: 2
| blog: status_quo
| Ostrava
10.1.2010 09:04
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
9.1.2010 12:35
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
9.1.2010 14:36
Nicky726 | skóre: 56
| blog: Nicky726
9.1.2010 12:39
LukynZ | skóre: 2
| blog: status_quo
| Ostrava
Tak bych rad vedel, cemu rikas stabilni? Pripoj se na NFS a vytahni si sitovy kabel. Pak uvidis stabilni...
Nacteni desktopu (po zadani hesla) z rezimu spanku je pomale pokud neni pripojena sit, ktera byla pripojena, kdyz to das do spanky. XFWM4 to nedela.
Celkove pomale jak lemra. Vyzkousej si Windows 7
Pri kazdem novem vydani milion chyb a jede se od znova.
Naprosto souhlasim s prispevkem vyse. Hold pro kazdeho stabilni znamena neco jineho.
A narážky na vzhled jsou neopodstatněný - není problém dát tam 3.5 vzhled a vypnout ty utilitky!to zní dobře. můžu se zeptat, najdu někde nějaké howto, kterak KDE 4.3 nebo 4.4 vzhledem, chováním, rychlostí apod. co nejvíc přiblžit KDE 3.5.x? díky.
9.1.2010 09:01
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
No ehm ku kvalite programátorov:
Pod pojmom desktop si predstavujem niečo, čo mi nastaví root background (to plasma nerobí), zobrazí wallpaper (ktorý vykresľuje bleskovo). U KDE majú asi inú predstavu o desktope, takže ak mám aj prázdny desktop musí sa to renderovať cez X nezmyslov a ide to pomaly. Ako by k tomu asi pristupovali kvalitní programátori?
Pozrime sa na problém trochu zo strany používateľa KDE 3. Tam boli kraviny na ploche riešené cez samostatný program (superkaramba). Využívalo to pseudotransparentnosť no a tak nejako to dokopy dokonca aj celkom dobre fungovalo. Áno bolo vidieť prekresľovanie pri presune, ale nič strašné.
V súčasnej verzii z neviem akého dôvodu rozhodli, že celá plasma bude ako jediná aplikácia (vrátane panelov) a aby toho nebolo dosť tak to všetko ešte napráskali do QGraphicsScene. Takže teraz pri každej verzii Qt riešia nejaké tie regresie plasmy, ale to je už ich vec.
Takže pozrime sa na to, čo je vlastne plasmoid. Je to akási knižnica alebo skript (preferovanejšie sú skripty), ktorý(á) má vytekajúci text a ikony z tlačidiel. To vytekanie je asi spôsobené tým, že plasma team sa rozhodol klasické Qt widgety (napr. QPushButton, kde som vytekanie nikdy nevidel) znovu implementovať. A pre zjednodušenie zanedbali drobnosti ako je oblasť borderu, marginy ... No ani sa nedivím, že sú jedným z najviacej vyťažených tímov v KDE keď si implementujú vlastné widgety namiesto toho, aby si napísali obyčaný štýl pre Qt widgety, ktorý by čítal SVG.
Takže keď už vieme čo majú byť tie plasmoidy pozrime sa na implementáciu v KDE. Takmer každý plasmoid potrebuje zisťovať nejaké dáta. Či už je to aktuálny čas, alebo počasie používa na to pravdepodobne data engine, čo je zase nejaká knižnica, alebo skript. Uvažujme situáciu, že data engine má nejakú chybu, resp. neošetrenú situáciu (povedzme zle formátované XML z RSS) a pri tejto situácii dôjde k zápisu na zlú adresu v pamäti. No keďže aj engine, aj plasma, aj plasmoidy sú jediná aplikácia všetko sa nám jednoducho zosype.
Klasickým príkladom kvalitných programátorov sú ľudia z googlu. Taký google chrome umožňuje len skriptovanie v javascripte a napriek tomu je každý tab samostatným procesom. Prečo tomu nie je tak u plasmy? Prečo jediný plasmoidy, jediný engine dokáže spôsobiť zamrznutie plasmy? Prečo nemôžem nastaviť individuálne práva na prístup na disk pre plasmoidy, ale každý plasmoid má také práva ako samostatná plasma. Prečo ešte vôbec dovolia niečo takéto zdieľať cez internet keď nie sú vyriešené základné problém s bezpečnosťou?
9.1.2010 13:27
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
No ono sa tam viac menej všetci hrajú na koderov aj architektov. V podstate sa nevylučuje to, aby človek mohol byť kvalitným programátorom a zároveň architektom.
Stabilizácia má podľa mňa zmysel až vtedy keď máme architektúru, ktorá umožní stabilizáciu. Ak máme nejakú zlátaninu, ktorá sa dá zhodiť nekvalitným kódom (plasmoidom) tak tam moc toho moc na stabilizáciu nezostane. Ruku na srdce, kto by bol teraz ochotný používať na desktope systém s kooperatívnym multitaskingom žiadnym poriadnym oddelením procesov (jeden chybný zápis do pamäte - pád systému). Presne takým spôsobom k tomu pristupuje plasma. Jedna chyba - pád desktopu, panelov a občas dokonca zhavaruje aj kded a plasma sa už ani nenaštartuje.
No a skriptované plasmoidy nie sú žiadne riešenie. Videl som už x-krát segfaultnúť interpret javascriptu, videl som už aj pád pythonu (myslím skutočný segfault, nie niečo, čo by sa dalo v programe odchytiť), videl som memory leaky v python bindingoch, videl som aj segfault javy, videl som nespočetné množstvo pretečení, podtečení bufferov vo všeličom čo si hovorilo "bezpečné".
Na to aby tu človek zbadal závažný problém v architektúre nemusí byť žiadnym architektom, stačí len trochu pohnúť rozumom.
9.1.2010 11:54
Milan Lajtoš | skóre: 22
| blog: /blog/babraq
9.1.2010 13:07
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
9.1.2010 15:19
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
No ono je to docela smutné, že kedysi celkom dobré (zďaleka nie dokonalé) prostredie v dôsledku takéhoto vývoja poriadne upadlo. Staršia verzia (KDE 3) sa ešte stále dá používať ale mnoho ľudí už opustilo Linux pretože ich distribúcia KDE 3 proste vyhodila. Väčšinou mám také skúsenosti, že práve tí, ktorí niečo vedia opúšťajú Linux a prechádzajú na iné OS (uvažovať o prechode na iné prostredie nemá pre nich moc zmysel, u gnome nie je isté, či neskončí rovnako ako KDE, minimalistické prostredia si treba poriadne nakonfigurovať a výsledok nie je vždy ono, niečo medzi veľkými DE a minimalistickými tiež nie je zrovna ideálne riešenie).
Ja sa zatiaľ držím Linuxu a nejako to prežijem aj s konzolou a fvwm2, zrovna pohodlné to nie je, ale až budem mať čas tak si snáď doprogramujem nejaké tie drobnosti, ktoré mi chýbajú.
9.1.2010 15:43
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
...(ač já mám třeba vážné výhrady k častým změnám rozhraní, které firmám komplikují dodávání ovladačů)...Ten, čo zmení rozhranie musí zmeniť aj všetky ovládače, ktorých sa tá zmena týka (a pochybujem, že sú tie zmeny až tak časté).
Ak sa niekto rozhodne, že bude dodávať len binárne ovládače tak nemôže očakávať, že niekto len kvôli nemu bude udržiavať spätnú kompatibilitu. Otázne je napr. kto by sa staral o to, aby tie staré rozhrania stále fungovali (ak by ostatné ovládače používali upravené rozhrania).Nechci tu vyvolával nijaký flame, ale nesouhlasím s tím, že jediný způsob pro výrobce driveru, jak se připojovat k linuxu, je mít kus ve zdrojáku a dokompilovat to. Podle mne je to špatná cesta. To není otázka o zpětné kompatibilitě, ale o nestabilitě rozhraní. Proč se současné distribuce nejsou schopny připojit na jeden současný driver (tedy nekteré ano a jiné ne). Jediná možná odpověd že jsou binárně na tom rozhraní různé, ale nechápu proč. Dokážu si lehce představit vývoj rozhraní jako narůstání množiny funkcí na rozhraní s tím, že novější rozhraní znamená nadmožinu funkcí a obě strany se při spojení domluví na maximální množině, kterou mají společnou. A čas od času, ale spíše za delší intervaly bude odříznutí staré nepoužívané nebo nevyhovující funkcionality na tom rozhraní. Tedy že Xorg a kernel bude se na rozhraních chovat stejně a jen je rozšiřovat a třeba za 2-3 roky se provede odříznutí nepoužívané funkcionality, ale pak v intervalu těch 2-3 let by se každý bin driver spojil se systémem nezávisle na distribuci nebo stáři driveru či kernelu nebo Xorg. Ale v tomhle světě je to asi jen zbožné přání.
V Alse je aj podpora 24 bitových vzoriek (aj aj 32b a zopár iných formátov).Pokoušel jsem se přesvedčit alsu, aby mě jakýkoliv vstupní signál převzorkovala na 192kHz/24bit než jej přijme DAC převodník na kartě, ale nepodařilo se mi to. Nevíte jak se to dělá? Driver ke kartě to pod Win umí a navíc je to i trochu slyšet v tranzitních zvucích.
A to co napsal mirec o tom jak je organizovaná plasma mne vyděsilo.Takéto praktiky vo vývoji softvéru sú (bohužiaľ) bežné. Ako ďalší príklad si môžeme zobrať nový Midnight Commander (MC) a spýtať sa otázku, prečo je taký pomalý. Pozriete sa do zdrojákov a (bohužial) zistíte, že je to kôli úplne absurdným veciam. Napríklad ide o bezbrehé používanie konverzie medzi UTF-8 a inými formátmi. Krásnym príkladom neefektivity je tiež nápad použiť regulárne výrazy na to, aby sa zistilo či meno súboru má určitú príponu. Efektivita knižníc, ktoré používa MC, tiež má svoje medzery. Atď. Horor.
To co požadují od systému je spolehlivost, a ještě jednou spolehlivost a pak možná také rychlost, pokud to neohrozí spolehlivost. To že když budu něco editovat a diky chybě v nejaké jiné aplikaci mě spadne celé prostředí je něco nepřijatelného. A to se mohli poučit z cizích chyb. Vista je příklad jako hrom. Velká firma, obrovské peníze za marketing, zez ačátku nadšená podpora médií a stejně komu nebyly vnuceny s novým kompem tak je nepřijal. XP jsou stabilní systém, Visty ne.Mám pochybnosti, či máte znalosti o tom akým spôsobom je implementovaný Windows.
A tomu daly v podstatě všechny korporace přednost, minimum firem přešlo. A znám i velké firmy, které mají ty XP nakonfigurovány tak, aby vypadaly jako Win98, uživatelé totiž žádné změny nechtěji.Ako sa toto týka spoľahlivosti softvéru?
10.1.2010 10:07
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Radšej neefektívne použitie regulárnych výrazov než deravosť. Mimochodom regulárne výrazy nie sú zrovna najpomalšie a spracovanie 100 000 názvov súborov obvykle netrvá viacej než pár desatín sekundy (i keď bez nich by sa to dalo o dosť rýchlejšie a zase to nájdenie bodky sprava nie je z programátorského hľadiska moc veľký problém).
Keď sa to s efektivitou preháňa je to o dosť väčší problém (aspoň podľa mňa). Minule som tak programoval pripojenie na BOINC klienta. Zistil som, že mi občas xml parser robí blbosti. Nebudem chodiť okolo horúcej kaše a radšej sem hodím kód z BOINC klienta.
8.1.2010 14:06
8.1.2010 14:33
10.1.2010 11:41
fout.printf(
"<msg>\n"
" <project>%s</project>\n"
" <pri>%d</pri>\n"
" <seqno>%d</seqno>\n"
" <body>\n%s\n</body>\n"
" <time>%d</time>\n",
mdp->project_name,
mdp->priority,
mdp->seqno,
mdp->message.c_str(),
mdp->timestamp
);
V správach sa mi občas objavovali časti xml, ktoré boli chybne spracované. Takže obsah body vyzeral nejako takto: <body> Blablabla <nejaky_nespracovany_element </body>. Vďaka pevnej veľkosti char * (áno je to v C++, aj string tam niekde využívajú, ale tu zrovna nie) to občas sekne aj v polovici chybného tagu. Žiadne escapovanie, chybné xml, to pravé na spracovanie xml parserom.
Celá komunikácia funguje s takýmto akože xml a oficiálne gui funguje len vďaka tomu, že má rovnako prasácke spracovanie xml. Už som sa aj prestal diviť, že v dobe keď som skúšal rôzne projekty sa mi každú chvíľu rozbili xml do nečitateľného stavu (to myslím aj pre oficiálneho klienta, pre normálne xml parsery je v nečitateľnom stave stále).
Radšej neefektívne použitie regulárnych výrazov než deravosť. Mimochodom regulárne výrazy nie sú zrovna najpomalšie a spracovanie 100 000 názvov súborov obvykle netrvá viacej než pár desatín sekundy (i keď bez nich by sa to dalo o dosť rýchlejšie a zase to nájdenie bodky sprava nie je z programátorského hľadiska moc veľký problém).
Deravosť: Či sa programátor rozhodne použiť regulárne výrazy alebo nie, nemá vplyv na deravosť kódu. Skôr má hlavný vplyv to, či ide o kvalitného programátora alebo nie. Kvalitný programátor vyprodukuje správny kód (väčšinou) bez ohľadu na to, či sa použijú regulárne výrazy alebo niečo iné.
Efektivita: Je pravda, že regulárne výrazy sú relatívne rýchle. Na druhej strane, moje vyjadrenia o tom, že v MC spôsobuje ich použitie zbytočné spomalenia, sú založené na konkrétnych meraniach (Valgrind+KCacheGrind). Inak povedané, ja som to moje tvrdenie o neefektívnom použití reg. výrazov v MC "neplácol len tak z brucha".
Ja osobne väčšinou podriaďujem efektivitu správnosti. Správnosť má u mňa ako programátora a niečo väčšiu prioritu ako rýchlosť programu. Ak neverím, že niečo nie je dobre naprogramované (=počítačový model daného fenoménu nezodpovedá realite, ktorú má modelovať), tak načo by som to zbytočne optimalizoval.Keď sa to s efektivitou preháňa je to o dosť väčší problém (aspoň podľa mňa).
Minule som tak programoval pripojenie na BOINC klienta.
Keď si niekto (=tvorcovia BOINC) pod optimálnou komunikáciou predstavuje, že zahŕňa
Nedokážem pochopiť prečo sa na komunikáciu medzi aplikáciami používa textový protokol, a nie binárny protokol. Pri komunikácii človek-aplikácia by som to považoval za racionálne, ale prečo sa XML používa pri komunikácii aplikácia-aplikácia tomu vôbec nerozumiem. Tiež je podľa mňa absurdné ukladať konfiguračné dáta na disk v XML alebo v nejakom inom textovom formáte.
Viď napríklad:
http://channel9.msdn.com/posts/Charles/JAOO-2007-Joe-Armstrong-On-Erlang-OO-Concurrency-Shared-State-and-the-Future-Part-1/
http://channel9.msdn.com/posts/Charles/JAOO-2007-Joe-Armstrong-On-Erlang-OO-Concurrency-Shared-State-and-the-Future-Part-2/
Tomu nerozumiem (a možno ani nechcem rozumieť).Vďaka pevnej veľkosti char * (áno je to v C++, aj string tam niekde využívajú, ale tu zrovna nie) to občas sekne aj v polovici chybného tagu. Žiadne escapovanie, chybné xml, to pravé na spracovanie xml parserom.
10.1.2010 12:32
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Tá posledná poznámka je o tom, že keď už píšu v C++ (pôvodne s príponou C! ale v kóde bežne využívali vector, string) tak už mohli std::string použiť aj na správy a podobné veci ak nevedia alokovať char * potrebnej dĺžky, ale len pevnej dĺžky, takže časť správ môže byť oseknutá.
To s MC ma celkom zaujalo. Ako je možné, že spomalenie spôsobuje regulárny výraz? Pri zobrazení súborov a adresárov by som predpokladal, že hlavnou brzdou bude prístup na disk. Alebo nebodaj MC pracuje s regulárnymi výrazmi nejako divoko? Fakt si neviem predstaviť ako na tak jednoduché úlohy môže toto spôsobiť viditeľné spomalenie. Nikdy som MC nepoužíval, takže neviem, ale fakt ma to zaujíma.
Ok, už tomu rozumiem. Aj napríklad v MC sa také veci nájdu (ala "static char s[100]"). Ja také programovanie nepraktizujem, čiže takýto štýl programovania je pre mňa nepochopitelný/absurdný. V mnou vytvorenom kóde (dosť veľa lines-of-code) som našiel len 2 prípady, keď som použil niečo ako "char s[100]" - ide však o prípady kde pravdepodobnosť, že nenastane chyba, chraničí so 100% istotou.Tá posledná poznámka je o tom, že keď už píšu v C++ (pôvodne s príponou C! ale v kóde bežne využívali vector, string) tak už mohli std::string použiť aj na správy a podobné veci ak nevedia alokovať char * potrebnej dĺžky, ale len pevnej dĺžky, takže časť správ môže byť oseknutá.
Neviem, či to má nejaký zmysel, pretože neverím, že to niekto opraví. Ja také "sračky" nie som ochotný opravovať, ale vedel by som to opraviť. Dôvod tej neefektivity sa týka file higlighting-u. Napr. "a.txt" má na mojom počítači v MC hnedú farbu. MC ide na to asi takto (radšej si sadnite na stoličku pred tým ako začnete čítať ďalej):To s MC ma celkom zaujalo. Ako je možné, že spomalenie spôsobuje regulárny výraz? Pri zobrazení súborov a adresárov by som predpokladal, že hlavnou brzdou bude prístup na disk. Alebo nebodaj MC pracuje s regulárnymi výrazmi nejako divoko? Fakt si neviem predstaviť ako na tak jednoduché úlohy môže toto spôsobiť viditeľné spomalenie. Nikdy som MC nepoužíval, takže neviem, ale fakt ma to zaujíma.
".*\.(txt|doc|...)" sa mapuje na farbu.
No a celý tento cirkus zaberie "iba" 15% z celkového času, ktorý MC potrebuje na prekreslenie konzoly (Ctrl-O).
Teda neviem ... ale toto je už naozaj priveľa.
11.1.2010 13:32
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Mám pochybnosti, či máte znalosti o tom akým spôsobom je implementovaný Windows.Máte pravdu, že nevím detaily s implementaci windows. Je to jen uživatelský pohled na počítače v práci. Kdy jsem BSOD neviděl už několik let. Kdy když spadla aplikace (nestalo se to často) tak zbytek systému zůstal stát a nezamrzl, kdy hardware fungoval spolehlivě. A kdy mne systém neotravoval. Možná primitivní, ale je to uživatelský pohled.
A tomu daly v podstatě všechny korporace přednost, minimum firem přešlo. A znám i velké firmy, které mají ty XP nakonfigurovány tak, aby vypadaly jako Win98, uživatelé totiž žádné změny nechtěji. Ako sa toto týka spoľahlivosti softvéru?Týká se to konzervativismu v používání software. Starý opravený a vyhovující systém je většinou lepší než nový, nebo jinak ten nový musí nabídnout hodně navíc, aby byl důvod ke přechodu.
Týká se to konzervativismu v používání software. Starý opravený a vyhovující systém je většinou lepší než nový, nebo jinak ten nový musí nabídnout hodně navíc, aby byl důvod ke přechodu.A tomu daly v podstatě všechny korporace přednost, minimum firem přešlo. A znám i velké firmy, které mají ty XP nakonfigurovány tak, aby vypadaly jako Win98, uživatelé totiž žádné změny nechtěji.Ako sa toto týka spoľahlivosti softvéru?
1. No, dobre, to je síce pekné, ale je to nepodstatné. Microsoft má defakto monopolné postavenie, čiže ak sa rozhodne, že sa ide "spraviť prechod", tak to spraví bez ohľadu na to, či s tým "nejakých pár" používateľov súhlasí alebo nie. Podobne, ak sa KDE developeri rozhodnú ďalej nezlepšovať KDE3, ale len KDE4, tak "nejakých pár" nespokojných používateľov s tým nepohne.
2. Podľa môjho názoru, staré systémy sú poväčšinou horšie ako tie nové.
ad 1. To je pravda jen částečně. ano Microsoft má defakto monopol, a může ignorovat koncové uživatele, ale nemůže ignorovat velké korporace. Těch které Ty často s novým HW koupily Visty a provedly legální downgrade na XP. Tím pádem se instalovaná báze XP nesnižovala tak prudce. A i velký a silný MS se musel přizpůsobit, jen si uvědomte kolikrát vyhlásil konec podpory XP a kolikrát to musel odvolat. A to ho donutily korporace a ne drobní uživatelé. A KDE také může ignorovat nespokojené, ale způsobí to odliv od KDE. Ad 2. Nový systém může být lepší, protože se může poučit z chyb těch předchozích, ale musí být dobrý koncepní design a dost času na vychtání chyb. Tím tvrzením, že staré systémy jsou lepší jsem chtěl vyzdvihnout dvě věci. a) Současné kompy jsou pro většinu lidí jen pracovní nástroj. A tito uživatelé v podstatě nemají zájem se nic nového učit. 99% je požívá tak že klikne na aplikaci udělá v ní to co potřebuje a pak ji zavře. Dělá to co má jako cíle v reálném žívotě. Ale aplikace chce mít stabilní. Takže změna vzhledu jim nic nepřinese. b) V každém systému jsou chyby, novější systémy jsou vetší a složitější a těch chyb je tím pádem více. Odchytání chyb vyžaduje čas a úsilí. Bohužel vývoj jde tak že když konečně se chyby odchytají a systém je stabilní, což dost let trvá, tak se systém prohlásí jako zastaralý a spustí se nový polotovar. V Současnosti každý nový systém je nedodělek. Kvalitní může být teprve po letech až se odladí, pokud nebude tlak jej nahradit.1. No, dobre, to je síce pekné, ale je to nepodstatné. Microsoft má defakto monopolné postavenie, čiže ak sa rozhodne, že sa ide "spraviť prechod", tak to spraví bez ohľadu na to, či s tým "nejakých pár" používateľov súhlasí alebo nie. Podobne, ak sa KDE developeri rozhodnú ďalej nezlepšovať KDE3, ale len KDE4, tak "nejakých pár" nespokojných používateľov s tým nepohne.
2. Podľa môjho názoru, staré systémy sú poväčšinou horšie ako tie nové.
V každém systému jsou chyby, novější systémy jsou vetší a složitější a těch chyb je tím pádem více. Bohužel vývoj jde tak že když konečně se chyby odchytají a systém je stabilní, což dost let trvá, tak se systém prohlásí jako zastaralý a spustí se nový polotovar.
To v žiadnom prípade nie je pravda. Je to ako by sa povedalo, že mrakodrap je viac náchylný na spadnutie pri zemetrasení ako rodinný dom, pretože je vyšší. Zrejme, keby ten mrakodrap bol postavený z tehál, tak by to aj platilo - on však z tehál postavený nie je. Podobne, Windows NT nie je "postavený" na takých istých technológiách ako DOS.
Iný príklad: u žiadnej aplikácie napísanej čisto v jazyku Java sa nemôže vyskytnúť prípad, že by sa zapísal čo len jediný bajt na adresu, ktorá je mimo pamäte alokovanej pre objekty. Skrátka nie je možné, že by sa to mohlo stať. Nie je to možné preto, lebo všetky aplikácie v Jave podliehajú určitým pravidlám o narábaní s pamäťou. Implementácia jazyka Java a jeho runtimu obsahuje konečné množstvo riadkov kódu, ktorý toto zabezpečuje - keď o tomto kóde niekto dokáže, že naozaj tie pravidlá implementuje, tak tie pravidlá budú platiť pre všetky Java programy (a nie len pre určitú podmnožinu programov, ako je to napríklad v jazyku C).
Ďalším príkladom môže byť Google Native Client: definuje sa konečná množina pravidiel, ktoré ak daná aplikácia dodrží, tak je o nej možné v absolútnom zmysle prehlásiť, že má také a také vlastnosti. V tomto prípade ide o vlastnosť, že binárny kód aplikácie je možné vykonať bez obavy, že by spôsobil zrútenie systému, mal možnosť bezbrehého prístupu k súborom na počítači, atď.
Podobne, ak niekto chce, aby mu program nikdy nevyhodil "Null pointer exception", tak si navrhne/použije taký programovací jazyk, ktorý mu to umožní.
... čiže tvorba bezchybných programov je skôr o tom, že ide o triumf imaginácie. Dúfam, že pod tlakom uvedených príkladov si uvedomíte akú somarinu Ste napísali.
Java nebo Google Native Client jsou opravdu dobré příklady, ale žádný jazyk neodstraní chyby programátorů, když si udělají chybu v úvaze.To je pravda. Problém podľa mňa je v tom, že programovacie jazyky neumožňujú robiť úsudky o programoch v nich napísaných. Dôsledkom tohto je, že ak podľa programátora má vytvorený program vlastnosť X, tak informácia o tomto existuje bohužiaľ len v hlave programátora (alebo teda ľudí, ak ich je viacero). Vlastnosť X nemá explicitnú počítačovú reprezentáciu, a keďže ju nemá, tak nemožno od počítača očakávať, že by sa k nej "vedel vyjadriť". No a tie relatívne jednoduché typové systémy programovacích jazykov ako C/C#/Java/atď síce sú schopné odstrániť určité programátorské chyby, ale jednoducho nemajú na to, aby sa v nich dali špecifikovať a overovať vlastnosti programov.
Také neznám systém, který by byl napsán takto vysokoúrovňovém jazyce jako je Java, a nemám ani rámcovou představu jaký by takový systém mohl mít overhead na zajištění kontroly.V princípe, run-time overhead je možné stlačiť takmer na nulu - ak je človek ochotný akceptovať, že mu programovanie bude trvať 10x dlhšie, v porovnaní s tým keď by nič neoveroval a naprogramoval to "narýchlo" v C++. V podstate ja sa snažím taký prog. jazyk vytvoriť, ale je to "beh na dlhé trate".
Nicméně pořád mám představu, že vnitřky systémů jako linux kernel, Xorg, KDE i Gnome a i to windowsí jádro, které rozhodují o stabilitě, jsou napsány v C/C++ případně C#. A tam se chyby prostě musí najít a odstranit a to chce čas.Uvedené programy sú naozaj napísané v C/C++. Čo sa týka odstraňovania chýb, tak v tomto ohľade som skôr skeptický.
Asi nemá cenu se v tom moc patlat. Pro mne je ten současný vývojový cyklus příliž rychlootáčkový. Pořád mám pocit, jako bych pracoval s polotovarem, který po čase je nahrazen jiným polotovarem, možná o neco hezčím ale pořád polotovarem. A nikde nevidím cestu, jak z toho zmizet.Ok, s takouto interpretáciou súhlasím. Sú to "polotovary".
Prečo jediný plasmoidy, jediný engine dokáže spôsobiť zamrznutie plasmy? Prečo nemôžem nastaviť individuálne práva na prístup na disk pre plasmoidy, ale každý plasmoid má také práva ako samostatná plasma. Prečo ešte vôbec dovolia niečo takéto zdieľať cez internet keď nie sú vyriešené základné problém s bezpečnosťou?
Pretože väčšina ľudí o takýchto veciach nepremýšľa, a ak aj premýšľa tak ich ignoruje. Skrátka, je to tak. Nehovorím, že som sa s tým zmieril - to v žiadnom prípade - len akceptujem, že SW svet je v tomto ohľade taký aký je a najbližšie desaťročia takým aj zostane. Je to smutné.
Poviem to takto: Ľudia (bez ohľadu na ich IQ) si radšej dajú natlačiť do hlavy, že antivírusový softvér je neoddeliteľnou súčasťou operačného systému, namiesto toho aby sa spytovali sami seba, či neexistuje taká architektúra OS a jeho aplikácií, ktorá nebezpečenstvo vírusu eliminuje defakto na nulu.
8.1.2010 15:18
void Pager::wheelEvent(QGraphicsSceneWheelEvent *e) vypadá jako přesně to, co jsi chtěl najít.
8.1.2010 23:09
Prcek | skóre: 43
| Jindřichův Hradec / Brno
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
