Egy Microsoft frissítés eltörte a VS Code-ot Ubuntu-n (18.04 LTS)

Microsoft, Windows

FYI: amennyiben használod, olvasd el ezt és ezt.

( trey | 2024. 02. 04., v – 10:52 )

VS Code 1.86 (aka the ‘January 2024’ update) saw Microsoft bump the minimum build requirements for the text editor’s popular remote dev tools to ≥glibc 2.28 — but Ubuntu 18.04 LTS uses glibc 2.27, ergo they no longer work.

While Ubuntu 18.04 is supported by Canonical until 2028 (through ESM) a major glibc upgrade is unlikely.

trey @ gépház

Egyrészt áprilisban lesz EOL (tudod, öt év)

Plusz azt hiszem, a 18.04-re is van Ubuntu Pro, ami újabb öt év támogatást ad.

És ami jól működik, azt minek piszkálni?

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Pontosan erről írtam már többször, amikor nem értettétek, hogy mi a baj ezekkel a 100 évig támogatott disztrókiadásokkal. Ez egy szép példa rá, és kivételesen nem is a MS hibája, mert ők becsülettel léptetik a függőségeket, hogy ne avuljanak el, meg ne épüljön a szoftvere sérülékeny komponensre. Ez az, amiben a rolling disztrók jók, általában mindegyik kellően friss, ilyenből sosincs gond, hogy valamiből frissebb függőség kell, simán fordul mindenféle kód is emiatt, sokkal könnyebben.

Pedig az Ubuntu 18.04 még nem is annyira régi, mindössze „csak” 6 éves se egészen, még 4 évig támogatott lenne Pro keretében, de minek, ha már most törnek el dolgok rajta. A MS még így is türelmes volt, hogy eddig 2.27-en hagyta a cuccot, az egy 6 éves verzió, a glibc most a 2.39-nél tart. Így aki még Ubunu 18.04-et használna desktopon, az vagy most upgrade-el 20.04-re vagy még jobb, ha 22.04-re, vagy VS Code-ból futtat régebbi verziót, vagy Snap-ként, Flatpakként, stb. használja (mert azok a saját függőségeikkel jönnek).

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

...nem értettétek...

...ne avuljanak el...

Egy ennyi idős függvénykönyvtár, mint a libc, mivel avul el? Kíváncsi lennék, hogy mi változott meg abban a libc-ben, ami miatt kell az újabb verzió. Vagy csak simán verzióbuzulás. Kijelölték, hogy nekik mostmár ez kell. Nehogy ósdinak hasson, hogy a mi cuccunkhoz ilyen régi libc kell.

Ez szép és jó. Találnak valami sérülékenységet. Változik az implementáció. De nem gondolnám, hogy egy libc beli függvény hívásának alakja megváltozna.

Pusztán valamit egy verzióhoz kötni.

Az más, ha a libc-ben lett egy új függvény, ami kell a program új verziójához.

A verziók elavulnak, nem maga a libc. Főleg a Linux világa olyan, hogy rohadt gyorsan röpködnek az új verziók, meg történnek az állandó nagy váltások, pl. utolsó 10 évben jöttek-mentek a nagyobb dolgok, bejött a systemd (ráadásul az bővül is, nemrég a bsod-ot és a homed-t adták hozzá), pulseadio helyett pipewire és wireplumber, cups helyett a ipp/pappl, X11 helyett egyre inkább elkezdik a Wayland-et nyomni, bejöttek az univerzális csomagformátumok (eléggé erőltetik ezeket is, Snap, Flatpak). shedulerek, fájlrendszerek is folyton változnak, adódnak hozzá a kernelhez (ntfs3 kernel driver, bcachefs), plusz most bejött az NV-tól is egy új opensource driver, állandóan frissül a vulkan, mesa, stb.. Ez nem olyan, mint a Windows volt 10 éve, hogy csak lassan változnak a dolgok. Windowsnál is a MS csak azért tart vissza fejlesztéseket, hogy a következő főverziót is el tudja adni valami újdonsággal. A Linuxnál ilyen nincs, mivel ott nem akarnak az emberből pénzt kicsikarni, ha jön egy fejlesztés, mindenki megkapja, nincs semmilyen visszatartás, meg nagy corporate jóváhagyatás. A FOSS projektek nagy része úgyis kisebb projekt, néhány emberesek csak, de azok mindig mások, csak úgy záporoznak a git PR-ok, commitok.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( persicsb | 2024. 02. 04., v – 11:03 )

A 18.04 már csak biztonsági frissítést kap, amúgy tavaly óta EOL.

glibc 2.28 release date:

The release branch of glibc-2.28 was released on August 1st 2018.

Amúgy Ubuntu userek számára amúgy is a Canonical által támogatott módon, snapből beszerezhető a legfrissebb code: https://snapcraft.io/code

A Microsoft ezt hivatalosan támogatja.

Vagom, de ezert miert gond?

Anno a WinXP-hez is adtunk el CSA-t, de nem tarthattunk fegyvert a szoftver vendor fejehez, hogy marpedig supportalni kell neki is a regi vackokat, plane ingyen. Vagy nem ertem, hogy gondoltad ezt.

szerk: https://snapcraft.io/code itt az official support, az ubuntu 18.04 ugy latom a top #4 legnepszerubb install target

Tamogatott rendszereken nem is tortek el semmit.

VS Code is supported on the following platforms:

    Windows 10 and 11 (64-bit)
    macOS versions with Apple security update support. This is typically the latest release and the two previous versions.
    Linux (Debian): Ubuntu Desktop 20.04, Debian 10
    Linux (Red Hat): Red Hat Enterprise Linux 8, Fedora 36

Starting with VS Code release 1.86, the minimum requirements for the build toolchain of the remote server were raised. The prebuilt servers distributed by VS Code are compatible with Linux distributions based on glibc 2.28 or later, for example, Debian 10, RHEL 8, Ubuntu 20.04.

1.85->1.86 minor verzió(szám)váltás

Probléma:

VS Code 1.86 (aka the ‘January 2024’ update) saw Microsoft bump the minimum build requirements for the text editor’s popular remote dev tools to ≥glibc 2.28 — but Ubuntu 18.04 LTS uses glibc 2.27, ergo they no longer work.

trey @ gépház

Wayback Machine az ember barátja. Eddig hivatalosan is támogatott volt a VSCode által a 18.04, mert 2.17-es glibc volt a minimum.

Bár én azért egy valamire kíváncsi lennék, ha már ennyi ember panaszkodott a Github oldalon: Ha annyira szükséges a 6 éves 18.04-es verziót használni, akkor a vscode-server miért lett automatikus frissítésre állítva/hagyva? Ha kell a stabil környezet, akkor ez miért rollingol?

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

A Canonical fogalmai szerint de.

https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices

Az ESM nem számít bele ebbe, az az EOL után van.

 

Akinek meg nagyon kell a vscode, használja snapből telepítve. Anno a Canonical blogolt is róla, hogy ez így a jó.
https://snapcraft.io/blog/why-the-visual-studio-code-team-launched-a-sn…

Nem tehetek arról, hogy a Canonical kétféleképpen kommunikálja az EOL-t.

Másrészt vicces látni, hogy 2023. május 31. a standard support vége, de a táblázatban június szerepel.

Harmadrészt pedig, te magad is azon a véleményen voltál, hogy a support az ügyfélszolgálatot stb. jelent: https://hup.hu/comment/3013985#comment-3013985

Nos, az ESM az nem ez.

A Canonical is megkülönbözteti ezt: https://ubuntu.com/blog/security-maintenance-vs-support-whats-the-diffe…

A 18.04 nincs támogatva, de vehetsz hozzá támogatást, ha szeretnél (az Ubuntu Proban sincs support, külön vehetsz hozzá addont Ubuntu Support néven).

Mindkettőtöknek igaza van, csak elbeszéltek egymás mellett, mivel máshogy definiáljátok az EOL-t. A 18.04 valóban nem kap már lényegében frissítéseket, az a fajta support lejárt rá 2023 áprilisában, azóta csak biztonsági foltokat kap, meg az ingyenesen igénybe vehető Pro-ban a tárolókat még eléred hozzá, de lényegében 2023 óta szanált rendszernek minősül. Nem is értem, hogy ki ragaszkodna hozzá, főleg a VSCode-on fejlesztők közül.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Jaja, pont az enterprise-ban támogatott, ahol lényege lett volna, hogy a Microsoft szó nélkül ne hugyozza keresztbe. A végén maga a Microsoft is belátta, hogy ilyen böszmeséget nem csinálunk és visszakozott. Miért nem lehet elengedni a hülyeség pörgetését még ezután se?

trey @ gépház

Az teljesen jogos, hogy ha egy Enterprise támogatott rendszer esetén az Enterprise specifikus szoftverek támogatják és egy minor verziónál nem törik azt, de a fejlesztőknek szánt szoftver esetén ez miért lenne elvárás?

A kódszerkesztő és a fejlesztők támogatását nyújtó szoftverek az én értelmezésemben nem esik az enterprise kategóriába. Jobb esetben nem azon a szerveren fejlesztenek, amin a prod környezet fut, sőt még teszt környezetben sem. Van fejlesztő környezet, van repó, amit kitolnak teszt környezetre és ha minden jó kitolják prodra. 

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Enterprise specifikus szoftverek

Ez a homályos izé mit jelent? Ha egy enterprise vállalat a saját rendszerére a saját szoftverfejlesztői gárdájával saját enterprise szoftvert fejleszt, számára a toolchain-ben szereplő fejlesztőszoftver egy enterprise szoftver.

Ha egy központi menedzsment rendszerrel (pl. Microsoft SCCM stb.) deploy-olnak egy vállalaton belül fejlesztői munkaállomásokat, akkor az arra kitolt image package egy enterprise szoftvercsomag, aminek az összetételét nem ad hoc módosítgatnak, hanem meghatározott időközönként és okkal.

Próbáljunk meg ezen a vonalon elindulni. Ezt jeleni az enterprise.

trey @ gépház

Oké! Más a nézőpontunk ebben. Megértem! Neked nagyobb rálátásod van ezekre, így tovább kérdezek:

Egy ilyen szoftvercsomag esetén nem meg szokott határozva lenni egy adott verzió amit deploy-olnak és központilag történik a frissítése? Mert ha igen, akkor az érintett fejlesztők desktop és server VSCode-ja miért frissült automatikusan?

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Eljutottunk oda, hogy egy minor (azaz karbantartási = általában: bug és sec. fix) verziónál nem váltunk glibc követelményt. Lehet, hogy ez nem az éles deployment-nél jött elő, hanem a tesztek alatt.

Akik a sec. és bugfixekről nem akarnak lemaradni érthető módon, azok nyilván deployolnák élesben a minor verziófrissítést, arra számítva, hogy abban nem fog eltörni semmi.

Ahogy annak lennie is kellene.

trey @ gépház

( dotnetlinux | 2024. 02. 04., v – 16:07 )

Valszeg menni fog 18.04-n a nodejs fejlesztés, csak a c++ -os projektek nem.

( bzt | 2024. 02. 05., h – 11:20 )

Szerkesztve: 2024. 02. 05., h – 11:24

Szerintem ez a nem látjátok a fától az erdőt tipikus esete...

A kérdés nem az, hogy miért frissítették a glibc-t, hanem a kérdés az, hogy a glibc2.27 miért nem kompatíbilis a glibc2.28-al, mikor mindkettő pontosan ugyanazt a POSIX szabványt implementálja, ami fikarcnyit sem változott e két verzió között!

Igazából itt van a kutya elásva, és nem ott, hogy újabb glibc-re frissítettek. Kivételesen (ebben egyetértek Raynes kollágéval) ez most nem a Microsoft sara. A glibc hibája, hogy minor verzióváltásnál törnek a dolgok (és nemcsak a VSCode, hanem minden más is).

Ez amúgy érdekes kérdés.

A 2.28 changelogjából látszik, hogy került bele új fejlesztés, ami fontos lehet a VS Code-nak, pl.

- The fcntl function now have a Long File Support variant named fcntl64

- Support for ISO C threads (ISO/IEC 9899:2011) has been added.

- Unicode 11.0.0 Support

De aztán ki is került belőle funkcionalitás, így persze nem lehet könnyen upgradelni.

mikor mindkettő pontosan ugyanazt a POSIX szabványt implementálja, ami fikarcnyit sem változott e két verzió között!

Ez viszont így nem igaz, a glibc nem csak POSIX szabványt implementál, hanem C standard library is, ott pedig (láthatólag) van standard funkcionalitás, ami bekerült.

Tény, viszont a VSCode működött ezek nélkül is glibc2.27-el, szóval egyik sem lehet olyan funkcionalitás, ami nélkülözhetetlen a VSCode számára. Ráadásul:

- fcntl ezt nem tudom értelmezni, mivel a 64 bites támogatás eddig is volt ha USE_LARGEFILE64 define-al fordította az ember, itt mindössze annyi történt, hogy ez lett az alapértelmezett. Ráadásul problémát sem jelent, mivel a C fordítónak kutya kötelessége automatikusan castolni a korábbi 32 bites paramétereket 64 bitessé az új prototípus alapján. Persze ahhoz, hogy ki is használja egy program ezt, ahhoz abban is 64 bites változók kellenek, na de ez semmiképp sem töri a kompatíbilitást!

- ISO C threads, megintcsak, attól még, hogy ez bekerült, a korábbi thread támogatás is megmaradt, szóval megintcsak nem töri a kompatíbilitást! (glibc esetében ráadásul a pthreads nem is része a libc-nek, mint mondjuk musl esetén, szóval független könyvtár nyújtotta a threads támogatást eddig is)

- Unicode 11.0.0 újfent, attól még, hogy újabb karakterek kerültek bele, a kompatibilitításnak nem szabadna törnie!

Az egyetlen, ami magyarázat lehet, hogy olyan funkcionalitás került ki, amit használt a VSCode, de a changelog-ot végigolvasva ez meg nem túl valószínű, és még ekkor is könnyedén le lehetne cserélni egy olyanra, ami megy 2.27-el és 2.28-al is. Nem, az egyetlen és igazi ok, ami törte a dolgot, az az idióta funkció és szimbólum verziózás, és semmi más.

Nem az a lényeg, hogy törik-e a kompatibilitás. Hanem az, hogy ha a VSCode használni akarja ezeket a funkciókat (és pl. a platformfüggetlen szálkezelés nem egy utolsó szempont, főleg, hogy 13 éves szabványról beszélünk), akkor frissebb glibc KELL neki. Meg tudom érteni a Microsoft fejlesztőit, hogy nem akarnak platformonként szálkezelést implementálni, ha van 13 éve szabványos, crossplatform megoldás rá. Így Windowson, macOS-en és Linuxon is ugyanaz a kódbázis jó szálkezelésre.

Nem az a lényeg, hogy törik-e a kompatibilitás.

Ja, én azt hittem erről szól ez az egész topic.

ugyanaz a kódbázis jó szálkezelésre

Ez eddig is adott volt pthreads-el. Csont nélkül meg Windows-on is évtizedek óta, csak a libwinpthreads.dll-el is kell linkelni, ennyi. Vagy ha nem akarsz dll linkelni, akkor konkrétan 12 SLoC egy WIN32 Threads pthreads wapper, szóval nem, én nem értem meg őket, mert nem ügy. A Microsoft kódlopó segédje, a Copilot egyből első kérésre kiköpi, még csak különösebb dolguk sincs vele!

akkor frissebb glibc KELL neki

Abban viszont igaza van trey-nek, hogy a fejlesztők ezt nem dönthetik el önkényesen, ha egyszer a cég hivatalosan felvállalta, hogy támogatja a régebbi glibc-it is.

trey írta (kiemelés tőlem):

Egy akkora cég, mint a Microsoft, amelyik állandóan arra verte, hogy neki aztán mindene működik de mennyi ideig, figyeljen arra, hogy a szoftvere minor verzióváltáskor ne legyen használhatatlan egy még aktívan támogatott LTS op. rendszeren.

Én ebből azt szűrtem le, hogy ezidáig még nem jelentették be, hogy felhagytak volna a támogatásával, tehát a Microsoft hivatalosan egyelőre még támogatja az Ubuntu 18.04 LTS verzióját (és így következésképp a glibc2.27-et, mivel ott csak az van).

De nem használok sem Bugbuntut, sem VSCode-ot, és feltételezem nem ok nélkül írta trey, hogy "aktívan támogatott LTS op. rendszer". Ha tévedett, akkor én is, ez esetben bocs.

https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices

Ubuntu 18.04 ‘Bionic Beaver’ is reaching End of Standard Support this May. (2023). Szóval az, hogy van egy külön kiterjesztett bármi is, az nem aktívan támogatott. Annyi történik, hogy a kritikus, súlyos és közepes biztonsági javításokat megcsinálják rajta, és kész. EOS- end of support. EOL más kategória.

https://ubuntu.com/security/esm

What’s covered?

ESM continues security updates and kernel livepatching for high and critical CVEs (Common Vulnerabilities and Exposures).

 

Release Ubuntu Base OS security coverage Security updates for applications and toolchains in the Universe repository Kernel Livepatch Architectures supported with ESM
Ubuntu 14.04 LTS (Trusty Tahr) Until 2024 n/a amd64 amd64
Ubuntu 16.04 LTS (Xenial Xerus) Until 2026 Until 2026 amd64 amd64, s390x
Ubuntu 18.04 LTS (Bionic Beaver) Until 2028 Until 2028 amd64 amd64, arm64, s390x, ppc64el
Ubuntu 20.04 LTS (Focal Fossa) Until 2030 Until 2030 amd64 amd64, arm64, s390x, ppc64el, RISC-V
Ubuntu 22.04 LTS (Jammy Jellyfish) Until 2032 Until 2032 amd64,
s390x

amd64, arm64, s390x, ppc64el, RISC-V

Ubuntu 18.04 LTS Bionic Beaver, one of the most popular Ubuntu releases, has reached the end of standard support. If you continue to run Ubuntu 18.04 LTS without ESM, you will not receive any security updates after 31 May 2023. Watch a webinar to explore your options.

Nem, nem a támogatása ért véget.

Természetesen van hozzá támogatás is:

Ubuntu Pro add-ons

Add 24/7 phone & ticket support

Get phone and ticket support for troubleshooting and bug fixing whenever something breaks in your environment.

Csak végig kell menni a linkeken.

https://ubuntu.com/18-04 -> https://ubuntu.com/pro -> https://ubuntu.com/security/esm

trey @ gépház

Utána akartam nézni én is, de ennyire nem vagyok otthon programozásban. Egy egyszerű kis programot még csak-csak megírok, de egy ilyet átlátni... ez már meghaladja a képességeimet.

Ha letölteném a forráskódot, lefordítanám, előfordulhat, hogy lehetne linkelni a 2.27-es verzióval is?

szerk.: látom lentebb megválaszoltad tulajdonképpen.

Akkor mégegyszer, nemcsak a VSCode törik az újabb glibc verzióval, hanem MINDEN MÁS is. Bármilyen program, ami a 2.28-as glibc-vel lett linkelve, nem fog futni Ubuntu 18.04-en, szóval nincs ebben semmi VSCode specifikus!
Az csupán csak a tünetek egyike, hogy a VSCode is törik, de nem az ok.

Nem szokásom védeni a Microsoft-ot, mert nagyon a bögyömben vannak a kódlopásaikkal, de tényleg úgy gondolom, hogy ebben most kivételesen nem ők a ludasak, hanem a glibc.

Lényegtelen. Egy akkora cég, mint a Microsoft, amelyik állandóan arra verte, hogy neki aztán mindene működik de mennyi ideig, figyeljen arra, hogy a szoftvere minor verzióváltáskor ne legyen használhatatlan egy még aktívan támogatott LTS op. rendszeren.

Ezt így, egyben kell értelmezni.

trey @ gépház

Abban egyetértünk, hogy bár nem az ő saruk, mégis illett volna workaroundolnijuk a problémát, e felől nincs kétség.

(Megj. én például direkt ezért tartok egy LTS VM-et, minden projektemet abban fordítom, hogy a dl szimbólumok "@2.27"-re végződjenek, mert úgy a binárisok futási időben összelinkelődnek a 2.27-es és csont nélkül a 2.28-as glibc-vel is. Szóval a workaround annyi, hogy nem szabadott volna frissíteni a build environmentet, egy LTS verziójú Ubuntu-n kellett volna lefordítani a VSCode-ot és csók.)

Egy apró felhomályosítás, ha a GitHub issue-t és a kommentjeit nem olvastad.

A VSCode (és a server) indításkor ellenőrzi a függőségeket, köztük a glibc verzióját is. Az Issue egyik kommentelője például pont ennek az ellenőrzésnek a megkerülésére ad workaround-ot.

Itt ebben az esetben a Microsoft-ot nem azért kell hibáztatni, mert emelte az igényeket (ha jogos, ha nem). Ezt bármelyik szoftvergyártó megteheti.

A problémásabb része az egésznek, hogy frissítés előtti check nem történt. Amikor a Windows 7 támogatása megszűnt az én VSCode telepítésem egyszerűen nem frissült és kész. A mostani esetben azt nem tudom, hogy a desktop verziónál is jelentkezett-e a hiba és automatikusan frissült, vagy csak a server résznél. Itt sokaknál arról szól a fáma, hogy a server verzió frissült le és nem bírt elindulni, mert a függőség teszten nem ment át.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

A VSCode (és a server) indításkor ellenőrzi a függőségeket, köztük a glibc verzióját is. Az Issue egyik kommentelője például pont ennek az ellenőrzésnek a megkerülésére ad workaround-ot.

Nem számít, mivel a linux-vdso.so és a ld-linux-x86-64.so eleve nem hajlandó a libc-vel összelinkelni a binárist, így el sem indul maga a program. Ha elindulna, akkor lehet, hogy lenne benne további ellenőrzés, na de eleve el sem fog indulni.

Mégegyszer, ez nem VSCode specifikus probléma, hanem MINDEN glibc-t használó alkamazást érintő. Akár egy Hello World-el is előjön és demonstrálható:

$ readelf -s helloworld | grep printf
   138: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5
$ readelf -s /lib64/libc.so.6 | grep printf
    [... átláthatóság érdekében fprintf, sprintf és tsai eltávolítva ...]
  2976: 0000000000056250   205 FUNC    GLOBAL DEFAULT   16 printf@@GLIBC_2.2.5

Ha ebben a kimenetben a programbeli verziószám nagyobb, mint a telepített glibc-ben található szimbólum verziószáma, akkor run-time linker error keletkezik és el sem indul, még akkor se, ha egyébként kompatíbilis a prototípus! Mint ahogy történt ez az fcntl esetében, idézet a glibc changelog-ból (kiemelés tőlem):

As for others *64 functions, fcntl64 semantics are analogous with fcntl and LFS support is handled transparently.
$ readelf -s /lib64/libc.so.6 | grep fcntl
   433: 00000000000ff2f0   249 FUNC    WEAK   DEFAULT   16 fcntl@@GLIBC_2.2.5
  1190: 00000000000ff2f0   249 FUNC    WEAK   DEFAULT   16 __fcntl@@GLIBC_2.2.5
  2337: 00000000000ff2f0   249 FUNC    WEAK   DEFAULT   16 fcntl64@@GLIBC_2.28

Hát rohadtul nem transzparens, mivel eltér a verziószám, így valójában el sem fog indulni, tök feleslegesen szenvedett a C fordító azzal, hogy kompatíbilis gépikódú hívást generáljon rá.

( zdesigner | 2024. 02. 05., h – 13:27 )

Nagyon megy itt a sírás, de kéne egy filter azokra a hozzászólásokra, akiket ez tényleg érint és gondot okozott, nem volt rá egyértelmű workaround.

Én is vscode-ot használok Ubuntun. (De Rikárdó az nem vagyok.) Viszont a legújabb LTS-en.

Pont ez a lényeg. Itt nem azzal van baj, hogy Ubuntu, meg LTS, meg VSCode, hanem miért ragaszkodna valaki, aki desktop fejlesztésre használja a gépet, egy ilyen öreg, 6 éves LTS-hez, mikor a legújabb is elég stabil. Egyszerűen nem nagyon tudok elképzelni indokot, hogy valaki ha dekstopon fejleszt, az miért ne tudott volna mostanra 22.04-re frissíteni. Mert az oké, ha mondjuk majd a 24.04-re frissítésre kicsit várnak, pár hónapot, de a 22.04-gyel nincs mit várni, 2 éve kint van már. Ahogy te is, meg trey is tudtatok frissíteni, meg nem vitt el miatta a mentő, úgy ezt más is ugyanilyen könnyen abszolválhatja.

Persze, workaroudozni, meg hekkelni lehet, tuti működik is egy ideig, kérdés meddig, mikor lesz a következő elavulási probléma, de ez hosszú távon felesleges mutatványozás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igen. De most elmúlt.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

De a VSCode által támogatott  - volt. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Ez a kiszámítható support politika nagy erénye az MS-nek.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( arpi_esp v | 2024. 02. 06., k – 12:19 )

az MS helyebe beveztenem, hogy a free vscode csak az aktualis ubit tamogassa, a regebbi verziokat pedig csak penzert :)

Az egy teljesen korrekt hozzáállás lenne, hogy pénzért továbbra is támogatja a pénzes támogatásban jelenleg is részesülő régebbi Ubuntu verziókat, ugyanis pontosan a cégeket érintik ezek a döntések. Az Ubuntu Pro-ért is azok a cégek fizetnek, akik valamiért hajlandóak áldozni pénzt a 18.04 2028-ig való támogatására. Ha egy ilyen rendszeren nem megy a Microsoft szoftvere egyik minor verzióról a másikra, az nagy gond lehet. Ha pedig így van, akkor a cégek akár hajlandóak is lennének fizetni azért, hogy menjen. Erről szól kb. az enterprise téma.

trey @ gépház