> The other problem we need to solve is swap. Linux, or at least not this Linux, won't let you use a swapfile hosted over NFS; swapon will give you an illegal argument error and refuse to enable it.
No swap on nfs is strange. Mainly because as far as I can tell swap over nfs has always been a thing on bsd.
here is the openbsd manual on setting up a diskless system(note the bootparams swap line), however it picked up it's netbooting sequence from bsd which if I had to guess picked it up from sun who invented nfs. I was curious if sunos also has it and it does. I choose sunos as a sort of early snapshot of a commercial bsd system. As netbooting was an important thing to Sun I would guess swap over nfs was a day one thing. Anyone know where to go for very early manuals to confirm this?
Oh, I know it works today; I was just surprised that it might possibly be an option on a 2.4-6 kernel, as I had assumed that Linux didn't get NBD until... I dunno, I would have guessed late aughts?
Yes, or via the (very slow) built-in serial port. The broadband adapters are quite rare.
Interestingly, for a long time there were no publicly available tools for or docs on dumping GD-ROMs. New releases from Echelon and Kalisto would appear promptly, so there was obviously a way, but you could only partake in the rampant piracy by downloading the (occasionally-massaged to fit on a CD) disc images online.
A lot of discussion in the (tbf probably quite young and inexperienced) community was around how this was possible. A popular theory/rumor at the time was that they were using CD drives with modified firmware, for example.
This probably also helped keep the piracy amd homebrew scenes fairly well separated on the Dreamcast, as there was a lot of info and examples around running your own code. This is in contrast to eg. the Xbox scene, which was in many ways the equally vibrant successor to the DC scene, but where piracy and homebrew seemed much more intertwined. Not least because all the homebrew binaries were built using the off-limits Microsoft SDK, so you had to go to some shady FTP site via links found on IRC to download them.
Iirc the Katana devkit could be used to play commercial games so I wouldn't be surprised if some developers were part of the groups and if so writing a dumper was probably not hard.
There was even a preview version of the game I worked on that got leaked so either someone in our office was part of the cracking scene or someone at Sega/QA (they were our publisher) since AFAIK no-one else had any copies.
If memory serves, the first (at least publicly disclosed) interface was the "Dreamcast Debug Handler", created by a member of Hitmen. This worked by adding a breakout connector to the expansion port terminator (which came with some Asian Dreamcast systems instead of a modem), then connecting that to some homebrew hardware to adapt the bus to a parallel port.
Another alternative that was reasonably-priced for a short while was the Japan-exclusive "LAN Adapter", which was in lower demand because it was only officially supported by the Dreamcast web browser app and was only 10Mbps instead of 10/100.
From all the variants mentioned across the comments, the PS2Linux was the best one, being officially supported by Sony.
Originally they had though as a means to foster indie development, instead people got to use it for emulation, thus PS3 Linux Other OS no longer supported graphics acceleration, and then was completly dropped in a firmware upgrade.
On the PS2, we had official Linux CDs from Sony, a hard drive, connection cables, and a whole development environment, a GL like API, another more low level console like, both with hardware acceleration (although the actual one used on the devkit wasn't exposed).
The XBOX would do it better; but sadly current ports are abandoned.
An XBOX with 128MB of RAM would run Fluxbox or whatever light env with ease, and with Dillo
and a PSP user agent you could even post into HN. Gemini and Gopher would do it fine,
even with clients written in TCL/Tk. It would be a fine backup PC for either thinkering
or rescueing.
With ZRAM you could almost mimic a 192MB of RAM based device, good for maybe a browser like Seamonkey/IceApe if it could be built without SSE2.
It lives on today as Kodi, including the GUI hacks, the weird flaky add-ons, browsing file shares on the LAN, and the strange piracy-adjacent community.
It's all there, and on all kinds of devices -- just not on OG Xbox hardware.
> Never put a console running DC Linux outside of a firewall: it is an intentionally insecure system. Any bot scanning your network will get root immediately.
Yeah, that's really important advice. They'll get root, and then they'll... ummm... they'll... hmmmmm.... ahhh.... Be really confused? Start mining monero? Sideload Crazy Taxi and start playing it on your Dreamcast?
Well, a known problem with pre v4 NFS is that it uses and trusts client side UIDs I believe, In fact I believe even v4 does this by default. So if I understand correctly, it treats root on the client like root on the server, and since NFS gives direct access to the block device this is even worse than it initially sounds.
Yeah, with all those Hitachi SH-4 32-bit RISC payloads running around in malware you can't be too protective. With the mighty power of 200MHz just imagine all the RISC malware it could run.
Crazy to think that we've go the Steam Deck now, as our front-line Linux-based gaming console .. I guess I shouldn't be surprised to find out that the Dreamcast emulator is probably available for SteamOS ...
To my shock, https://en.wikipedia.org/wiki/Network_block_device says
> The protocol was originally developed for Linux 2.1.55 and released in 1997.
so I wonder if you could use that? It's better suited to swap anyways.