Beköszöntött a Feature Freeze a Focal Fossa-nál

Címkék

Mi sem bizonyítja jobban, hogy hamarosan itt az Ubuntu 20.04 LTS végleges kiadása, minthogy beköszöntött a Feature Freeze a Focal Fossa fejlesztési ciklusában. A roadmap szerint a végleges kiadás április 23-ra várható.

Hozzászólások

eleg fos neve van ennek a foss-nak.

Biztos vagyok benne, hogy nem igazítják az elnevezéseket a nemzeti nyelvekhez. Nem úgy, mint pl. az Ikea. Láttam egy dok. filmet róla, amiben az egyik marketinges arról beszélt, hogy mekkora gond a cégnek az, hogy a több (száz)ezer terméküket úgy nevezzék el, hogy az 128 nyelven véletlenül se legyen trágár, sértő stb. Külön ügyosztályuk van erre.

trey @ gépház

Alfonzó is így járt, és ha jól emlékszem szintén latin országban: a hirdető tábla előtt röhögött a tömeg, mert az Alfonzó stricit jelent - vagy a dialektusban, vagy egyébként is - talán spanyolul. Odament, és az ámulatba esett közönség szeme láttára, az ó betűt áthúzta.

Ez ellen semmi nem véd csak egy főosztály.

Én is csipázom. F(a)ecal Fossa, legeslegjobbabb kódnév eddig. Garancia lesz a stabilitásra, az biztos. Nem tudom mikor unják meg ezt a kódneves hülyeséget, bőven elég lenne a verzió, 20.04 és kész, azonnal tudni, hogy 2020. áprilisában jön ki.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

De savanyú valaki :)

bőven elég lenne a verzió, 20.04 és kész, azonnal tudni, hogy 2020. áprilisában jön ki.

És ha valamiért egyszer csúszna a release, akkor meg vagy lőve a 20.04-gyel :) Vagy nevezgetheted át mindenhol a repókat. Plusz jobban kereshető és marketingelhető egy fantázianév. 

Na de pont ez a lényeg. Hivatkozni a disztróra valamilyen formában már a megjelenés előtt is kell, amikor még nem tudod, hogy a verziószám fog-e változni vagy sem. Akár marketing oldalról nézed, akár technikairól (pl apt urlek), ha a verziót használod, és változik, akkor csak az egy csomó plusz munkát és félreértést szülne. 

Ezért jó ha van egy stabil kódnév. Aminek BTW nem az a célja, hogy te mint átlag user azt használd. Max jó ürügy egy kis extra marketing tevékenységre.

Szóltam, hogy nem szerencsés magyarul amikor megtudtam az új nevet, de akkor már nyilvános volt. :-(
Mondjuk a magyar nyelvű káromkodások száz árnyalata sem segít az ütközés elkerülésében. :-)
 

Rpi4-et érdemes r=1 userhez betenni desktop gépnek? Rokoni körben van aki ~10 éve innen-onnan levedlett notebookokat kap, és mindig van valami baja. Általában abból kifolyólag, hogy széthullik a gép. A use case 99%a web alapú, mellé minimális Office, de csak annyi, hogy évente 1-2 oldalt kinyomtatna Writerből amit legépel. Nagyjából. Egyébként asztalra kell, nem kell hordozhatónak lennie.

Most, hogy az ára is zuhant egy kicsit, elgondolkoztam rajta hogy ajándékozok egyet oda. Valami desktop Linux-szal, csak Chrome/Firefox menjen elfogadhatóan. (1-2 tab maximum, yt, fb, google, ennyi).

Sajnos erre nem tudok válaszolni érdemben mert én headless használom, de yt videókat nézegetve fel tudod mérni hogy mit tud tempóban (így ránézésre egy jóféle passzív hűtő mindenképpen jót tesz neki).

Ha türelmes az alany akkor jó lehet, bár én ilyesmi célra lehet néznék neki hasonló árban egy levedlett i3-as irodai konfigot (felsoroltak közül főleg a FB miatt).

