4,76 nap alatt, de végül bebootolt a Linux kernel az Intel 4004-en

Kernel

Dmitry Grinberg hardver hacker nemrégiben elért valamit, ami lehetetlennek tűnik: elindította a Linuxot az Intel 4004-en, a világ első kereskedelmi mikroprocesszorán. Ez az 1971-es CPU mindössze 2300 tranzisztort tartalmaz, és eredeti órajele 740 kHz volt, ami modern szemmel nézve rendkívül primitívnek számít. És lassú is — körülbelül 4,76 napig tart, mire a Linux kernel elindul rajta.

Részletek itt.

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

( trey | 2024. 09. 24., k – 08:19 )

Obligát kérdés: mi a helyzet a Doom-mal?!

trey @ gépház

A Fastdoom tud 80x25*-ös text-et (is), 16 színnel. Annyira nem jó :)) (ráadásul teljesen szükségtelenül 80486-on hajtják), de megy. Okés-okés, a CGA nem 4004 szint.. de az egész már megindult lefelé :D

Vortex Rikers NC114-85EKLS

( Botond | 2024. 09. 24., k – 08:53 )

"If you're skeptical that this feat is possible with a raw 4004, you're right: The 4004 itself is far too limited to run Linux directly. Instead, Grinberg created a solution that is equally impressive: an emulator that runs on the 4004 and emulates a MIPS R3000 processor"

Ez így csalás, nem? Szerintem inkább javascript interpretert kellett volna írnia, mert azon is fut már Linux.

Igen, kicsit csalás, mert MIPS emulátort futtat, és abban fut a Linux, de azért durva, hogy végül tökéletesen fut neki, és heteket töltött csak azzal, hogy bebootolja, egy alap uptime parancs is több napig fut le neki, azt írja a csávó, hogy az exec-fork vesz el sok időt.

Gyakorlati haszna nincs, de szép teljesítmény. Van ideje dögivel, az biztos.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

szép teljesítmény

Egyszer a tévében hallottam: Műmellekkel dicsekedni olyan, mintha valaki arra lenne büszke, hogy hibátlanul fingotta el a Für Elise-t.

Egyébként a linux i386-ra készült, annál kisebb processzoron nem csak a szó/utasítás szélessége kisebb, hanem mmu sincs. Kb. olyan, amikor egy roller csapkod a szárnyaival és repül - ami pont olyan mint egy galamb. :-D

Ezt szokták mondogatni, de valójában a 286-ban is volt már protected mode. Ahhoz meg gondolom kellett MMU.

Igaz, csak 16 megát tudott címezni, de az még a 486 korban sem számított kevésnek.

Inkább ami megdöbbentő, hogy a 4004 1971-ben jelent meg, a 8008 1972-ben, a 8080 1974-ben, a 8085 1976-ban, a 8086 pedig 1978-ban, és a mai napig ennek a leszármazottait használjuk.

Csak hét év telt el az első processzor és a 8086 között, azóta pedig már lassan ötven!

A 286 mmu jóval kevesebbet tud, de ez mindegy, mert Linus kifejezetten a 32 bites 386-ra írta.

a mai napig ennek a leszármazottait használjuk

Ez csak a Windows irányú megközelítés. Ha úgy tetszik az Arduino és a POWER* is Motorola 6800, de inkább 68k leszármazott. A mai vonal alapvetően a 8080 kiterjesztése. Akkoriban úgy mondtuk, hogy egy cpu lehet néhány regiszteres Intel vagy sokregiszteres Motorola szerű.

Az ötven évvel ezelőtti processzorok leginkább abban hasonlítanak a maiakhoz, hogy mindkettőnek vannak lábai. ;)

Azért nem megy a 286-on, mert Linus soha nem akarta rá megírni. Voltak Unixok 286-ra, meg ott volt a windows is egészen a 3.1-ig. Mindegyik ment a 286-on, védett módban, elérve a 286 teljes memóriáját.

Nem volt túl népszerű a 286 védett mód, de létezett.

A címzés, az aritmetika tök mindegy. Amíg C-ben van a kód, addig oldja meg a fordító.

A kezdeti Linuxban rengeteg assembly betét volt, na azok viszont csak 386-ra voltak megírva. Ahogy telt az idő, a 286-ra meg egyre csökkent az igény, úgyhogy ezt utána soha nem is kérdőjelezte meg senki.

Kicsit jobban utánanézve: a 286-os nem tudott lapozni, ez egy elég komoly limitációnak számított akkor. A 386 másik nagy feature-e pedig a VM8086 mód volt, az pont nem kellett a Linuxnak.

( khiraly | 2024. 09. 24., k – 09:53 )

Na jó jó, de systemd van-e rajta?

Anélkül nincs Linux....

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( benz | 2024. 09. 24., k – 10:53 )

Várjuk nagyz-t, hogy megkérdezze minek ez a projekt és mennyivel lesz olcsóbb tőle a kenyér nyugaton. A fickó meg menjen inkább Netflixet nézni airplayen, mert az legalább működik.

( Honkydoo v | 2024. 09. 24., k – 12:19 )

Vajon meddig tart rajta elindítani egy vim-et?

És mennyi idő kilépni belőle? :O

( ssikiss | 2024. 09. 24., k – 12:33 )

Ha NetBSD-vel próbálkozott volna, akkor az már tegnap beindult volna emuláció nélkül. ;)

( heckles04 v | 2024. 09. 24., k – 16:20 )

Ez is mutatja hogy csak felesleges e-hulladék az összes mai proci. Már 71-ben tudtak olyat gyártani ami a mai napig működik.
De a fősodratú mérnök urak lusták optimalizálni...4!

Nem, de lehetne.

Persze, hogy jó lesz 50 évig egy gép, pont annyi lesz, amíg az ember lefuttat rajta valami normálisat, összetett alkalmazást :D

Nyilván van egy pont, ahol megéri cserélni, ezt hajbi nem hiszi el nekem. Az ember ideje meg a futtatási lehetőségek bővítése megér azért annyit. Kb. 10 évente cserélni nem konzumeridiotizmus, de nem hiszi el.

Mondjuk ez az i4004 nem is arra lett tervezve, hogy OS fusson rajta, hanem egy primitív, 4 alapműveletes számológépbe szánták. Még a 8008, 8080, 8086-8088 is csak egyszerű, bare metal kódfuttatásra volt max. tervezve, nem multitasking OS-re, CP/M meg DOS volt reális ezekre. Bár egy 8086-8088-80286-on elment legalább a MS Xenix, de hát az is rettenet nyögvenyelő volt, az ember az ereit felvágta, mire lefutott rajta valami (erről valaki tett fel videót pár éve a YouTube-ra, de nem találom), azért a gyenge proci meg a kevés, 640 KB RAM az csúnyán benyomorította.

Nem véletlen, hogy a unixokat, meg a unixlike rendszereket csak a 90-es évek elején portolták át x86-ra (x86 Solaris, SCO Unix/386, 386BSD, NetBSD, FreeBSD, stb.), akkora megfizethetők lettek a 32 bites hardverek (386-486-os procik), kicsit nagyobb merevlemezek, meg voltak értelmesebb, pár MB-os RAM mennyiségek (4-8 MB körül már nem volt megfizethetetlen), ebbe már belefért egy ilyen rendszer. A Linuxnak is ezért volt esélye pont ebben az időszakban indulni, mert már egy egyetemista-kollégista is meg tudta venni a 386-osát hozzá, még ha vért hugyozva, meg agyonadósodva is, de sikerült neki, mert a 386 már akkor kint volt 6 éve, és a 486-osok hatására lement már kicsit az ára. A legkorábbi még ebben a műfajban a MINIX volt, az 8088-ra készült, de abban meg az volt a trükk, hogy csak egy proof of concept kód volt, nem volt jó túl sok mindenre, csak tanulási segédletnek.

Persze, voltak korábban is ilyen rendszerek, de azok nem átlag felhasználóknak, nem mezei PC-kre, hanem több ezer dolláros workstation, server vasra, VAX, m68k, később, PPC, SPARC, MIPS, stb. architektúrákra, DEC/Ultix, SunOS, SGI, NextStep, HP, stb.. Azért kellett idő a megfizethető x86-os PC-knek, mire felzárkóztak erre a szintre.

Sőt, Torvalds is hiába kezdte 386-oson, ahogy hízta ki magát a kernel egy floppy-snál nagyobbra, elég rövid időn belül kapta hozzá az új vasakat, 486-os, 1994-es képeken már Pentium gépekkel pózolt, már akkor se vívta ki hajbi elismerését.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Hajbi elismerését a Linux akkor vívja ki, ha eljön a desktop Linux éve, lehetőleg Red Hat-, IBM- és multimentesen. Nagyjából azzal a professzionális desktop koncepcióval, ami a 2000-es évek közepén volt (KDE3, GNOME2 stb.) és amit az elmúlt 10 évben sikerült korporatokrata erővel szétbarmolni (köszönjük szépen minden multinak, aki részt vett benne).

Arch Linux nem rossz koncepció, de mivel a projektek fele nem tartja stabilan az upstream-et, így a stabilitása nagyjából a Windows 10-11 feature (tehát nem LTSC) ágával vetekszik. Onnantól, hogy desktop és GUI kerül a képbe, a Red Hat kerül a képbe, minden Linuxon. Tehát ugyanaz a bajom a desktop Arch Linux-szal, mint az összes többi desktop Linux-szal.

és meg van a Gnome2 élmény

Nem nincs, mert már a MATE is GTK3. Ez a bohóckodás az egészben. A MATE fejlesztői forkolták a GNOME2-t, de a GTK2-t nem, és a GTK3-mal ugyanúgy mennek a Red Hat után. Az erőforráspazarló látszat marad meg csupán.

Esetleg már ez is bloat az unpatched XP-hez képest?

Igen, az.

Nem így értettem.

Úgy kerül a képbe, hogy a Linux világot felforgató, megcsúfoló, megerőszakoló szutykai (systemd, pulseaudio, csiligány gnome3, gtk3-bloat, gtk4-bloat, wayland stb.) ott vannak minden fősodratú disztróban, ergo megkerülhetetlenek.

Nagyrészt igazad van, a Red Hat tényleg uralja a tradicionális deszktopot, de nem teljesen. A Gtk, Qt majdnem teljesen elkerülhető. Egyedül a Gtk3 nem, mert azt minden böngésző használja, ha böngészni akarsz, azt az egyet nem tudod megkerülni, meg annak, aki játszik és game launchereket akar, mert azok is mind böngésző alapúak, ergó igénylik. Minden más megkerülhető, a titka az, hogy alternatív programokat kell hozzá vadászni, meg asztali környezet helyett ablakkezelőt (JWM, Fluxbox, Openbox, WindowMaker, IceWM, hasonló, azoknak nem kell sem Gtk, sem Qt).

Ahol neked még kicsit megkerülhetetlen lenne a Gtk/Qt, az a Total Commander kiváltására vagy a Double Commander vagy a Krusader miatt. Igaz a Double Commanderből van Gtk2-es verzió, azzal félig megúszod. Nekem ez pl. nem kell, mert elvagyok terminálos fájlkezelővel, azoknak nem kell grafikus framework.

Illetve a Qt akkor megkerülhetetlen még, ha valami kreatív, vizuális-audió tartalom-előállítással foglalkozol, CAD, rajzprogram, fényképszerkesztés, videóvágás, kiadványszerkesztés, zenélés. Neked ez nem kéne, de ha mégis valakinek kell, meg tudja oldani, hogy mondjuk felteszi az LXQt-t, ez indítja a Qt5-öt, amit tudnak más Qt-s programok már betöltve megosztva használni, de így elkerülted nagyrészt a Gtk meg a Red Hat hülyeségeit, de Qt terén a KDE bloatságát is nagyrészt. Nem ideális, de egy jó kompromisszum. Főleg, ha a Win10-11 hardverigényéhez nézed.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A szépítkezés ellenére te tudod a legjobban, hogy a Red Hat szutykai érdemi desktophasználat mellett nem megkerülhetők. Máskülönben nem erőlködnél a terminálos vackaiddal.

És amíg ez így lesz, addig a Linux desktop nem lesz értelmes alternatíva, mert addig a Windows és MacOS pingvinerőszakolásból fogant fattya marad.

A Linux akkor lesz alternatíva, ha nem a szart majmolják le a konkurens OS-ekről, hanem építenek valami egyedit, aminek van hozzáadott értéke. A KDE3 a maga korában sokkal menőbb volt, mint a Windows és funkcionalitása és konfigurálhatósága is több volt. A mostani verziók fele annyit se tudnak, mégis sokszor annyi erőforrást zabálnak és már alulról közelítik a csiligány Windows 10-11, meg a tabletek óvodásoknak lebutított GUI-ját.

A terminálos dolgok jók. Gyakran sokkal jobbak, mint a ,,grafikus" alternatívák.

Vannak jó terminálos dolgok, de nem helyettesítik a széleskörű funkcionalitással rendelkező és/vagy power usereknek szánt GUI-s alternatívákat.

Mi számít érdemi desktophasználatnak?

Én ezeket használom napi szinten, Windows XP-n:

  • Notepad++
  • IrfanView
  • SumatraPDF
  • Total Commander
  • MPC-HC
  • streamWriter (netrádióhoz)
  • Microsoft Office 2010
  • Outlook Express 6
  • WinAmp
  • Supermium és New Moon (böngészők)
  • MediaInfo
  • csomó NirSoft tool
  • TAudioConverter
  • 3DYD (Youtube videók letöltéséhez)
  • PuTTY
  • mstsc (RDP kliens)

Számomra ezeket jelenti az érdemi desktop használat.

A fentiek közül az alábbiaknak használok TUI-s verzióját Linuxon:

  • Notepad++    ->   Helix, Vim, Neovim
  • IrfanView       ->   LF
  • SumatraPDF 
  • Total Commander  ->   LF, MC
  • MPC-HC               ->    NCMPCPP + MPD
  • streamWriter (netrádióhoz)    ->   NCMPCPP + MPD
  • Microsoft Office 2010
  • Outlook Express 6     ->    AERC
  • WinAmp 
  • Supermium és New Moon (böngészők)
  • MediaInfo         ->    LF + exiftool
  • csomó NirSoft tool
  • TAudioConverter  ->    FFMPEG (parancssoros)
  • 3DYD (Youtube videók letöltéséhez)
  • PuTTY   ->  SSH
  • mstsc (RDP kliens)

Én pedig nem fogok egyik helyett sem TUI-s verziót használni, mert az számomra szuboptimális és felesleges kompromisszum. Ezek mind nagyon hatékony alkalmazások, amiknek a CPU- és memóriahasználata vetekszik a Linux-os parancssoros párjukkal.

ffmpeg, ssh egyébként nekem is van parancssorban, sőt mplayer, mencoder és lame is.

amiknek a CPU- és memóriahasználata vetekszik a Linux-os parancssoros párjukkal

Ezt kétlem, de az bizonyosan úgy van, hogy az általad használt gép erőforrásait nem feszegetik.
Ugye láttuk, hogy Total Commander 2MB vs. MC 12 KB, de a többit is megnézhetjük, kb. mind a 100 KB alatti kategóriában lesz.
Ezért is nehéz így bloatról beszélni, mivel az csak adott gépekhez mérhető. Ha nem relatív nézzük, akkor minden GUI-s kb. bloat (lassabb, több memóriát használ) a TUI-shoz képest.

Megnéztem a szövegszerkesztőket, 44 kis fájl megnyitása:

  • Vim: 73 KB
  • Neovim: 14 KB
  • Helix: 39 KB

Szerk.: Meg kell cáfoljam magam, a gVim meglepett, pedig az a bloat GTK-ra épül. Memória használata: 54 KB!

ffmpeg, ssh egyébként nekem is van parancssorban, sőt mplayer, mencoder és lame is.

Nem lehet, hogy ezek azért vannak meg neked is, mert sok mindenben többet tudnak, mint a GUI-s, "nagyon hatékony alkalmazások"?

Ugye láttuk, hogy Total Commander 2MB vs. MC 12 KB, de a többit is megnézhetjük, kb. mind a 100 KB alatti kategóriában lesz.

Helyesen: Láttad. Valójában az mc RSS-e 12980 kB (ps aux kimenete hazudik, vagy te?).

Ezért is nehéz így bloatról beszélni, mivel az csak adott gépekhez mérhető.

Meg funkcionalitáshoz.

Szerk.: Meg kell cáfoljam magam, a gVim meglepett, pedig az a bloat GTK-ra épül. Memória használata: 54 KB!

Aha persze. :D Ha a KB-ot átírod MB-ra, akkor még reális is.

Nem lehet, hogy ezek azért vannak meg neked is, mert sok mindenben többet tudnak, mint a GUI-s, "nagyon hatékony alkalmazások"?

Azért vannak meg, mert hasznos alkalmazások, amiket bizonyos egyszerűbb esetekben érdemesebb parancssorból használni.

Na-na, több mint 10 éve használok arch-ot és látom a kollégáimat, akik win10-et és 11-et használnak. Ez a stabilitási gond nem tudom, hogy honnan jön.... Ráadásul mindig a legfrissebb plasma-t nyúzom és legalább másfélszeres sebbesség-többletet érzek a használata közben. 3x volt problémám, ami ismert hiba volt és napokon belül javították. De mindegy is, csak kikívánkozott belőlem...

Egy pillanatra tedd félre a szarkazmust és az általam képviseltek szándékos, szélsőséges félreértelmezését.

Ha sikerült eljutnod idáig, akkor képzeld el, hogy összegyűjtjük a világ legjobb fejlesztőit, és adunk nekik egy évet, valamint fejenként egymillió dollárt, ha a 4,76 napot le tudják faragni 1 napra az Intel 4004-en úgy, hogy a többi hardverrel való kompatíbilitását közben nem sértik a kernelnek és nem is használnak semmilyen, célzottan Intel 4004 specifikus optimalizációt sem.

Vajon mennyivel lenne jobb hely a világ (vagy legalább a Linux-világ) ezután, az optimalizált kernellel? Beleértve a szervereket, a cloud-infrastruktúrát, a PC-ket, laptopokat, tableteket és akár az okostelefonokat is?

Mielőtt túl soknak tűnne a fejenként egymillió dollár: a Google harmincnégyezerszer ennyit profitál évente, a Microsoft százhetvenegyezerszer ennyit profitál évente, miközben már külön atomerőművet kell dedikálni a hardvereik energiaigényének, ami a töredéke lenne, ha valóban hatékony szoftverek futnának a cloud-jaikban.

bár a szélsőséges véleményeddel nem mindig tudok egyetérteni, most valahogy - ha még mindig szélsőségesnek is tartom - kézzel foghatobb . 

 

el lehet képzelni így, mi lenne ha csak a profit 1%-át fordítanák ezek ( és a többi multi ) optimalizálásra... 

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

Nekem nincsennek ilyen nagy vágyaim. Én már annak is örülnék ha nagyobb térnyerést kapnának a jelenleg elérhető optimálisabb rendszerek.
MacOS, SteamOS(Arch Linux), egyéb Linux disztrók.

Rendszeresen kiégek, hogy i5 4c8t + 16GB ram mellet az Outlook nem fut rendesen Windowson. Viszont örülhetek mert megy rajta a Lotus Notes yeah...

A Windows ARM lehetne a nagy lehetőség, de nem érdekük hogy ez meg történjen. A Control panelt 10 év alatt nem tudták az új felületre átültetni.

 

Az Otthoni Linux szerveremet most migráltam egy 9 éves Lenovo M900-ra és köszöni szépen jól van. A korábbi direkt alacsony fogyasztású Intel J1900 alapú rendszerről ami mai napig elleni ha nem ment volna tönkre.

Az Apple eszközök amik picit csökkentik az ipari hulladékok számát. Van családban még mai napig használatban 9 éves iPad, iPhone 6s, iPhone 8. Az elsődleges telefonom is egy iPhone 11 amit ha lecserélek még legalább 2-3 évig használatban lesz.

 

A Dell Latitude laptopok meg 3 évre vannak tervezve és maguktól szétesnek sok esetben.

Nem, de lehetne.

Itthon 13 éves Thinkpad T420-as gépet használok, egy szintén 12 éves Synlogy NAS-el. A munkahelyem által adott gépeken kivül nincs 3 évnél újabb eszköz a lakásban (telefon se). A TV is legalább... 10 éves. Jó ebből jó lenne egy nagyobb. De majd ha ez végleg elromlik.

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

... semmit?

Továbbra is: az OS nem magic. Biztosít neked szabványos interfészeket, hogy a webszerverednek ne kelljen már tudnia, melyik szektorban van az index.html. Ezek a szabvány interfészek pedig elhiheted hogy BAROMIRA ki vannak optimalizálva.

A boot idő a pont l*****m kategória bármilyen szervernél. És persze annak a boot időnek a nagy részét sem a kernel teszi ki, hanem a userspace felhúzása.

Amíg egy hello world-öt kell megoldani, persze, még a 8008 is overkill, de komolyabb problémához viszont kell is a komolyabb vas.

Abban igazat tudok adni, hogy sokminden túl van bonyolítva, és rossz irányba megy. Abban is, hogy rengeteg olyan rakás kaka framework-öt használnak manapság, ami hányinger meg anti-feature-ökkel van tele.

De ami alatta van, abban én nem nagyon látok hibát.

A cím: 4,76 nap alatt, de végül bebootolt a Linux kernel az Intel 4004-en

Ha a világ legjobb fejlesztői meg tudják oldani, hogy 1 nap alatt bootoljon ez a kernel az Intel 4004-en, az egy dolgot jelent: nincs BAROMIRA kioptimalizálva. Márpedig meg tudnák oldani, mivel jól definiálható mérnöki probléma. Csak senki nem áldoz rá erőforrást, mert a hardvereket még van, aki legyártja egy tál rizsért és az ezzel okozott környezetszennyezést sem kell megfizetnie senkinek.

Ha a világ legjobb fejlesztői meg tudják oldani, hogy 1 nap alatt bootoljon ez a kernel az Intel 4004-en, az egy dolgot jelent: nincs BAROMIRA kioptimalizálva.

Ez egy feltételes mondat, amit nem tudunk, hogy igaz-e vagy sem. Valószínűleg nem igaz, de ha igaz lenne, akkor se tudnád használni szinte semmi értelmesre sem.

Most képzeld el, hogy az Intel 4004-en mennyi ideig tartana a Windows XP-nek elindulni. Kb. évek. ;-)

Ez egy feltételes mondat, amit nem tudunk, hogy igaz-e vagy sem.

Elméleti akadálya igazából nincs. Mérnöki probléma, ami megoldható.

ha igaz lenne, akkor se tudnád használni szinte semmi értelmesre sem.

Ez igaz, de ha ennyit szűrtél le belőle, akkor a lényeg sajnos nem ment át.

A lényeg nem az Intel 4004-en való futtatás lenne, hiszen az 1 nap továbbra is irreális boot idő. A lényeg az, hogy ha a 4,76 napot sikerül 1 napra lefaragni, az a többi hardveren való futtatást is lényegesen meggyorsítja, majdhogynem négyszeresére.

Az elvet kéne megértened: Ha minden fejlesztő elé odaraknánk egy Pentium 3-at vagy egy Raspberry PI-t a 14. generációs Intel CPU-s, 1 TB SSD-s, 64 GB RAM-os újravásárolt csiligép helyett, akkor jóval erőforráshatékonyabb szoftverek születnének, ugyanis már fejlesztési időben lehetne érezni a bloat-ot. Az Intel 4004 meg igazából egy challenge lenne, aminek ugyanez a hosszútávú célja.

Most képzeld el, hogy az Intel 4004-en mennyi ideig tartana a Windows XP-nek elindulni. Kb. évek. ;-)

Legalább is, szeretnél nagyot túlozni, hogy burkoltan gyalázhasd az XP-t. Felhívnám a figyelmed, hogy 90 másodperc alatt elindult azon a 160 MHz-re felhúzott 486-oson amivel nemrég kompatíbilissé tették. [1]

Ha órajel alapján szeretnénk egy minimum becslést adni, akkor 90x160000/750 = 19200 másodperc (5-6 óra) a kiindulópont, amit nyilván megdobnak még egyéb dolgok, pl. a 32-bites utasításkészlet "emulálása", a memóriaelérés lassúsága miatti overhead stb. Szóval valószínűbb, hogy hasonló eredmény jönne ki, mint Linux kernellel. Az sem biztos egyébként, hogy az XP nem győzné le a Linuxot ebben a tekintetben. Egy 133 MHz-es 486-oson 11 percig bootolt a Linux, ami kicsit több, mint a 90 másodperc. :)

az amit irsz nem is lenne hülyeség, kérdés hogy az egyszeri boot idő optimalizálás, mit ér egy mai gépen: ami a 4004-en 4 nap ->1 nap , az egy mostani gépen ~ 10mp ->2,5mp. Egyszer, bootkor. 

Ami igazából érdekes lenne az időt tekintve gyakrabban futó kódok optimalizálása lenne. Ilyen mélyen azonban nem értek az OS-ekhez, szóval nem pofázok többet.

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

 lényeg az, hogy ha a 4,76 napot sikerül 1 napra lefaragni, az a többi hardveren való futtatást is lényegesen meggyorsítja, majdhogynem négyszeresére.

Ha meg 5 év alatt sikerülne 4 napra lefaragni, akkor meg kidobott idő volna az egész.

Az elvet kéne megértened: Ha minden fejlesztő elé odaraknánk egy Pentium 3-at vagy egy Raspberry PI-t a 14. generációs Intel CPU-s, 1 TB SSD-s, 64 GB RAM-os újravásárolt csiligép helyett, akkor jóval erőforráshatékonyabb szoftverek születnének, ugyanis már fejlesztési időben lehetne érezni a bloat-ot.

Vagy igen, vagy csak sokkal lassabban készülne el kb. ugyanaz, vagy csak sokkal kevesebbet tudnának.

Egyébként sok ilyen fejlesztő van, de a produktumaikat csak nagyon kevesen használják. Lásd a parancssoros és TUI alkalmazásokat. Te sem ezeket preferálod elsősorban, így is támogatva a bloat alkalmazások készítését. ;-)

Felhívnám a figyelmed, hogy 90 másodperc alatt elindult azon a 160 MHz-re felhúzott 486-oson amivel nemrég kompatíbilissé tették. [1]

Egy 10-szer lassabb (16MHz)-es 486-oson pedig 60 mp alatt bootolt be egy mai linux.

Látod, ennyit számít, ha nem akarunk grafikus UI-t. Csak a booton nyertünk 15 -szörös gyorsaságot.

Vagy igen, vagy csak sokkal lassabban készülne el kb. ugyanaz, vagy csak sokkal kevesebbet tudnának.

Később meg többet tudnának. Alapvetően nem kéne sehova se rohannunk, pláne nem egy olyan világban, ahol már inkább mindent is újraírkálunk, csak erőforráspazarlóbb köntösben, miközben a desktop PC-k, okostelefonok, tabletek stb. használati esetei semmit sem változnak már 10 éve. Lásd pl. JS-ben újraírt bloat Microsoft Office 365, ami funkcionalitás szintjén egy Office 97-tel egyenértékű, annyi extrával, hogy a cloudban fut és ezért online kollaborációra alkalmas. Az online kollaboráció azonban sem újraírást, sem ezt a mennyiségű JS-bloat-ot nem indokolta volna. Elegendő lett volna egy plugin minden korábbi Office-ba, ami hozzáadja a funkcionalitást.

Te sem ezeket preferálod elsősorban, így is támogatva a bloat alkalmazások készítését. ;-)

Nem támogatom a bloat alkalmazások készítését, mivel nem használok bloat alkalmazásokat, leszámítva a böngészőt, de abból sem azt használom, amit egy multi rak elém. Az, hogy egy alkalmazás GUI-s, nem teszi automatikusan bloat-tá. Pláne nem igaz ez a korábbi MFC-s alkalmazásokra, amik sokszor <10 MB memóriába beleférnek.

Látod, ennyit számít, ha nem akarunk grafikus UI-t. Csak a booton nyertünk 15 -szörös gyorsaságot.

Majd hasonlítsd össze egy Qt6-bloat KDE Plasmával is az XP GUI-t, aztán lehet, hogy meg fogsz lepődni.

Meglepő hogy 2024-ben az XP gui milyen buta fos tenger.

Persze másra mutogatni mindig könnyű. Hány sor optimális kódot írtál az elmúlt évben ami jobb mint a fősodartúménök urak cucca?

A bloat erőforrás pazarló 20 éves géped sokkal kevésbé hatékony mint egy modern rendszer.

 

Az XP mint a hatékony rendszer ahol mindenhez több megás fordított alkalmazás kell?

Egy zártforrású technológia katasztrófát próbálsz piedesztrára emelni. 10 év alatt mennyit sikerült gyorsítanod az XP futásán?

Jók ezek a vallásos ideológiák aztán a végén az ellenkezőjét csinálod. lol.

Nem, de lehetne.

Meglepő hogy 2024-ben az XP gui milyen buta fos tenger.

Meglepő, hogy a GNOME3 GUI milyen egy buta fostenger. Vagy bármelyik tabletesített UI. Ami ennél is meglepőbb, hogy több erőforrást zabál, mint egy nála jóval okosabb XP GUI.

A bloat erőforrás pazarló 20 éves géped sokkal kevésbé hatékony mint egy modern rendszer.

Nem annyival, amennyivel kevésbé hatékony, pazarló és környezetszennyező az a 20 generációnyi PC, amit azóta piacra dobtak, újravásároltatás céljából.

Az XP mint a hatékony rendszer ahol mindenhez több megás fordított alkalmazás kell?

A static linkelt alkalmazásokra gondolsz? Nos, azok egy Qt6-bloat-tal jóval nagyobbak, több tíz megát akarsz több száz megánál nagyobbnak feltüntetni. A memóriába ugyanúgy be lesz húzva, akkor is, ha a diszken csak egyszer van csak meg. Egyébként, nem csak static build alkalmazások vannak Windows-on sem, de amik vannak, és amiket használok, sokkal hatékonyabbak a gyarkorlatban, mint Linuxos alternatíváik.

Egy zártforrású technológia katasztrófát próbálsz piedesztrára emelni.

Én csak használom. Te akarsz egy multik által szétgányolt, nyílt forráskodú technológiai katasztrófát piedesztálra emelni (desktop Linux).

10 év alatt mennyit sikerült gyorsítanod az XP futásán?

Nem kellett, mert 10 éve is ugyanezt a hardvert használtam és elégedett voltam a gyorsaságával, miután beleraktam egy SSD-t.

Jók ezek a vallásos ideológiák aztán a végén az ellenkezőjét csinálod. lol.

Igen, pl. a static vs dynamic linking bigott különbségértelmezése, amit tolsz az tipikusan ilyen. Nem baj, ha bloat a Qt6, mert úgyis™ csak™ egyszer™ töltődik be a memóriába (kivéve a static buildelt Linux appokkal, flatpak meg stb. amik egyre népszerűbbek). Aztán végül lesz egy 300+ MB-os librarynk, amit akkor is be kell húzni, ha csak egy Qt-s alkalmazást használsz. 🤡

https://letmegooglethat.com/?q=windows+xp+touchscreen

Hint: úgy, ahogy a touch eszköz drivere ezt implementálja és ez rendben is van így.

Kifejezetten örülök neki, hogy nincs natív touch support az XP-ben, mert így a felhasználói felülete nem lett ennek megfelelően elsilányítva, eltabletesítve, helypazarlóra, óvodás tapicskoldára szétgányolva.

Apropó, soha nem volt touchscreen-es eszközöm és soha nem is lesz.

A touch-ot a linux is jól kezeli kernel szinten, csak GTK3-tól lefele éppen kb. használhatatlan.

Én se szeretem a GTK3-at (a korábbiakat se, egy horror őket programozni), de ettől még ez tudja kezelni, a GTK2 meg az XP meg nem tudja. És amikor mondjuk egy touchscreen-es raspi-ra fejlesztesz, amit billentyű meg egér nélkül fognak használni, akkor az XP többszörösen se jön szóba.

A GTK3 meg a Qt viszont igen.

Megint nem érted a lényeget, vagy legalább is úgy csinálsz, mintha nem értenéd.

A Gtk3-bloat-tal 2 fő probléma van. Az egyik, hogy bloat, a másik, hogy touchscreen-optimalizált. Tehát, az a 99% desktop user, aki nem használ touchscreen-t, szívjon csak nyugodtan az áttekinthetetlenné silányított, végtelen paddingos, animációbuzi, desktopot megcsúfoló UI-jal, csak azért, hogy Caro tudjon touch-only Raspberry PI-re fejleszteni.

Elmagyarázod egyébként, hogy egy touch event-eket mouse event-ekre normálisan leképző driverrel miért lenne használhatatlan egy natív XP-s (MFC-s), vagy egy GTK2 UI?

Kattintás triviálisan leképezhető, drag & drop triviálisan leképezhető, two-finger scroll triviálisan leképezhető... akár kurzor nélkül is.

Meglepő hogy 2024-ben az XP gui milyen buta fos tenger.

Persze másra mutogatni mindig könnyű. Hány sor optimális kódot írtál az elmúlt évben ami jobb mint a fősodartúménök urak cucca?

A bloat erőforrás pazarló 20 éves géped sokkal kevésbé hatékony mint egy modern rendszer.

 

Az XP mint a hatékony rendszer ahol mindenhez több megás fordított alkalmazás kell?

Egy zártforrású technológia katasztrófát próbálsz piedesztrára emelni. 10 év alatt mennyit sikerült gyorsítanod az XP futásán?

Jók ezek a vallásos ideológiák aztán a végén az ellenkezőjét csinálod. lol.

Nem, de lehetne.

Az, hogy egy alkalmazás GUI-s, nem teszi automatikusan bloat-tá.

Elvileg nem kellene, gyakorlatilag mind sokkal több erőforrást eszik. Egyébként a QT-sok elég jól teljesítenek általában.

Majd hasonlítsd össze egy Qt6-bloat KDE Plasmával is az XP GUI-t, aztán lehet, hogy meg fogsz lepődni.

A legbloatabb linuxos DE-t hasonlítsuk hozzá? Az, hogy van annál is bloatabb, az nem azt jelenti, hogy az nem bloat.

Miért ne inkább a kisebb erőforrás szükségletűekből válogassunk? Pl. lehetne a TinyWM. ;-) Ha már Qt, akkor miért ne az LXQt-t? 

Jól teljesítenek mi? Próbáltál már egy LxQt-t egy régebbi gépen? Behívod a beállítások menüjét másodpercekig mást sem csinál, mint 100% CPU-val példányosítgatja a Qt6-bloat ojjektumokat. Aztán nagynehezen betölt. Bezárod az ablakot, megnyitod még egyszer. Megint másodpercekig mást sem csinál, mint 100% CPU-val példányosítgatja a Qt6-bloat ojjektumokat. Aztán nagynehezen betölt.

Jól teljesítenek mi? Próbáltál már egy LxQt-t egy régebbi gépen? 

Igen, próbáltam, nagyon jól teljesített.

Még régebbi gépen pedig az antiX-ot használjuk, annak még sokkal kisebb az erőforrás igénye, köszönhetően az IceWM ablakkezelőnek. 

Szerencsére Linuxon válogathatunk a nagyon kicsi erőforrás igényű disztribúciók közül. Illetve akár használhatunk GUI nélkül is Linux-ot, aminek még sokkal kevesebb erőforrás kell.

Közben találtam egy 40 MHz-es 486-on futó grafikus Linux-ot (DSL), ami gyorsabban bootol, mint a Windows XP a 160 MHz-es 486-on. Tehát a Windows XP az 4-szeresen bloat ehhez képest ;-)

Még régebbi gépen pedig az antiX-ot használjuk, annak még sokkal kisebb az erőforrás igénye, köszönhetően az IceWM ablakkezelőnek. 

Disztrók közötti viszonylatban nem a Linuxnak van erőforrásigénye, hanem az alkalmazásoknak, amiket futtatsz rajta. A Gtk3-bloat szutyok nem fog kevesebbet zabálni AntiX-on.

DSL

A DSL egy fossá-húggyá herélt Linux, legalább is az eredeti koncepciója szerint. Fossá-húggyá herélt Windows XP-vel kéretik összehasonlítani. A 486-osra felpróbált XP nem herélt XP, hanem kompatíbilitási patchekkel megáldott XP.

Ja meg esetleg a DSL 2024-et is próbáld ki a négynyolcvanhatoson. Kíváncsi vagyok, a Firefox mennyi idő alatt képes elindulni rajta.

Mert lynx-szel guglizgatni könnyű gyorsabban, mint Firefox-szal, de a lynx-et meg egy DOS-os böngészőhöz kéne akkor hasonlítani.

Nem a Linuxnak van erőforrásigénye, hanem az alkalmazásoknak, amiket futtatsz rajta. 

Ebben nagyon tévedsz, az OS-nek magának van erőforrás igénye, nem is elhanyagolható. Természetesen az alkalmazásoknak is van erőforrás igénye, de ott már nincs számottevő különbség, ha ugyanazt az alkalmazást futtatod Linuxon és vagy Windowson (persze lehetnek kivételek, ha nem ugyanaz a GUI libre épül). Az, hogy milyen alkalmazásokat futtatsz egy-egy feladatra, ott megint hatalmas különbségek vannak.

Egyébként a Linux kerneltől indult a szál.

A DSL egy fossá-húggyá herélt Linux

A kívánalmaid szerint, optimalizálták a minél gyorsabb futás érdekében. Nem épp ilyen megoldásokra vágysz?

Mert lynx-szel guglizgatni könnyű gyorsabban, mint Firefox-szal, de a lynx-et meg egy DOS-os böngészőhöz kéne akkor hasonlítani.

Épp erről beszélek már az elejétől, hogy a bloat leginkább onnan ered, hogy erőforrás pazarló módon vannak megvalósítva a programok, web oldalak. Ha nem akarsz annyi bloat-ot, akkor használj erőforrásbarát alkalmazásokat! Az kicsit visszás, hogy kellenek a csillivilli dolgok, de azok megvalósítását optimalizálják mérnök seregek, de azért maradjon ingyenes is.

Természetesen az alkalmazásoknak is van erőforrás igénye

Igen és ez az, ami számít is, mivel az alkalmazásokat használod. Az OS tehát mindegy, mert abból választhatsz olyan disztrót, aminek elhanyagolható az erőforrásigénye.

nincs számottevő különbség, ha ugyanazt az alkalmazást futtatod Linuxon és vagy Windowson (persze lehetnek kivételek, ha nem ugyanaz a GUI libre épül)

Jaj dehogynincs... Double Commander a legjobb példa, ami Windows-on kb. vetekszik a Total Commander pehelysúlyával, Linuxon meg a Qt-bloat és a GTK-bloat miatt úgy 2x-3x annyi CPU-t és memóriát zabál.

A kívánalmaid szerint, optimalizálták a minél gyorsabb futás érdekében. Nem épp ilyen megoldásokra vágysz?

Optimalizáció nem azt jelenti, hogy kiszeded belőle a bloated funkcionalitást, hanem hogy ugyanazt a funkcionalitást nem bloated módon valósítod meg.

Épp erről beszélek már az elejétől, hogy a bloat leginkább onnan ered, hogy erőforrás pazarló módon vannak megvalósítva a programok, web oldalak.

https://a.te.ervelesi.hibad.hu/lenyegtelen-konkluzio

Ebben egyet is értünk. Amit nem veszel figyelembe, hogy lehet GUI-s appokat is bloat nélkül megírni, csak 2024-ben nem divat.

Az kicsit visszás, hogy kellenek a csillivilli dolgok, de azok megvalósítását optimalizálják mérnök seregek, de azért maradjon ingyenes is.

https://a.te.ervelesi.hibad.hu/hamis-dilemma

Nem kellenek a csilivili dolgok. Letisztult, professzionális GUI kell, amilyen egy Total Commander-nek, SumatraPDF-nek, IrfanView-nak stb. Egy hamis dilemmát próbálsz felállítani, miszerint GUI-s app csak bloat lehet, de ez nem igaz. GUI-s appot is meg lehet írni normálisan, bloat nélkül.

Az OS tehát mindegy, mert abból választhatsz olyan disztrót, aminek elhanyagolható az erőforrásigénye.

Pont ugyanez igaz az alkalmazásokra is. Választhatsz olyat, aminek kicsi az erőforrás igénye.

Double Commander a legjobb példa, ami Windows-on kb. vetekszik a Total Commander pehelysúlyával, Linuxon meg a Qt-bloat és a GTK-bloat miatt úgy 2x-3x annyi CPU-t és memóriát zabál.

Én is ezt írtam. Ha Windowson is ugyanazt a grafikus libraryt használja, akkor nem lenne nagy különbség.

Optimalizáció nem azt jelenti, hogy kiszeded belőle a bloated funkcionalitást, hanem hogy ugyanazt a funkcionalitást nem bloated módon valósítod meg.

Szerintem ezt is jelenti. Sőt, ennek kellene lennie a kezdőlépésnek. Ha van két alkalmazás, amiből az egyik sok erőforrást használ, de vannak benne bloat funkciók, a másikban nincsenek, de kevés erőforrást használ. Ilyenkor nem jobb az optimalizálatlan kicsi, mint az optimalizált nagy?

Letisztult, professzionális GUI kell.

A GUI is egy felesleges igény. Ha ugyanazt, vagy több funkcionalitást ad egy TUI, akkor nem az a jobb a szükségleteidnek?

Egy hamis dilemmát próbálsz felállítani, miszerint GUI-s app csak bloat lehet, de ez nem igaz. GUI-s appot is meg lehet írni normálisan, bloat nélkül.

Megnéztem pár file manager memory használatát:

  • GUI. Windows, Total Commander: ~2 MB
  • GUI. Windows, Windows Intéző: ~110 MB
  • GUI. Linux, Double Commander: ~120 MB
  • GUI. Linux, Dolphin: ~120 MB
  • GUI. Linux, Nautilus: ~120 MB
  • GUI. Linux, Thunar: 55 KB
  • TUI. Linux, MC: 12 KB
  • TUI. Linux, LF: 7+12 KB

A Thunar, ami egy bloat GTK-s alkalmazás, példája mutatja, hogy valóban meg lehet írni sokkal kisebb erőforrás igényűre is. Ám még ez is 3-5 -ször több erőforrást kíván, mint a TUI-sok. Szóval a gyakorlat azt mutatja, hogy a TUI-sok jóval kisebb erőforrással beérik. (A parancssoros fájlkezelőkről meg nem is beszélve, cp, cd, mv, ...  ;-)

Pont ugyanez igaz az alkalmazásokra is. Választhatsz olyat, aminek kicsi az erőforrás igénye.

Csak Linuxon nincs ilyen választék GUI-s alkalmazásokból.

Én is ezt írtam. Ha Windowson is ugyanazt a grafikus libraryt használja, akkor nem lenne nagy különbség.

De nem ugyanazt használja, hanem a saját bloated szutyok megvalósítását.

A GUI is egy felesleges igény. Ha ugyanazt, vagy több funkcionalitást ad egy TUI, akkor nem az a jobb a szükségleteidnek?

Ha ugyanazt vagy több funkcionalitást ad, akkor jobb, de általában nem ugyanazt adja és nem is úgy adja. Nem, nem szeretnék parancsokat gépelgetni mondjuk több száz gigás mappákban több ezer fájl rendezgetéséhez. Szeretném átlátható módon, összesítve látni egy GUI-n, de nem 120 MB memóriahasználatért cserébe, ha a tizedéből is lehetséges.

A Thunar, ami egy bloat GTK-s alkalmazás, példája mutatja, hogy valóban meg lehet írni sokkal kisebb erőforrás igényűre is.

Helyesen: A Total Commander, MFC-s alkalmazás példája mutatja, hogy valóban meg lehet írni sokkal kisebb erőforrás igényűre is. Linuxon Fltk-ban lehetne ezt utánozni, Gtk-bloat-ban, Qt-bloat-ban nem.

Ám még ez is 3-5 -ször több erőforrást kíván, mint a TUI-sok.

Mert Gtk-bloat.

Csak Linuxon nincs ilyen választék GUI-s alkalmazásokból.

A File Managerre felsoroltam vagy 6-ot, de van még bőven.

De nem ugyanazt használja, hanem a saját bloated szutyok megvalósítását.

Nem egy alkalmazásról beszélünk. Van amelyik ugyanazt használja, valamelyik nem. Javarészt törekednek arra, hogy ne kelljen több megoldást fejleszteni, a Qt az pont ilyen, megy Windowson is Linuxon is.

Nem, nem szeretnék parancsokat gépelgetni mondjuk több száz gigás mappákban több ezer fájl rendezgetéséhez. Szeretném átlátható módon, összesítve látni egy GUI-n, de nem 120 MB memóriahasználatért cserébe, ha a tizedéből is lehetséges.

TUI-s programoknál nem kell parancsokat gépelgetned, ráadásul nem a tizede, hanem az tízezrede a memóriahasználat.

Helyesen: A Total Commander, MFC-s alkalmazás példája mutatja, hogy valóban meg lehet írni sokkal kisebb erőforrás igényűre is. Linuxon Fltk-ban lehetne ezt utánozni, Gtk-bloat-ban, Qt-bloat-ban nem.

Nem, a Thunar mutatja, mert az van a TUI-sok szintjén, de az is 3-5-ször többet eszik. A Total Commander pár százszor annyi memóriát eszik, mint a TUI-s programok.

Ám még ez is 3-5 -ször több erőforrást kíván, mint a TUI-sok.

Mert Gtk-bloat.

Akkor mit mondjunk a Total Commanderre, ami 40-szer annyi memóriát eszi, mint a Bloat GTK-s Thunar? Bloat a köbön?

A File Managerre felsoroltam vagy 6-ot, de van még bőven.

Kis erőforrásigényű nincs olyan, ami hozza a Total Commander funkcionalitását.

Javarészt törekednek arra, hogy ne kelljen több megoldást fejleszteni, a Qt az pont ilyen, megy Windowson is Linuxon is.

Cserébe ritka nagy bloat és igazából egyik platformon se hatékony.

TUI-s programoknál nem kell parancsokat gépelgetned

Captain Obvious strikes again.

ráadásul nem a tizede, hanem az tízezrede a memóriahasználat.

Ami meg konkrétan hazugság.

Nem, a Thunar mutatja, mert az van a TUI-sok szintjén, de az is 3-5-ször többet eszik.

A Thunar memóriahasználata azt mutatja, hogy az xfce4-hez már be van töltve a gtk-bloat és a shared libraryk miatt nem tölti be mégegyszer.

A Total Commander pár százszor annyi memóriát eszik, mint a TUI-s programok.

Helyesen: A Total Commander annyi memóriát eszik, mint a TUI-s programok, cserébe százszor annyi funkcionalitást ad.

Akkor mit mondjunk a Total Commanderre, ami 40-szer annyi memóriát eszi, mint a Bloat GTK-s Thunar?

Hogy vagy hazudsz, vagy nincs fogalmad a memóriahasználat jelentéséről.

Midnight Commander (verzió: 4.8) RSS = 12980 kB (ps aux)

Total Commander (verzió: 11.03) RSS = 12849 kB (wmic process where processid=PID get WorkingSetSize)

Bloat a köbön?

Igen, a Double Commander, Nautilus, Dolphin, Krusader stb. mind bloat a köbön. Double Commander annyiból kivétel, hogy Windows-on nem akkora bloat.

Nem vagyok nagyon jó ismerője a disztróknak.

Grafikus felület nélkül egy Atom-on szerintem már szinte bármelyik Linux disztró elmegy.

A TinyCore-t nem ismerem, de úgy tűnik, hogy abból kell gazdálkodni, ami benne van a telepítőben.

Én egy régebbi gépen antiX-et próbáltam, azt még grafikus felülettel is elvitte. Az Debian alapú. Foghatsz egy Debiant is és összelegózhatod, ami kell. Esetleg kiindulhatsz egy Ubuntu server-ből is. Ha bátrabb vagy, akkor tudom ajánlani a NixOS-t is, én ez utóbbit használom, de nem túl gyenge gépen.

Lényeges, hogy 32 bites a gép és korlátozott az SSD mérete (már nem emlékszem pontosan, de pár giga). Sok disztró dobta a 32 bit támogatását, többek között az is, ami most éppen rajta van.
Tiny Core-ban ha nincs csomagkezelő, akkor hogy működik a frissítés?

GUI nem kell semmilyen, csak bonyolítaná az életet. Úgyis egy xterm-et nyitnék.

Szia!

 

Szerintem annyira nem lehet nehéz..

[OpenWrt Wiki] OpenWrt on x86 hardware (PC / VM / server)

 

Én anno olyat csináltam, hogy az img-t átkonvertáltam vdi-re, így lett egy virtuális routerem, ami ha kellett el tudta látni mondjuk VPN-el az összes virtuális gépemet... De csomó minden másra is jó volt amit a virtualbox anno nem igazán tudott. dns, dhcp, routing, stb...

Puppy-t. Az én 64 bites netbookomon az offline retrojátszós xp mellett bookwormpup64 van, ennek a kommentnek a kedvéért bekapcsoltam :)

         OS: BookwormPup64 10.0.8 x86_64
   Neo     Host: 1001PX x.x
  Fetch    Hostname: root@puppy-eee
 SysInfo   Kernel: 6.1.106
  •••••    Uptime: 11 mins
   •••     Display: 1024x600 @ 60.19Hz
           WM: JWM v2.4.3
           WM Theme: Color: #3C5FB4
           GTK Theme: Polished-Blue [GTK2/3]
           Icons: Puppy Standard [GTK2/3]
           CPU: Intel Atom N450 (2) @ 1.667GHz [55.0°C]
           GPU: Intel Atom Processor D4xx/D5xx/N4xx/N5xx
           GPU Driver: i915
           Memory Used: [■■■■■■■■■■■■ ] 1532M / 1948M (78% used)
           Swap (Used): [ ] 94M / 1903M (4.9% used)
           UnionFS (/): [■■■■■■■■ ] 15G / 30G (54% used) - overlay
           Drives: 234.7G
             sda: ST9250315AS (232.9G)
             zram0: RAM Swap Disk (1.9G)

 

top így néz ki egy firefox ESR-el és netrádióval a háttérben:

top - 09:31:57 up 13 min,  0 user,  load average: 0,30, 1,04, 1,09
Tasks: 128 total,   2 running, 126 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18,4 us, 11,2 sy,  0,0 ni, 70,4 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   1948,8 total,    118,8 free,   1542,9 used,   1116,1 buff/cache     
MiB Swap:   1903,1 total,   1809,6 free,     93,5 used.    405,9 avail Mem

 

Amúgy 2-3 rókatabot simán elvisz, nyilván facebook és társai felejtős, ytfzf-el 480p simán nézhető rajta,

Valamikor próbaképp szabim alatt csinálok majd magamnak egy ilyen netbook only challange hetet a vicc kedvéért. Szerintem nagyon simán vehető lesz :)

( Caro | 2024. 09. 24., k – 19:30 )

Lesz még itt Linux csövön, relén is :)

( hokuszpk | 2024. 09. 25., sze – 14:05 )

hajolemlexem a NetBSDre volt az a mondas, hogy mindenen is fut ; ezzel a 4004 mutatvannyal arrafele mi a helyzet ?

HUP te Zsiga !