Újabb problémák az Ubuntu Rust-alapú GNU coreutils helyettesítővel

Él nélkül kérdezem: pl a 22.04-nél a pro támogatás 2032-ig mit jelent? Addig tolják ki rájuk a friss browsereket is, vagy egy idő után már csak sec fixeket backportolnak?

Nem tudtam hogy trey ilyen "laggard" (ő szokta mondani), bezzeg én már Debian 13-on vagyok :D

Az a baj, hogy erről többet beszéltünk, mint a hüvelygombáról, csak képtelen vagy megérteni. 2032-re a 22.04 és 2034-re a 24.04 csomagverziói teljesen elavulnak. A Linux világa gyorsan változik, csak az utóbbi pár év (nem egész évtized) termése: Wayland kényszerítése, Wayland portálok, Pipewire, Wireplumber, dbus-broker, systemd-homed, systemd-bsod, Proton, DXVK, NTsync, Wine WOW64, OOMkiller, számos újabb Gtk és Qt és glibc főverzió, Bash 5.x, stb.. Ez nem az a műfaj, főleg desktopon, ahol 10 évig hátradőlhetsz, és nem lesz változás. Szerveren vagy ipari vezérlőn, embedded eszközön talán még elmegy, hogy ha valami régi PHP, Python verziós cuccot kell kiszolgálni, egy 10 éves rendszer arra még alkalmas, de desktopon agyhalál lesz, addigra talán már az univerzális csomagformátumok se fognak vele menni.

Az is egy magoldás, hogy időben mindig átmész a következő LTS-re, 26.04, 28.04, és kézzel telepíted a gnu-coreutilst, ami lecseréli a default uutilst, de ha már kézileg kell hekkelni az Ubuntu értelmét veszti, ha kézimunkára vágysz, arra van vagy tucat jobb disztró.
 

Attól függ.

Nekem pl van olyan docker compose alapon futtatandó alkalmazásom ami az újabb composer-t igényli ami az újabb dockert igényli ami nincsen 22.04-en. 
Nyilván nem leküzdhetetlen akadály.

Mert olyan gépem van (Lenovo T470), amin az újabb verziók már nem adnak semmit. Nem akarok a waylanddal és egyebekkel szívni, nekem csak az kell, hogy működjön.

Ez szerintem 10.1-es openssh kliens verzió felett jön elő, ha a szerver verzió viszonylag régi. Itt vannak a részletek: https://www.openssh.org/pq.html

RHEL8 és társai mutatják pár hete. Így buzdítva az embert a frissítésre, hiába lenne még vagy 4 évig supposed.

Már leírtam egyszer, Shor algoritmussal eddig a 7x3 = 21 volt a legnagyobb publikus kulcs, amit sikerült faktorizálni.

Na, majd ha 1000 bit körül járnak, akkor kezdhetünk aggódni. Hagyományos algoritmussal eddig 829 bites RSA-t már faktorizáltak, elképzelhetőnek tartom, hogy NSA szintű helyeken az 1000 bitet is tudják, de hogy nem kvantumszámítógéppel, abban biztos vagyok.

hat ez az. es akkor mi lesz? latni fogjak hogy kiadtam az ls parancsot?

mert belepni ugysem fognak tudni, nincs kint a neten az ssh.

Hát, ezt tudjuk kevésbé megmondani előre :)

bele lehet qrni az egész json kezelő library-t dependencyként, majd nézd meg mekkora resource footprint lesz belőle. Neked otthon mindegy de egy AWS szinten már a villanyszámlában nagyon nem

tényleg azon aggódunk abban a világban, ahol egy random telepítés hoz magával pl egy teljes python szinte bármiben, hogy oda kéne még tenni egy párszáz Ks json libraryt a C vagy a rust mellé? Tényleg azon aggódunk, hogy az alapvetően managementre való (értsd mivel nem workload, kb mérhetetlen arányban futó) eszközök majd sokkal több energiával fognak futni? Zárójel kinyit, ráadásul messze nem vagyok megyőződve róla, hogy ez tényleg igaz, a json egy viszonylag hatékony formátum viszonylag jól megírt parserekkel, főleg ha azzal kell hasonlítani, hogy | grep | tr -s| cut | vagy mondjuk vmi awk, zárójel bezár.

arról nem beszélve hogy akkor az egész scriptkupacot át kéne migrálni ennek az inputnak a kezelésére.

Ezt nyilván inkermentálisan kell csinálni.

Van is egyébként már azért jó pár eszköz, ami egyébként tud is ilyet már, pl az 'ip', a systemd suitnak is vannak részei

(miközben látható h az eddigi limited scope-ot sem sikerült kezelni)

Egyébként tényleg ennyire gyász a helyzet? Mert ha jól értem, eddig volt egy kis baj a date-tel, meg most kiderült, hogy hiányoznak darabok a du-ból meg a sort-ból. Ami azért egyrészt nem akkora rohadtnagy tragédia egyébként a scopehoz képest (persze ettől még nem is jó, a sort talán a leggányabb), másrészt eléggé felveti a kérdését annak, hogy itt tényleg a babzsákfejlesztőkkel van-e a baj, vagy azzal a hülyével, aki a drop-in replacement szót találta használni (esetleg azzal a hülyével, aki elhitte az elmúlt tízensokév után, hogy bármilyen drop-in replacement tényleg az lesz). Mert azért mikor az hangzik el, hogy "In fact, it turns out that the Rust-based sort replacement is incomplete — only implementing a portion of the GNU sort function." akkor bizony gyanús, hogy itt nem feltétlen arról van szó, hogy nem tudnak tesztelni, hanem ez vagy nincs kész, és mégis be lett management tolva, vagy eleve nem is volt terv, hogy tök kompatibilis legyen. Ez utóbbit explicit cáfolja a repó, és azért az is látszik, hogy egyébként futtatják a gnu tesztjeit, és fekete-fehéren (well, színesen, de érted) oda van rajzolva, hogy a 600 környéki tesztből még bukik úgy 75 meg skippelve van vagy 50. Szóval a fejlesztés még nem tart ott, hogy legalább azon el kelljen kezdeni gondolkodni, hogy ennyi teszt elég-e, vagy valójában az eredeti coreutils tesztkészlete fos, és még csomó minden hiányzik... ez ki is van téve az ablakba, aztán valaki mégis úgy döntött, hogy beemeli. Nekem gyanús, hogy itt nem babzsák probléma van.

(Az meg, hogy ennek az egésznek mi köze van az edge computinghoz, azt kifejthetnéd)

Egyébként a powershell azért jó, mert tökéletesen rámutat, hogy két alapvetően teljesen más igényhalom van.

A rendes shell interaktív munkára nagyon jó, de -- tudom, majd mindjárt jönnek a hívők -- programozni az egész egy kifejezett határfos. Az egész kártyavár space delimited hell, meg az egész execution pipelinet végigszopató parsing és santizáció (idézőjelek ugye) alapvetően szar ötlet. Ehhez képest a powershell remekül megmutatja, hogy

• egy object pipeline sokkal normálisabb scriptelésre
• egy object pipeline, pláne ha -javaProgramozós kapcsolónevekkel van megverve kibaszottul szar ötlet interaktívan :)

Ha csak új mezők kerülnek be, akkor még megmaradhat a kompatibilitás. Nyilván, ha egy régi át van definiálva, akkor nem, de az ritka eset.

Persze, olvasni jó is a két oszlopos. Itt épp arról beszélünk, amikor nem olvasni kell, hanem az adott értéket felhasználni.

Nyilván emberi fogyasztásra jobb szépen printelni, de a gép igényei mások.