Cool Linux Tricks With Atlas

dpilgrim writes: "Looks like some powerful players want to see Linux going toe to toe with Unix 'big iron.' Would you like to be able to run two Linuxes simultaneously on the same box? Or seemless swap processor and memory in and out of your machine? The Atlas project aims to bring you all that and more. There's a press release from TurboLinux reported here, and a more in-depth article running on SourceForge's Linux on Large Systems Foundry."

Comments

Re:Do you need special MOBO to hot swap memory/cpu

[zeno_2]

Atlas seems to be relying upon this new Intel chipset and the Mckinley processor (one of intels new 64bit processors). This new chipset will support hotswapping it sounds like, and any motherboard maker that would use that chipset, would make sure that the slots could do that. So yes you do need a special mobo, but it wont be available for a while.

Re:Starcat

[Anonymous Coward]

Reliability, scalability, a working VM subsystem...the list goes on and on.

Solaris and Hardware

[einhverfr]

OK. Technically, you can run Solaris on x86 hardware and IA64. However, it sucks. On Sparc, it is decent, but many people affectionately call Solaris on x86 "Slowaris."

Now look at the architectures that Linux runs on:
PowerPC
Alpha
x86
IA64
Clawhammer
Power4
etc.

This means that you have much more choice about what you run the Linux machine on.

Also, I think the parent's point about ease of transition being the point of using Linux was missed by you. I would not run my business off Solaris on x86 anymore than I would use Mac OS9 on my web server... Although it is different on the SPARC, Linux and BSD are still the choice *Nix on x86 hardware. If you are running servers on x86, then you may want to move to Linux servers on big iron because the transition would be easier.

Re:What we need

[conway]

While I realize that its reliability is more than proven to most of us here, it's important that it be proven to executives as well.

No, its not proven, at all!

Because you ran your Linux boxen at home and work without powering down for a year doesn't prove anything. You haven't gotten your machines even close to the level of load that enterprise server machines handle each day. Also, most of us run uniprocessor or 2-CPU machines. Not too much stuff is being done on the 32-CPU enterprise machines with Gigs and Gigs of RAM, hundreds of disks, network connections, and PCI buses.

Linux has not been proven in these environments at all. And even if you say that it runs on those machines, when you install an OS on a $1 million machine, you better damn be sure its proven to be reliable.

Now, big Uni*es -- Sun, IBM, HP, etc. have entire teams of people running stress tests on these machines, and (as a former developer of HP-UX) I know that developers must run through at least 12 hours of stress testing a system (thats a system running through automated test suites that excercise every subsystem, and get system load averages to about 200 consistently) when making kernel changes. These things are TESTED

Noone does that with linux, because noone wants to do it -- its not fun work at all. But the companys do do it, and must do it, since they must guarantee 99.99% uptime for the "executives" to buy the system.

So don't blame them for not jumping on Linux.

Looks more like Intel toe to toe with 'big iron'

[Ungrounded Lightning]

Looks like some powerful players want to see Linux going toe to toe with Unix 'big iron.'

This isn't a linux issue. It's a hardware issue.

The significant thing about 'big iron' is that it's an enabling hardware technology.

Once you have it you can write firmware and software that creates the illusion that the hardware never fails

Until you have it, you can't.

The hardware described looks about right - if they handled machine checks properly. (And the fact that they even used the term implies they either did or are trying.) Basic idea: The machine catches ANY error, with enough state saved that you can:

CORRECT the error

IDENTIFY any failed components,

MOVE tasks to non-failed components or reconfigure the failing components to limp along,

NOTIFY the OS of any problem, so it can do things like start moving things off a dying component, and

pick up the computation where it left off WITHOUT the error.

When you can do this you can write a modified Linux, Windows, BeOS, or what-have-you that can do the things a mainframe can. (But you'll need to have a REALLY reliable OS for your starting point - you're now talking uptimes measured in decades. The software better not take the system down in the absense of hardware trouble, and there IS NO hardware troube. B-) )

Hot-swappable parts are more a side-effect than something key. You have to be able to hot-swap to replace a broken part with the system live. Once you have the ability to hot-swap in a replacement for a failed part and add it back into a running domain, it's trivial to generalize that to "fix" parts that were "bad" because they had never been installed.

Partitioning is also implied: You need a minimum of two domains ("virtual machine" subsets of the total device) - working (where the live system is) and diagnostic (where the maintainence guys check out the parts). Once you have that mechanism, making a LARGE number of working domains (with varying amounts of resource, including full or time-shared CPUs) is straightforward.

Re:Virtual machines

[DGolden]

However, there's no two ways about it, VMWare is intrinsically a kludge, because the x86 architecture as it stands today simply wasn't designed to be fully virtualisable (irritatingly, 32-bit x86s CAN fully virtualise 16-bit x86 code - dunno why intel didn't make the conceptual leap to doing the same for the 32-bit stuff - perhaps IBM had patents on it or something, thanks to their POWER architecture, for all I know.)

And true virtualisation, mainframe-style, needs not just CPU support, but support from lots more of the hardware in the computer system.

So, VMWare is part virtualiser, part emulator.

The open source VMWare clone, plex86, similarly, has a lot in common with the bochs x86 emulator.

It's all very clever, but the PeeCee architecture is simply vile, and definitely an example of the "Eat shit, 10 billion flies can't be wrong" effect - even way, way back, there were better designed hardware architectures than the PC available for similar prices - the dominance of the PC arose partly because it was easy to semi-legally produce IBMPC-compatible clones, and partly through non-technological forces (i.e. lying salesmen and marketers combined with completely computer-clueless businessmen who believed them).