25 ezerért 10 éves Sandy Bridge (2. gen core i3-i5) használt laptopot kapsz, 4 GB RAM, lassú zörgős HDD, enbloc kilóg már a bele. Öröm lehet rajta a win7 is, nemhogy a w10! Marseus-nál egy normális állapotú és korú i5 pedig 75-80 ezer.

Fentebb pont az volt a baj h  a levedlett gépek szétesnek nála. Az irodai / céges gépek is kb. 10 éve voltak stabil masszívak. Ma már azokat is csak pár évre tervezik, és az 1. tulajánál gariidőben szétesnek. Csak az i7U meg a fancy dizájn miatt kerül egy mai irodai laptop 600 ezer pénzbe, nem azért mert strapabíró. Ja meg mert jobs árazásán vérszemet kapott a többi gyártó is az elmúlt 8-10 évben, sajnos.

Most épp egy i5-520m-en pötyögök. SSHD van benne, Windows 10. Egész jól megy. Ez még bőven egyben van (Probook 6450b). Delljeink akumulátorai púposodnak, többnek a zsanérja elvált a képernyő hátától...

Nem írnám le párezerért a Sandy/Ivy korú gépeket. A laptopnak extra rizikója van nyilván, desktopban viszont simán. Nem hiszem, hogy laptopról beszélt mikor 10-20 ezret írt.

Már egy ideje meg van oldva a közvetlen USB-ről bootolás, szóval elvileg nem kell SD kártya. Többek közt azért is elvileg, mert a Pi 4-es firmware még nincs felkészítve erre, de várható, hogy lesz. Eközben a korábbiak már legalább jópár hónapja tudják (akkor próbálkoztam a 3-asomon ilyennel) 

Itt van amúgy a hivatalos leírás:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

en vettem rpi4-et, a gyari sd kartyaval (sajat linuxuk), hat volt vagy 15 perc mire bejott az ablakkezelo, es valami hihetetlen lassu volt az egesz. youtube videot lejatszotta fullscreeenbe szal a hw accel megvolt de az abalakok kezelese mozgatasa, gorgetes nagyon gaz. szerintem nem a vga hanem a cpu volt a gyenge pont.

hirtelen azt hittem Feature Freeze az új kiadás neve

Egyébként tegye fel a kezét, aki a bionic-ot beaver-nek hívta, a precise-t meg pangolinnak... :)

Vagy az tegye fel aki ezeket a hülye neveket használja, verziószám helyett.

Amíg nem kattintottam a cikkre nem tudtam mi ez a Focal Fossa(=Ubuntu) és csak kíváncsiságból jöttem, ha az lett volna a cím, hogy  "Beköszöntött a Feature Freeze az Ubutnu 20.04 LTS-nél" simán továbbhaladok.

A Chrome nem jó példa lényegében nem számít a verziószám, nincsenek párhuzamosan futó verziók. 1 Chrome van, az aktuális stabil (dev/beta/canary/stb nem számít). Vagy ha számít akkor elég a főverzió, pl megjelent a Chrome 80. Ezzel szemben ha azt olvasnám, hogy megjelent a Chrome Drag Worth (random adta) csak fognám a fejem hogy oké, de ez mi?

Legyen valaminek belső fantázianeve ez nem érdekel, de nem azt akarom látni pl csomagkezelőben, hogy focal-fossa vagy eskimo-boy, ehhez külső eszköz kell hogy megértsem milyen verzió. Ha annyi szerepel hogy ubuntu-1804 vagy ubuntu-2004 egyből tudom melyik melyik... ezért preferálom a dátum alapú verziózást ilyen projekteknél.

 

és minden fiszem-faszom változásra kihajítanak egy új verziót. - CI/CD alapvetően nem rossz dolog, de az is igaz hogy nem minden helyzetben a legjobb.

Tök egyetértek, én a böngészőknél is szívesebben látnék dátum alapú verziózást. Sok értelme nincs másnak, konkrétan nem mond többet a Chrome verziószáma számomra, mint az Ubuntu fantázianeve. Sorrendbe mindegyiket tudom rakni, azt is, hogy melyik az utolsó, de pl nem tudnám időben hova tenni a Chrome 70-est, így aztán sok értelme nincs is.

remélem senki sem Fossa össze magát fókuszáltan ettől a Feature Freeze bejelentéstől

Gnome-terminal (libvte) alatt használhatóak már a ligaturák? Firacode-t szeretnék.

„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Nem, upstream-ben még nem csináltuk meg (és nincs is tervben a közeljövőre). Eoan-hoz képest a VTE és GNOME Terminal nem változik érdemlegesen. (Bionic-hoz képest akadnak újdonságok.)

Az egyik gond: ha tökéletesen implementálnánk, a végeredmény, a teljes végfelhasználói élmény akkor sem lenne tökéletes. Gondolj a szövegszerkesztőben a margóknál félbevágott jelekre, mondjuk egy "!="-ból csak a "!" fér ki a jobb szélen. A terminál nem tudja, hogy a szerkesztett fájlban mi a következő karakter, így nincs esélye egy "≠" bal felét renderelni. Ez kifejezetten félrevezető, ha például a "<==" jelből csak "<=" fér ki, teljesen hibás ligatúrát kapsz. Ezt nem lehet máshogy megoldani terminálban, mint egy vadiúj kiterjesztéssel, ami a vásznon kívüli karaktereket is át tudja küldeni, egyetértésben a terminálok közt, implementálva kellően sok terminálban és applikációban – esélytelen, hogy ilyen megszületne, elterjedne. Nem tiszta az sem, hogy ha "cat"-olás során pont itt törik új sorba, akkor a ligatúrát kéne felesben/harmadolva rajzolnunk, vagy az eredeti szimbólumokat.

A másik gond: nincs olyan font engine, ami készen megoldaná a ligatúrák rendeselését, egyszersmind atombiztosan garantálnál a fix betűszélességet. A monospace font pedig legfeljebb elvi síkon létezik: a gyakorlatban ott van a fontconfig a fallbackjével, meg csomó nemzetközi írás, egyesek (például dévanágari, arab) igencsak hadilábon állnak a fix szélességgel. Namost a fontconfig ezeket összegyúrja egy virtuális fonttá, az eredmény minden csak nem monospace.

Jelenleg minden betűt egyenként teszünk ki, a megfelelő helyre, ezért nincs ligatúra. A másik triviális megközelítés az volna, hogy valahogy detektáljuk a grapheme cluster-eket, vagyis az egyben renderelendő dolgokat, amíg nem kell a "ceruzát felemelni" (erre talán, remélem van API), és azt kirajzoljuk, na de hogyan is pontosan? Tegyük fel, hogy 10 pixel széles egy cella, és 10 betűből áll egy szó. Odaadjuk a font engine-nek, várunk tőle vissza egy 100 pixel széles képet, de ehelyett kapunk mondjuk egy 88 pixel széleset. Vagy 107 pixeleset. Mihez kezdjünk vele? (Arról nem is beszélve, hogy ha a kurzor ennek a közepén van, akkor azt hova és hogyan is rajzoljuk ki pontosan?) Ha szélesebb a kelleténél, akkor kezdjük el jobbra tolni a maradékot (mint a Konsole-ban), elrontva a függőleges igazításokat, a sor vége meg lehet hogy már nem is fér ki?

De láttam már olyan screenshotot is valamelyik terminálról, hogy a "fi" betűket összevonta egyetlen karaktercellás ligatúrába, majd utána egy üres cella áltt. Hát, kösz, nem. Egyelőre amelyik terminált én láttam ligatúrákkal próbálkozni, azok mind különféle problémáktól szenvednek, remélem most már érthető hogy miért.

Szóval kellene valami olyasmi intelligencia, vagy akárcsak beégetett szabályok, amelyik különbséget tesz ligatúra típusok között. Például a "!="-re azt mondja, hogy jó, az jöhet, a dévanágari betűkre pedig azt, hogy nem, ott inkább betűnként külön renderelünk, mert a kisebb szakadások vagy átfedések a betűk között még mindig jobbak, mint ha hosszú távon esik szét a sor. Hogy ez a döntés hogyan nézne ki, min alapulna, mondjuk Unicode karakter-osztályonként (betűkre tiltjuk, írásjelekre engedjük), majd esetleg folytatjuk azzal hogy lemérjük hogy a font mit csinál, és tiltunk akkor is ha a ligatúrával renderelt szélesség nem pont akkora mint kellene (esetleg tűréshatáron belül), ez nagyon nem tiszta. Rengeteg heurisztika, kísérletezés míg talán sikerülne belőni valami viszonylag jót.

Amúgy a VTE 0.56 vagy 0.58, nem is emlékszem már, immár egész sorokat renderel egyszerre, kisebb egységeket (egy-egy betűt külön) nem, ez egy hatalmas előrelépés a ligatúrák implementálhatósága irányába. Valamint rendereléskor mindig ismert a teljes "bekezdés" szövege (a következő explicit újsorig előre-hátra, akkor is, ha az az aktuális vásznon kívül van), ami szükséges akkor ha implicit sortörésnél a ligatúrát szeretnéd félbevágni, ez is egy fontos előrelépés volt a közelmúltban. De még elképesztően nagy munka befejezni innen (beleértve azt is, hogy talán az egész pango renderelést harfbuzz-ra kéne cserélni előfeltételként).

Nem ismerem az IntellJ-t. Van esetleg terminál komponense? Vagy a szövegszerkesztő részére vonatkozik a kérdésed? Szövegszerkesztő esetén jóval kisebb probléma, ha mégsem monospace a font, különösen a nem latin írások esetén. Ott simán működhet, hogy a fontra bízol mindent, és a felhasználói élmény pont addig monospace, amíg a font is az.

nezzetek meg mac-en az iTerm-et, eleg jol mukodik benne. vagy barmelyik terminal/editor appot ami tamogatja, sok van.

a fixed font-ok elvileg nem adnak vissza mas meretet ligaturanal sem, szoval a 100px-bol 88px-el nem kell foglalkoznotok. igy a kurzor pozicio sem problema. egyedul az a necc hogy ossze kell vonni a karaktereket es elore nem tudom honnan lehet tudni, melyiket. vagy az egesz sort egybe kell renderelni, mai gepeken azert ez se egy nagy load.

mondjuk az ha a jobb szelen lemarad a <== fele az tenyleg jo kerdes... megnezem majd, csak en nem hasznalok ilyen fontot, csak kiprobaltam egyszer.

A'rpi

szerk: kiprobaltam, sor vegen x!=y  es ahogy toltam jobbra mar csak x! lett :(

a fixed font-ok elvileg nem adnak vissza mas meretet ligaturanal sem, szoval a 100px-bol 88px-el nem kell foglalkoznotok.

De kell. Mert az elvileg meg a gyakorlatilag az nem ugyanaz. Mert a fixed font-ok is talán legfeljebb a latin és egy-két hasonló írásokra monospace-ek, a szimbólumokra, CJK-ra, egyéb írásokra már egyre kevésbé. Vagy csak nem fedik le a teljes Unicode-ot (mert aligha van akár egyetlen font is, ami lefedi), tehát jön a font fallback, a hiányzó betűk máshonnan betöltése. Meg jön a user aki hozzákeveri még a powerline-t. Meg a font renderelő engine ami maga kitalál valami frappánsat a hiányzó glyphekre, szabadon választott szélességgel. Meg a Unicode, aki néha átdefiniálja, hogy melyik karakter dupla széles, és ezt a terminálnak követnie kell akkor is, ha a font le van maradva. Meg jön a pixelekben mérve nem egész számú szélesség, betűk subpixel pozicionálása, ami totálisan inkompatibilis az ablak geometry hintekkel, meg a kézzel renderelt táblázat karakterekkel (amik ismét csak azért ilyenek, mert a fontokból szedve nem illeszkednek szépen ugyebár), meg a rajzolandó kurzorral, stb. Kábé millió oka van annak, hogy ha egy engine-t kérünk meg egy szó (vagy akár teljes sor) renderelésére, akkor az sokszor nem pont olyan széles lesz, mint szeretnénk. Ezek nem ritka corner case-ek, ezek mindennaposak.

Szerk: Azt kihagytam, hogy természetesen a bold font betűi sem lehetnek semmivel sem szélesebbek. Na ez sem így szokott lenni.

Szerkesztve: 2020. 03. 08., v - 21:57

.