[HN Gopher] ELKS: Linux for 16-bit Intel Processors
___________________________________________________________________
ELKS: Linux for 16-bit Intel Processors
Author : emersonrsantos
Score : 202 points
Date : 2025-01-04 19:23 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| marcodiego wrote:
| What would be really interesting: porting DOSEMU 1.4.0 to it.
| This would give us a maintained unix-like OS combined with a huge
| abandonware dos library turning those old machines into something
| fun and maybe useful.
| devit wrote:
| That makes no sense, since DOSEMU is based on virtual 8086
| mode, which requires a 80386, while ELKS is for 8086-286 CPUs.
|
| You can just run MS-DOS or FreeDOS directly on those machines,
| that's what the machines were made for.
| anthk wrote:
| This. I literally rebuild DOSEMU yesterday after years of not
| using it. It used that mode extensively.
|
| A good thing about DOSEMU against DOSBOX is that the first
| could run high end DOS game at amazing speeds as the
| environment was more like Wine than emulating the whole
| machine, so you could run Tomb Raider, Need For Speed, Duke
| Nukem 3D... on a Pentium II while 'simulating' a Pentium MMX
| or a Pentium 90-like speeds, if not more, being far closer to
| the performance you got under W95/W98.
|
| And, as you said, booting SvarDOS either from a floppy or
| from an IDE->CF card it's straightforward.
| duskwuff wrote:
| Computers which use 16-bit Intel processors (80286 or earlier)
| are quite rare nowadays - most of them are 30-40 years old, and
| are more valuable to collectors than newer and more capable
| hardware would be. If you want something "useful", this isn't
| where you'd find it.
| yjftsjthsd-h wrote:
| I don't know that it's really Unix like, but I feel like
| freedos covers that use?
| forinti wrote:
| Wait, "ROM-based systems"? Were there such x86 micros and is this
| saying you could run Linux from ROM?
|
| That's super interesting.
| retrac wrote:
| The 8086 and 8088 etc. were relatively popular for embedded
| devices. For example some early 90s Apple printers used an
| 80186 as the controller. Such designs were often incompatible
| with the IBM PC; 8086 doesn't necessarily mean PC compatible.
| snerbles wrote:
| The Tandy 1000 SL/2 I grew up with had DOS 3.3 in ROM, mounted
| on D:\
| EvanAnderson wrote:
| I've never seen a fully ROM-based PC, but I have worked with
| ISA NE2000 NICs with boot ROMs that allowed them to diskless
| boot into a DOS-based Novell NetWare client. It wouldn't
| surprise me if there were ROM-based local boot environments on
| ISA cards.
|
| The Cisco PIX firewall, in it's original incarnation, booted
| from non-volatile memory (I don't know if it was EEPROM or
| flash) an ISA card.
| kjs3 wrote:
| Fully ROM/Flash PC-ish systems are/were pretty common in the
| embedded and industrial control space. Usually the boards
| emulate one or more floppy drives. I've got a half dozen
| variations, including PROM, Flash and battery backed SRAM.
| Even one with bubble memory, which is pretty nifty.
|
| The first-gen PIX you mention had an 8M or 16M ISA flash card
| it booted from, containing the whole OS.
|
| The Novell netboot is called "RPL".
| gattilorenz wrote:
| The DiskOnChip was a somewhat popular solution (think of
| thinclients), often running stripped down versions of Linux in
| the early 00s.
|
| Here you can see it on an external board:
| https://www.os2museum.com/wp/diskonchip/
|
| I have a few thinclients with a socket directly on the
| mainboard for a DOC
| Dwedit wrote:
| Some of the Tandy 1000 computers (such as the HX) had MS-DOS
| 2.11 in ROM. So it's not unheard of for an IBM-Compatible PC to
| have an operating system in ROM.
|
| Also the "Macintosh Classic" had System 6.0.3 in ROM as well,
| but you had to use a keyboard shortcut to boot from there. It
| did not run normally.
| andix wrote:
| Are those real ROM-based-systems, that could execute code
| directly from ROM, without loading it to RAM first?
|
| The only ROM-based-systems I worked with are the Atmel AVR
| microcontrollers. They don't need to load code into RAM for
| execution, they have the ROM memory mapped into the address
| space. I think they can't even run instructions from RAM,
| which makes remote code execution physically impossible.
| Dwedit wrote:
| Even if you can't execute code from RAM, stack corruption
| and Return-Oriented-Programming (ROP) can still be a thing.
| It's just far more limited if you can't use ROP to set up
| regular code.
| kevin_thibedeau wrote:
| Memory devices were not accessed via exotic interfaces at
| the time. ROM was directly addressable on the bus in early
| PCs. They executed their ROM code directly as the access
| time was sufficient for low speed clocks. That is what the
| BIOS is. Any additional OS/BASIC environment worked the
| same. Later BIOS implementations had shadow RAM options to
| allow execution without wait states as bus speeds eclipsed
| ROM access times.
| nxobject wrote:
| For what it's worth, a significant proportion of the classic
| Mac OS's implementation was in rom anyway - you "upgraded"
| the OS by patching in-memory jump tables to ROM functions.
| kevin_thibedeau wrote:
| IBM itself made PS/2s with PC-DOS in ROM. The 5150 had ROM
| BASIC and that also continued through to the early PS/2s.
| nijave wrote:
| Lots of embedded systems like routers run read only although
| maybe they're not technically ROM. Usually they mount the root
| filesystems read only and create some small ram disk/tempfs for
| logs. Persistent settings go to a small NVRAM area
|
| The root filesystem is only written to when you flash a new OS
| image
| seba_dos1 wrote:
| The context of ROM here is "can execute code without putting
| it in RAM" rather than "code is stored in a read-only
| memory".
| sillywalk wrote:
| My first computer was a 286 PS/1 model 2011, with PC-DOS and a
| graphical shell in ROM.
|
| Interestingly, somebody has made an emulator for it.
|
| https://barotto.github.io/IBMulator/
| fidotron wrote:
| Less obvious than some of the embedded things:
| https://en.m.wikipedia.org/wiki/Atari_Portfolio
|
| x86 (and licensed derivatives) were a thing in more custom
| handhelds like the Psion Series 3, and games systems like the
| Wonderswan. The variants made by NEC alone were:
| https://en.m.wikipedia.org/wiki/NEC_V20#Variants_and_success...
| tengwar2 wrote:
| The Psions could do execute-in-place, including for third
| party software on ROM SSD - i.e. they did not have any
| fundamental distinction between working memory and disk
| storage.
| usr1106 wrote:
| Yes, NOR flash was common in these kind of devices and
| phones until maybe 2005 or so. So you could run code
| without loading it to RAM first. However, I believe RAM was
| still needed for stacks and heaps. Writing them to NOR
| flash sounds too slow.
| tengwar2 wrote:
| No, I really do mean that they used the disks as ROM. No
| writing to it. This worked because you can just put the
| stack and heap at a difference position in the memory map
| from the executable code.
| indymike wrote:
| Yes, there were many - including the original IBM PC which
| would could boot to BASIC loaded from ROM. Some more
| sophisticated machines included:
|
| - Many Tandy PC compatibles could boot from ROM to their
| DeskMate GUI - HP, GRiD, Zenith and others had laptops that had
| DOS and in some cases Windows in ROM.
|
| - IBM's PS/1 line could boot from ROM - Many GEOS devices
| booted from ROM into a GUI, and often could boot to DOS from
| ROM too.
| EvanAnderson wrote:
| I said in my earlier post that I hadn't seen a fully ROM-based
| PC but I completely forgot about stuff like the HP and Psion
| and Atari PC handhelds!
|
| In that vein, I've got an old V20-based NEC laptop (the
| PC-17-02[0], arguably an Ultrabook in its day) that booted MS-
| DOS 3.3 from ROM. It had a 2MB battery-backed RAM disk that the
| ROM got copied into. It showed up as a hard disk drive with an
| INT 13H-style interface.
|
| [0] http://old.chuma.org/ultralite/index.shtml
| accrual wrote:
| Another example was the Headstart Explorer from 1989. My
| parents had such a computer.
|
| > But the most characteristic part was the operating
| environment - 384kB of ROM contained MS-DOS version 3.31 and
| Explorer GUI which allows to work in PIM programs, database and
| text editor using mouse. The GUI is shown using CGA mode and
| allows to launch DOS programs too.
|
| https://oldcomputer.info/pc/hs_explorer/index.htm
|
| CathodeRayDude (CRT) has an entertaining video on the subject:
|
| https://www.youtube.com/watch?v=d1jpIiST6ec
| Narishma wrote:
| The original IBM PC was ROM-based. It worked fine without a
| disk drive, it just booted into ROM BASIC instead.
| lproven wrote:
| I wouldn't be at all surprised.
|
| There is an MS-DOS compatible ROM OS still sold today:
|
| https://www.tuxera.com/products/rom-dos/
| jvanderbot wrote:
| They mention "SBC"s. Is this something that is intended also for
| modern 16bit SBCs?
| snvzz wrote:
| Yes absolutely.
|
| There are success stories with it on 8088 book, pocket 8086 and
| similar such hardware.
| IgorPartola wrote:
| I do wonder in today's landscape of single board computers what
| the right bit width is. A 64-bit system with like 1-2GB or RAM
| doesn't make a ton of sense since your program size and data
| structure size grows by quite a bit but you don't need it to
| since you don't get to have more than 4GB of RAM. On the other
| hand there you do have SBCs with 8-16GBs of RAM but that's a far
| cry from needing full 64 bits. Would an optimal bit width be 48
| bits? 40?
| mixmastamyk wrote:
| Yes, this already happens. Address bus width is usually
| different from register width due to cost. I found this, old
| CPU's address bus only getting to 44 bits wide on Itanium.
|
| https://www.tech-faq.com/address-bus.html
|
| My newish AMD laptop: `grep 'address sizes' /proc/cpuinfo`
| address sizes : 48 bits physical, 48 bits virtual
|
| Looks like 36 bits wide is already plenty for anything typical,
| up to 68 GB: >>> f'{2**32:>30_}' '
| 4_294_967_296' >>> f'{2**36:>30_}' '
| 68_719_476_736' >>> f'{2**40:>30_}' '
| 1_099_511_627_776' >>> f'{2**48:>30_}' '
| 281_474_976_710_656' >>> f'{2**64:>30_}' '
| 18_446_744_073_709_551_616'
| ChocolateGod wrote:
| I guess no point wasting hardware supporting things that will
| never be possible for the lifetime of the processor.
| p_l wrote:
| AMD64 mandates 48bit virtual addressing minimum, with the
| rest sign-extended unless certain optional features are
| enabled.
| Retr0id wrote:
| Many "64-bit" systems only have ~48 bits of virtual address
| space, and while canonical pointers have all the high bits
| equal, you can put the otherwise-wasted bits to work by storing
| metadata.
|
| If you're writing really space-optimised code, you can pack
| pointers closer together.
| vardump wrote:
| 32-bit ARM-based systems supported up to 1 TB of RAM. 32-bit
| x86 only up to 64 GB. Unless you want to map more than 4 GB in
| a single process, you could very well stay 32-bit.
|
| But AArch64 (or ARM64) and AMD64 did bring a lot more on the
| table than just larger address space. More registers, and a
| performance boost by just being better suited for the modern
| CPU core design.
| ploxiln wrote:
| 32-bit x86 linux will typically support 3GB per process, with
| 1GB kernel address area, I think? (Windows did 2GB / 2GB
| split by default, custom boot options can change it to 3GB /
| 1GB, but only some 32-bit apps fully supported it, like
| photoshop).
|
| Also, FWIW, security people can get real bothered that ASLR
| doesn't do much in 32-bit systems.
|
| So, I think starting around 2GB DRAM, it's probably a "big
| enough" system to justify a 64-bit OS.
| junon wrote:
| On 32 bit you can of course make the kernel higher half,
| but yes AFAIK most mainstream kernels chose higher quarter
| to grant more vaddr space to processes.
| garaetjjte wrote:
| >Unless you want to map more than 4 GB in a single process,
| you could very well stay 32-bit.
|
| Provided you are not bothered by highmem. https://www.realwor
| ldtech.com/forum/?threadid=76912&curposti...
| lproven wrote:
| I didn't notice who wrote that initially, and was getting
| annoyed with his failure to notice that it's not
| _HIGHMEM.SYS_ , it's _HIMEM.SYS_.
|
| But why should Linus, even in 2007, use Win9x in the 21st
| century?
| bpye wrote:
| > But AArch64 (or ARM64) and AMD64 did bring a lot more on
| the table than just larger address space. More registers, and
| a performance boost by just being better suited for the
| modern CPU core design.
|
| There is the x32 ABI - 32-bit pointer length, but the AMD64
| ISA. I don't think it ever saw significant adoption though.
| junon wrote:
| 32 bit gave you that much with PAE, which has its own set of
| unfortunate problems.
|
| I still think it's pretty safe to say 64 bit is the future,
| and will be for a long time (if I live long enough for 128
| bit processors to become defacto or even widely _necessary_ I
| 'll be truly shocked).
| andix wrote:
| I think it's either 8, 32 or 64 bit. Maybe 16 bit.
|
| The size of memory space is not necessarily aligned with the
| bit width of the CPU. There are a lot of 32 bit systems that
| can use much more than 4 GB of RAM. And there are no 64 bit
| systems I know of, that are even theoretically able to use 16
| exabytes (16 million TB) of RAM.
|
| AFAIK ARM32 is still the norm for embedded systems. And there
| is still a place for 8-bit microcontrollers.
| happycube wrote:
| For embedded uses, 1GB is certainly big enough to not _need_ to
| be 32-bit, so it makes sense IMO to use the same 64-bit
| binaries /toolchains/BSPs as larger platforms, especially since
| they're better supported by upstreams now.
| Narishma wrote:
| 42-bit is the right answer of course.
| tialaramex wrote:
| Cool. A quarter of a century ago a friend of mine worked on this
| and you can still see his name in some copyright notices
| (Alistair Riddoch)
|
| Most recently Al was learning Rust because he needs that for his
| current role, it might be fun to see whether you can write an
| ELKS target for Rust.
| ghaerr wrote:
| Is Alistair Riddoch still around? I've been wondering about
| him, his name is all over the early dev86 and ELKS C library
| code :)
| tialaramex wrote:
| Well I mean, he's a friend and in fact hosted the NYE party I
| was at so, in that sense he's still around. I might see him
| later this week and if so I'll try to remember to mention
| that ELKS is still going.
| tmzt wrote:
| Does anybody have the archive of the original ELKS site with the
| quote from Linus that Linux is not suitable for anything but 486
| or higher or something like that?
| jagged-chisel wrote:
| How recent was the quote? Anywhere near 486 through Pentium,
| and the quote makes absolute sense. He wouldn't have been
| optimizing for smaller architectures.
|
| Since then, some (many?) contributors have supplied support for
| smaller systems.
| mepian wrote:
| Linux started on the 386.
|
| "It is NOT portable (uses 386 task switching etc), and it
| probably never will support anything other than AT-harddisks,
| as that's all I have :-(."
| gregw2 wrote:
| Couldnt find that quote on the 2001 version of the site.
|
| https://web.archive.org/web/20010626233912/http://www.elks.e...
|
| Not sure if you are confusing that with the original
| Linux/Linus announcement post:
|
| https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/Sw...
| garaetjjte wrote:
| I'm confused what relation this has with Linux.
| pm215 wrote:
| The "getting started" doc briefly mentions the history: it
| began in 1995 as a fork of the standard Linux kernel (initially
| named Linux-8086), by Linux kernel developers Alan Cox and Chad
| Page. So it does share both code roots and some initial
| community with the "real" mainline Linux.
| lproven wrote:
| What isn't explained by the name?
|
| ELKS: Embeddable Linux Kernel Subset.
|
| It'a a subset of the Linux kernel, which is suitable for
| embedded systems. Meaning, "don't expect this to be a usable
| desktop OS."
| nh2 wrote:
| Could somebody with a good understanding of microchip production
| economics explain what the price difference would be if all 8-bit
| chips (such as the Atmega328) were replaced by otherwise
| equivalent 32-bit or 64-bit chops tomorrow (that is, same
| production capacity and unit counts sold)?
|
| How much would it cost, in cents, to just have those extra bits?
| omeid2 wrote:
| Supply-chains are more complicated than merely the unit price.
| Things like existing stock, talent, software, product design,
| certifications (both chip and products based on chip), and
| hundreds of other things play just as substantial role.
| LeFantome wrote:
| Probably more about ecosystem compatibility at this point.
| There are already RISC-V chips that sell for less than a 6502.
| anthk wrote:
| I doudbt about that stance, you can have 6502's on every
| keybard at ridiculous prices.
| Palomides wrote:
| a cheap 32 bit RISC-V chip like the CH32V003 goes for about
| $0.10, and the cheapest MCU I've heard of (PMS150C, barely
| useful for anything) goes for around $0.03
|
| there's little real point in 8 bit chips anymore
| fulafel wrote:
| Even without special knowledgeon production economics, I dare
| say there would be a race to produce replacement compatible
| 8-bit microcontrollers to get people's stuff working again.
| vkoskiv wrote:
| I recently added dual screen support to the ELKS console-direct
| driver, so if your system has both MDA and CGA cards, you enable
| CONFIG_CONSOLE_DUAL in your kernel config and select runlevel 5
| in /bootopts, it will allocate 4 ttys, with one of them on the
| MDA display. You can see this setup running on my hardware in
| this pic in the README:
|
| https://raw.githubusercontent.com/ghaerr/elks/refs/heads/mas...
|
| I could use some help testing it on EGA and VGA hardware, as I
| don't have any 8 bit cards for those in my collection.
| LeFantome wrote:
| We are removing 32 bit support from the Linux kernel because
| nobody uses that hardware anymore. Yet, this 16 bit version has
| commits from today.
| happycube wrote:
| It's a hobby, not big and professional like GNU^H^H^HLinux.
|
| Seriously, I haven't worked on this in a long time (I'm Chad)
| and I'm very impressed by the changelog! Wouldn't have ever
| thought it'd run DOOM. ;) (and the use of OS/2 for medium model
| is clever too)
| userbinator wrote:
| Tons of embedded stuff use 32-bit Linux.
| grishka wrote:
| But that stuff is usually not x86.
| PhilipRoman wrote:
| Embedded projects where intel was involved often use
| something like Atom.
| philistine wrote:
| There is a temporal element to your statement. 32-bit support
| is being removed from the kernel of today. No one uses that
| hardware for a modern OS anymore.
|
| But a small band of hobbyists use old OSes with old machines.
| pantalaimon wrote:
| Nobody is removing 32 bit support from the kernel.
| anthk wrote:
| Hyperbola GNU/Linux, Parabola and Guix still have 32 bit
| support. And I still use a 32 bit computer.
|
| And for sure the 2nd and 3rd world use 32 bit devices.
| nolist_policy wrote:
| I bet more than 50% of computer e waste is 64 bit machines
| nowadays.
| snvzz wrote:
| Tangentially related, DOS is a popular choice in this category of
| hardware.
|
| Freedos has released 1.4rc1 recently, thus 1.4 is close.
|
| Svardos switched to EDR-DOS kernel, which is derived from DR-DOS.
| That's a very nice kernel, written in assembly. Notably, Windows
| 3.1 works with it, including protected mode.
| lproven wrote:
| Yup. I wrote about it:
|
| https://www.theregister.com/2024/12/23/svardos_drdos_reborn/
|
| I have built a hobby project around it:
|
| https://github.com/lproven/usb-dos
| ghaerr wrote:
| Thanks for the comments! ELKS will run on an 8088, but also runs
| on any x86 PC using the legacy "real mode" which runs in 16-bit
| segmented architecture without an MMU or any hardware protection.
| It can be fun to boot a PC and see a close resemblance to Linux,
| but run the way things used to be, using only 16-bits.
|
| It'll also run in ROM, e.g. using a 8018x CPU w/onboard PIT and
| PIC.
|
| The point of ELKS today is about "small is beautiful" and seeing
| what can be done when limited to 64k code and 64k data, and 640k
| RAM. It's based on a very old fork of Linux and many of the
| internal structures are similar to what was found in Linux 2.0,
| without the changes for SMP support.
|
| We just recently got a native C compiler/assembler/linker
| toolchain up and running. I must say making that happen provided
| some vivid comparisons of what programmers had to go through in
| decades past in both slower speeds and small executable file
| sizes, versus what we all have and expect today at our
| fingertips.
| ikari_pl wrote:
| This is what I've been looking for! Can you fit a workable
| version on a 1.44 floppy?
| cricalix wrote:
| Around 1996/97 timeframe, you could fit a kernel and
| userspace. I remember building a 1.44 setup that booted a
| compressed kernel and had enough user space tooling to bring
| up telnet, ftp, and the radio stack to drive the long haul
| radio cards (we were replacing JNOS [0] IIRC at an ISP ).
| Even had writable space at the end of the floppy (the kernel
| etc were readonly) to write overrides of the config; poor
| man's overlay I think, but it is rather a long time ago.
|
| Given we were working with 286 era hardware (maybe 386?), I'd
| be surprised if ELKS doesn't fit on a 1.44. Indeed, simply
| looking at the downloads page linked from the original link
| would have answered your question.. [1]
|
| 0 - https://www.langelaar.net/jnos2/documents/about.html
|
| 1 - https://github.com/ghaerr/elks/releases
| ikari_pl wrote:
| I'm totally going to run it on an Amstrad PPC640 soon :)))
| YakBizzarro wrote:
| Well, for that you need to fit it on a 720k floppy :)
| Unless you modded it with a 1.44 drive
| ghaerr wrote:
| Yes it runs on that Amstrad. A funny story about the
| Amstrad, at one point we added divide-by-zero trap
| handler in the kernel for user space apps. When the
| Amstrad reboots via our 'shutdown', its gets a div zero
| exception in its own BIOS (which at the time prohibited
| the reboot, lol).
| rzzzt wrote:
| Single-floppy router distributions were also in style:
| https://en.wikipedia.org/wiki/Floppyfw
| dcminter wrote:
| I'm 99% sure the original kernel and thus the boot&root
| disk Linux (the original "distribution" I guess) only ran
| on the 386 & up as it required & used the memory management
| capabilities.
|
| There were some forks that could run without the mmu
| (micro-Linux I think?) but as I recall it they came quite a
| bit later.
|
| Edit: Ah, close, this:
| https://en.m.wikipedia.org/wiki/%CE%9CClinux
| ghaerr wrote:
| We dropped all support for 286 or 386+ protected
| mode/paging etc, as well as produce only 8088/8086
| instructions so it'll run on any x86 (including the PCjr
| with its peculiarities, remember that?) running in real
| mode only without MMU. Of course, that means any program
| can write anywhere, so more care is taken towards program
| correctness, which is kind of fun.
| ghaerr wrote:
| That's pretty cool about the radio stack!
|
| We don't support a compressed kernel anymore but have a way
| to compress user executables which saves about 30%. Sadly,
| even with straightforward decompression, that process on
| ancient 8088's sometimes takes longer than reading an
| uncompressed executable. But we're finally at the point of
| having "too much stuff" to fit on a floppy. And of course
| everyone wants games. (Don't ask about Doom: yes we have
| it, no it doesn't fit on a floppy :)
| anthk wrote:
| Check NeHaBodi. Nethack 3.4.3 or Slashem 0.7f might
| compile under elks, slashem itself shouldn't need
| ncurses, but it would need some colour support to
| differentiate some mons (not as a requeriment, but it
| helps a lot on the gameplay).
| vasvir wrote:
| Can you find a 1.44 floppy?
| ghaerr wrote:
| Yes, one can actually boot and run a minimal system on 360k
| floppy, but if you want networking you need 720k. The native
| compiler might fit on 1440k but needs a lot more for any
| development if the C library header files etc are wanted.
| anthk wrote:
| Could nethack be compiled under elks? Frotz? Inform6?
| pjlegato wrote:
| There was a DOS port of nethack, so likely it could be made
| to run on elks.
| happycube wrote:
| Very awesome work indeed... I haven't looked at ELKS in a long
| time and seeing everything it can do now is heartwarming.
|
| The 8018x/ROM mode sounds like it could make for a fun
| breadboarding project, not that I'll likely wind up doing it
| myself. Is there any way to run it in emulation?
|
| Running native compilers on XT/286 hardware does indeed sound
| sloooow. At least it can be tested, probably automatically, in
| emulators where it'd run faster than the native compilers did
| back when this all started :)
|
| ---
|
| It's funny... 7-10 year old hardware back in 95-96 when this
| started could barely keep up with current software at all, and
| I'm writing this on a 7 year old Dell Precision (albeit
| upgraded well beyond stock :) ) that still runs Linux pretty
| darn well.
|
| - Chad
| ghaerr wrote:
| There's a couple of ROM versions, one which runs with a ROM
| filesystem and boots a shell over serial and another which
| uses BIOS INT 13h calls for an external MINIX or FAT
| filesystem. Both are run using an emulator which allows
| selection of ROM address, RAM size, etc. It'd be too hard to
| develop reliably without emulators for any of our images.
|
| And yes the native compilers are running way faster under
| emulation than the originals on real hardware! Funnily
| enough, we're finding the slowest portion of the native
| toolchain is the assembler, due to lots of symbols and slow
| hashing.
| LeFantome wrote:
| If you go back 15 years, to January 2010, you find x86-64
| hardware that you could install modern Linux on as easily as
| running the installer off a USB stick. The unibody 2009
| MacBook Pro was out by then, so your computer could even look
| totally normal at a Starbuck's today (and connect to the WiFi
| just fine). That machine will take 8 GB of RAM and run the
| COSMIC desktop written in Rust for Wayland (run it well-I
| have done it).
|
| Go back another 15 years to 1995 and you have Pentium
| desktops. Linux was created just a few years earlier for
| similar but even more modest hardware (as was Windows NT).
| Not every modern Linux distro will still run on Pentiums but
| many will. You may have to burn a CD but up-to-date Antix,
| Q4OS, or Adelie releases will still work out of the box.
| Certainly NetBSD will. Not everything will still run on 32
| bit machines and RAM is going to be a problem. The "modern
| web" would bring those machines to their knees. Still,
| surprisingly modern.
|
| Go back another 15 to January 1980 and you have to wait
| almost two years for hardware that will even run ELKS. Crazy.
| Koshkin wrote:
| Oh well... At least, in 1980 we got Xenix.
| accrual wrote:
| My oldest working systems are now a 386/DX40 and 486/DX2-66, but
| I never had a chance to run Linux on them back then. Did anybody
| here have a favorite distro for such early 90s hardware? When I
| find a 286 or earlier I'd love to give ELKS a try.
| fragmede wrote:
| Slackware was the distro I started on, back around then.
| gregw2 wrote:
| This
| fulafel wrote:
| Sounds optimal for microservices.
| squarefoot wrote:
| The memories. I had it run ("installed" would be a big word ona 2
| flopppy and no hard drive system) on a super cute Carry-1 8088
| computer ages ago, which I stupidly sold on Ebay shortly after as
| I had no use for it. Here's one of the very rare photos online.
| http://vintagescan.blogspot.com/2015/12/flytech-carry-i-1990...
| cloudsec9 wrote:
| Another operating system that deserves mention for 286 class
| machines is Coherent. This was an Unix like OS you could buy for
| $99, and it had all of the various Unix utilities and came with a
| HUGE manual to help you learn it.
|
| They had a 386 version as well, but went all in on getting
| X-windows and graphics working, and ignored TCP/networking just
| as the Internet started to gain a lot of traction. Still an
| interesting OS to look at!
| lproven wrote:
| The final version of Coherent is FOSS now:
|
| https://github.com/gspu/Coherent
| knorker wrote:
| I used elks back when I was too poor to buy a real laptop. My
| laptop was a 286 (old even then), with a shot battery.
|
| So I used elks and lugged around a lead acid motorcycle battery.
|
| It was great for my circumstances, but I wouldn't say I miss it
| compared to my many cores and gigs laptop.
| chriscappuccio wrote:
| There was a version of KA9Q NOS with multitasking that could
| serve telnet, ftp, smtp, bbs, convers, and more plus give you
| multiple switchable terminals for telnet, ftp, all at the same
| time on an 8088 and connect to a packet driver for modem,
| ethernet, or AX25. It was a port of BSD networking with its own
| multitasking capability.
|
| Also PC/MIX was pretty cool.
| incanus77 wrote:
| I had tried to get some version of Linux running on my 386SX /
| 25MHz / 8MB RAM but only succeeded in getting BasicLinux[1]
| running bootstrapped from a DOS boot first. Somehow I had never
| found ELKS! But I was just able to trivially make a floppy and
| boot the system[2]. Amazing. Looking forward to playing with
| this.
|
| [1] https://distro.ibiblio.org/baslinux/
|
| [2] https://mastodon.social/@incanus/113777573079528868
| hudecekdev wrote:
| I don't know exactly why, but this makes me happy.
___________________________________________________________________
(page generated 2025-01-05 23:01 UTC)