Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Třeba se jednou Java začne porovnávat s dalšími jazyky a technologiemi - minimálně alespoň .NETem, Pythonem, Ruby, když už mám vyjmenovat ty aspoň největší stálice. Rád bych se toho dočkal, protože Javistům by konečně trochu spadnul hřebínek, pochopili by to, co chápe většina zkušených programátorů - že každý má své výhody a nevýhody a zdaleka jednoznačně nejlepší není nic.
Nechápu, co pořád Javisty vede ke srovnávání se s C++ - tedy s jazykem vymyšleným na zajištění maximální rychlosti a efektivity běhu výsledného programu porovnatelného se strojových kódem. Na systémové programování - i na platformách, kde by se ani největší optimista nepokoušel spustit JVM.
Podle mého se doména C++ a Javy až tak nekříží, ale nějakým způsobem zastánci Javy se pořád obouvají do C++, aniž by si vzpomněli, že Sunovská JVM je stejně jen 3 milióny řádek zdrojového kódu v C++.
Chce se mi u Javistů neustále křičet do světa - srovnávejte srovnatelné. Až bude potřeba rychlost a efektivita, až bude potřeba psát drivery, kodeky, šifrovací algoritmy, nebo nenáročné aplikace na systém, nikdo soudný nepůjde pro Javu. Zatímco zase rozsáhlé enterprise bankovní systémy nikdo nebude bastlit v C++.
A ten zbytek, kde se dá použít cokoliv - proč nesrovnat Javu s Pythonem, .NETem, Ruby, nebo třeba také by mě zajímalo srovnání s řekněme Eiffelem, Adou, Smalltalkem a mnoha dalšími jazyky.
Je mi to vždycky líto, když z úst zastánců Javy vyletí C++. C++ mám zařazené - potřebuji rychlost, efektivitu, či na systémové zdroje nenáročný program? Či program, nebo fragment, kde chci naprosto všechno do posledního detailu mít pod kontrolou? C++ nemá konkurenci a IMHO žádný vhodnější kandidát neexistuje.
Potřebuji něco jiného, než co je doména C++ - mám na výběr: Ada, Eifell, Java, .NET, Python, Ruby, Smalltalk, pro Windows třeba Delphi, Visual Basic, C++ Builder, Microsoft Access, či prostě spoustu jiných platforem. A Javisté by měli srovnávat právě tyto platformy.
30.9.2007 09:32
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
30.9.2007 10:43
kyknos | skóre: 18
| blog: Quid novi?
| Ranša Rosa
Eclipse se proste nevyrovna zadne IDE (teda mozna Idea nebo Netbeans). Troufam si tvrdit ze jsem 3x efektivnejsi nez v jakemkoliv jinem jazyku.Pro Eclipse přeci existuje spousta pluginů - C, Python, Perl, PHP. Sice s různou kvalitou, ale zrovna ten pro C by neměl být tak špatný, né? OT: z javovské konference (a někt. i osobně) mám pocit, že dost javistů zná: Open Solaris, Ruby, Mysql, Netbeans (samozřejmě i Eclipse) - vše produkty nějak spojené se Sunem. Jak vysvělit windowsákovi, že pro něj bude lepší, když na jeho Un*x like server zvolí Linux místo Open Solarisu. Trochu větší přehled a menší marketingová nalejvárna od Sunu by se hodila.
Proč se mluví o Javě? Není to náhodou proto, že v ní vzniká 45% veškerého software na zakázku?
Proč se srovnává s C++? Není to náhodou proto, že C++ je druhý nejrozšířenější jazyk v téže oblasti?
Četl jsem už mnoho čláků, které vykřikují, že jazyk X by mohl být v každém ohledu lepší než Java. Ale volná ruka trhu rozhodla jinak. Takže o čem se tady flamuje?
O těch 45% si dovolím silně pochybovat - a ani Vy sám nebudete schopen toto Vaše tvrzení hodnověrně doložit, protože to je naprostý nesmysl.
Nemusí to být pravda, ale je to napsáno na několika místech. Když chcete nějaké tvrzení označit za nesmysl, musíte být napřed schopen jej vyvrátit. Nic takového se vám ale nepodařilo.
A jste si jist, že srovnáváte srovnatelné? Java i C++ prostě jsou každý na něco jiného - to není dobrá dvojice do srovnání.
Ano, jsem si jist. Pokud vezmete v úvahu všechny faktory jako je druh projektu, plaforma/platformy a osobní preference programátora, můžete směle srovnávat Javu s C++ hned v několika ohledech. Nevidím nic špatného na srovnávání rychlosti, přenositelnosti, doby vývoje a dalších kritérií. Nesrovnatelné věci se ve světě počítačů vyskytují extrémně vzácně. Srovnání může pro jednu stranu dopadnout velmi špatně, ale nic horšího se stát nemůže.
Co je tedy na Javě a C++ tak nesrovnatelného?
Taky slyším, že Linux je lepší, než Windows, ale volná ruka trhu rozhodla tak jaképak copak - pryč s Linuxem.
Kdo říká, že volná ruka trhu rozhoduje „správně“ nebo podle gusta konkrétní skupiny uživatelů? Já sice Windows nikde nemám, takže to nemůžu zodpovědně srovnat, ale nemyslím si, že jsou pro každý druh nasazení a pro každého uživatele horší než Linux. Kromě toho jsem si nevšiml, že by Linux zanikal, vidím kolem sebe spíš vývoj opačným směrem. Takže si prosím takové plamenné fráze nechte raději od cesty.
Váš výčet oblastí, ve kterých nelze srovnávat, je sice vyčerpávající, ale naprosto off-topic. Zaprvé proto, že mě z mně neznámých důvodů považujete za příznivce Javy a vkládáte mi do úst věci, které jsem neřekl. Zadruhé, ani slovem jsem nenaznačil, že by možnost srovnání existovala pro všechny druhy projektů. Lze samozřejmě srovnávat jen ta řešení, která jsou v obou jazycích proveditelná. Nečekal bych, že mě budete takto chytat za slovo.
Výrok o chameleónovi opět plyne z nepochopení toho, co jsem napsal. Tedy se ptám: Jak jste přišel na to, že [obhajuji | mám v oblibě] Javu? Její dnešní využití možná není dobrým řešením, ale nikdo s tím v nejbližší budoucnosti nic nenadělá. Java je prostě jeden z mnoha open-source nástrojů a žádného zlého démona v ní nevidím. Windows mi vadí mnohem víc, proto jsem se o nich zmínil. Neobhajuji Javu podílem na trhu ani jakkoli jinak.
Zklamání osobou diskutéra je oboustranné. Toto je už cca pátá diskuse, u které vidím, jak vyvoláváte naprosto zbytečný flamewar. Pokud nemáte rád Javu, rozhodně nejste sám. To ale ještě není dost dobrý důvod k neobjektivnímu zpochybňování některých jejích kvalit. Mně Java rozhodně nepřirostla k srdci. Ale co s tím asi tak nadělám?
Já ale problém nevidím. Ten pragmatický přístup je mi velmi blízký. Ale reagujete tady opravdu ve stylu boje s větrnými mlýny.
Dobře tedy, nechť jsem třeba mladý a hloupý. Buďte rád, že vy jste chytrý. Doufám jen, že to s tím černobílým světem byl pouze vtip. Kdyby mi bylo patnáct, možná bych podobnou výtku byl schopen přijmout. Ale není mi patnáct.
Já ale problém nevidím...Slepota? Fanatické zaslepení?
Jste si jist, že víte, na co reagujete?
C++ mám zařazené - potřebuji rychlost, efektivitu, či na systémové zdroje nenáročný program? Či program, nebo fragment, kde chci naprosto všechno do posledního detailu mít pod kontrolou? C++ nemá konkurenci a IMHO žádný vhodnější kandidát neexistuje.C + asm.
(Ale jestli MJ je jediný na světě s takovýmito problémy, tak jste to možná nezpozoroval. ) Tedy, ne, že by tohle nešlo napsat uvnitř C++ kódu (asm, intrinzika...), akorát si tu člověk s C++ konstrukcemi moc nepomůže. Možná tak s šablonami (viz MacSTL), ale to můžu i v závorkových jazycích, kupříkladu. A na ty zajímavé fígle jako ten zmíněný to je stejně jedno, protože i napsat to ručně může být i trivka (v porovnání s vymýšlením), akorát člověk musí vědět, co.
).
Jen je škoda, že je z toho vždycky taková flamewar.
Java samotna je jednoducha, az nudna. Sice to neni tak cool, jako Lisp a jeho "makra upravujici makra, ktera muzou upravovat dalsi makra upravujici puvodni makra".Tak to bych si vyprosil - na spoustu jiných věcí bych klidně mlčel, ale že Java je jednoduchá a nudná? Kdybych porovnal CLHS (nebo aspoň tu část, co upravuje jazyk, nikoli standardní knihovnu) a specifikaci Javy, nejspíše bych dospěl k výsledku, že specifikace Javy je několikrát nafouklejší. A to vůbec nemluvím o padesátistránkové specifikaci Scheme.
Ta je "tak jednoduchá, až je nudná".
S knihovama souhlas, ty jsou fajn (i když API je poplatné onomu rigidnímu jazyku), jen doufám, že nejsou pořád celé v paměti.
.
* tedy může být, ale ani zde není tak nemožné si ustřelit nohu
Java tu jednoduchost maskuje. Chceš spojovat řetězce? Klasické String + String je neefektivní, takže musíš použít StringBuffer, anebo StringBuilder, které se liší v tom, zda jsou, či ne thread-safe,Klasické
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
2.10.2007 12:57
30.9.2007 10:50
30.9.2007 12:46
String+String (a to i pro víc než dva Stringy) kompilátor přeloží jako new StringBuilder(String1).append(String2), takže rozdíl není v efektivitě. StringBuilder (nebo starší synchronizovaný StringBuffer) se používá tam, kde kompilátor nemůže uhodnout, že jde o spojování do stále jednoho celku, a kde by zbytečně neustále vytvářel StringBuildery a převáděl je na řetězce.
Tiskni
Sdílej:
