Slackware and Red Hat were the two distros in use in the mid 90s.
My local city used proper UNIX, and my university had IRIXworkstations SPARCstations and SunOS servers. We used Linux at my ISP to handle modem pools and web/mail/news servers. In the early 2000s we had Linux labs, and Linux clusters to work on.
Linux on the desktop was a bit painful. There were no modules. Kernels had to fit into main memory. So you’d roll your own kernel with just the drivers you needed. XFree86 was tricky to configure with timings for your CRT monitors. If done wrong, you could break your monitor.
I used FVWM2 and Enlightenment for many years. I miss Enlightenment.
I used Enlightenment on Arch Linux for a year, in 2020-21. The PC had 4G ram and an HDD, Enlightenment was blazing fast. I could type enlightenment_start to a tty and reach a Wayland desktop under a second with 250M ram used total. E is still alive and kicking.
@andrewth09 I bricked a monitor when I tried to fiddle with the graphics settings in Linux back in the late 90s (tried to get it to run on 1280*1024 - which was considered "hi resolution" back then). I had to buy a new monitor. Then installed Windows and only returned to Linux a long time after that.
I managed to make mine do some very worrying noises, but none of my monitors broke either, even though the bandwidth I based my calculations on was often kinda made up.
By the late 90’s most monitors were smart enough to detect when sync speed was too far off and not try to display an image.
It was the old monitors that only supported a single or fixed set of scan rates that you had to worry about damaging. Some could be very picky and others were more tolerant.
If you weren’t at a university it was generally a challenge to get hold of disks. Downloading at home took forever on a 28.8 or even 56k modem (ie. 56 kilobits per second).
Slackware and Redhat disk sets were the thing, in my experience. But generally that only gave you the compiled code, not the source (although there was an another set of disks with the source packages).
If you wanted to recompile stuff you had to download the right set of packages, and be prepared to handle version conflicts on your own (with mailing list and usenet support).
Recompiling the kernel with specific patches for graphics cards, sound cards, modems and other devices (I remember scanners in particular), or specific combinations of hardware was relatively common. “Use the source, Luke!” was a common admonition. Often times specific FAQ pages or howtos would be made available for software packages, including games.
XFree86 was very powerful on hardware it supported, but was very finnicky. See the other posts about the level of detail that had to be supplied to get combinations of graphics cards and monitors working without the appearance of magic smoke.
Running Linux was mostly a enthusiast/hobbyist/geek thing, for those who wanted to see what was possible, and those who wanted to tinker with something approaching Unix, and those who wanted to stretch the limits of what their hardware could do.
Many of those enthusiasts and hobbyists and geeks discovered that Linux could do far more than anyone previously had been prepared to admit or realise. They, and others like them, took it with them into progressively more significant, and valuable projects, and it began to take over the world.
“mailing list and Usenet support”. Yeah. If you’ve ever looked up some weird issues and the only thing that you can come up with is some Debian message group that looks like it was typed on a typewriter, is extremely difficult to follow the response chain, and is apparently from before Y2K… That’s what it was like to run Linux back then.
Slackware took like 40 3.5" double sided double density disks, and woe betide the poor soul who didn’t label them because the stack was a foot high and you damn well would get them mixed up.
When doing it from home I would frequently run into issues that required me to completely reinstall dos and Tekemate to go back to usenet and get help, print the help and then take another stab.
Dos and Linux had different opinions about SCSI chain termination so this usually involved full cover off to move jumpers on the hard drives and sometimes irq jumpers on the motherboard to get the modem AND sound card working right.
Then the fact that to get online once you had slackware installed required you to write your own SLIP/PPP dialup scripts because every ISP was doing their own thing.
Honestly it was a fucking wonderful time. Many happy memories.
“WM8650” seems to indicate a VIA WonderMedia WM8650 armv5te chipset, used by a lot of anemic Android laptops circa 2011 (sold under various brandnames, but apparently all made in the same factory). People have installed Linux on them in the past (there seems to have been a fad for Arch on these for a while, given the search results), but you might have trouble getting a device tree that will work with a modern kernel.
Honestly, though, it has less processor than a Raspberry Pi 3. Unless you’ve already thought of a specific use for this, I’d dump it back in the junk drawer.
I’m so divorced from normalcy I have no frame of reference. Do normal people who don’t do this stuff for a living use Linux now, outside handheld gaming devices? I figured they just used whatever came on whatever device they wanted to buy.
Do normal people who don’t do this stuff for a living use Linux now, outside handheld gaming devices?
I run into folks using linux fairly often in tech hobbies. Ham operators, DIY solar folk, people dorking around with a RasPi, etc. And some Normals who want a lighter experience than Win.
Last dedicated windows box I ran at home was Windows NT 4, IIRC. Last time I had to use it at work was Win7 (?) before I retired. I do have a Win7 virtual somewhere around here I spin up every couple years to run something obscure I can’t get to run in WINE.
I went to college in 93, and they ran a Unix mainframe with thin clients connected to it in the computer labs.
I didn’t really know much about any computers then, but I learned quick and had nerdy friends teach me a lot. Home computers ran DOS, but this fancy thing called Linux had entered the scene and nerds played with it.
I remember it being a bear. My comp sci roommate did most of the work, but he’d dole out mini projects to me to help him out. You had to edit text files with your exact hardware parameters or else it wouldn’t work. Like resolutions, refresh rates, IRQs, mouse shit, printer shit - it was maddening. And then you’d compile that all for hours. And it always failed. Many hardware things just weren’t ever going to work.
Eventually we got most things working and it was cool as beans. But it took weeks - seriously. We were able to act as a thin client to the mainframe and run programs right from our apartment instead of hauling ourselves to the computer lab. Interestingly, on Linux, that was the first time I had ever gotten a modem and a mouse working together. It was either/or before that.
It was both simultaneously horrific and fantastic at the same time. By the time windows 95 rolled out, the Unix mainframe seemed old and archaic. All the cool kids were playing Warcraft 2 and duke nukem 3D.
For better or worse the more correct name GNU/Linux did not catch on and is universally shortened to Linux. Android uses the Linux kernel, but is not GNU/Linux, and therefore is not Linux.
This is some ass-backwards logic. You’re trying to redefine Linux and then declaring that Android does not meet your novel definition. If Android, Alpine, and Chimera are not Linux, then what are they?
Operating System Concepts by Silberschatz, Galvin and Gagne is a classic OS textbook. Andrew Tanenbaum has some OS books too. I really liked his OS Design and Implementation book but I’m pretty sure that one is super outdated by now. I have not read his newer one but it is called Modern Operating Systems iirc.
Sadly no, because while Android is based on Linux, it is so far removed that the kernel is wildly different. Some teams such as mobian, SFOS, postmarketOS, etc. have got fair dinkum Linux running on android devices though.
Firstly humans having lizard brains is pop science nonsense, and secondly humans and lizards are amniotes. And thirdly, the Android userland is Apache 2.0 licensed, regardless of whatever proprietary apps might or might not be installed on top of it, and the vast majority of Linux distros’ kernels have proprietary binary blob drivers installed in them.
This looks like one of those low cost netbooks from the time where “EPad” and “MID” tablets were a thing. There is an edition of Windows CE floating around for these - but WiFi will not work, neither the modem if this has one built in.
No idea about Linux - there is a kernel so you’re technically half way there, but considering most of these had a slow single core ARM CPU and 256MB of RAM on a good day, practical use is limited IMO
I started playing with Linux in the late 90s while I was in grad school. Slackware 3.x. I think I might have tried one or two others, but since I was somewhat familiar with Unix, Slackware was the easiest for me to learn.
I got them via CD ROMs; I’m pretty sure they came with a book on Linux (I think it included several distributions on CDs). I don’t think I have that book any more; I likely got rid of it long ago as it was badly out of date. But my memory is that it was published by Que, a publisher that I had good experience with on other topics. (dBase III, for example) I’m pretty sure it was this one…leave it to Amazon to still have it.
I recall recompiling kernel because it was “so much faster” (I cringe at myself now for thinking that - it probably wasn’t even true on my Pentium 133 machines). I also remember spending time trying to get X-windows configured, but I was successful. I think I was using fvwm95 window manager, a Windows-like experience. I started using Linux essentially full time pretty quickly.
A few times I got frustrated with Linux and tried to switch back to Windows, but the headaches of Windows always quickly drove me back to Linux. Linux is not perfect, but Windows is even worse.
I wouldn’t recommend swapping afterwards, moving devices around is a good way to confuse a bootloader and run into problems.
I think you should create your installation medium, remove the Windows SSD from laptop, install your new one, then install Linux.
You won’t need anything special to transfer files, but keep in mind windows 11 uses bitlocker by default, you’ll probably want to disable that while windows SSD is still in the laptop, otherwise that drive will remain encrypted and inaccessible by Linux.
I would only be swapping once and then having the windows SSD in the USB C hub. Would you still recommend that I install the SSD straight away in the laptop and set it up from there?
Well, if Garuda’s installer does what it’s supposed to do and assigns your boot drive by UUID, it really shouldn’t matter. I still think swapping before install and having the system in the planned final configuration minimizes the risk of failure.
Some background: There was a time in history where boot devices were defined by their physical port location, so if you reordered or moved drives, it was up to the user to update the boot config to align it to the new location. If the user didn’t know to do that step, the computer would fail to boot. Modern linux distros should use the drive’s unique hardware identifier to find the device, wherever it’s plugged in.
Linux bootloaders discover the correct linux volume by UUID (which is in the filesystem), or PARTUUID (which is in the GPT table). It’ll look at every drive, and when it sees the matching one it’ll look in that partition, find the kernel & initrd, suck them into ram, and launch the kernel.
The main problem with moving drives around is - where is the EFI firmware looking for the bootloader in the first place? If you read efibootmgr, the efi data is pretty simple and very much tied to a hardware port. The EFI takes the most preferred bootloader entry, goes to that drive, and runs a file like “\EFI\grub\grubx64.efi”. If that file isn’t right there, the EFI isn’t going to look elsewhere for it.
There is one bootloader name that EFI will pluck out of the blue and (smash the Fx key) offer to you as a boot option - “\EFI\BOOT\BOOTX64.EFI”. Self booting usb installers use that, but you could use it too. Put all the other files that go along with the bootloader in with that boot folder, and rename the appropriate .efi to bootx64.efi.
One thing that I’ve done on odd setups is to put rEFInd on the efi partition as the boot\bootx64.efi loader. It’ll do a pretty fancy job of detecting what’s bootable (may need an additional filesystem_driver.efi), or even chain into grub to finish the startup.
well in a cosmic sort of sense, it already is. (android is based on a modified linux kernel). seriously though, check out antixlinux.com it’s a distro to put on any computer, even ones that old.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.