My Linus story from this era: my brother had a brand new 486, and when he got it, he managed to convince my parents to get him a second hard drive, so that he could run Linux. We did not understand the idea of disk partitions at the time, and I don't even remember the exact details--I believe we booted from floppy to get into Linux.
After spending a couple of days on tech support figuring out how to set the master/slave jumpers on the drives, we felt like we were making good progress. That's right, not all drives labeled their jumpers, and given that the web was a few years from being invented, there were not any support websites on which we could look up that info, so phone was the only way.
Next, we spent a week going to the UIUC CCSO computer lab and downloading slackware floppies. We installed them, and managed to get everything up and running... until we tried getting X to run. We had a strange 800x600 monitor, and getting the dot clocks right was another week of trial-and-error.
The dot clock hurdle surmounted, another problem: almost anything "big" we did under X would pretty quickly cause a kernel panic.
So what did we do? We followed what the README file in Linux said to do: we emailed Linus Torvalds the panic message. A few hours later, we had a response. Linus noticed that the crashes were all with pointers with a value of 0x08000000 (or whatever) which most likely was supposed to be a null pointer, but one of our SIMMs probably had a bit-stuck-at-1 error. He apologized for not being able to tell us which SIMM in the system it was, but encouraged us to swap hardware.
The local computer store sales guys were unimpressed that LINUS TORVALDS HIMSELF had told us we bad memory, but we eventually got them to do a warranty exchange, probably just to get us to go away. And I'm 100% sure those modules found themselves in the next system they built for a different customer. New SIMM modules in hand and the problem was resolved!
I was luckier than I deserved. I pretty much chanced into going to UIUC, which was home to an NCSA supercomputing center and thus was directly on the NSFNet. So not only did we have internet, but it was mind-blowingly fast.
The university was connected via 1.5Mbps T1 when I started, soon upgraded to an ultra-luxurious 45Mbps T3. Let me stress... this was for the entire university of 35K+ students.
The BIOS (nobody called it firmware) of that era was very limited. You could do little more than setting a few configuration options (which were stored in the battery-backed RTC chip aka "CMOS", barely a hundred bytes including the ones keeping the date and time), including things like which floppy drives and hard disk drives were present.
Yes, not sure when they started doing that, but even 386 of the very early nineties had a memory test part of POST. I suspect it started when PC clones came with empty memory slots the users could populate themselves, i.e. the memory configuration wasn't otherwise known in advance.
That memory test was however most basic and shouldn't take too long. It was generally insufficient to determine whether memory was reliable.
> Adoption of Linux in production environments, rather than being used only by hobbyists, started to take off first in the mid-1990s in the supercomputing community, where organizations such as NASA started to replace their increasingly expensive machines with clusters of inexpensive commodity computers running Linux. Commercial use began when Dell and IBM, followed by Hewlett-Packard, started offering Linux support to escape Microsoft's monopoly in the desktop operating system market.[50]
If adoption first started in the less well-resourced academic organisations, I wonder if that commercial shift is connected with the pattern of more and more tech-types moving from academia into industry -- due to a growing lack of opportunity in the academic hierarchy -- bringing their Linux know-how into the large companies.
I was using Coherent, a Unix-like operating system famous for its thick manual in the early 1990s. I eventually switched over to Linux due to the limitations like networking. I had wanted to set up an NFS server at home.
I bought a set of 5.25in floppies from someone advertising on Usenet. The distribution was Softlanding Systems (SLS) with Linux kernel version 0.99pl13. switched to Slackware shortly after that, though I tried most of the popular ones at some point in the 1990s.
I too used SLS in the early days, and before that I believe MCC Interim Linux. Then eventually Debian after SLS, a year or two after it came on the scene.
I believe the first kernel version I had installed was 0.97ish. Definitely a.out pre-elf era, X didn't work yet (at least for me). X was always a hassle with my Trident 8900 card. Modelines and all that.
Wish I remembered more. And wish I could have been more focused and done some real programming and contributed back. I mainly spent my time on MUDs, MOOs, and IRC, and tinkered in an unfocused way in C without accomplishing much concrete. Man those were cool times tho.
Ignorant of the details of a.out vs elf, when the switchover was being discussed I thought this was a decision I’d have to make and agonized over what to choose, hoping I didn’t pick Beta while everybody else went VHS.
My first Linux was Slackware 2.0, which I got via the first edition of Linux Unleashed book, and it had a big sticker bragging about being the first Slackware release with elf support.
I shared your Trident woes, having a Trident 9000, couldn't set it beyond 640x480, whereas I was already on 800x600 on Windows 95, on a 14" monitor.
Yes the modeline thing was the worst; I could never understand (and I haven't gone back to analyze now) why it was that Windows could manage screen resolutions and modes automagically but X required manually futzing with the X config to make it work.
It took a half decade or more before any of this just worked out of the box.
Though it was written for x86 initially, it was nearly all C, with GCC extensions and macros/inline functions containing a tiny bit of inline assembly where x86 instructions were needed.
That made it easy to port to other architectures as soon as someone was motivated, by replacing macro/inline definitions, the bootloader, entry/exit/interrupt paths, and simple architecture-specific device drivers such as keyboard and console.
If Linus had said no, it would have been difficult, as there were many changes that needed to be maintained for each new architecture, and internal APIs that needed changing to help them perform well.
Luckily Linus was happy to accommodate new architecture changes as people did the ports, and over many years the internal APIs gradually shed their x86-flavoured semantics to become more portable.
The first versions weren't. It wasn't until people wanted to port it to the DEC Alpha architecture in 1995 that the changes that they proposed ended up removing a lot of the X86 dependencies. That made further ports much easier.
> It wasn't until people wanted to port it to the DEC Alpha architecture in 1995 that the changes that they proposed ended up removing a lot of the X86 dependencies.
The m68k port started in 1993 when people wanted to run Linux on their Amiga computers, and Linux/m68k was under lively development in 1994, supporting Amiga and Atari computers.
tl;dr starts with a little background before the "just a hobby, won't be big and professional like gnu" post and describes the progression for the next ~year, including a response to someone asking how to go about starting a similar project
Very cool that it went from disk drivers to being able to run X in that time
After spending a couple of days on tech support figuring out how to set the master/slave jumpers on the drives, we felt like we were making good progress. That's right, not all drives labeled their jumpers, and given that the web was a few years from being invented, there were not any support websites on which we could look up that info, so phone was the only way.
Next, we spent a week going to the UIUC CCSO computer lab and downloading slackware floppies. We installed them, and managed to get everything up and running... until we tried getting X to run. We had a strange 800x600 monitor, and getting the dot clocks right was another week of trial-and-error.
The dot clock hurdle surmounted, another problem: almost anything "big" we did under X would pretty quickly cause a kernel panic.
So what did we do? We followed what the README file in Linux said to do: we emailed Linus Torvalds the panic message. A few hours later, we had a response. Linus noticed that the crashes were all with pointers with a value of 0x08000000 (or whatever) which most likely was supposed to be a null pointer, but one of our SIMMs probably had a bit-stuck-at-1 error. He apologized for not being able to tell us which SIMM in the system it was, but encouraged us to swap hardware.
The local computer store sales guys were unimpressed that LINUS TORVALDS HIMSELF had told us we bad memory, but we eventually got them to do a warranty exchange, probably just to get us to go away. And I'm 100% sure those modules found themselves in the next system they built for a different customer. New SIMM modules in hand and the problem was resolved!