openSUSE Leap 16, včetně Leap Micra 6.2+, nově nabízí 24 měsíců podpory pro každé vydání. To je dva roky aktualizací a stability, což z něj činí nejdéle podporovanou komunitní distribuci vůbec. Leap se tak stává ideální platformou pro všechny, kdo hledají moderní, stabilní a dlouhodobě podporovanou komunitní Linux distribuci.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal dne 3. 9. 2025 VAROVÁNÍ před hrozbou v oblasti kybernetické bezpečnosti spočívající v předávání systémových a uživatelských dat do Čínské lidové republiky a ve vzdálené správě technických aktiv vykonávané z území Čínské lidové republiky. Varováním se musí zabývat povinné osoby podle zákona o kybernetické bezpečnosti.
Americká internetová společnost Google nemusí prodat svůj prohlížeč Chrome ani operační systém Android. Rozhodl o tom soud ve Washingtonu, který tak zamítl požadavek amerického ministerstva spravedlnosti. Soud ale firmě nařídil sdílet data s jinými podniky v zájmu posílení konkurence v oblasti internetového vyhledávání. Zároveň Googlu zakázal uzavírat dohody s výrobci mobilních a dalších zařízení, které by znemožňovaly
… více »Prvního září ozbrojení policisté zatkli na na londýnském letišti Heathrow scénáristu a režiséra Grahama Linehana, známého především komediálními seriály Ajťáci, Otec Ted nebo Black Books. Během výslechu měl 57letý Graham nebezpečně zvýšený krevní tlak až na samou hranici mrtvice a proto byl z policejní stanice převezen do nemocnice. Důvodem zatčení bylo údajné podněcování násilí v jeho 'vtipných' příspěvcích na sociální síti
… více »Studentská dílna Macgyver zve na další Virtuální Bastlírnu - pravidelné online setkání všech, kdo mají blízko k bastlení, elektronice, IT, vědě a technice. Letní prázdniny jsou za námi a je čas probrat novinky, které se přes srpen nahromadily. Tentokrát jich je více než 50! Těšit se můžete mimo jiné na:
Hardware – Bus Pirate na ESP32, reverse engineering Raspberry Pi, pseudo-ZX-80 na RISC-V, PicoCalc, organizéry na nářadí z pěny nebo … více »Google Chrome 140 byl prohlášen za stabilní. Nejnovější stabilní verze 140.0.7339.80 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 6 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
LeoCAD (Wikipedie) je svobodná multiplatformní aplikace umožňující také na Linuxu vytvářet virtuální 3D modely z kostek lega. Vydána byla verze 25.09. Zdrojové kódy a AppImage jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
RubyMine, tj. IDE pro Ruby a Rails od společnosti JetBrains, je nově zdarma pro nekomerční použití.
Český LibreOffice tým vydává překlad příručky LibreOffice Calc 25.2. Calc je tabulkový procesor kancelářského balíku LibreOffice. Příručka je ke stažení na stránce dokumentace.
Byla vydána (Mastodon, 𝕏) vývojová verze 3.1.4 příští stabilní verze 3.2 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání.
Tuhle jsme s vedlebydlou rozjímali nad C# a jeho novou verzí 3.0. V této verzi je spousta zajímavých novinek. K anonymním funkcím přibyly anonymní struktury (struct), lambda-výrazy, implicitně typované proměnné, rozšiřující metody (extension methods) atd. Většina těchto nových vlastností byla přidána kvůli zázraku jménem LINQ (Language INtegrated Query). LINQ by měl zlepšit integraci s externími daty (databáze, XML). Vypadá to docela zajímavě. Tento LINQ výraz:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
from c in customers, o in c.Orders
where o.OrderDate.Year == 2005
orderby o.Total descending
select new { c.Name, o.OrderID, o.Total }
se vlastně převede na něco takového:
customers.
SelectMany(c =>
c.Orders.
Where(o => o.OrderDate.Year == 2005).
Select(o => new { k1 = o.Total, v = new { c.Name, o.OrderID, o.Total } })
).
OrderByDescending(x => x.k1).
Select(x => x.v)
Což je mix všelijakých anonymních implicitně typovaných lambda-udělátek 
. Ještě pro zajímavost, tato rozšiřující metoda:
public static T[] Slice<T>(this T[] source, int index, int count)
{
T[] result = new T[count];
Array.Copy(source, index, result, 0, count);
return result;
}
umožní dělat plátky ze všech typů s indexerem, tedy například:
int[] digits = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
int[] a = digits.Slice(4, 3); // Same as Extensions.Slice(digits, 4, 3)
A teď to přijde: skoro si myslím, že je to celé blbě
Ty fíčury jsou mocné a asi i užitečné. O tom nemíním polemizovat, to ukáže čas. Problém je, že tenhle nános dělá z C# úplně jiný jazyk.
Myslím, že je krásné a dokonce důležité mít mocný ale zároveň jednoduchý "minimalistický" jazyk. Jazyk, kde jsou konstrukce ortogonální, kde nejsou žádné temné kouty. Takové jazyky mají šanci být nadčasové, neskončí se svým hype.
Dobrým příkladem takových jazyků je Lisp a SmallTalk. Ale taková Java se tomu hodně blíží (nebo spíše blížila, taková konstrukce pro výčtový typ z jazyka trochu "čouhá"). A C# ve verzi 1.0 byl prostě skvělý - jednoduchý, řešil některé problémy Javy a to obvykle velmi elegantně, zkrátka dílo génia.
Jenže toto nabalování fíčur z něj dělá míň uspořádanů hromádku vlastností (jako Object Pascal v posledních verzích), nemůžu si pomoct.
Podle mne jedna z nejlepších vlastností platformy .net je možnost efektivně kombinovat různé jazyky. Kdysi před mnoha zimami jsem psal pod Win32 program, kde různé moduly byly v C++ ala Borland, C++ ala Microsoft a Delphi. Dosažení kompatibility nebylo jednoduché. Když se tehdy objevily první informace o .netu, byl jsem z možného mixování jazyků nadšen. (Pozn: Java bytecode je dost natvrdo navržen pro Javu, překládat do něho jiné jazyky není jednoduché.) CLR rocks!
Jak už jsem naznačil, proti LINQ a funkcionálním udělátkům nic nemám, ba právě naopak. Jenže proč přidávat tyto věci do "dokonalého" jazyka a tím ho destabilizovat. Není lepší udělat nad dotnetem nové dotazovací/funkcionální jazyky? Když je platforma pro absobci nových jazyků dobře naladěna? Takové nějaké jazyky už jsou, třeba Python, F# a Boo.
Více jazyků v jednom projektu je sice možné, ale ne vždy úplně pohodlné. Ale to se dá vyřešit velmi elegantně, v C# je konstrukce #region, která slouží k oddělování úseků kódu. Stačí ji doplnit o popis syntaxe a rázem je možnost mít v jedné třídě každou metodu v jiném jazyce. Třeba:
class Pokus
{
// C# je takové "lepidlo", jeho syntaxe je implicitní
public static void Main()
{
System.Console.WriteLine(pow(10));
}
#region syntax("Ada")
function pow(a : integer) returns integer is
begin
return a*a;
end;
#endregion
}
Samozřejmě to není úplně bez problémů, spolupráce jazyků je sice CLR teoreticky zajištěna, ale "Devil is in the details". Každopádně využívat různé jazyky dle potřeby (vlastně jako dnes lepíme na projekty knihovny) by nemuselo být špatné. Pamětníci z časů DOSu zavzpomínají na oblíbenou kombinaci Turbo Pascal + vkládaný assembler.
Tiskni
Sdílej:
pre mňa sú java aj c# obmedzené deriváty inak skvelého, no nepochopeného, jazyka. Okrem toho ešte uznávam aj perl (ktorý, uznávam, je takisto ťažký na pochopenie).
nevraviac napr okrem spomínaných Lisp a Smalltalk o Objective C, Prolog, ... 1000 ľudí 1000 chutí (resp, ako sa nás isté trendy snažia presvedčiť 1000 ľudí, len jedna správna chuť)
Koncepce oddělených jazyků má jeden dost podstatný problém, a to je ten, že mezi jazyky se pak musí komunikovat pomocí "interface", který zvyšuje režii a složitost programu. Je to tentýž problém, který řešil Linus při návrhu Linuxu. Proč Linus nedělal Linux jako mikrojádro s oddělenými moduly, ale zvolil makrojádro? Protože prostě koncepce "vše v jednom" (systému, programovacím jazyce) vede k vyšší efektivitě a omezuje režii "interfaců". Ve svém důsledku je i zvládnutí jednoho složitého programovacího jazyka jednodušší a efektivnější, než několika oddělených. Takže s Vaším názorem, že je levnější mít několik oddělených jazyků s danými koncepcemi musím silně nesouhlasit. V praxi totiž vidím, že právě tento koncept je výrazně dražší a mnohdy vede k manažerským rozhodnutím jazyky sjednotit, případně omezit jejich počet na minimální. Takové velmi známé rozhodnutí je rozhodnutí NASA, která se po ekonomické analýze rozhodla vyvinout vlastní univerzální programovací jazyk, který a jen tento bude používat. Tak se zrodila Ada. A rozhodně zapomeňte na to, že by Ada trpěla nějakou minimalistickou koncepcí. Podle mého časem (i když třeba za hodně let) se ukáže, že právě koncepty minimalistických a ořezaných programovacích jazyků jsou příčinou značných ztrát a manažeři postupně přejdou k jazykům komplexnějším.
IL je sice zásobníkový assembler, který se dá ohnout různě, ale trpí závislostí na určitém formátu metadat a dalších věcí. A je tu plno předpokladů, které možnosti ohnutí velmi shazují. Ale to je na jinou debatu.
.
Jinak s tou mezijazykovou režijí máte samozřemě pravdu. Ve svém příspěvku píšu, jak nepříjemné bylo kombinovat kód ze dvou překladačů C++ a Delphi. Jenže mé návrhy vycházejí z předpokladu, že kooperace mezi jazyky je na dotnetu mnohem (řádově!) lepší.
Můžem diskutovat nakolik je tento předpoklad podložený...
Něco se už přeci jen zlepšilo, o Jave 1.5 jsem osobně schopný i uvažovat... 
Je ale pravda, že s těmi operátory jsou trošku paličatí.
...pochopí to každý středoškolák...Nepochopí. Nechápou to ani vysokoškoláci na elektrofakultě. (A pro rejpaly jde i o absolventy průmyslovek)
Ale Graham razí Lisp, jak to sedne ke stoupenci C++? Že by pragmatismus používání v dnešním prosíťovaném, proknihovnovaném, prowindowsovaném světě?
za "úspechom" javy je princíp návrharov "čo neviem používať ja, to nevie používať nikto iný", resp, "tomuto by idiot porozumieť nemusel, toto by mohol zle zapísať, toto vyhodíme"
)
while (...) {
Integer i = hashtable.get (key);
int ii = i.intValue ();
ii++;
hashtable.put (key, new Integer (ii));
}
toto bol posledný klinec vo vzťahu java a ja. jednoducho mi vadilo, že základné datové typy (int, double, ...) nie sú objekty, ale reťazec už ano
BTW, funkce jako data...dejte mi vědět, až v C++ bude lambda... Ta anonymní třída aspoň simuluje uzávěr, jak se v C++ dělají uzávěry?
class Phone; class FMRadio; class MP3Player; class PhoneWithFMRadio extends Phone, FMRadio;samozrejme, dá sa to napísať aj ako:
class PhoneWithFMRadio {
Phone phone;
FMRadio radio;
}
ale tým stratím možnosť
PhoneWithFMRadio my_nokia = new ...; t_mobile.registry (my_nokia); cz_republic."zaplat koncesionarske poplatky" (my_nokia);
Mám pocit, že právě kvůli jeho existenci se v Javě na vícenásobnou dědičnost implementace (nikoli rozhraní) vykašlali. A zdá se, že jsou i stoupenci mixinů pro C++.
"Functional Style in C++: Closures, Late Binding, and Lambda Abstractions"
http://okmij.org/ftp/cpp-digest/Functional-Cpp.html
Ani tak bych ji nepovažoval za ideální, ale takhle je to celkem bída. Myslím, že kdybychom odřízli prostředí, knihovny a podporu dodavatelů a ponechali jen jazyky a jejich kvality, byla by na tom o dost hůř.
Osobně mám pocit, že zastánci Pythonu a Javy se tak chovají, zatímco C++kaři a rubisté jsou příjemnější lidi...
BTW, ten odkaz už mám docela dlouho na seznamu k přečtení...
)
Že někteří railsaři mohou být fanatici, to bude ten "poturčenec horší turka"-syndrom. (To ale nemění nic na tom, že koleje jsou jako prostředí podstatně lepší než PHP... ) To se stává.
Jinak s kolegy pythonisty v okolí vycházíme bez problémů, koukáme tak nějak všichni na oboje a bereme si ponaučení. A ještě si navzájem pomáháme. (On má Raymond s tím přínosem znalosti více jazyků, i kdyby je člověk aktivně nepoužíval, doclea pravdu.)
Nechápu, co má Turingův stroj společného s "rekurzivními jazyky", ať už ten termín znamená cokoliv...to je trida jazyku v Chomskeho hierarchii ( http://en.wikipedia.org/wiki/Chomsky_hierarchy ), jsou to prave ty jazyky, ktere turinguv stroj prijima, rekursivne spocetne jsou ty, u kterych je navic schopen ( v polynomialnim case ) rozhodnout, ze je neprijme... ;) v praxi (ehm... teorii ;) ) to funguje tak, ze nejaky problem zakodujes nejakou abecedou (pro jednoduchost vem 0 a 1 jako celou abecedu ;) ) a pak zkoumas, pomoci turingova stroje, jestli dane slovo (mnozina znaku) odpovida tvym predstavam (definovanymi pomoci gramatik). Jestli je turinguv stroj po precteni vstupniho slova ve vystupnim stavu, slovo prijima a odpovida tedy programu turingova stroje (resp. gramatice podle ktere vznikl). doporucuji: http://ktiml.mff.cuni.cz/~bartak/automaty/prednaska.html btw. taky se mi zda, ze Ruby-isti jsou mnohem militantnejsi nez python-isti - osobni zkusenost (viz take http://www.artima.com/weblogs/viewpost.jsp?thread=141312 )
). Snad téměř v každé diskuzi o Ruby či Pythonu sem narazil na rubysty kteří bezdůvodně začali na Python házet špínu a hnůj. Asi se Pythonu bojí, tak jsou proti němu tak vyhrazení
Možná sem se s tím setkal hlavně díky tomu, že jsem se rozhodoval mezi Ruby a Pythonem, takže sem četl hlavně články kde byly vlastnosti těchto jazyků srovnávány. Ale prostě ten zealotismus rubystů byl naprosto očividný... a možná to trošku i přispělo k tomu, že sem se rozhodl tradši pro Python (ale je to jen podružná věc, ty důvody byly racionální, né tohle ).
24.3.2006 14:09
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
I generování přes XML má své meze
preto pri návrhu používam práve tento spôsob, núti ma premýšľať multiplatformovo. samozrejme, že mám možnosť obchádzať svoje vlastné mantinely. no a implementačným obmedzením je to, že generujem medzivrstvu (v mojom prípade Class::DBI). z xml navyše generujem len limitované featuresky, ak sa dajú (napr view). je to zošívané na mieru mojej súčastnej práce.
ale z-do ste kľudne mohol spomenúť
24.3.2006 14:10
Pavel Stárek | skóre: 43
| blog: Tady bloguju já :-)
| Kolín