Everyone mentioned this yesterday…

275,000 transistors of awesomeness!

275,000 transistors of awesomeness!

Kind of interesting is that Linux has finally dropped support for the 80386 microprocessor.

The 386 is perhaps one of the top ten things that has changed our world, along with 4.3BSD .

No, really!

The 386 microprocessor was the first CPU by Intel that was single sourced.  This means that Intel, and only Intel would fabricate the 386 processor.  Before this time, Intel had licensed their processors to other companies (Siemens, AMD, Harris, IBM etc) So that if there was some kind of production issue at Intel other companies could manufacture 8086,80186s and 80286s.  However this all changed with the 386, as Intel stopped renewing these agreements with other companies (IBM had a license that included the 386, although they were slow in making their own), so now Intel was in charge of its destiny.

The 386 brought three major changes onto the then champion processor the 286.  The first being a 32bit processor where it could handle larger data sizes than the 16bit 286 & 8086.  The 386 also included a larger memory model, the so called “flat mode” where it could directly address 4GB of combined code+data, while the 286 could address 1GB it was limited to 64kb segments.  Lastly the 386 introduced hardware virtualization, the “v86” mode where the 386 could emulate multiple 8086 processors, allowing people to have multiple ‘virtual machines’ on the desktop.

At the time the only consumer grade 32bit processor was the hybrid 32/16 68000 from Motorola.  The 68000 could work with 32bit data, but it was restricted to a 16bit data bus, and only could address 24bits of RAM (16 megabytes).  The 68000 however did not include any kind of memory management unit (MMU) making things like porting UNIX improbable (The SUN-1 workstation included a custom MMU).  Because of the open nature of the IBM PC, clone manufacturers were able to leapfrog IBM, and release 386 based machines before IBM got around to releasing the PS/2 model 80.  It was this that effectively brought 32bit computing to the masses with the Compaq Deskpro.

Compaq's 386 Deskpro

Compaq’s 386 Deskpro

The 8086 processor could address 1MB of RAM, with its 20bit address bus.  However to preserve some compatibility with the 8080 processor it was decided that the 8086 (and 8088) CPUs would work with 64kb segments.  This became a massive headache for years as you could not easily contain more than 64kb of data at a time as you would exceed a segment.  Compiler vendors made some workarounds via the large & huge memory models, but porting a program from a 32bit minicomputer (VAX) would prove difficult if it addressed large amounts of memory, and would require a rewrite.  The 286 increased the addressable memory to 16MB, and included a limited MMU, which enabled an address space of 1GB.  However the 286 was flawed in that again the 286 could only work in 64kb segments, and in order to work with large amounts of memory, the processor had to be shifted to protected mode.  However in protected mode, you couldn’t (easily) switch back to real mode.  This needlessly delayed the adoption of protected mode environments, as you would then lose access to the sizable, and growing, library of MS-DOS programs.  Although workarounds were in place for things like OS/2 and DOS Extenders, they were hacks and couldn’t fix the fundamental 64kb issue.  The 386 built upon the 286’s foundation and included a flat memory model where it could address all 4GB of addressable memory in a single segment.  This meant that you could now use massive amounts of data on a consumer grade machine.

For a while the only 32bit environments were Xenix and MS-DOS via DOS Extenders this proved to be a huge liability and effectively stagnated the industry for a long while.  The 286 was a massive determent.  Making things worse was IBMs insistence that the new OS/2 be able to run on the 286, while Microsoft wanted to create OS/2 to run on the 386, and ignore the IBM AT all together. Basically the 286 was created with the assumption that the 8086 wouldn’t be anywhere near as popular as it was.

With the ability to address large amounts of RAM programs only seen on minicomputers and mainframes were finding their way to the microcomputer such as AutoCAD, Oracle, Links 386 Pro, and of course many in house programs where departments now wouldn’t have to pay to run on then ‘big’ minicomputers.  Combined with the 386’s MMU it was also possible to use more memory than was available in the computer, also known as virtual memory.  The 386 made this transparent to the program, only the 32bit environment needed to handle the swapping.

Finally the last big feature of the 386 was v86 mode.  V86 mode in short is a hardware virtualization platform where the 386 can emulate multiple 8086 processors in hardware.  Each virtual machine can get its own isolated memory space, virtual hardware.  Effectively 8086 programs (such as MS-DOS) can run unaltered inside of v86 mode, with the added benefit of being able to run more than one at a time. Windows/386 lead the charge into this new world of virtual machines for the end user.  Before this point, the only wide scale virtual machine environment was the IBM 370 mainframe which could also create virtual mainframes within itself allowing groups to share a single mainframe, but run incompatible software platforms all at the same time.

Thanks to its capabilities the 386 also brought UNIX to the end user.  First with Xenix, then Microport SYSV, and with the removal of AT&T code BSD was able to be released on the 386 via 386 BSD (and later BSDi’s BSD/OS).  During this timeframe the research OS, Minix was extended by Bruce Evans to be able to use some of the 386’s features which then gave rise to Linux.

Thanks to cheap commodity based 32bit computers, and the GNU projects development tools (binutils, gcc, bash) people could then finally realize GNU’s dream of bringing a free and open UNIX like operating system to the masses.

Needless to say, a lot has changed since 1991, and Linux now moving beyond the 386 processor is no surprise.  The rapid adoption of 64bit computing via AMDs extensions, and the new forthcoming 64bit ARM processors do signal the eventuality that one day Linux will even drop support for 32bit processors… Although I wouldn’t expect that for another 20 years.  Even Intel has ceased manufacturing the 386 processor in 2007.

So it is now time to say good bye to the 386 processor.  At the same time thanks to full software emulation, you will never truly be dead. And as always you can check out Linux’s early versions.

I just saw an uptick in traffic from Oldlinux.org

And even a quick shout out!

2012-10-21
A long time passed! I found someone is also interested in the old things. Neozeed built some Linux 0.00, 0.1x images running on Qemu emulator . I also put them HERE for people to find them easily. Thanks Neozeed. And during this period of time, I also find some valuable old things. The first is the source code of lib-0.12 for kernel 0.12. The other is the full ancient Linux system using kernel 0.98 patchlevel 1 released early by SLS, the 0.98pl1 system .

For anyone who doesn’t know, oldlinux.org is a historical repository for the early start of the now wide spread Linux operating system.  In a somewhat ironic sense of being available on the internet much of the early stuff is lost, however thanks to the work of these fine folks, and some less than scrupulous shovelware dealers, and hoarders much of it has been pieced back together.

I suppose much of it is really of no practical use today, although at the same time the pre 2.0 linux stuff was incredibly small.. And capable of running in ultra minimal configurations.

Running ‘ancient’ linux binaries on modern systems

I just found out about this page which mentions me and my old iBCS/NetBSD adventure to running Xenix binaries on NetBSD 4.x (Sadly 5.x broke xcoff).  In there they also refer to this old redhat page on running a.out binaries on newish systems.

Apparently the ability to run old a.out stuff is still present as Alan Cox notes that “my 3.6rc kernel will still run a Rogue binary built in 1992. X is back compatible to apps far older than Linux.

I’ll have to investigate later on.

Linux turns 20 today….

Wow 1991 was so long ago.  I didn’t get pulled into Linux until the summer of 1992 (0.12 I think?), but wow I’ve sure had my ups & downs with Linux but it certainly had a major impact on everything we do.  Even if it is ‘kind of fringe’ it is in all kinds of things all around us all over the place.  No doubt the whole 20 year thing has been covered pretty much everywhere.

You would be kidding yourself if you have used anything on the internet and not had any interaction with a Linux machine in some manner.  Heck even this blog runs on a Linux VM.

While Linux 0.10 may have been the first ‘usable’ version to many, 0.11 is the first version that has been preserved.  I had even did a Qemu bundle of 0.11 that oldlinux.org had put together as I find Qemu runs Linux better, and of course faster than Bochs.

So here we are and I thought I’d update the Qemu and add in a personal favorite this time…

Download it from sourceforge.

Linux on Qemu’s s390x-softmmu

It’s getting there….!

With a bit of poking around in the latest Qemu 0.15.0 rc2 beta, the S390x now builds by default.  Finding something for it to run was a bit of a stretch but I should have figured that Debian would have something.

It does take a few seconds to boot up, and by default you’ll just be sitting at a blank screen until you toggle to the virtcon0 screen.

But it’s VERY snappy… I haven’t gotten it to install (unsupported NIC?!) but I’m pretty positive it’s 100% my fault.  I’m just happy I saw it boot.  And it runs the busybox stuff just fine so it’s tentatively working.

If anyone wants to give it a whirl, download my exe, and the kernel/init.rd I’ve found that at least boot up here.

I’m hoping this will spur someone to spell out how/what to install onto it, and maybe if things like MUSIC/SP and CMS will run on it… That’d be fantastic!

In the meantime I’d imagine this combined with KVM on people with accelerated configs will enjoy some SERIOUS competition to the IBM Mainframe monopoly!

 

XRDP

This is more of a ‘network virtualization’ thing but I LOVE the RDP protocol.  The issue is when you connect to Linux/UNIX machines they don’t talk RDP it’s either VNC or X11.. and that. well. is a PITA.

Wouldn’t it be cool if you could somehow interface RDP to a private X11 server?

Enter XRDP.

And let me say, if you have UNIX machines with Windows people that need to get involved (Say Oralce on Linux) and what a nightmare it would be to roll out cygwin or some other incredibly complicated thing to rollout, it’ll be a zillion times easier to just let them RDP to the machine.

It’s AWESOME!

Loin screen

And of course the desktop

XRDP Desktop

Isn’t that just AWESOME?

Anyways just to spread the word.

Building Qemu for a VPS

So touching on my prior long winded post, I was mentioning that running Qemu ‘headless’ on a resource constrained VPS was different then running it interactively at home.  For starters you don’t want to install X11, and all the necessary libraries just for a single program if your VPS is limited to 2GB, as it is more then likely that you will exceed your disk space just by trying to get a workable environment.

Instead, I’ve found the way to go is to take advantage of Qemu’s built in VNC server.

I build my own version of Qemu at home, then just upload the binary.  While there may be packages, because of the expectation that you’ll be running X11 for the SDL output it could easily pull in several gigabytes, that I’d rather use for disk images.  I recommend people build with the same OS as their VPS uses, to keep things ‘sane’.  Not to mention you’ll have a far higher success rate by matching OS levels.  And yes I do this in a VM, all the more reason to have VMs.

Also I should mention that in constrained space, I find that 32bit OS stuff is smaller, if you have a 64MB memory limit, then yes size does matter.

The steps are pretty simple, it’s basically download & unpack the source, then configure it something like this:

./configure --target-list=i386-softmmu --disable-sdl --enable-vnc-thread --disable-bluez --disable-curl --disable-vnc-tls --disable-vnc-sasl --disable-spice

Then run make, and after a few minutes it should complete the build.  I then manually ‘strip’ the qemu executable, tar it up and then take it for a test run.  For the most part it really is that simple.

Again I’ve found building on the same distro as your VPS is using helped an incredible amount.  Not to mention trying to keep your ‘build’ machine as bare as possible so it’s not pulling in all kinds of wild dependencies.

The next thing with Qemu uploaded is you’ll want to test it.  It works like normal Qemu with the exception of how you then specify your display to go out via VNC. For me, I run it like this:

./qemu -m 16 -hda os2.disk -hdb data500.qcow2 -vnc <Public IP>:101 -net nic,model=ne2k_isa -net user -L pc-bios -fda empty.vfd -no-reboot  -redir tcp:23::23

Then you can connect with just about any VNC client on VNC port :101 (or TCP 6001)

My OS/2 BBS on Qemu via VNC

And from there I just wrap it in a while true/do true script so that way every time I reboot the VM or if it were to crash for what ever reason it’ll keep on trying to start it over and over.

Back to memory consumption, as you can see I’ve configured my Qemu intance for a whopping 16MB of ram, and this is what it looks like according to top:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 2785 root      20   0 72868  33m 2164 S    2 57.5   1:03.69 qemu

Which is the resident size is 33MB, out of my 64MB VPS, with lhttpd running and php for the socket support I have a whopping 1MB free!

That about covers it, and for the Debian people out there here is my build of Qemu 0.14.1. I should imagine it’ll run on other i386 Linux OS’s (or x86_64’s with the 32bit compatibility installed)

Javascript PC! / Linux in a browser!

That’s right.  Fabrice Bellard, has done it again, he’s given us such great things like TCC, Qemacs, and of course, Qemu.  But now he’s written a x86 emulator in javascript.

Thats right, javascript.

Behold jslinux (works in Chrome 11 & Firefox 4).

I must say, it’s fast.  A lot faster than I would have ever expected.

The hardware is a basic CPU, clock chip, and a UART.  however it’ll run things like vi just fine.  If you have either browser, give it a shot, it’s nothing short of amazing.