Posts by Crass Spektakel

    Beim Antworten auf einen anderen Beitrag ist mir gerade aufgefallen daß es ja einen Amiga mit nur 256kByte gab: Der Ur-Amiga aus der ersten Reihe. So einer steht sogar auf meinem Dachboden aber als ich ihn gebraucht erworben habe kam er schon mit 512kByte RAM die intern auf die alten RAM-Chips verlötet waren - sowas war anno tobak ja immer eine preiswerte Methode das RAM aufzurüsten.


    Was kann man eigentlich mit einem Amiga mit 256kByte anfangen? Ich schätze selbst mit Kickstart 1.0 war nach dem Booten der Workbench bestenfalls noch 180kByte frei.


    Hat jemand von euch jemals mit sowas gearbeitet?

    Und die Verarbeiten sogar "die gesamte MS/DOS"-Software. Soso. Windows 2.x (was auch '87 rauskam) auf dem Amiga 500. Das wärs (nicht) ;-)

    mit dem Sidecar war das wohl so...kleines unerwähntes Detail....

    Dafür brauchte man nichteinmal ein Sidecar, die Transformer-Software reichte ja. Und die lag imho dem Amiga 1000 serienmässig bei, vor Kickstart 2.0 konnte man das zumindestens nachkaufen.


    Und ja, Amiga Transformer war ELEND lahm und bot ausschießlich Textmodus. Imho lag die Leistung bei einem 0,5Mhz 8088. Spätere x86-Software-Emulatoren waren auf der gleichen Hardware locker drei bis viermal schneller. Beachtlich war aber daß relativ viel Speicher zur Verfügung stand. Imho belegte der Emulator nur 32 oder 64kByte so daß selbst ein 256kByte Amiga noch 192-224kByte nutzbaren DOS-Speicher anbot.


    Insgesamt war das aber eklatanter Quatsch. Der Transformer übernahm den Amiga komplett und ein Datenaustausch war praktisch nicht möglich. Was wirklich bescheuert war, der Transformer konnte Disketten voll MSDOS-kompatibel nutzen aber vom AmigaOS aus gab es noch mehrere Jahre keine Möglichkeit auf diese Inhalte zuzugreifen. Mit Speichererweiterungen und Harddisks oder anderen Upgrades konnte Transformer auch nicht umgehen. Updates gab es auch keine. Klassische Halbtot-Geburt. Hätte das Ding ein bischen Pflege erhalten (Multitasking, Datenaustausch) dann wäre das tatsächlich zu irgendetwas gut gewesen.

    MOD:
    xmp - module player supporting AWE32, GUS, and software-mixing
    timidity* - Software sound renderer (MIDI sequencer, MOD player)


    Leider kann ich nichts dazu sagen, wie performant oder resourcenschonend diese auf dem Pi laufen.

    Der Timidity-Hintergrunddienst läuft sogar auf Pi Zero aber dann bleibt für sonst nix Rechenleistung übrig. Man braucht das auch für viele Anwendungen/Spiele/etcpp die auf Midi angewiesen sind, z.B. Descent, OpenTTD. Auch viele DOS-Spiele im Emulator hören sich mit MIDI besser an als mit OPL. Als Soundbank ist freepats (imho vorinstalliert/abhängig) ein guter Anfang, grössere und bessere Soundbanks gibt es auf Fan-Sites, da bin ich allerdings out-of-date.


    Man kann die Config von Timidity per Hand editieren und ein paar Effekte ausschalten dann braucht es locker 90% weniger Rechenleistung, siehe Kommentare in /etc/timidity/timidity.cfg

    Ebenfalls hilft es das rtkit (Realtime Kit) per apt/dpkg zu deaktivieren/entfernen weil das zwar das Abspielen genauer macht aber auch die Rechenlast deutlich erhöht.

    Ohne rtkit und mit "slow CPU" rennt timidity sogar auf einem Amiga 1200 locker im Hintergrund.

    Im Paket alsa-utils findet man aplaymidi, einen sehr einfachen Midi-Player für die Kommandozeile. Schwierig ist es eigentlich nur das richtige Midi-Ausgabegerät auszuwählen, egal ob aplaymidi, VLC oder sonstwas...

    Soweit ich weiß, waren Intel und AMD bis einschließlich 486'er identisch. Erst ab Pentium hat AMD angefangen, wirklich eigene x86-kompatible Prozessoren zu entwickeln.

    Nope.


    Beim 386DX waren AMD und Intel technisch noch ident und arbeiteten mit den gleichen Masken auch wenn es den 40Mhz-Chip nur von AMD und in anderer Fertigungtechnik gab.


    Beim 486er war AMD dann selbständig. Zur Info, ein 486er ist kaum mehr als ein 386er mit Cache und FPU. Es ist wirklich so einfach, schalte bei frühen 486er (16-33Mhz) Cache und FPU aus und Du hast einen 386. Erst spätere 486er wichen von dieser Formel ab.


    Also war es für AMD ein einfaches den von Intel lizensierten 386 zu einem 486 aufzubohren. Wobei die AMD-486er sogar ein wenig mehr überarbeitet wurden und z.B. schrittweise bis zum 486dx4-133Mhz alias 5x86PR75 komplett umgekrempelt wurde, bei der vom Intel-Original kaum noch was übrig war. Mehr Cache, Writeback- statt Writethrough-Cache, überarbeitete Pipelines, überarbeitete ALUs/Multiplier/Burst-RAM-Zugriffe uswusf... nicht umsonst stellte der 486 bei 160Mhz oft sogar einen Pentium 100 in den Schatten...

    Die USB-Soundlösungen unterscheiden sich in der Klangqualität teils massiv.


    Für viel Geld gibt es natürlich tolle Lösungen aber wer nach günstig und gut sucht ist mit einem Speedlink Vigo gut beraten. Coronabedingt kostet das Gerät derzeit €10, vor Corona wars die Hälfte. Unter einem dutzend getesteter Low-End-Modelle war das nach Meinung mehrerer Bekannter der Testsieger auf einer LAN-Party.


    Einziger Nachteil, unter dem Namen gab es auch mal andere Lösungen. Also idealerweise mit Rücksenderecht testen.


    Das schafft es sogar mein Sennheiser Game One mit genügend Saft zu versorgen.


    https://geizhals.de/speedlink-…-8850-bk-01-a1599629.html

    mp3blaster ist ein sehr resourcenschonender Player der sogar auf 486ern im Hintergrund problemlos läuft. Selbst auf einem Pi3 liegt die Rechenlast unter 5% Prozent so daß mehr für andere Dinge übrig bleibt.


    Schön ist er zwar nicht, dafür einfach zu bedienen, unterstützt praktische Commandline-Parameter, ist Scriptfähig und läuft unauffällig im Hintergrund


    Und das Beste: SID-Files spielt er auch ab. Leider keine Amiga-Module.

    Mit 8GB lässt sich praktisch nichts machen mit einem Desktop Linux. Die ist ja sofort voll.

    Was nur wieder belegt, dass auch heute übliche „Desktop Linux“ Distributionen völlige Bloatware sind.

    Gibt es kein Puppy oder DSL für den Pi?

    Das Problem ist nicht "das OS". Ein Debian/Ubuntu-Minimal oder Debian/Ubuntu-LXDE-minimal saust selbst auf 2GByte Storage wie ein junger Dackel und da läßt sich auch mit Puppy&Co nicht unterbieten.


    Das Problem sind die Anwendungen. Ein Firefox und erst Recht ein Chromium sind eben fett und träge auf solcher Hardware.

    Aber was sind die Alternativen? Dillo? Kann der überhaupt noch Google darstellen? Lynx/W3M? Echt jetzt?


    Die sogenannten sparsamen Distributionen lehne ich inzwischen ab. Ja, sie verfolgen interessante Ideen die sich aber aus technischer Sicht nur auf eine passende Vorauswahl von Anwendungen mit geringem Verbrauch beschränken. Dafür sind sie notorisch veraltet und mit Updates unterversorgt. Immer. Besser man geht den Weg sich an einer sparsamen Distribution zu inspirieren welche Software wenig Resourcen verbraucht und dann installiert man genau das aus dem stinknormalem Packet-Manager auf der grossen Distribution.


    Exemplarischer Firefox-Exkurs: Beim Optimieren muß man vorsichtig sein. Schaltet man z.B. im Firefox die diversen Blacklists für Schadverhalten aus dann spart man sich zwar ein paar 100MByte Storage und RAM aber sitzt völlig nackt in einer bösen Welt. Schaltet man Caches im Arbeitsspeicher oder Massenspeicher ab kann das zwar kurzfristig was bringen aber nach dem nächsten Update braucht er vieleicht mehr aber darf nicht und läuft dann schlechter. Daher habe ich das Rumschrauben an Arbeitsspeicher-Cache-Einstellungen weitgehenst eingestellt - Massenspeichercache abschalten spart ein paar 100MByte und schon das Flash aber kostet deutlich Leistung wenn man Firefox öfters neu startet. Imho bringt es am meisten die Anzahl der Threads zu reduzieren - jeder braucht etwas mehr RAM - wenig Addons zu verwenden - und mittels ublock Origin oder noch besser No-Script alles zu blocken was man nicht braucht - es ist zum Staunen wie flott Firefox auf Ultra-Low-End-Hardware rennt wenn man mittels No-Script nur das allernotwendigste zuläßt. Und das allerbeste, selbst Puppy-Linux-Firefox ist langsamer als ein stinknormaler Windows/Debian/Ubuntu-Firefox den man manuel


    https://www.techosaurusrex.com…nd-laptops-and-computers/


    Nachtrag, das Entfernen der Locales bringt auch oft überraschend viel: https://wiki.debian.org/ReduceDebian

    Mir haben bisher immer englische und deutsche Locales gereicht.

    OK, das stimmt nicht so ganz

    Korrekte Einschätzung. ;) Es geht darum, herauszufinden, welchen Codec ein aktuell laufender (evtl. ruckelnder) Stream verwendet und nicht darum, herauszufinden, was es sonst noch so alles gibt. Und noch besser, als es nur herauszufinden, wäre es, auf YouTube einstellen zu können, welchen Codec man verwenden möchte. Andere Einstellungen, wie z.B. die Auflösung, kann man ja auch wählen.

    Das Firefox-Addon "Video Download Helper" kann zumindestens gezielt ein bestimmtes Format herunterladen.


    In gewissen Grenzen kann man das abzuspielende Format auch mit einem VLC-Plugin fest einstellen, dann schaut man das Video im VLC an der ohne viel weniger Leistung zum Abspielen als Firefox braucht. Theoretisch ist dieses Youtube-Plugin schon im VLC drin aber notorisch veraltet. Auf meinem uraltem EEE901 mit Ubuntu 18.04 kann man das wie folgt aktualisieren: wget "https://raw.githubusercontent.com/videolan/vlc/master/share/lua/playlist/youtube.lua" -O /usr/lib/i386-linux-gnu/vlc/lua/playlist/youtube.luac und in VLC kann man den Codec und die Auflösung einstellen (ich komm nur grade nicht drauf wo, ist verdammt gut versteckt).


    Natürlich kann man auch im Firefox was machen.. entweder schaltet man Codecs ganz ab oder man installiert ein Plugin, das folgende habe ich in einer Minute Google gefunden: https://en.blog.themarfa.name/…e-video-codec-on-youtube/ - diese Lösung gefällt mir zwar wenig aber Firefox und Chrome sind bei sowas hochflexibel und notfalls drückt man F12 und überschreibt im Debug-Monitor die Variable in der der Codec gespeichert wird.

    Problem daran ist, Pi ist arm. Die ganzen Games sind für x86/x64 programmiert. Dazu müsste man den ganzen Kram portieren. Wi

    Die meisten Mobil-Games erscheinen heute exklusiv für ARM. Man muß also entweder Android-Native oder einen Android-Wrapper nutzen. Bei der Rechenleistung kommt der Pi durchaus an ein zwei Jahre altes Mittelklasse-Gaming-Smartphone ran. Ob Fortnite darauf gut läuft kann man diskutieren aber z.B. GTA3 in der Android-Version läuft sehr gut: https://www.raspberrypi.org/forums/viewtopic.php?t=19949 - das lief sogar schon mit deutlich älteren Pis recht brauchbar.


    Der C64 wurde mit Sicherheit in mehr Büros verwendet als die CBM-Rechner, schonmal weil er billiger, kompakter war und mit mehr RAM kam - Visicalc, Vizawrite usw. machten doch erst mit 64kByte Sinn.


    An einem FBAS-Monitor war der C64 scharf genug, spätestens nach POKE53280,0:POKE53281,0:POKE646,5 kam echtes CBM-Feeling auf. 50hz-Flimmern gab es sowieso bei beiden.


    Ich merke gerade daß ich den CBM8296 mit dem MMF9000 verwechselt habe, das ist ein PET mit zusätzlicher 6809-CPU. Wozu das Ding gut war ist mir ein absolutes Rätsel...

    Die Nutzung als Spiele-Computer wurde nicht einfach freudig in Kauf genommen, sondern war (wenn man sich z.B. den VIC II und den SID anschaut) klar geplant. Für was außer Action Games benötigst du denn das schnelle Softscrolling und die vielen bunten Sprites und den 3-Kanal-Sound? Und für ernsthafte Anwendungen hatte Commodore (anders als Konkurrent Atari) ja auch noch die PET/CBM-Reihe. Beim VC20 hat Commodore schon die Erfahrung gemacht, dass Spiele sehr wichtig sind für eine Home-Plattform – und hat beim C64 dann in die Vollen gegriffen, was die Spieltauglichkeit anging. "Störte sie nicht" ist da krass untertrieben – es war das primäre Ziel.

    Der C64 war den meisten PET/CBM-Maschinen der ersten Generation (PET2001, CBM30xx) deutlich überlegen, schon wegen des grossen Speichers und des sehr günstigen Preises. Zusätzlich war der C64 zu diesen Rechnern sehr kompatibel was z.B. in meinem Bekanntenkreis ein Hauptargument für die Anschaffung des C64 war - man war ja mit CBM-Software perfekt versorgt, gerade in der Anfangszeit 1982/1983/1984 als des kaum native Software für den C64 gab.


    Daß der C64 keine 80 Zeichen darstellen konnte war je nach Anwendung ein Vorteil weil er so auch an billigen Monitoren und Fernsehern lief.


    Erst die zur CBM-Reihe völlig inkompatible 8296-Reihe übertraf den C64 in dieser Disziplin ohne aber darübehinaus irgend einen Sinn zu ergeben. Und da stimmt mir sicher jeder zu daß der C128 der 8296-Reihe deutlich überlegen war.

    Monitore/Glotzen sind hier eh genug vorhanden

    Wem es an Monitoren mangelt: Ein Gang auf den Wertstoffhof und man findet mehr brauchbare Monitore und Ferneher mit HDMI als man tragen kann. Selbst regulär gekauft kostet sowas auf Ebay oder Geizhals kaum mehr als ein Wurschtbrot.

    Hat die Series X so viel Power? Also meine GTX 1660 Super 6 GB Ram DUAL ADVANCED EVO kostet so um die 250 Euro, und ist richtig flott - siehe hier - für insgesamt 800 Euronen haste also nen flotten GamingPC.

    Nein. Nominell hat sie zwar die GPU-Eckdaten einer Radeon 5700 bezüclich Shader und CUs ist aber langsamer getaktet und muß sich den Bus mit der CPU teilen was gerade bei den grundsätzlich verschiedenen Zugriffprofilen verherrend ist - die GPU will grosse Datenblöcke im Stück transferieren und die CPU greift kreuz und quer auf kleine Einzelbröckerl zu, das GDDR6 ist aber für groses Blöcke optimiert wodurch die CPU und GPU sich gegenseitig oftmals bis zu 50 Taktzyklen ausbremsen. Es kann durchaus sein daß man synthetische Benchmarks basteln kann in denen XBX und RX5700 gleichschnell sind. Aber in der Praxis düfte sie rund 30% langsamer sein und damit zwischen RX5500/€200 und RX5600/€300 liegen.

    Dazu solltest du dir 'Log2RAM' anschauen. Schreibt die Logs in eine RAM-Disk und diese einmal pro Stunde oder beim Shutdown auf die SD-Karte.


    https://mcuoneclipse.com/2019/…berry-pi-lorawan-gateway/

    Das ist etwas redundant da man Logfiles auch gepuffert schreiben kann was die Last auf den Flash-Chips locker um 99% reduziert - war irgend eine versteckte rsyslog-Funktion oder alternativ das FS gepuffert ohne updated starten.


    Oder alternativ legt man /var/log ins RAM und weist das sowieso laufende logrotate an die Dateien einmal pro Stunde mit gzip/bzip2/xz zu komprimieren und nach /var/backup/log zu schieben.


    Angeber schreiben die Logdateien einfach auf einen anderen Server per Netz - das "R" in rsyslog steht nämlich für "remote", mit einer Konfigänderung schreibt dann der Pi-rsyslog die Dateien auf einen rsyslog eines anderen Systems ;-) Das war in der Uni immer lustig wenn auf hp00 die /var/log/messages ungelogen 2MByte/s wuchs weil rund 500 Rechner dort ihre Logs ablegten... wohlgemerkt, 1990 :-) Einmal pro Stunde Logrotate sonst wäre selbst das damals größte RAID nach einem Tag geplatzt...


    Faule Säcke wie ich lassen das Zeug einfach in der tmpfs/RAM-Disk verschimmeln, der Shutdown entsorgt sie dann normgerecht. Zumindestens auf reinen Arbeitsplätzen steht da nie was wichtiges drin. Auf meinem EEE901 LUbuntu18.04 32Bit oder dem Pi0 fallen da pro Tag keine 500kByte an Daten an. Server sind natürlich ne andere Geschichte.

    Fest verbauten Speicher finde ich hingegen keine gute Idee. Mit der SD-Lösung kann man schnell zwischen verschiedenen OS wechseln, je nachdem was gewünscht wird.

    Das eine schlließt das andere nicht aus. Einen Pi kannst Du wie einen Amiga oder einen PC sowohl vom internen als auch externen Speicher booten. eMMC wäre halt praktisch weils klein, preiswert und relativ performant ist.


    Es kommt aber natürlich immer auch drauf an was man so mit der Karte treibt. Im "normalen" Desktopbetrieb mache ich mir da nicht soviele Sorgen. Ich habe aber auch Raspis im Serverbetrieb laufen, bei denen sekündliche Logeinträge anfallen. Nachdem ich die erste SD Karte innerhalb eines Monats geschrottet hatte, habe ich die Logs ganz schnell in eine RAMdisk verlagert. Damit halten die Karten nun schon ein paar Jahre.

    Ja, das kenne ich auch. Gerade billige SD-Chips oder USB-Sticks halten nur ein paar hundert Schreibvorgänge pro Zelle aus. Mit ungepufferten Log-Dateien habe ich billige USB-Sticks an einem Tag geschrottet...


    Tipp, das Tool dumpe2fs gibt für Ext2-Ext4 Filesysteme die Menge der geschriebenen Daten seit Erzeugung des Filesystems an.

    Das Gaming Thema kann man gar nicht groß genug einschätzen, wenn man einen Computer erfolgreich machen will. Daaamals™ wie heute.

    Ja und eigentlich ist der Pi400 dafür garnicht schlecht.


    Die Leistung des Pi400 liegt um Faktor Zehn über Nintendo Gamecube, Xbox1, PS2, Wii und Faktor Zwei wenig über der Switch, XBox360, PS3 - selbst mit €500-Gaming-Smartphones kann es der Pi400 aufnehmen!!!


    Nur so als Beispiele, Fortnite, World of Tanks Blitz, Doom3, Halflife 2 gibt es native für ARM und laufen mit mehr oder weniger Tricks auf dem Pi400 und das macht grafisch schon etwas her. Java-Spiele laufen gut (Minecraft, Wurm Online), FDA/XDA/Mono-Spiele sind teilweise auch gut. Ich wette E-Sports-Titel wie Dota, CSGO, Fortnite kämen auch gut rüber. Portieren müßte man sie eben. Das ist weniger ein technisches als ein "lets do it" Problem.


    Das Problem: Die Nutzung vieler Spiele auf dem Pi400 ist schwierig. Man kann das Ding nicht einfach dem Sohnematz (oder in unseren Fällen eher den Enkeln) hinstellen und sagen "lad Dir mal Dota2 bei Steam runter". Da steckt sehr, sehr, sehr viel Arbeit dahinter und man muß regelmässig das OS wechseln. Z.B. läuft Fortnite "im Prinzip gut" aber eben nur unter Android. Also bootet man Android. Doom3 wieder läuft gut als 32Bit-Binary unter RaspberryOS und Minecraft wiederum läuft besser als 64Bit-Binary unter Ubuntu 20.10. Man wechselt dauernd...


    "Im Prinzip" wäre es sogar möglich alle genannten Spiele unter einem OS zu verwenden. Stichwort "Android unter Linux". Aber da ist das aktuelle RaspberryOS/Debian-32Bit nicht der richtige Ansatz, da muß man eher in Richtung eines angepaßten Debian64/Ubuntu64 sehen bei dem die Virtualisierungsfunktionen und Kompatiblitäts-APIs für Android+Google-Services, 32Bit und 64Bit ARM und eventuell XEN-86 integriert sind.


    Gäbe es ein besseres Basis-OS und darin eine Art Steam für den Pi bei dem man mit einem Klick das Spiel laden kann dann wäre das ein Killerfeature weil der Pi als Spielkonsole eigentlich ziemlich gut ist. Bis auf aktuelle Spielkonsolen kommt da derzeit nichts ran und die kosten "etwas mehr" als €70...


    Die echte Kröhnung wären natürlich Bare-Metal-Banging-Games. Aber naja, ich denke sowas werden wir in diesem Jahrtausend nicht mehr sehen...

    Was wir schon gleich zu Beginn des Threads alle vermutet hatten: Raspberry Pi 400: The ULTIMATE Amiga Emulation Machine :thumbsup::ChPeace

    Ich hab auch nie verstanden wieso man den Pi400 mit dem C64 verglichen hat. Der C64 war ein sehr eingeschränkter 8Bit-Rechner der praktisch kein professionelles Betriebssystem mitbrachte und einfach kein erweiterbares Gesamtkonzept mitbrachte - oder kann man mit einem C64 im Internet surfen (textonly) und gleichzeitig einen Text verfassen (textonly) während man SID-Musik hört? Eben, mangels Betriebssystem und APIs geht da garnix.


    Der Amiga hingegen kann heute noch alles was ein PC auch kann. Office, Web, Voice-over-IP, egal was, der Amiga kann es weil sein Betriebssystem alles kann was heutige Rechner auch können.


    Und da paßt der Pi400 einfach perfekt rein. Er kann wirklich alles was man heute braucht ohne sich krumm zu machen. Und noch ein paar Sachen mehr.

    Contra:

    • lommeliges MicroHDMI
    • kein schneller, interner Flashspeicher
    • SD Karte hinten schlecht zugänglich

    Mir ist klar, dass man nicht alles haben kann und sich einige Wünsche/Kritikpunkte widersprechen. Ja, SD Karten erlauben es schnell das ganze System zu tauschen, aber doch hätte ich sie gerne leichter zugänglich an der Seite und für das Hauptsystem (Linux mit allem Pipapo) gerne eine interne SSD, eMMC oder was auch immer.


    Günstiger Preis ist gut und offene (reverse engineerte) Spec auch, aber eigentlich gäbe des deutlich bessere SoCs zu minimal höheren Preisen ( siehe diverse Odroids oder NV Jetson Nano).

    Naja. Ich warte mal ab. Vielleicht wird der RasPi 500 ja was für mich.

    Viel Kritik am Pi 400 kann ich nicht nachvollziehen aber bei den gequoteten Contras bin ich absolut bei Dir. Ein eMMC-Chip mit 64GByte 250MByte/s read kostet einzeln in der Apotheke Conrad gerademal €4 und der JEDEC-Anschluß dafür ist eine reduzierte USB3-Variante.


    Wenn die MicroHDMI-Buchse wirklich mal rausbricht lötet man halt ne Fullsize-Buchse rein.


    Die hinten schlecht zugängliche SD-Lösung halte ich zwar für unpraktisch aber imho ist es auch nicht kostendeckend machbar die woanders zu positionieren weil die Platine nunmal die Grösse hat die sie hat und sich ein SD-Slot nunmal nur auf der Platine befestigen läßt. Einzige Alternative wäre eine zweite Platine die seitlich am Gehäuse nur den SD-Anschluß bereitstellt. Das treibt den Preis aber mit Sicherheit nochmal €10 nach oben ohne daß es praktisch was bringt.


    Abhilfe: SD-Card-Reader per USB. Davon kann der Pi auch booten und man kommt leichter an die Karte ran. Ein flotter UHS-Reader ist auch deutlich schneller als der integrierte Reader vom Pi. Geizhals USB-UHS-Cardreader-Hubs

    Keine Ahnung, wann du das letzte Mal eine Notizen-App verwendet hast – aber die wurden in den letzten Jahren massiv aufgerüstet. Du kannst neben Rich-Text und Handschrift auch Fotos, Videos, Webseiten, Tabellen, Slides, Link-Sammlungen und ähnliches verwalten. Je nachdem, was du also in die "Notizen" einfügst (und wieviele tausend du verwaltest), können die schon etwas an Power gebrauchen. Ich würde mich aber trotzdem wundern, wenn ein aktueller Raspi damit nicht klarkäme (außer wenn man das richtig heavy nutzt).

    Nur so nebenbei : auf der Schule meiner Nichte hat die Klasse/Schüler beschloz,das IPads anzuschaffen sind..

    Da ist nichts gegen einzuwenden, wenn das Finanzierungsproblem gelöst ist – immerhin rund 300 € je iPad und nochmal 50 € für einen 3rd-Party-Pencil (wenn man sowas haben will). Und man kann natürlich Klassenraum-Ladestationen auf Rädern, Keyboards usw. anschaffen, wenn man es besonders komfortabel haben will.


    Die Frage ist halt, was man mit den "Rechnern" machen will. iPads würde ich nicht unbedingt für den Informatik-Unterricht anschaffen – da wäre so ein Pi 400 genau das richtige. Wenn man aber die IT benutzen will, um beim normalen Lernen (egal welches Fach) unterstützt zu werden, dann ist so ein Tablet nicht die schlechteste Wahl – unabhängig von der Steckdose, Bildschirm integriert (dadurch räumlich unabhängig und sogar draußen oder stehend einsetzbar), Video-Kameras eingebaut (Fotografie, Videokonferenz), extrem einfach zu bedienen und nicht kaputt-konfigurierbar, Massen-Administrierbar durch MDM, spezielle multimediale Lernsoftware, Handschrift-Erkennung etc. Das ist halt ein ganz anderer Anwendungs-Schwerpunkt als ein Computer-Lernsystem, wie der Raspi. Bei einem iPad will man sich gerade NICHT mit IT beschäftigen, während man beim Raspi meistens genau DAS will.

    Meine Notizzettel erstelle ich mit "vi info.txt". Ich bin halt ein alter Sack.


    Tablets für die Schule? WTF? Ja, zum Konsumieren ist sowas in Ordnung aber zu Arbeiten? Tippen die Kids dann ernsthaft auf einem 10 Zoll Bildschirm der zur Hälfte vom Onscreen-Keyboard belegt wird?


    Soweit mir bekannt ist gibt es für die Dinger nichtmal brauchbare Schulsoftware auf Deutsch. Für englische Lehrpläne aus der USA gibt es ein grosses Angebot aber sonst nix.


    In Deutschland läuft der ditigale Unterricht seit 15 Jahrn normiert über Web und Windows. Es gibt zumindestens in Bayern eine normierte Plattform bei der eine Black-Box in ie Schule gestellt wird auf der sämtliche von Schulbuch-Anbietern lizensierten Lehrinhalte gespeichert werden und die läuft 50/50 im Browser oder auf Windows. Die wird gerne verwendet weil sich da die Nutzung sehr effizient abrechnen läßt und man da tatsächlich etwas günstiger als bei gedruckten Holz wegkommt. Netter Bonus, es gibt auch eine Videothek mit für den Schulgebrauch geeigneten Unterhaltungsvideos wenn mal wieder eine Stunde ausgefüllt werden muß. "Ben Hur" z.B. kostete da pro Zuschauer 18 Cent (!).


    Die sollen den Kindern einfach ein paar Aldi-Notebooks hinstellen. Für €250 gibt es einen Zweikern-Ryzen mit 4GByte RAM und 64GByte Flash, das Gehäuse ist aus ziemlich dicken und robusten Kunststoff.


    Ich wette der Vorschlag mit Tablets kam von Hipster-Eltern denen es wichtiger ist daß die Kids mit Statussymbolen rumrennen als daß sie was lernen.

    Allerdings hat der Raspberry mindestens ein (quasi) Alleinstellungsmerkmal, das einzelnen Leute wichtig ist: Er ist die mit Abstand günstigste Möglichkeit nativ(!) RISC OS laufen zu lassen. Das geht selbst auf einem "allerneusten" 3.000 EUR-Intel-Laptop nicht. ;)

    Doch, mit qemu und xen kann man RISC-OS auf x86 verwenden. qemu ist eine generische CPU-Emulation die auch ARM unterstützt und rennt sogar flockig flott. Ist nicht ultra-trivial aber hochinteressant.


    qemu ist eher eine allgemeine CPU-Emulation, damit kann man in der Linux-Shell auf einem x86-Rechner auch Linux-arm- oder Linux-m68-Binaries starten. Mit etwas Basteln kann man so auch PPC-BSD- oder x86-Mac-Binaries laufen lassen. RISC-OS unter qemu ohne VM habe ich mal auf Youtube gesehen war aber eher Proof-of-Concept bis nutzlos und eine irre Fiesselei qemu ist soweit es eine Anwendung gebacken bekommt ziemlich effizient und schlägt gegenüber native-Hardware nur ein paar Kilobyte oben drauf.


    xen ist gleichzeitig ein Typ1-Virtualisierer, d.h. Du bekommst einen streng getrennten virtuellen Rechner. Das ist minimal weniger effizient wie ein Typ2-Virtualisierre (HyperV, KVM) aber da ohnehin ne Emulatin drauf läuift ist das die kleinste Problematik. Dafür braucht ne VM halt schnell mal viele GByte Arbeits- und Massenspeicher. RISC-OS läuft damit perfekt. Xen hat eine Emulationsschicht für ARM, x86-64 und noch ein paar, alles andere muß man mit qemu reinbasteln und da wird es wild. Was ich so im qemu-Wiki und bei Google gesehen habe ist das ne witzige kleine Fleißaufgabe die ein ambitionierter Linux-Amateuer schon an einem Abend schaffen kann.


    Theoretisch wäre es auch möglich auf einem echten ARM-Rechner RISC-OS über XEN oder KVM parallel zu Linux laufen zu lassen bei sehr hoher Arbeitsgeschwindigkeit ohne Emulationsverluste. XEN läuft auf ARM gut, KVM kann ich nicht sagen, das hat auch auf x86 etwas höhere Anforderungen an die Umgebung wie VT/VTd/VTvIO-Support in Hardware...


    Ich habe mal testhalber den Libreoffice Writer auf dem Pi400 gestartet. Der Writer war schneller einsatzbreit als auf meinem iMac. So langsam kann der Pi nicht sein.

    Das hat einen anderen Grund.


    Obwohl der Mac formal ein BSD-Unix ist ist vieles jehnseits von Kernen+libc ein propietäres Kuddelmuddel. Für direkte Portierungen aus der echten Unix/Linux-Welt braucht man viele Support-Bibliotheken und Emulationen. X11, Pulseaudio, SDL und sogar OpenGL sind z.B. nicht in MacOS enthalten und müssen nachinstalliert werden.


    Alternativ könnte man natürlich die Programme auf die Mac-API umstellen aber da haben wir das nächste Problem: Mac-User tragen zu solchen Projekten so gut wie nichts bei. Kein Scherz, bei Firefox, Libreoffice und OpenTTD tragen Linux- und Windows-Anwender bis zu Faktor 100 mehr bei als Mac-Anwender. Also gibt es für die Mac-Anwender nur Varianten die nicht optimiert sind. Ende aus Basta.


    Das ist die Frage ob die hardwarebeschleunigten Treiber verwendet werden. VLC unter Windows/Skylake/Geforce mit H.264 nutzt natürlich Hardware-Decoding, da braucht ein Film mit 4k etwa 3-8% Rechenleistung eines einzelnen Skylake-Kerns. Für den Raspi kann ich leider mit keinen aktuellen Daten dienen, hier läuft als Mini-Rechner ein Atom-N270-System und der hat KEIN Hardware-Decoding so daß bei 720p bede SMT-Kerne so 70% ausgelastet sind. Der Pi400 ist allerdings mehrfach flotter also geht da in Software wohl deutlich mehr. Mit anderen Treibern oder Codecs siehts natürlich anders aus.


    Soweit es mir bekannt ist besitzt der Raspi zumindestens in den neuesten Versionen einen Hardware-Decoder der allerdings explizit freigeschaltet werden muß indem man eine Lizenz für ein paar Cent erwirbt. Für MP2 und MP4 bis 1080p ist das imho nicht notwendig, das schafft imho schon ein Pi2 locker. Der Pi400 sollte theoretisch 4k rein in Software darstellen können solange es "nur" MP4 mit maximal 20MBit/s ist.


    Was beim VLC noch zu beachten ist: Nicht zu viel Klim-Bim aktivieren. Ich verwende z.B. gelegentilch einen De-Noiser oder andere Filter und damit steigt die Rechenlast um ein Vielfaches, die Bildqualität allerdings auch - wer mal VLC in der Standard-Einstellung z.B. mit dem Windows-Mediaplayer vergleich der bekommt ne Gänsehaut, mit guten Filtern hingegen dreht sich das um.