Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Operační systém 9front, fork operačního systému Plan 9, byl vydán v nové verzi "do not install" (pdf). Více o 9front v FQA.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
Hned na začátku přiznávám, že nejsem žádný zkušený programátor - až asi na jednu výjimku jsem nikdy jsem nepřekročil hranice domácího bastlířství. Čas od času se začtu do vyjadřovaných zkušeností těch pokročilejších a v téhle souvislosti bych se rád zeptal na jednu věc, které bych moc rád přišel na kloub: kde se bere ta neutuchající kritika Javy?
Jestli tomu dobře rozumím, tak programátoři se v zásadě dělí na ty, kteří...
Pokud se chci orientovat do té druhé skupiny (mám subjektivní pocit, že poptávka právě po ní by měla být větší), zdá se mi, že jazyk překládaný do bytecodu, rozumně zjednodušený a vybavený garbage collectorem, je pro ně lepší volbou z následujících důvodů:
Ta multiplatformost mi přijde jako docela silný argument, který musí s přehledem přebýt argument nějakých elegantních vychytávek platformy NET. Celkově mi přijde, že je pro tuto oblast budoucnost v nějakém standartizovaném společném virtuálním stroji, do jehož bytecodu budou mít všechny slušnější jazyky možnost překladu - a této myšlence je virtuální stroj Javy zřejmě právě nejblíž. Na nedávném blogu však přesto zazněla slova "menší zlo", "obloukem vyhni". Dříve jsem si podobná odmítání spojoval s tím, že se nejednalo o otevřený sw, ale i tato námitka teď padla.
Předem děkuji případným lidem, kteří nebudou litovat času na vyvrácení, poopravení, nebo potvrzení mých názorů.
Tiskni Sdílej:
Java je dneska ve složitých výpočtech stejně rychlá jako C++. Výkonostní rozdíly jsou zanedbatelné, ať už je v konkrétním případě Java pomalejší nebo rychlejší, a programátor by měl raději upřednostňovat rychlost vývoje.Ano, a proto Peter Norvig prohlašuje, že výkon Javy je žalostný i v 21. století? Proč tedy Google na ty složité výpočty používá kombinaci C++ a Pythonu a ne Javu?
g++ -c -pipe -O3 -fomit-frame-pointer -march=pentium4 binarytrees.gpp-2.c++ ...
) a kolik pro Javu (způsob překladu autor vůbec neuvádí - jaký byl cílový bytecode? stripnul debug informace? jaký použil překladač? způsob spouštění: java $JDKFLAGS -server -Xbatch
). Nemluvě o tom, že tihle autoři znají akorát sunovskou Javu...
I nejnovější g++ a super zoptimalizovaný kód přeložený g++ generuje velmi výrazně horší a pomalejší kód, než Microsoft Vistual Studio 6 z roku tuším 1996 bez jakéhokoli nastavování optimalizačních parametrů.Vzpomínám na jeden výpočetně orientovaný program v C++. Zkusil jsem ho zkompilovat (vždy s maximální optimalizací) na MSVC++ a na g++. Microsoftím kompilátorem zkompilovaný program byl o cca 7 % rychlejší.
Java je dneska ve složitých výpočtech stejně rychlá jako C++.Tak tomu snad sám nevěříte... Docela by mne zajímalo, jak jste na to přišel. Z osobních zkušeností si jsem naprosto jist, že ve složitých výpočtech je Java pomalejší. Například, když pracuji s neuronovými sítěmi, tak jsem první implementaci projektu napsal v C, trénování sítě trvalo mezi 20-21 hodinami, následně jsem chtěl s kódem trochu experimentovat, což se mi s céčkovou implementací zdálo nepohodlné, tak jsem kód přepsal do Javy a doprogramoval nějaká rychlostní vylepšení - dnes mi Javová aplikace seběhne v čase většinou o půl hodiny pomalejším. Tu samou zkušenost mám s kompresními algoritmy, kterým se dnes sice až tak nevěnuji, ale opět třeba Range kodér s modelem řádu nula byl v C++ vždy znatelně rychlejší, než stejná implementace v C# v .NET Frameworku 1.1 a později i 2.0 ve Windows. Musím však uznat, že co se pohodlí týká, tak Java a C# vedou nad C a C++, ale to asi není nic nového.
Kdyby Javu zakazali, tak spotreba elektriny celosvetove klesna aspon o 10%.
A co potom takové Gentoo
Ano, souhlasím. S tím, že ty jiné jazyky dosahují stejnou rychlost jako Java za výrazně nižší spotřeby systémových zdrojů - především paměti.
To musí být opravdu silná nenávist, když v každé větě, který by jinak vyzníval pro Javu alespoň neutrálně, uvedete nějaké negativum.
Ač uznávám, že ta potřeba použít asm je v 0,01%, MI asi nebude moc dobrá škola, pokud prohlásí jednoznačný nepravdivý závěr bez dalšího.
Matematická Informatika, Přírodovědecká fakulta University Palackého v Olomouci. Že to není dobrá škola jim řeknete Vy, nebo to mám udělat za Vás?
Byla řeč o x86 PC, které tehdy měli 512MB RAM a za rok budou mít 8GB. S procesory, které si přehazují instrukce podle aktuální situace. S instrukční sadou doplňovanou s každým dalším modelem. Psát 100% odladěný kód v ASM, to bych nedělal nic jiného, než nonstop studoval změny v nových CPU. Naopak jsem rád, že to za mě na 80% udělá překladač. U jednočipů jsem měl vždy větší problém se vejít do paměti, proto jsem ASM optimalizoval na velikost, rychlost byla taky důležitá, ale vejít se to tam prostě muselo.
Byla řeč o x86 PC, které tehdy měli 512MB RAM a za rok budou mít 8GB.Hmm, a těch 8GB do paměti dostanete jak? A z paměti do procesoru? A to všechno je zadarmo?
Jestli to opravdu všechno leží jen na té rychlosti (jak se mohu domnívat z vašeho příspěvku), tak se to časem umlátí silou HW. Dnes už přece také nikdo nemá potřebu vyvíjet hratelné gamesky do pamětí řádů kB a procesorů typu Z80, ne?Na to jsem reagoval, že není pravda, že Java je pomalá a že ani neplatí rovnítko ASM=rychlé. Pak došlo na HW (a týkalo se to především CPU). Přečtěte si to sám. Nikde jsem nepsal o jednom stále stejném algoritmu hůře a hůře napsaném nebo přeloženém a proto vyžadujícím více RAM a CPU. Naopak. Jestli má někdo pocit, že dnešní programy umí stejně jako ty co před šesti lety, ale potřebují k tomu šekrát větší výkon, tak nechť otevře oči.
"Jestli má někdo pocit, že dnešní programy umí stejně jako ty co před šesti lety, ale potřebují k tomu šekrát větší výkon, tak nechť otevře oči."Ehm, v mnoha případech tomu tak je. Ba co hůř, najdou se i situace, kdy nespokojený uživatel (ovšem hard-core power user) sedne a napíše vlastní SW - tisíckrát (vím i o extrému, kde byla nula navíc) menší, ale překvapivě i použitelnější a lepší. Opravdu mě nenapadá moc věcí, které by před šesti lety s šestinovým výkonem principielně nešly, tedy s výjimkou aplikací opravdu náročných na výkon, jako jsou lepší kodeky, grafické filtry a podobné blbosti. Určitě se to netýká kancelářských balíků, většiny zakázkových aplikací, databázových věcí... V mnoha případech by určitě stačil výkon i desetinový, třicetinový... Případně před šesti lety mohl někdo napsat aplikaci, která je podobně rychlá i funkční, jako obdobná aplikace někoho jiného, ovšem psaná na dnešní železo. Požadavek na odezvu ~1.5 s maximálně tu zůstává, jen nám nakynuly knihovny, runtimy, disky...a lidi, pokud jim v tom něco nezabrání, se prostě roztáhnou. Přijde mi to skoro přirozené.
Když se tak kouknu na to, kolik výkonu si vzaly programy před pár lety a co berou teď, tak mi je z toho chvílema poněkud nevolno.Když se kouknu na to, jak pomalé je dnešní GTK, je mi chvílemi opravdu nevolno
java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)
java version "1.6.0_02" Java(TM) SE Runtime Environment (build 1.6.0_02-b05) Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode)
Například Azureus, nebo Eclipse jsou nechutně pomalé, že se nedají skoro ani používatAzureus se nedá používat? Mně tu běží rovnou 2x a používat se dá dost dobře
Ale v globále ani jeden z výše zmíněných virtuálních strojů se příliš nehodí na dynamicky typované jazyky, takže třeba pro Perl, nebo pro Python se vyvíjí Parrot a další virtuální stroje.A co DLR?
vim ~/.emacs
To je velmi optimistické. Já bych toto netvrdil. Ale řekněme, že obecně je větší tolerance vůči nenažraným programům, než byla dříve. Přesto bych řekl, že Java to dost přehání - a mnoho lidí prostě Javu odmítá vůči pomalosti/žravosti. Pro jistotu napíšu, že je jedno, jestli za to může Java, nebo neschopný Javista co to naprogramoval - uživateli je to zcela jedno. Javovské programy mají speciální pověst - a mnoho lidí, kteří ani neumí programovat odmítne program v Javě, má-li náhradu v čemkoli jiném.
Tohle jsem tu četl už tolikrát, že na to konečně musím reagovat. Podívejte se to poradny a najděte si tam dotazy ohledně spotřeby paměti v Linuxu. Dotaz je typu: "Mám 768MB RAM a volný jen 52MB, přitom mám spustěný jez Firefox. To jsou ty linuxi tak žravý na paměť???" Následuje vysvětlení, že 600MB je cache.
Na tom samém portálu se neustále dočítám, že Java je náročná na paměť. Přečtěte si prosím něco o tom, jak JVM hospodaří s pamětí. Linux má své cache, JVM taktéž (akorát se to jmenuje jinak). Pokud ván Java app žere moc paměti, změnte si parametry JVM.
"Pokud ván Java app žere moc paměti, změnte si parametry JVM."To jsem zvědav, jestli mi zrovna tohle to využití paměti XEPem srazí z těch 1.4 GB někam rozumně dolů.
V nějakém příspěvku výše se rozplýváte, jak g++ je třeba nastavovat s optimalizačními parametry, zatímco o Javu se není třeba starat - byl to případ benchmarku. A teď z Vás vypadne, že g++ stačí nastavit jednou při kompilaci a uživatelé to mají bez práce, zatímco Javu aby si nastavoval každý uživatel včetně posledního BFU, jinak mu pojede špatně.
Spletl jste si uživatele, o g++ jsem nic nepsal.
A opravdu si myslíte, že všichni kromě Herona jsou nýmandi, co nejsou schopni zjistit skutečnou spotřebu paměti procesem?
To rozhodně ne a ani to z mého komentáře neplyne. Jen jsem se pozastavoval nad tím, že na stejném portálu lidi vysvětlují jak je to se spotřebou paměti v linuxu (a že je to takto dobře) a na druhé straně nadavájí na "stejně" spotřebovanou pamět v JVM (kde je to podle nich špatně).
Pokud se bude potřebná paměť blížit té, které jste JVM dal, bude gc makat jak vzteklé a efektivita jde prudce dolů. Prostě Java potřebuje plýtvat pamětí - je to podmínka efektivního běhu javovského procesu.
Totéž co výše. Dejte Linuxu, Windows, Macu 1GiB RAM a spusťtě tam program (třeba v C++), který reálně potřebuje 1000MB. Uvidíme, jak to pojede.
Pokud dáte programu v Javě, který potřebuje 1 GB RAM přesně 1 GB RAM, JVM se umlátí na častém spouštění garbage collectoruTohle snad děláte schválně
Program v C++ nepotřebuje nadbytek paměti pro efektivní běh.
Ale potřebuje. Jenže se to maskuje jako buffers a cache v systému pod ním. Pod programem v javě je co? Ano správně JVM. Má-li OS pro C++ program k disposici 600MB cache, dopřejme to i JVM.
Ale potřebuje. Jenže se to maskuje jako buffers a cache v systému pod ním. Pod programem v javě je co? Ano správně JVM. Má-li OS pro C++ program k disposici 600MB cache, dopřejme to i JVM.Opravdu si myslíte, že se JVM obejde bez té cache v systému pod ním?
Inak ked sa ti zda ze java aplikacie su rovnako rychle, skus si nainstalovat solaris kde ich je podstatne viac a potom nam o tom nieco povedz.Pokud vím, tak zrovna na Solarisu je Java nejpomalejší a nejžravější. Je to docela pikantní, vzhledem k tomu, že je obojí produktem téže firmy a mělo by to tedy být nejlépe sladěno.
A pan Kyosake by si asi taky rval vlasy, kdyby se někdo pokusil jeho oblíbený LISP přechroustávat na Java mašině a on to musel používat.Zase mně przníte. Ne, nerval bych si nic, protože pro mě by to byla jen další implementace Lispu. Jenže jakýkoli jazyk se pro JVM dá snadno kompilovat pouze tehdy, pokud je víceméně ekvivalentní Javě. Pokud ne, stojí implementátor před úkolem "napsat kompilátor z jazyka A do bajtkódu navrženého pro jazyk B", což je nevděčné, netriviální, a nefunguje to nijak dobře. Implementátoři JRuby se potýkají s implementací výjimek, a to by člověk řekl, že to bude "trivka", když JVM je má taky. Kompilátor Common Lispu pro JVM sice taky existuje, ale jen za cenu spousty nekompatibilit a omezení, protože jazykový model Javy je z pohledu implementátora Lispu žalostně neúplný. (Generic functions, anynone? Closures? Migrace tříd objektů v živém systému na novější verzi? Když už ne v produkci, tak aspoň pro interaktivní vývoj...) A kdybych stál před úkolem to někam naportovat, čekalo by mě v případě SBCL, které má asi tak 20000řádkový Cčkový kernel (dokonce věřím, že i já bych mu byl po čase schopen porozumět ) a nad ním přísně oddělených 200000 řádků vyšší vrstvy runtimu, kompilátoru a standardní knihovny (to vše v čistém Lispu), o dost méně práce, než v případě Suní Javy, která má pro Intel pečlivě vyladěný runtime o milionech řádků kryptického kódu, a přitom výkon je srovnatelný, občas v případě SBCL i lepší, a to ani zdaleka není nejlepší implementace, protože je zadarmo. A kdybych to nedokázal já, každý port SBCL měl na svědomí jeden člověk za pár týdnů, maximálně měsíců. U suního runtimu si to nějak nedokážu představit. Tolik k té "přenositelnosti". Myslím si tedy, že Java je ta nejlepší Java, jakou můžete sehnat, a pokud Javu nepotřebujete, je lepší se podívat po vhodnějším řešení.
velmiDlouheIdentifikatoryKtereSeBezIdeTemerNedajiNapsatPříklad z praxe bude?
FormatFlagsConversionMismatchException
Na druhou stranu je to (hlavně u méně používaných věcí) názornější než mít identifikátor ffcmex
, který bez manuálu nikdo nerozluští.
Na druhou stranu je to (hlavně u méně používaných věcí) názornější než mít identifikátor ffcmex, který bez manuálu nikdo nerozluští.No to každopádně.
Obzvlaste v (dnes jiz ustupujicimu) trendu co nejrychlejjsi cpu a ram az co "zbyde".Tohle bývalo (a ještě do značné míry je) doménou PC v hypermarketech. Dají do letáku údernou hodnotu rychlosti procesoru a k tomu nízkou cenu. Šetří samozřejmě na grafice, disku, a hlavně operační paměti.
"samozdrejme ne objektove ale jako parametr"Fuj, za tohle bych střílel lidi u zdi. Co jiného je příjemce zprávy, než skrytý (v případě Smalltalku, Javy, C++ a podobně - v případě CLOSu/Dylanu je naopak viditelný) parametr, nad kterým se dispatchuje? Až tyhle jazyky konečně budou umět dispatch podle více parametrů, budou "méně objektové" či co?
Donekonečna omýlaný argument. Podle Moora (nebo jak se jmenuje), se výkon PC zdvojnásobí za jeden až dva roky. A to platí i o paměti. PC se většinou tak často nekupuje. Nevšiml jsem si, že by na stejném PC stejná aplikace (pravidelně aktualizovaná) jela stále a stále pomaleji - většinou se optimalizuje a jede lépe. Naopak, když už koupím nový stroj, většinou na něj naložím mnohem víc, než co běželo na tom původním starém, nebo je to výrazně kvalitnější (teď mám výkon, tak zkusím 16xFSAA - třeba).s rozšiřováním stále nabouchanějších počítačů, klesá handicap větších nároků na strojový čas a paměť....tak todle je presne argument kterej neberu! prece si nebudu kupovat novy stroj jenom kvuli tomu aby mi to bezelo zase stejne pomalu...
... A nez si ve svem Ccku/Lispu/Pythonu atd vyresite data storage, konfiguraci, formulare apod ja mam hotovy tri dalsi programy.Ano, někdo potřebuje sekat programy jako baťa cvičky a někdo potřebuje psát programy o kterých se vám zjevně ani nezdálo ať už co do požadované komplexity, spolehlivosti, nebo výkonu.
persistent-class
místo standard-class
), nulovou konfigurací...co proti tomu postavíš, Hibernate? Chm. Lidi jen leckdy nevědí, co pro tyhle jazyky existuje. (Samozřejmě, Franz si účtuje za tyhle věci šílený prachy. Ale taky poskytuje dokonalý služby...)
Visty byly puvodne napsane v C#. Kvuli kompatibilite a vykonu se vse prepsalo znova v C++.Což je docela škoda.