VST 3 je nově pod licencí MIT. S verzí 3.8.0 proběhlo přelicencování zdrojových kódů z licencí "Proprietary Steinberg VST3 License" a "General Public License (GPL) Version 3". VST (Virtual Studio Technology, Wikipedie) je softwarové rozhraní pro komunikaci mezi hostitelským programem a zásuvnými moduly (pluginy), kde tyto moduly slouží ke generování a úpravě digitálního audio signálu.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 25.10. Podrobný přehled novinek v poznámkách k vydání.
V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
Gemini CLI umožňuje používání AI Gemini přímo v terminálu. Vydána byla verze 0.10.0.
Konference OpenAlt 2025 proběhne již příští víkend 1. a 2. listopadu v Brně. Nabídne přibližně 80 přednášek a workshopů rozdělených do 7 tematických tracků. Program se může ještě mírně měnit až do samotné konference, a to s ohledem na opožděné úpravy abstraktů i případné podzimní virózy. Díky partnerům je vstup na konferenci zdarma. Registrace není nutná. Vyplnění formuláře však pomůže s lepším plánováním dalších ročníků konference.
Samsung představil headset Galaxy XR se 4K Micro-OLED displeji, procesorem Snapdragon XR2+ Gen 2, 16 GB RAM, 256 GB úložištěm, operačním systémem Android XR a Gemini AI.
Před konferencí Next.js Conf 2025 bylo oznámeno vydání nové verze 16 open source frameworku Next.js (Wikipedie) pro psaní webových aplikací v Reactu. Přehled novinek v příspěvku na blogu.
Sovereign Tech Fund oznámil finanční podporu následujících open source projektů: Scala, SDCC, Let's Encrypt, Servo, chatmail, Drupal, Fedify, openprinting, PHP, Apache Arrow, OpenSSL, R Project, Open Web Docs, conda, systemd a phpseclib.
Bylo vydáno OpenBSD 7.8. S předběžnou podporou Raspberry Pi 5. Opět bez písničky.
Valkey (Wikipedie) byl vydán v nové major verzi 9.0. Valkey je fork Redisu.
require "my-evil-script.rb", vim se přepne do ruby-mode, a v site-packages se objeví váš zákeřný exploit, aby jej vim mohl spustit?
system("echo #{$:.inspect} >> /tmp/zde_je_pako")
.
3. krok (pokud vám to ani teď nedocvaklo) - zamyslete se nad tím, jestli je třeba možné, že by někdo pustil VIM z adresáře /tmp/.
4. krok a) pokud vám to už docvaklo, nasypte si popel na hlavu a příště před psaním ironického příspěvku přemýšlejte, b) pokud se cvaknutí stále nedostavilo, změňte povolání
I ten loading kvůli zjištění názvů metod by měl jít celkem rozumně zasandboxovat. Jen by se o to měl přičinit autor...
".", je to jistý bezpečnostní nedostatek, ovšem pro Ruby, ne pro Vim.
2) Pusťte si Bash. Pod rootem napište echo >/etc/povolny_je_pako, a stiskněte ENTER (ta velká klávesa napravo se zalomenou šipkou). Ha! bash je děravý.
3) To samozřejmě možné je, ale netuším co tím chcete dokázat.
4) Myslím že vaše rady nebudu brát příliš vážně.
1) pokud má Ruby jako prioritní search path pro moduly ".", je to jistý bezpečnostní nedostatek, ovšem pro Ruby, ne pro Vim.
Jako prioritní ne, ale v serch path '.' má a to stačí. A problém VIMu to je, protože mluvíme o variantě, kdy je VIM linkován s Ruby a VIM nevhodným způsobem Ruby používá (nenastavuje $SAFE).
2) Pusťte si Bash. Pod rootem napište echo >/etc/povolny_je_pako, a stiskněte ENTER (ta velká klávesa napravo se zalomenou šipkou). Ha! bash je děravý.
No to je dost mizerný vtip a ještě horší přirovnání.
3) To samozřejmě možné je, ale netuším co tím chcete dokázat.Třeba to, že exploit zranitelnosti, kterou jsem popsal je poměrně proveditelný.
Jinak než z již vykonaného kódu se v jazycích jako Python, Ruby a Lisp doplňovat prostě nedá. Používám hlavně Slime, takže mi to vlastně ani nevadí a už mi přijde úplně přirozené, že completion bere v úvahu kód, který jsem již napsal, načetl a vyzkoušel. (Stejně si ho člověk krátce po napsání chce taky vyzkoušet, že jo...
) Třeba ty accessory v Ruby a v Lispu prostě jinak zjistit nejdou, leda, že by se udělala ad-hoc omezená statická analýza omezená pouze na standardní jazyk. Což by ve větším kódu asi dlouho nevydrželo.
(Forth vynechám, ten je na tom teoreticky nejhůř, ale asi se neočekává, že by někdo do několikakilobajtového softwaru montoval Visual Studio
)
Slime to řeší úplně jednoduše s přímočaře. C-c C-k provede compile-file a load. Tím pádem se dostane kód do běžícího lispu a je přístupný pro swank (serverová část Slime). Completion je řešená na straně serveru, tedy v tom bežícím procesu. Slime klient v Emacsu tedy nepředstírá, že umí doplňovat symboly z aktuálního souboru - to umět samozřejmě nemůže.
Tahá si je ze spuštěného image.
Zákonitě se nenajde nikdo, komu by to vadilo, přestože jde o tentýž proces, jako v případě Vimu a Ruby.
Jediný rozdíl je v tom, že tady je ta kompilace explicitní.
Mimochodem, fuzzy code completion ve Slime je z pohledu lispera úplný mazlíček. Třeba negado expanduje na most-negative-double-float, wiof na with-open-file...prostě expanduje podle procenta fuzzy matche dost vychytaným způsobem...
To by možná ocenili i javisti a C#aři, kdyby jim oumeme + TAB samo vyhodilo OutOfMemoryException (OutOfMemoryError) a nemuseli se se vším tak psát, zvlášť, když z toho dělají proměnnou a musejí to psát dvakrát.
Docela by mě zajímalo, co na tomhle poli šikovných fíčur vznikne v průběhu příštích dvaceti let a jak se s tím editory vypořídají.
if ($a == ($b ± autobus)) {
...
}
hmm, a to sa jeden čuduje, prečo im ten vývoj trvá tak dlho
On je trochu rozdíl mezi textovým editorem a interaktivním interpretrem. VIM se pokud vím interaktivním interpretrem nenazývá
Spousta editorů ten interpret obsahuje nebo nějaký umožňuje používat. Nehledě na to, že já zásadně nepoužívám textové editory. Používám výhradně interaktivní interpret Emacs Lispu, který se (jen) jako textový editor defaultně tváří.
Na běžné věci používam Kate a když programuju v Pythonu tak Eric3 (který autocompletion v Pythonu dělá a to aniž by vykonával kód
). Sice v něm to doplňování kódu asi nebude tak "dokonalé" jako v editorech který ten kód vykonávají, ale mně to stačí a nemusim se bát, že mi textový editor napáchá škody v systému
No a jako interaktivní interpretr nejčastěji používám výborný IPython, ten nemá konkurenci
A v konzoli třeba na editaci konfiguráků mi bohatě stačí nano
Možná by to stálo za nějaký Slime-reklamní blogpost. Nebo rovnou video.
http://common-lisp.net/movies/slime.mov
No jo, ale já stejně přemýšlím, že v téhle zemi se tvoří příliš málo screencastů...
Taková skvélá forma sdělování informací a ono kde nic, tu nic.
(((vím, ((jsem ignorant) a tohle) je) poněkud laciný) (humor))
Neupírám Vimu jednu přednost: Mnoho textových editorů obsahuje závažný bug, který náhodně poškozuje editovaný text a vkládá do něj náhodný šum, například :wq!, ZZ nebo qq. Ani Emacs se tomu nevyhnul. Vim je zato z nějakého důvodu imunní.
Mimochodem, převeďte si "vi vi vi" z římských číslic na arabské a pochopíte postoj Církve Emacsu k tomuto tématu...
Statickým parsingem zase všechny metody člověk nezjistí, nebo aspoň ne obecně. Můžu mít ošetřený attr_reader, attr_writer a attr_accessor, ale podobné "metaprogramovací metody" si člověk může nadefinovat sám a pak je editor bez pomoci v pytli.
Vítejte do světa dynamických jazyků...
Jó, kdo přičichne k lispu, uvědomí si, že i pouhá kompilace může mít side-effecty, protože při ní dochází třeba ke spouštění makrofunkcí (ty side-effecty ovšem mohou být záměr).
)
Tiskni
Sdílej: