BSD auf 486er... ;)

Ich betreibe hier mal etwas Cherry picking.
pit234a schrieb:
Ist es zielführend, dann von schmal zu reden, wenn möglichst wenige Zeilen Code kompiliert werden müssen?
Oder, wenn das System möglichst wenig Speicherplatz verwendet? Was Makulatur wird, wenn dann auf dem System ein X-Server und Firefox und LibreOffice laufen sollen. Wenn die Anwendungen sehr viel mehr Ressourcen verbrauchen, als das darunter liegende System selbst, was soll dann schmal sein?
Zum Vergrößern anklicken....
Wenn das System annähernd so viele Ressourcen braucht wie die Anwendungen, die darauf laufen ist ganz schön was schief gegangen. Das System tut ja nichts von dem was Du eigentlich willst. Es ist nur ein Stück Infrastruktur das Deinen Anwendungen möglichst alle verfügbaren Ressourcen zugänglich machen sollte.
 
Bezüglich "schmal" schließeich mich der Meinung von @Kamikaze an. Trotzdem Danke für Deine Ausführugen, @pit234a , denn ich wusste z.B. auch nicht, dass mit systemd auf einmal eine Menge gewohnter Befehle nicht mehr vorhanden sind. Also nochmal, welches Linux ohne systemd ist empfehlenswert?
 
Du koenntest auch sowas wie http://www.kolibrios.org/de/index testen.

KolibriOS ist ein kleines, aber dennoch unglaublich leistungsstarkes und schnelles Betriebsystem. Dieses Packet benötigt nur einige Megabyte Festplattenplatz und 8 Megabyte Arbeitsspeicher um vollständig zu laufen. Kolibri enthält eine reiche Anzahl an Anwendungen, wie z.B.: ein Schreibprogramm, ein Bildbetrachter, eine Bildverarbeitung, einen Internet Browser und mehr als 30 aufregende Spiele. Volle FAT12/16/32 Unterstützung wurde eingebaut, wie die Lesefunktionalität für NTFS, ISO9660 und Ext2/3/4. Treiber wurden für weitverbreitete Sound-, Netzwerk- und Grafikkarten geschrieben.
Zum Vergrößern anklicken....
 
cabriofahrer schrieb:
denn ich wusste z.B. auch nicht, dass mit systemd auf einmal eine Menge gewohnter Befehle nicht mehr vorhanden sind.
Zum Vergrößern anklicken....

Das hat halt auch großteils nichts mit systemd zu tun. Klar, bei nem neuen Init muss man eben systemctl anstatt service nutzen um die Services zu steuern, soweit so klar.

Das Dinge wie ifconfig, route oder brctl verschwunden sind liegt aber daran, dass das alles schon seit über 5 Jahren von ip abgelöst wurde, und ip auch der Standard ist. Die alten Programme waren seit ewigkeiten als deprecated markiert. Dementsprechend gibt es neue Funktionen wie z.b. Namespaces oder rulebased Routing (oder wie das Ding heißt) auch nur mehr in ip und die alten Tools sind eigentlich unbrauchbar für vieles. Wer sie dennoch vermisst kann sie immer noch nachinstallieren.
 
Kamikaze schrieb:
Ich betreibe hier mal etwas Cherry picking.

Wenn das System annähernd so viele Ressourcen braucht wie die Anwendungen, die darauf laufen ist ganz schön was schief gegangen. Das System tut ja nichts von dem was Du eigentlich willst. Es ist nur ein Stück Infrastruktur das Deinen Anwendungen möglichst alle verfügbaren Ressourcen zugänglich machen sollte.
Zum Vergrößern anklicken....

ahja, das ist ziemlich genau das, was ich damit sagen wollte: weshalb redet man so viel über schlanke Systeme, wenn sie doch tatsächlich im Endausbau nur noch eine minimale Rolle haben und die Anwendungen selbst den Löwenanteil stellen.

Ich muss allerdings gestehen, dass ich mit "System" automatisch so etwas wie FreeBSD oder eben GNU/Linux verbunden habe.
Benutzt man den Begriff für ein komplettes Desktop-System, dann kann es durchaus mehr Sinn machen, sich über "schlanke" Anwendungen zu unterhalten. Da zeigt sich viel eher Potenzial, als in dem eh recht schmalen und unbedeutenden Unterbau.
Ich behaupte mal etwas nassforsch, dass es kaum einen Unterschied machen dürfte, ob ich für ein derartiges System ein FreeBSD nutze oder ein GNU/Linux und ob mit oder ohne systemd. Mit systemd bootet es vielleicht noch etwas schneller, was interessiert das schon. Im Betrieb, auf dem Desktop, dürfte der Unterbau ziemlich wenig ins Gewicht fallen.
Und deshalb würde ich mir da auch nicht irgendein fertig-System ansehen, wenn es nicht gerade gilt, wirklich exotische HW zu versorgen.
Wer ein schlankes Desktop-System will, sollte sich Gedanken darüber machen, was er möchte und braucht, auf welche Dienste man verzichten kann und welche Anwendungen wenig Ressourcen verbrauchen und sich das dann zusammenstellen und zwar egal, ob aus einem GNU/Linux oder FreeBSD.

Ich meine, dass heute wohl jeder einsieht, dass neue Spiele auf schwacher, alter HW nicht richtig laufen. Das akzeptiert jeder und so muss man vielleicht akzeptieren, dass ich auf schwacher HW besser keine große Office-Suite oder ein Desktop-Environment mit gefühlten hundert Diensten laufen lassen kann. Egal, auf welchem Unterbau.

Nebenbei: wenn ich mich nicht teusche, stand in der Debian Doku auch was darüber, wie man ohne systemd bleiben kann und die Live-Linux-DVD Knoppix, die aus Debian gebaut wird, benutzt ebenfalls keinen systemd. Mir scheint das flexibler zu sein, als es bei fertig-Desktop-Versionen erscheint. Als ich zB damals hörte, dass Debian sich für systemd entschieden hatte, erschein mir das alternativlos. Scheinbar ist dem aber nicht so.

Und vielleicht noch was: die ip-Kommandos sind durchwegs kürzer, als die alten Tools, angenehm. Die systemd-Kommandos aber deutlich länger und umständlicher. Trotzdem erscheint mir auch die Entwicklung unter ip noch nicht ganz zeitgemäß und der Stein der Weisen zu sein. Wir wechseln heute viel häufiger Netzwerke, als das früher der Fall war und dazu ist die Konfiguration doch noch etwas steif und schwerfällig. Nicht umsonst liefert quasi jedes DE eine GUI, womit das dann der Endnutzer einfach verwalten kann.
 
cabriofahrer schrieb:
"Lite", aber nur für 64bit? Ist ja Panne...
Zum Vergrößern anklicken....
nein, finde ich nicht.

"Lite" und so sind natürlich nur Namen und sagen nichts.
Die Problematik hatte ich oben schon mal erwähnt.
Du darfst deshalb jedenfalls nicht erwarten, dass eine dermaßen benannte Distribution eine fertig Lösung für deine Fragestellung anbietet und auch nicht schließen, dass "Lite" = "light" = "gut für alte HW" steht.

Alexander88207 schrieb:
Eine 32bit iso haben die auch noch, die bis April 2021 unterstuetzt wird.
Zum Vergrößern anklicken....
32Bit-Intel wird derzeit bereits "quasi" nicht mehr unterstützt.
Beinahe alle Distributionen haben das abgekündigt und schleppen es nur widerwillig weiter, auch FreeBSD und das ist auch vollkommen verständlich. Damit muss irgendwann mal Schluss sein, so leid es mir persönlich auch tut. Die Stimme der Vernunft sagt deutlich: weg davon und endlich begraben!
 
Das große Problem mit 32 Bit x86 ist halt auch, dass es eine recht unsaubere Architektur ist. Diplomatisch ausgedrückt. 64 Bit x86 aka amd64 aka intel64 aka x64 aka x86_64 ist da viel sauberer. Einfach in den Longmode schalten, die Altlasten vergessen und glücklich sein.

Das Drama geht schon damit los, dass viele der von modernen Betriebssystemen benötigte Funktionen erst nach und nach kamen. Man nutzt dann die schnelle Hardwarefunktion, wo sie verfügbar ist und fällt auf langsamere Softwareimplementierungen zurück, wo es nicht der Fall ist. Das verkompliziert den Code extrem. Um das abzufangen, haben die meisten Betriebssysteme ihren 32-Bit Support für x86 in den letzten Jahren schon stark verkrüppelt. So haben der Linux-Kernel und FreeBSD die Unterstützung des originalen 80386 schon länger eliminiert. In FreeBSD 13.0 wird nun der 80486 folgen. Außerdem wird inzwischen die x87 FPU praktisch überall vorausgesetzt. Mittelfristig wird man sicher durchgehen dort landen, wo viele Linux-Distros schon sind. Wenn noch 32-Bit x86, dann nur in der letzten Ausbaustufe 80686, aka Pentium Pro.

Dann kommen da unendlich viele Altlasten zu. Beispielsweise muss man für einige Dinge mit dem BIOS sprechen, was aber nur im Real Mode geht. Also kann man entweder vom Protected Mode zurück in den Real Mode schalten, was sehr frickelig ist. Oder man nutzt den Virtual 8086 Mode, was wieder seine Probleme hat. Die meisten modernen Systeme nutzen einen 8086 Emulator in Software. Oder Segmentation. Kein modernes System nutzt Segmentation, aber die Register und so weiter sind da und müssen an diversen Stellen beachtet werden. 32-Bit x86 hat auch einen recht interessanten Bootprozess. Die Liste ist noch viel länger.

Außerdem ist da das API-Problem. Beispielsweise schleppt FreeBSD/i386 jede Menge Altlasten mit sich herum. Das geht damit los, dass es komplett anders als alle anderen Architekturen bootet. Es geht über große Unterschiede in der virtuellen Speicherverwaltung. Und es endet beim 32 Bit time_t, der 2038 überlaufen wird. FreeBSD/i386 hat man bisher aufgrund der Verbreitung der Architektur noch mit durchgeschleppt und zu 13.0 haben sich noch genügen Entwickler gefunden, die es weiter unterstützen wollen. Aber zu FreeBSD 14.0 wird man eine unbequeme Entscheidung treffen müssen. Es entweder ganz rauswerfen, nach über 20 Jahren FreeBSD/amd64 wäre es vielleicht wirklich Zeit dafür. Oder es inkompatibel brechen, um zumindest das Jahr 2038 Problem zu lösen, womit alte Binaries aber nicht mehr laufen würden.

Nun hab ich mehr geschrieben, als ich wollte. Ich wollte eigentlich darauf hinaus, dass man Hardware und Software irgendwo zusammen sehen sollte. Man kann nicht erwarten, dass ein neues Betriebssystem auf teils Jahrzehnte alter Hardware läuft. Muss es auch gar nicht. FreeBSD 4.11 gilt bis heute als eines der besten, wenn nicht sogar beste Release, was FreeBSD jemals hatte. Und es dürfte auf einem 486er wunderbar laufen. Die Software von damals, ich glaube die Pakete waren fast vollständig auf der Installations-CD, kommt mit der CPU auch viel besser klar, als moderne Programme. Nur kann ein Firefox 1.0 [1] wahrscheinlich BSDforen.de gar nicht mehr sinnvoll rendern.

1: https://svnweb.freebsd.org/ports/tags/RELEASE_4_11_0/www/firefox/
 
pit234a schrieb:
Die Stimme der Vernunft sagt deutlich: weg davon und endlich begraben!
Zum Vergrößern anklicken....

Im Prinzip richtig, in Einzelfällen aber schade, wenn ein Stück Hardware gerade für bestimmte Zwecke obendrein auch noch gut funktioniert. Ich bin sicherlich kein Anhänger der Nachhaltigkeit, aber solange ein Prozessor nicht durchbrennt, kann man ihn noch nutzen. Den vorigen Post von @Yamagi finde ich wie immer wieder sehr informativ, und wenn die 64bit Architektur so viel sauberer und besser ist, dann hat sich nach meinem Empfinden diese Architektur viel zu langsam durchgesetzt.
Ich kann mich noch erinnern, dass die ersten 64bit-Prozessoren (von AMD?) so gegen Anfang des Milleniums auf den Markt kamen. Zu der Zeit nutzte praktisch jeder noch Windows XP (32bit). Es brauchte glaube ich Jahre, bis Microsoft eine 64bit Version von XP auf den Markt brachte, die sich aber nicht dursetzte. M.E. hatte das damit zu tun, dass man dann plötzlich für seine Hardware (Drucker, Scanner, Grakas, Soundkarten, etc) 64bit Treiber brauchte, die die Hersteller noch nicht lieferten. Also was war dann der Nutzen? So blieb man jahrelang eben bei Win XP, es hing natürlich wieder alles vom OS, bzw. von Microsoft ab. Erst ab Windows 7 ging die Reise langsam in Richtung 64bit. Und trotzdem gibt es immernoch Spiele, für die Windows-Plattform natürlich, die nur ein paar Jahre alt sind und immernoch über einen 32bit Installer verfügen. Wenn man ab und zu auf Steam guckt fällt auf, dass erst in den letzten paar Jahren die Spiele zunehmend nur noch in 64bit angeboten werden.
Das Problem ist für mich also, dass die Umstellung auf 64bit viel zu lange gedauert hat und wahrscheinlich aus dem Grund noch lange Zeit Hardware mit 32bit Architektur angeboten wurde, gerade im Laptopsegment.
 
Nicht zu vergessen auch Intels Träume von der Eroberung der Weltherrschaft mit dem Itanium. Liebevoll auch als "Die Itanic" bezeichnet (Grafik von Wikipedia):
Itanium_Sales_Forecasts_edit.webp


Intel hoffte noch Jahre nach der Ankündung von AMD64 (2001) und dem Erscheinen des Opteron (2003) darauf, dass sich der Itanium durchsetzten und x86 verdrängen würde. Sie lizensierten und implementierten AMD64 erst, als Microsoft klarstellte, dass es Windows Vista nicht für den Itanium geben und man sich auf AMD konzentrieren würde. Und weil Intel nun mal Intel ist, implementierten sie es in den ersten CPUs noch leicht anders und nannten es erst EMT64 und später Intel64. Vor allem unterstützten der Pentium 4 und Pentium D im 64 Bit Modus das NX-Bit nicht. Das wurde erst mit dem Core2 korrigiert, es gibt aber bis heute kleinere Unterschiede zwischen AMDs und Intels Implementierungen.
 
Das mit dem "leichtgewichtigen" OS hatte mich direkt weiters interessiert; früher brauchten die ganzen Konsorten ja auch keine GBytes an RAM usw.
Hatte noch ne pcengines 3d3 (1x 500 MHz Geode, 256MB RAM, VGA) im Fundus, welche ich mal spaßeshalber mit dem aktuellen OpenBSD 6.7 für i386 bestückt habe (auf 8 GB CFcard aus ner Kamera), und siehe da: sogar X läuft;

Die Installation war etwas holprig (direkt auf der 3d3 selber ging bei mir gar ned) - ich hab die CFcard in ner 2d13 (800MHz Geode, kein VGA) über PXE installiert und dann auf die 3d3 umgesteckt.

Habe nach der Installation /tmp und /var in je ein RAM-Laufwerk verlegt (8MB /tmp, 16 MB /var) sowie swap deaktiviert, um die Schreibzugriffe auf die CFcard auf ein minimum zu reduzieren.
Die standardmäßig aktivierten Daemons smtpd und sndiod sind ebenfalls deaktiviert.

Direkt nach Start in die Konsole laufen 22 Prozesse; ca 67 MByte (Anzeige in top: 18/67 act/tot) nimmt sich das System an RAM;

Nach Start von xenodm laufen dann so um die 28 Prozesse, RAM Verbrauch fürs System klettert auf ca 110 MByte (44/110 act/tot), in fvwm Sitzung dann auf ca 54/122 MB;

Bei Installation von Paketen mittels pkg_add ist man dann bei ca 40 Prozessen, (90/161 MByte), die load average bei ca 0.5, also noch durchaus Reserven vorhanden.

Alles in allem fühlt sich die Maschine bei Login per ssh oder auch direkt in die lokale Konsole erstaunlich "normal schnell" an; ich hätte mir das weitaus schlimmer vorgestellt - auch die X-Sitzung unter fvwm kann man noch dann bedienen, wenn z.B. ein pkg_add nebenher läuft - und das mit nur einem CPU Kern, mit ner Geschwindigkeit im dreistelligen MHz Bereich.

Wunder braucht man jedoch keine erwarten, z.B. dauert die Installation vom midori-Browser und seinen -zig Abhängigkeiten über 20 min - hier spielt vermutlich jedoch auch die alte CFcard eine Rolle.

Nach Neuinstallation startet man mit ca 50 MB in / und 1.2 GB in /usr, dies könnte man mit Sicherheit weiter abspecken und auf ne 4 GB oder sogar 2GB CFcard drücken, je nach Nutzung;

Bei Installation von weiterer Software erhöht sich halt der Wert in /usr (das hat BSD ja eindeutig Linux voraus :D)


Fazit:
War mal wieder eine nette Erfahrung so _wenig_ wie möglich an Ressourcen zu verbrauchen; mit dem/für den 486er vom Anfangs-Thread wirds aber vermutlich mau ausschauen.
Kann man mit dieser Maschine somit heute noch was anfangen? Ich denke: ja
Sie könnte auf alle Fälle als low-Power Terminal dienen - zuerst denkt man da vermutlich heutzutage erst an RasPi, aber diese Maschine steht noch zur Verfügung, läuft von CF Karte, und - läuft mit OpenBSD; etwas, was der RasPi (4) bislang noch nicht kann; zumindest waren meine Versuche damit nicht von Erfolg gekrönt.

Mit dem modernen OpenBSD zeigt sich hier jedoch auch gleich noch ein Nachteil: Kernel-ARL und Library-ASLR;
diese (bzw deren Compiler- und Linkerläufe) blockieren nach einem Neustart die Maschine bis zur Unbenutzbarkeit.
Auf quasi-embedded-Systemen wie diesen alten Alix ist dieses Plus an Sicherheit eher kontraproduktiv, da die dazu notwendigen Ressourcen dort eben _nicht_ zur Verfügung stehen - jedoch beim RasPi vermutlich schon.

Filesystem, nach Installation midori-Browser (tmp hatte hier noch 24MB gesamt):
Code: 
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/wd0a      1.0G   48.4M    931M     5%    /
/dev/wd0g      1.8G   36.0K    1.7G     0%    /home
/dev/wd0f      3.9G    1.9G    1.8G    51%    /usr
mfs:29089     23.2M   55.0K   22.0M     0%    /tmp
mfs:95351     15.4M    7.7M    7.0M    52%    /var


Ohne X:
Code: 
load averages:  0.01,  0.02,  0.00                       pdp-7.titan.lan 21:09:57
22 processes: 21 idle, 1 on processor                                    up  0:09
CPU states:  0.3% user,  0.0% nice,  0.2% sys,  0.0% spin,  0.3% intr, 99.2% idle
Memory: Real: 18M/67M act/tot Free: 162M Cache: 31M Swap: 0K/0K

Mit X, Login Screen/xenodm:
Code: 
load averages:  0.00,  0.01,  0.00                       pdp-7.titan.lan 23:06:00
28 processes: 27 idle, 1 on processor                                    up  0:11
CPU states:  0.1% user,  0.0% nice,  0.2% sys,  0.0% spin,  0.1% intr, 99.7% idle
Memory: Real: 44M/110M act/tot Free: 119M Cache: 45M Swap: 0K/0K

Mit X, in fvwm Session:
Code: 
load averages:  0.09,  0.03,  0.01                       pdp-7.titan.lan 23:08:20
33 processes: 32 idle, 1 on processor                                    up  0:13
CPU states:  0.1% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.2% intr, 99.8% idle
Memory: Real: 54M/122M act/tot Free: 107M Cache: 45M Swap: 0K/0K
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben