Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Další zásadní nevýhoda (těchto nástrojů obecně) je to, že když odtamtud chceš vykopírovat víceřádkový text, tak se text označuje po řádcích napříč těmi virtuálními okny. Tyhle nástroje byly nejužitečnější v dobách textových terminálů a konsolí (bez X). Ale když už člověk GUI má, tak je lepší i pro tohle používat GUI nástroje (např. rozdělení pohledu v Konsoli nebo to řešit na úrovni DE a mít více oken), které jdou ovládat i klávesnicí.
Další zásadní nevýhoda (těchto nástrojů obecně) je to, že když odtamtud chceš vykopírovat víceřádkový text, tak se text označuje po řádcích napříč těmi virtuálními okny.A nefunguje tam scrollování (samozřejmě to má vlastní scrollback, ale ten nereaguje na grafické posuvníky X terminálu, tažení myší atd.). To je hlavní důvod, proč to nepoužívám.
Další zásadní nevýhoda (těchto nástrojů obecně) je to, že když odtamtud chceš vykopírovat víceřádkový text, tak se text označuje po řádcích napříč těmi virtuálními okny.konsole umí blokové označení - Ctrl + Alt + táhnu myší.
A nefunguje tam scrollování (samozřejmě to má vlastní scrollback, ale ten nereaguje na grafické posuvníky X terminálu, tažení myší atd.). To je hlavní důvod, proč to nepoužívám.V tmuxu mám nastaveno
bind -n M-Pageup copy-mode -eu
(tj. alt + pgup) na vstup do scrollback režimu, funguje mi v tom módu i kolečko myši. Ale osobně mi stačí pgup a pgdown, v lokálních sessions taky používám jen shift+{pgup, pgdown, home, end} a scrollbar nemam zobrazený (popravdě mi moc není jasný, k čemu v terminálu je).
Jak řeší lidé, kteří nepoužívají screen nebo tmux, když chtějí někde spustit nějakou dlouho trvající operaci třeba s nějakým výstupem a mezitim třeba měnit svoji fyzickou lokaci, připojení apod.? tmux mi na tohle přijde krásně pohodlný.
V tmuxu mám nastaveno bind -n M-Pageup copy-mode -eu (tj. alt + pgup) na vstup do scrollback režimu, funguje mi v tom módu i kolečko myši.Hmm. Já dělám velmi často to, že někde začnu označovat a táhnu a ono to scrolluje. A pak taky používám funkci na zkopírování celého scrollback bufferu do schránky (používám Terminator (GTK2 verzi) a tam je na to plugin), to by byl dost opruz implementovat když mi tam běží SSH (muselo by se to připojit na ten stroj a dumpnout scrollback z tam běžícího screenu/tmuxu, kterých navíc může být několik). A dost často potřebuju abych mohl ve scrollbacku hledat i když spojení na vzdálený stroj už není (umřel, reboot, …).
a scrollbar nemam zobrazený (popravdě mi moc není jasný, k čemu v terminálu je)Pro odhad velikosti scrollbacku a kde se v něm zhruba nacházíš. Ano, asi bych dokázal vymyslet praktičtější indikátor.
Jak řeší lidé, kteří nepoužívají screen nebo tmux, když chtějí někde spustit nějakou dlouho trvající operaci třeba s nějakým výstupem a mezitim třeba měnit svoji fyzickou lokaci, připojení apod.?Ano, tohle je jediný use-case, kdy screen používám. (a samozřejmě nadávám když něco spustím bez něj, trvá to dýl než jsem čekal, a reptyr/retty řekne něco o tom že process grupa má blbě filedeskriptory a nejde to přehodit)
a samozřejmě nadávám když něco spustím bez něj, trvá to dýl než jsem čekal, a reptyr/retty řekne něco o tom že process grupa má blbě filedeskriptory a nejde to přehoditpřesně tak
Jak řeší lidé, kteří nepoužívají screen nebo tmux, když chtějí někde spustit nějakou dlouho trvající operaci třeba s nějakým výstupem a mezitim třeba měnit svoji fyzickou lokaci, připojení apod.? tmux mi na tohle přijde krásně pohodlný.
Přesně k tomu ten GNU Screen používám. Ale to ostatní mi přijdou takové rovnáky na ohýbáky. Když už mi tu běží desktop s GUI, tak dává smysl používat primárně GUI nástroje – nikoli textové nástroje, které vznikly v prostředí, kde neexistuje WM nebo DE, takže se správa oken nebo třeba schránka musela řešit jinak a v tom textovém režimu.
Když mi screen/tmux poběží přes SSH na jiném stroji, tak tam asi těžko bude fungovat jeho schránka sdílená mezi jeho instancemi. Já ten text potřebuji dostat do schránky v X, což je standard používaný napříč aplikacemi v mém pracovním prostředí.
Blokové označení sice funguje, ale vloží mi tam zalomení řádků, kde nemá být. Zatímco když v Konsoli vykopíruji třeba dlouhý příkaz (přes několik řádek) nebo dlouhý výpis, který je zalomený tou Konsolí, aby se vešel do okna, tak mi to zachová původní řádky, ale když mi ty řádky zalamuje screen, aby se vešly do jeho oken, a vykopíruji z toho blok textu, tak v něm mám i tato nežádoucí zalomení.
Pokud jde o klávesové zkratky, ty mohou úplně stejně fungovat i v GUI aplikacích. GUI resp grafický režim neimplikuje nutnost používání myši.
Jinak tedy: i když mi tu běží Xka a KDE, tak tu mám plno oken s textovými terminály, běží mi tu Emacs v textovém režimu, docela rád používám Midnight Commander a používám i ten Screen… ale nedělal bych z nouze ctnost – třeba ten mc
používám, protože mi vyhovuje jeho jednoduché UI, používám ho navzdory tomu, že je textový, nikoli proto. (samozřejmě používám i Dolphin, někdy přetahuji soubory myší, někdy kopíruji přes schránku, někdy s nimi pracuji přes příkazový řádek… prostě používám způsob, který mi v danou chvíli přijde nejvhodnější)
Vždyť o tom mluvím výše:
Ale když už člověk GUI má, tak je lepší i pro tohle používat GUI nástroje (např. rozdělení pohledu v Konsoli nebo to řešit na úrovni DE a mít více oken), které jdou ovládat i klávesnicí.
Na tom není co řešit – tohle už je vyřešené – třeba v té Konsoli, ale věřím, že i v jiných emulátorech terminálu. Prostě jen označíš myší kus textu, vykopíruješ třeba do editoru a zachová ti to původní řádky, i když v tom emulátoru terminálu byly zalomené, aby se vešly do okna.
afl-fuzz
, který běžel v několika instancích výsledku asi tejden. Na to ti je lokální GUI k ničemu.
*) Nefungovalo by to pro CLI aplikace kreslící okýnka jinak než pomocí VT box/line drawing charset, ale to většina afaik nedělá.
konsole by mohla vědět o těch "okýnkách" které kreslí curses-based a podobné CLI/TUI aplikace (protože ty informace většinou stejně už má - musí je vést v rámci vt102 state machine a potřebuje je k renderování), takže by mohla umět vybírat text v TUI "okýnku" *.
Byl by k tomu nějaký zdroj? Tohle se mi nějak nezdá.
Asi nemyslíš to, že by Konsole koukala na změny barev nebo hledala znaky jako │ a podle nich odvozovala, že to je okno a text pokračuje na dalším řádku, ne?
Nefungovalo by to pro CLI aplikace kreslící okýnka jinak než pomocí VT box/line drawing charset, ale to většina afaik nedělá.
Aha, takže asi myslíš. To je právě ten rovnák na ohýbák. Jasně, nějaká taková chytristika by tam být mohla, stejně tak by to mohlo umět třeba vybírat sloupce z výpisů relpipe-out-tabular
, ale otázka je proč? Resp. proč nepoužít raději to rozdělení pohledu v Konsoli nebo obdobnou funkci v jiném emulátoru terminálu nebo třeba možnosti DE (klidně dlaždicového) a otevřít si víc oken.
Asi jediný smysl by byl pro vzdáleně běžící aplikace ve screen
u, kde ti stačí jedno SSH spojení přes které protáhneš víc oken a víc výstupů vzdálených aplikací (i když SSH tedy umí multiplexovat a sdílet jedno TCP spojení pro víc relací).
Byl by k tomu nějaký zdroj? Tohle se mi nějak nezdá. Asi nemyslíš to, že by Konsole koukala na změny barev nebo hledala znaky jako │ a podle nich odvozovala, že to je okno a text pokračuje na dalším řádku, ne?TUI aplikace typicky nerenderují znaky jako │ , i když ti to tak může připadat. Viz třeba tady, VT102-like state machine má 4 "sloty" pro "znakovou sadu". Tohle samozřejmě pochází ještě z doby, kdy nebyl Unicode etc., těch znak existuje několik pro různé jazyky + sada pro kreslení rámečků. V praxi se dnes používá pouze sada "US ASCII" (reálně Utf-8), kód 'B' a právě sada pro rámečky - kód '0'. Pomocí příslušných escape sekvencí si aplikace nastaví, která sada má být v jakém slotu a pak aktivuje příslušný slot pro např. kreslení rámečku buď natrvalo nebo pro následující znak. Napiš si do terminálu
echo -e '\e)0\xe'
a sleduj, co se stane Asi jediný smysl by byl pro vzdáleně běžící aplikaceAno, to mám samozřejmě na mysli, však to taky píšu v tom komentáři
Tohle jsem myslel tím, že ten emulátor v podstatě už má ty informace o hranicích těch "okýnek", protože ví, jaký znak kreslí jakou "znakovou sadou"
Zajímavé, dík.
Nechceš to tedy do té Konsole doimplementovat? :-) Asi jako další režim výběru (vedle normálního a blokového), který označoval text uvnitř rámečku.
A jak to dostaneš do nějaké GUI aplikace? Nebo třeba i do textové, ale běžící v jiném okně, na jiné ploše atd.?
pouzivam Byobu(nad tmux), rozlozeni si pamatuje (s trochou kompromisu(mc obnovi jen 1 panel a pokud je mc pres sudo, tak je potreba jit do ciloveho adresare pred pustenim mc) i po rebootu pri pridani tmux-resurrect pluginu), viceradkove kopiruju tak ze dane cast prepnu do fullscreen... pouzivam to primarne na ssh->server->byobu ale i na lokalnim NB, pouzit GUI nastroj nepotrebuju a predpokladam ze bych o cast funkci stejne priselDalší zásadní nevýhoda (těchto nástrojů obecně) je to, že když odtamtud chceš vykopírovat víceřádkový text, tak se text označuje po řádcích napříč těmi virtuálními okny. Tyhle nástroje byly nejužitečnější v dobách textových terminálů a konsolí (bez X). Ale když už člověk GUI má[...]
Spravovat vic jak 10 stroju je prace pro CM (CFEngine, Puppet, Chef, SaltStack, Ansible)Ne když na každém běží úplně jiné věci.
+1, starám se o celkem dost strojů (fyzických bude tak kolem deseti, ale virtuálek mnohem více), ale každý je v podstatě unikátní, každý dělá něco jiného, takže to moc automatizovat nejde. (maximálně tak automatizovat apt update ; apt full-upgrade
)
Tedka se pohybuju v prostredi, kde jdou stroje do tisicu a to je manualne nezvladatelne.Tak to je pochopitelné. Já mám tu výhodu, že se jedná o linuxové desktopy u kterých je žádoucí aby měly podle potřeby identické softwarové vybavení. Toho jsem dosáhl tím, že používám dynamický ramdisk. Stroj dostane z DHCP hostname, a na základě toho se mu předhodí konfigurace do ramdisku. Tím odpadá konfigurace pxe menu, protože je pro všechny stroje stejná. Pochopitelně situace, kdy je třeba instalovat tisíce strojů, které si pak mají žít vlastním životem, nebo mají sloužit pouze jako kontejner pro nějakou webovou appku je to pochopitelně jiné.
Pochopitelně situace, kdy je třeba instalovat tisíce strojů, které si pak mají žít vlastním životem, nebo mají sloužit pouze jako kontejner pro nějakou webovou appku je to pochopitelně jiné.
Ty můžou být taky bezestavové a pokud jich je hodně stejných, tak by to šlo řešit podobným způsobem, jako ty tvoje desktopy. Sice třeba ne přes PXE, ale tak, že by se do nich nezasahovalo, nikdo by je nespravoval a prostě by se celá virtuálka zahodila a spustila by se nová z aktualizované šablony. V případě třeba různých proxy nebo DNS serverů to může být docela dobré řešení, pokud jich má člověk hodně.
Rovnice je: smysl=zisk/namahaAno, toto je dost podstatné. Sám jsem se ansible poctivě snažil používat asi dva roky na skupině stejných serverů do počtu dejme tomu 30 a použití ansible bylo mnohem pomalejší a náročnější, než to dělat ručně. Bylo to v době hype kolem "pokud se přihlašujete na servery ručně přes ssh, tak to děláte blbě" kdy mnozí doporučovali to používat i na jeden stroj. Možná je to tím, že jsem za ty roky praxe se stovkami serverů zvyklý ty věci dělat rychle a na lecos mám svalovou pamět, nebo tím, že mi příliš nevadí občas dělat 30 stejných opakujících se akcí nebo nevím, ale ansible (zkoušel jsem puppet, díval jsem se i na chef, ansible mi přišlo nejlepší) bylo prostě násobně pomalejší a náročnější. Už třeba jen oprava chyb. Když mám v hosts 30 strojů, tak chyba se jedním příkazem dostane na všech 30 a služba na všech strojích nejede*. Je tedy potřeba mnohem více testovat. Když se uklepnu při nastavení jedné služby na jednom stroji, tak to zjistím okamžitě a oprava je prakticky hned. Tj minimální plocha a minimální čas. Chápu, že pro tisíce serverů už je automatizace nutnost a nějaké testování na testovací skupině 100 strojů je součástí práce. Další věcí jsou chybějící moduly. V době, (tj tak dva roky na zpět), když jsem ansible používal, tak krom notoricky provařených věcí chyběly moduly na všechno. Rady "najděte si to na internetu" jsou úsměvné. Prošel jsem si několik modulů, které lidi prezentovali na githubu a všechny byly špatně (nebo ne špatně, ale téměř okamžitě jsem viděl možnost, jak je rozbít). Zcela evidentně je psali lidé, kteří o dané problematice (tj o tom, co se má nastavit) nevěděli vůbec nic a jen nadšeně napsali modul na první use case, který jim fungoval. Toto není profesionální přístup ani vhodné doporučení pro profesionální nástroj. Takže ansible nakonec používám pro primitivnější věci. Sjednocení základních balíčků (všude chci mít nějaké balíčky a je celkem opruz navštívit všechny stroje, pokud se rozhodnu přidat další balíček), výměna klíčů a nějaké základní služby. Určitě by to šlo jinak, dřív jsem měl deb balíček bez obsahu ale s nastavenými závislostmi na jiných balíčkách, takže stačilo udělat update tohoto balíčku a všechny ostatní závislé balíčky se nainstalovaly automaticky. Apod. *) Úplně klasická chyba je správa ssh klíčů. Ansible se připojuje na stroj přes ssh, je prakticky nutné používat klíče a má i modul na správu ssh klíčů. No takže, se stalo, že jsem si takto vymazal přístupové klíče a už jsem se tam nepřihlásil a ansible pochopitelně taky ne. (Komu se nikdy nic podobného nestalo, až si to hodí
A někdo řekne, ano, je to deklarativní popis toho, jak vypadá server. Ale je opravdu? Když přijde někdo nový a zeptá se "jak mám dostat server do provozního stavu" a odpovědí mu je: nainstaluj minimal a spusť tam playbook. Ok, server se mu přivede do produkčního stavu. Potom začne ten playbook studovat a vidí tam Tasky: Remove Apache, Install nginx. No ale na tom jeho stroji žádný apache nebyl. Ten playbook najednou nedává smysl (i když ve výsledku dělá, co má - task remove apache prostě proběhne a po jeho ukončení tak apache skutečně nebude), ale z hlediska dokumentace stroje to příliš smysl nedává.
To mi připomíná aktualizaci datového modelu. Tam ti po letech taky vznikne dlouhý seznam postupných kroků, které historicky dávaly smysl, ale když konfiguruješ nové prostředí, tak tě to fakt nezajímá a nechceš si tou celou historií procházet (byť automatizovaně). Řešením je si tam udělat nějaké „záchytné body“ – typicky pro major verze – které popisují stav v tom bodě. A inkrementálně se nasazují pouze změny zavedené v rámci jednotlivých minor verzí.
Prošel jsem si několik modulů, které lidi prezentovali na githubu a všechny byly špatně (nebo ne špatně, ale téměř okamžitě jsem viděl možnost, jak je rozbít). Zcela evidentně je psali lidé, kteří o dané problematice (tj o tom, co se má nastavit) nevěděli vůbec nic a jen nadšeně napsali modul na první use case, který jim fungoval.Jako bys mi z duše hovořil. A to neplatí bohužel jen pro ansible a orchestrační nástroje.
1
true
true
true
true
true
true
U disklessu se také využívá swapovací oddíl, pokud existuje. Ale ty stroje mají různou HW kombinaci, což vyžaduje plnou kontrolu nad tím co se děje, a to ansible nezajistí. Přes hromadný vzdálený přístup velice rychle – vizuálním srovnáním – zjistím, u kterých strojů jsou přehozené disky, kde chybí swap, který stroj má málo paměti, kde se v dmesgu objevují chyby. A případně mohu odstartovat smart aby se disky otestovaly. & etc. & etc. Fantazii se meze nekladou.Tak na tohle pouzivam monitoring, ktery zjisti, jak se veci maji a v pripade neschody me na to upozorni. A protoze si nehodlam pamatovat kraviny, tak jak maj veci vypadat mam napsane v souboru. A kdyz uz jsem se obtezoval to nekam napsat, tak mam ansible, aby zajistilo, ze je vsechno udelane tak jak bylo definovano.
…ale prislo mi to jen jako oda na cssh (nic proti tomu).No tak to ti opravdu jen tak přišlo, poněvadž primárně jsem chtěl upozornit na terminator, který umí něco podobného, ba i něco navíc.
…a pokud mozno tezce nahraditelny :)Ó kéž by tomu tak bylo. V takovém případě skonám s klidem v duši, až mě skolí někdo na přechodu. Bohužel realita se zdá být poněkud jiná. Pokud bys věděl o takových náhradách, sem s nimi. Rád jim svoje know-how předám dřív než na to dojde.
~/.ssh/config
distribuciu ssh kluca na vzdialeny server riesi ssh-copy-id
inak pekny prehlad, vdaka!
Máš pro každý vzdálený server unikátní pár klíčů?
Tiskni
Sdílej: