Google Blog ČR informuje, že mobilní aplikaci Gemini a NotebookLM lze používat už také v Česku.
Byla vydána nová major verze 8 duálně licencovaného open source frameworku JUCE (Wikipedie, GitHub) pro vývoj multiplatformních audio aplikací.
Od 18. června bude možné předobjednat notebook DC-ROMA RISC-V LAPTOP II od společnosti DeepComputing s osmijádrovým 64-bit RISC-V AI CPU a s předinstalovaným Ubuntu.
Byla vydána verze 1.79.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Byly zveřejněny výsledky průzkumu (infografika) mezi uživateli FreeBSD.
Na konferenci DevConf.CZ 2024 je na stánku Furi Labs prezentován linuxový telefon FuriPhone FLX1. Jeho cena 499 dolarů.
Bylo vydáno Eclipse IDE 2024-06 aneb Eclipse 4.32. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-2 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Po roce od vydání verze 15.5 bylo vydáno openSUSE Leap 15.6. Přehled novinek v nejnovější verzi této linuxové distribuce v oznámení o vydání a v poznámkách k vydání.
Byla vydána nová verze 256 správce systému a služeb systemd (GitHub). Nově mimo jiné s run0 jako alternativou k sudo.
Autor se v článku na svém blogu zabývá použitím Pythonu jako skriptovacího jazyku pro systém a porovnává ho s BASHem. Jako jeden z důvodů pro použití Pythonu popisuje vznikající knihovnu interpipes, která umožňuje použít v Pythonu "roury" tak jak je známe ze shellu.
Tiskni Sdílej:
fint -print0 | xargs -0Ruzne vystupy programy mají, viz funkce isatty() a barevné zvýrazňování u ls a dalších programů.
Je nutna oprava v clanku: iterpipes misto interpipes.
Jinak i pro jednoduche shell skripty (> 5 radku) pouzivam vetsinou uz jen Python, mohu doporucit (hlavne pokud nekdo neumi dobre bash a musi se tedy stejne prohrabavat dokumentaci).
Uvědomte si, že bash je de facto jednosměrně kompatibilní přes 30 let zpátky. Z tohoto úhlu pohledu těch "jen jednou za 10 let" dostává úplně jiný rozměr.
Initscripty (a vůbec skritpy) se v debianu se taky nedávno přepisovaly, protože se změnilo /bin/sh na dash místo bashe.
Je-li tomu tak, je to chyba autora těch skriptů. Pokud jako specifikaci interpreteru napíše /bin/sh
, pak by v tom skriptu žádná rozšíření bashe (ani jiného rozšíření Bourne shellu) neměl používat. Naopak, pokud je chce použít, měl by do specifikace napsat ten shell, který používá.
Bourne shell (a v důsledku tedy i bash) má především naprosto nekonzistentní syntaxi, která silně připomíná Čapkovu pohádku o tom, jak pejsek a kočička vařili dort (k dokonalosti ovšem tento přístup dotáhl až perl). Ke cti autorů bashe slouží, že se snažili o logičtější a konzistentnější postup, ale vzhledem k tomu, na čem museli stavět, uspěli jen ve velmi omezené míře.
Na druhou stranu si také nemyslím, že python plně nahradí shellové skripty nebo že by něco takového vůbec bylo rozumné.
Jo ták, to už tak u překladačů bývá, že část jejich kódu je spefická pro každou podporovanou cílovou architekturu.Až na ten detail, že ta část je nezbytná nutnost pro provoz, protože bez překladu do cílové architektury se to ani nehnulo. Jako by je ten jeden switch pro generickou architekturu zabil. No Jarídkove kecy tady snad nemusím připomínat. Až se budou dělat systémové skripty opravdu v JavaScriptu a bude je interpretovat v8, tak ani nechci domyslet co se stane, až budu chtít rozbíhat takové OpenWRT na nějakém MIPSu.
Hm, takže hack.Má to ještě keš pro snapshoty toho vygenerovaného kódu. Přeloží se to jednou a při dalších spuštěních, pokud se skript nezmění se dává řízení čistě binární formě. To už je IMHO víc překladač než interpret. A tomu říkám ten hack (a určitě jich tam bude spousta i v samotném kódu).
Virtuální mašiny s plným JIT překladačem a bez přenositelného interpretu nejsou nic nového.Ale rozhodně ani nic pěkného. IMHO se tim zabíjí jedna z výhod interpretovaných jazyků.
Tak o V8 snad nikdy nikdo jako o interpretu nemluvil#96:
vzhledem k tomu že máme rychlé implementace jako V8...A to stejné si myslím o Chromiu.
No pokial viem tak postupne nove distra nahradzaju init scripty upstartom
To je dost optimistický výklad. Tedy optimistický z pohledu fandů upstartu.
Mě by zajímalo, co je podle Vás věcná argumentace, když ne to co píšu. Můžete se třeba rozepsat a dát příklad věcné argumentace? Tedy za vysoce nepravděpodobného předpokladu, že nějaké věcné argumenty vůbec máte.Ale kludne . Vecna arguemtacia je zhrnutie faktov bez snahy ovplyvnit usudok. Toto evidentne nie je pripad vasho prispevku. Mna napriklad nezaujima Vas traumaticky zazitok s Pythonom (ktory sa s vysokou pravdepodobnostou stal). Prosim neberte ako osobny utok ani nechcem byt ironicky, citam to medzi riadkami. Python po 10 rokoch zmenil cast API (podobne ako napriklad Qt) a migracne skripty nefunguju na 100%. Takto podla mna ma vyzerat vecna argumentacia. O nestabilnom API sa mozme bavit, ak vieme, ze sa v buducnosti necakane zmeni. Tu by som suhlasil, ze nemame zaruku stability (ani potvrdene ani vyvratene). Vidim ze reagujete trosku podrazdene (...za vysoce nepravděpodobného předpokladu, že nějaké věcné argumenty vůbec máte) a do debaty uz vstupujete s tym, ze mate pravdu prave vy. Preto dalsie pokracovanie v tomto threade vidim ako zbytocne. Snad sa pocasie umudri a bude sa dat lyzovat ...
Za sebe bych jako hlavní systémový jazyk chtěl Luu, která je geniálně jednoduchá a její implementace běhá v dané kategorii neskutečně rychle při nízkých systémových nárocích. Navíc je její vývoj velmi konzervativní, teda ve srovnání s Pythonem určitě. Bohužel není v *nixových prostředích tak rozšířená jako Perl nebo teď i Python. Asi nedostatek hype
Je třeba vše zkontrolovat, prohnat novými testy, znovu označit kód za alfa/beta verzi, odladit případně nalezené chyby, znovu výsledek prohnat testy,…A nebo co třeba zkusit si dát pár piv a pustit se do práce? Proboha, snad se tu bavíme o systémových skriptech a ne o Black-Box© Enterprise Edition, ne?
Pane Ponkraci, bod 2 tady na abc stale opakujete dokola :) Nevim co je na tom tak spatneho, kdyz vyvojari Pythonu zacli logicky sjednocovat a predelavat nektere casti jazyka po nekolika letech vyvoje (ano, meli to delat hned od zacatku, ale lepsi ted, nez nikdy). Tvrdit, ze se jim ted uz neda verit a ze verze 4 bude urcite zase naprosto zpetne nekompatibilni k verzi 3 je ciste Vas nazor, ja si to nemyslim. Kazda nova hlavni verze jazyka prinasi spoustu novinek, takze se budto programatori svezou na vlne nebo zustanou u stare verze.
Mimochodem ma tady nekdo zkusenosti s konvertovanim Python skriptu pomoci te utilitky 2to3? Zajimalo by me, jestli je to opravdu tak strasne moc prace, jak pan Ponkrac tvrdi. Ja zacinam rovnou s verzi 3 (+ minimum 2.6), takze me cely ten proces jaksi minul - napr. Python od verze 2.6 povoluje uz psat "print" ve stejnem syntaxi jako Pythonu 3, cili je videt, ze ten prechod tak prudky nebyl.
Trochu si protirecite. Python dle meho nazoru nikdy nebyl staven na to, aby se v nem delaly projekty s delkou 10 milionu radku (jak uvadite v prikladu nekde o vlakno nahore), zaroven ale pisete, ze se v P. nepise nic duleziteho. Na obrovske projekty mame Javu, Adu apod., u nich je samozrejme naprosto nemyslitelne zrusit zpetnou kompatibilitu.
Pro ucely, pro ktere byl Python vytvoren, se bude v budoucnu prece hodit minimalne stejne dobre jako doposud, obliba napr. u webhostingu stoupa (kdyby nebyla poptavka, tak by zcela zmizel). Programatori nejsou sochy, tudiz se kazdym rokem "rodi" dalsi a je jim uplne jedno, jak vypadal Python pred par lety. Kdyz se bude dobre hodit na reseni aktualniho problemu (+ bude dostatecne rozsiren, bude pro nej dostatek knihoven atd), tak se eventuelne pouzije.
5 > 2
XHTML 5 je jen XML serializace HTML 5, podle mne nic moc důležitého, sice jsou lidi, kteří staví weby na XML technologiích, ale svůj masochismus si musí každý vyřešit sám
Ty změny, které způsobovaly nekompatibilitu přišly neohlášeny, neprodiskutovány (byla to mnohem větší katastrofa než ukončení 2.x řady Pythonu) - bylo to v době, kdy byl vývoj Javy čistě interní záležitostí Sunu.Který to byl přibližně rok nebo verze Javy? Marně přemýšlím, co konkrétně myslíte.
assert
ve verzi 1.4 nebo klíčové slovo enum
ve verzi 5?
protože s tím nikdy nebyl žádný problémNikdy jste neměl proměnnou nazvanou
enum
?
který pak prezentujete pomalu za pravdu božía někdy se jedná opravdu o ničím nepodložené bludy.
...Já osobně jsem od pythonu upustil, ale ty změny v trojkové řadě se mi zdají jako dobrý směr, hlavně unicode.
program | less
ls --output-format=xml
. Každý program však má vlastnú množinu datových typov (rôzne namespaces), každý formát má rôzne utility ...Moje predstava byla takova, ze kazda utilita by mela svuj vlastni format vystupu (ktery by na zacatku ohlasila), ale ten metaformat ...Toto spĺňa aj súčasný textový formát
Serializace neznamena nutne textovy interface (viz tez Protocol Buffers).Potrebuješ parser. Aj napr bzip/gzip textové data chápem textové.
Samozrejme, krome casu a zajmu o jine veci, mi nic nebrani si to naimplementovat. Nechci se tim zkratka zabyvat, presto si myslim, ze by to inovace byla.z toho vyplýva, že navrhovaná invácia nemá pre teba praktický význam.
stále je tam parser, je jedno, či textový, alebo binárny.
popisovaná modelová situácia má však muchy ... hlavnou je použitie nesprávneho nástroja. Áno, bolo by pekné, keby vedeli medzi sebou programi komunikovať na XML úrovni, ale načo? Na podobné veci sú tu iné nástroje, (takisto by niekto mohol požadovať zotriediť súbory podľa dňa v týždni alebo intervalu od vopred zadaného dátumu ...). A na rozdiel od shell prístupu tento prístup neťahá množstvo informácii zbytočne.
To je mi ale plamenů. A proč by se nemělo dát používat obojí. Kdo chce s Bashit nechť si bashí, kdo chce Pyhonit nechť si pythoní (perluje, javascriptuje, visuálbasicuje, ....)
Každý přístup má své klady a zápory, proč se omezovat jedním řešením?