Now that we have been able to make the source public, upstream is free to incorporate the changes we've made, and I certainly would hope they do. It's really the same situation as we had with Linux on the mainframe a decade ago.
I don't think anyone has been specifically tasked with pushing the patches upstream, but they're there, and we'd certainly love for them to just go into the upstream tools. We don't want to be supporting forked versions of, well, anything.
After GCC, most everything else (once autotools is patched so that configure recognizes the system type) just falls into place. A new config.sub and config.guess are really what autotools needs (this is exactly like Linux on the mainframe a decade ago) and things, after that, pretty much work.
As you suspect, though, Sine Nomine will certainly be willing to sell commercial support for OpenSolaris on Z, much as we do for other open-source applications and operating systems.
The new documentation is up, although the documentation inside misc.vmarc and phase6.awstape is still the old stuff. I'll replace that over the weekend sometime.
You'll notice that the release notes also refer to "phase 4" in a number of places.
The current awstape image is "phase 6"; we're revising the documentation. That paragraph no longer exists. Do what you like with the loader, including preparing your own ramdisk. The source is available from Sun; just follow the links on the page.
Phase 4 was a non-public release, which did not, in fact, come with source code. Phase 6 is the first public release. Knock yourselves out.
Just to blow my own horn here, SYSVINIT for VM/ESA and z/VM--which is an Open Source product--does in fact do the parallel start and real dependency tracking part of this.
We created it as--as the name should tell you--something like System V Init for z/VM. The traditional method of starting service machines under VM is to put a bunch of AUTOLOG statements in the PROFILE EXEC of the AUTOLOG1 user. This is, yes, even cruder than System V.
The motivation was basically to give a more flexible and familiar startup system to people running multiple Linux images under z/VM, who understand Linux but don't want to deal with CMS and would rather just approach z/VM purely as a hypervisor.
SYSVINIT uses runlevels, which are like System V runlevels except arbitrarily named, and which define a list of services that should start in each runlevel. Each service can in turn list other services that must be running before it can start, and other services that should have been shut down before it can exit.
The system builds a dependency graph from this information, and starts whatever it can in parallel. Basically, I grew annoyed at the inability of System V Init to do real contingent startup processing, and so I fixed that part of it.
It also provides well-defined APIs so that the services you write can respond appropriately and do graceful shutdowns or configuration reloads. Failing that, it is able to do the moral equivalent of TERM; wait some (user configurable) number of seconds; KILL.
I like to think it's pretty slick, but then I wrote it. The underlying operating system is most definitely non-free, but this tool is free (speech and beer; it's released under the Artistic License).
Go to http://sinenomine.net/vm/s5i and get it if you're interested. You have to register with the site to get to the download section, but registration's free.
A future development--not there yet--is the ability to submit commands from an external (non-VM) machine. This is going to involve NJE-over-TCP, and should let you control your VM services from any old TCP-networked workstation, assuming you're running RSCS on the VM box and have defined a link to the workstation. This ought to make life *really* easy for people wanting to control Virtual Penguin Farms from their desktops, without requiring them to be good at VM system administration.
No, it's not as slick as launchd, but it does at least provide real dependency tracking and contingent service startup.
This doesn't quite come out of nowhere. We've had a couple of indications in the series that River is very capable of surprisingly precisely targeted violence.
Pity there's no Book in the trailer, and they talk about the six people on Serenity in the trailer. I want to know Book's backstory.
Tod Frye was told in September that he had to have Pac-Man done in mid-October so it could be in stores by Christmas.
He actually negotiated royalties on it (a first for Atari carts) and became a millionaire, because millions of us bought the damn thing even though it sucked.
For a game that he had to hammer out in something like five weeks, it's not all that bad, but of course the 1999 hack of the Ms. Pac-Man cart shows how it could have been done right.
Princeton does not have any professional schools. There is no "Princeton Law" as there is, for example "Harvard Law."
However, Princeton, unlike many universities, actually has a rather strong tradition of backing up its faculty members against stupid-ass lawsuits. They've supported Ed Felten, and I can report that, as a graduate student, when I was harrassed and threatened with a lawsuit by net.kook Right Reverend Colin James III, they assured me that not only had I done nothing wrong, but that should he actually bring his threatened legal action, the University would stand behind me.
And Princeton has got *quite* deep pockets.
SunnComm doesn't realize yet that it probably picked the wrong target to threaten.
It's slightly more complicated than that (guests need to be shut down at least to single-user mode to pick up changes to, say,/usr, and depending on what libraries are in use you might as well just reboot the guest at a convenient time, and you'll want to stage your changes to the system disks so that everyone always has a consistent view of the disks--but since you can move device addresses around under VM, this is pretty easy, etc., etc., etc.), but, yes, that's a lot of it. A single shared/usr (plus other stuff if you're clever) linked read-only to a bunch of machines makes life tons easier.
Also, just *not dealing with hardware* is a bigger win than it seems like at first. You don't have to care what's running hot, how the cable management is working in the server room, finding the network cables/power cords/whatever that someone "borrowed" for their server two weeks ago. Want to restructure your network topology so you can do a backup across a nonrouted network, and you didn't design it into the original architecture? No problem. You don't have to worry that adding another 10 machines is going to overload your HVAC, or your power.
Plus, you can use something the RMFPMS collector for Linux data to use Performance Toolkit, and see, at a glance, how hard a Linux box *thinks* it's working as well as how hard it's really making the actual box work. This is great for doing consolidation. Tip one: your Linux virtual machines are too big (especially if you listen to the IBM guidelines, which are very conservative) and it's hurting your overall performance.
I've done plenty of these. I'm sure a little Googling will reveal who I work for and that I'm probably not lying. I'm also not an IBMer.
As with anything, "it depends." In my experience, L/390 under z/VM works best in I/O-intensive heavy-throughput roles. Do not throw CPU-intensive work at it. If you need CPU, either build an Intel farm, or use an architecture that's designed for serious computing, like a pSeries.
From a manageability standpoint, you will be flabbergasted how much easier it is to manage a z/VM box with 100 Linux instances on it than it is to maintain 100 rackmounted x86 boxes. And once you get your legs under you with VM, it's amazing how tunable the system parameters are. FCON/ESA (now Performance Toolkit, in z/VM 4.4) is really, really your friend in terms of determining where the system hotspots are. And once you've tasted how to deploy additional servers in two minutes without leaving your chair, it's really hard to go back to old-skool provisioning.
This has nothing to do with whatever IBM is doing, but with what Linas Vepstas and friends have done:
The following trace is from my IPLing Linux on Princeton's VM box yesterday. I don't have a root file system set up yet, so it bombs kind of early. But you can see what the first part of the boot sequence looks like: (I've added <br> tags to preserve the formatting)
ipl 191 Linux version 2.2.1 (root@cheapo.rvdheij.iae.nl) (gcc version egcs-2.91.66 19990 314 (egcs-1.1.2 release)) #58 Tue Nov 23 15:31:32 CET 1999 SAPL booting from VMLINUX MODULE dated 991129 152545 Command line: root=/dev/mem ramdisk_cmsfile=0191:root.disk register eckd0 at major=60 i_dev=0 Device 9 is console (5, 1) register eckd1 at major=60 i_dev=0 register eckd2 at major=60 i_dev=0 register eckd3 at major=60 i_dev=0 register eckd4 at major=60 i_dev=0 register eckd5 at major=60 i_dev=0 vm_load_ramdisk() Failed to load ROOT DISK (rc=1) exit vm_load_ramdisk() trap init with storage key=0 enter time init exit time init vid3270_putcs 1 chars at (0,0):
vid3270_putcs 1 chars at (0,0):
vid3270_putcs 79 chars at (0,1): Console: mono vid3270 80x24 Calibrating delay loop... 1710.49 BogoMIPS trap init with storage key=6 Memory: 9264k available (524k code, 356k data, 32k init) Init Ramdisk: 0k [00000000,00000000] kmem_create: Illgl flg 500 - signal_queue POSIX conformance testing by UNIFIX i370_kernel_thread i370_sys_clone flags=0xf00 i370_copy_thread, usp=0xa1fe8 i370_copy_thread: finished swapper pid=1 regs=000fc764 i370_sys_clone(): after do_fork, res=1 i370_kernel_thread(): return from clone, pid=1 task switch swapper/0 -> swapper/1 PSW 0x3680000 0x80014716 cpu 0 current sp=0xa2420 next sp=0xfc828 i370_sys_clone(): after do_fork, res=0 i370_kernel_thread(): return from clone, pid=0 Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 i370_kernel_thread i370_sys_clone flags=0xf00 i370_copy_thread, usp=0xfc5e0 i370_copy_thread: finished swapper pid=2 regs=000f888c i370_sys_clone(): after do_fork, res=2 i370_kernel_thread(): return from clone, pid=2 Starting kswapd v 1.5 i370_kernel_thread i370_sys_clone flags=0xf00 i370_copy_thread, usp=0xfc5e0 i370_copy_thread: finished swapper pid=3 regs=009de88c i370_sys_clone(): after do_fork, res=3 i370_kernel_thread(): return from clone, pid=3 vid3270_putcs 1 chars at (0,0):
vid3270_putcs 79 chars at (0,1): Console: switching to mono vid3270 80x24 Keyboard hardware init pty: 256 Unix98 ptys configured RAM disk driver initialized: 16 RAM disks of 4096K size VFS: Cannot open root device 00:00 Kernel panic: VFS: Unable to mount root fs on 00:00 HCPGIR450W CP entered; disabled wait PSW 000A0000 8000DEAD
The next question is, why would you ever want to run Linux on the bare metal?
You wouldn't.
At least, not if you had a real S/390.
But for those of us who don't, or who find it inconvenient to get to one, there's Hercules.
So if Linux/390 runs, even poorly, under Hercules (i.e., on the bare iron), I don't have to either work under x3270 on an actual mainframe, nor do I have to build a cross-compiling GCC to do development and porting on the Linux/390 platform.
Of course it'd be nice if IBM would start distributing evaluation, software-only versions of VM so I could load VM on Hercules and then Linux under VM. But now I'm just fantasizing.
You've got a point that IBM nearly dealt a death blow to VM by witholding its source. But then, IBM's been trying to kill VM for a long time. Too bad it's the only way to run MVS^WOS/390 second-level, huh?
Nevertheless, if I had to pick *one* large company right now that "gets" Open Source, and isn't attempting to cash in on it as a cynical ploy to get a lot of cannon fodder to throw at MS, it'd be IBM.
IBM is finally remembering that it is, and has always been, a service company, not a hardware, and not a software company. And, of course, there's the article over at Linux Today--I tipped/. off to it, but they haven't deigned to acknowledge the same: that IBM has ported Linux to the S/390. I know that some really smart people have been doing the same on their own: Linas Vepstas and friends. IBM would gain a lot from bundling Linux with a VM distribution, of course: that would stanch some of the flow of people off mainframes onto Unix boxes. Further: what are mainframes good at? That's right, I/O. What do you need for a heavily trafficked web site? Hunh. Funny thing that. An S/390 running Apache would be something to see. And for those of us who much prefer VM to OS/390...well, it'd be pretty nice if Linux/390 sat on top of VM but not OS/390. Especially if it could also run on the bare iron, so those of us with Linux boxes plus Hercules could run it at home, just for the "hey, wow!" factor.
I view Sun's latching on to Open Source as a self-evidently cynical ploy to get some attention. But as long as they are primarily software/hardware providers, they can't *really* get behind the penguin, because it's going to cut into their Solaris market. Watch: I give Star Office six months, and then they kill the standalone versions and only develop the Java client, which you can only use with the (Solaris-only, I bet) server piece, which will cost real money.
IBM, on the other hand, makes most of its money on service. Open Source is great for them, since it means they don't need to pay developers to write the stuff. They've got an army of people doing it for them, for free. And since their plan wasn't to make money selling the software in the first place, then it doesn't hurt them to give it away. They still sell you the service on it.
I don't trust Sun. They have every reason to turn around and screw us when the opportunity strikes. IBM, at least, has fewer such reasons.
Slashdot Mirror
Hi there. I recognize that handle.
Now that we have been able to make the source public, upstream is free to incorporate the changes we've made, and I certainly would hope they do. It's really the same situation as we had with Linux on the mainframe a decade ago.
I don't think anyone has been specifically tasked with pushing the patches upstream, but they're there, and we'd certainly love for them to just go into the upstream tools. We don't want to be supporting forked versions of, well, anything.
After GCC, most everything else (once autotools is patched so that configure recognizes the system type) just falls into place. A new config.sub and config.guess are really what autotools needs (this is exactly like Linux on the mainframe a decade ago) and things, after that, pretty much work.
As you suspect, though, Sine Nomine will certainly be willing to sell commercial support for OpenSolaris on Z, much as we do for other open-source applications and operating systems.
Adam
The new documentation is up, although the documentation inside misc.vmarc and phase6.awstape is still the old stuff. I'll replace that over the weekend sometime.
Adam
Hey, good eyes.
You'll notice that the release notes also refer to "phase 4" in a number of places.
The current awstape image is "phase 6"; we're revising the documentation. That paragraph no longer exists. Do what you like with the loader, including preparing your own ramdisk. The source is available from Sun; just follow the links on the page.
Phase 4 was a non-public release, which did not, in fact, come with source code. Phase 6 is the first public release. Knock yourselves out.
Adam
Just to blow my own horn here, SYSVINIT for VM/ESA and z/VM--which is an Open Source product--does in fact do the parallel start and real dependency tracking part of this.
We created it as--as the name should tell you--something like System V Init for z/VM. The traditional method of starting service machines under VM is to put a bunch of AUTOLOG statements in the PROFILE EXEC of the AUTOLOG1 user. This is, yes, even cruder than System V.
The motivation was basically to give a more flexible and familiar startup system to people running multiple Linux images under z/VM, who understand Linux but don't want to deal with CMS and would rather just approach z/VM purely as a hypervisor.
SYSVINIT uses runlevels, which are like System V runlevels except arbitrarily named, and which define a list of services that should start in each runlevel. Each service can in turn list other services that must be running before it can start, and other services that should have been shut down before it can exit.
The system builds a dependency graph from this information, and starts whatever it can in parallel. Basically, I grew annoyed at the inability of System V Init to do real contingent startup processing, and so I fixed that part of it.
It also provides well-defined APIs so that the services you write can respond appropriately and do graceful shutdowns or configuration reloads. Failing that, it is able to do the moral equivalent of TERM; wait some (user configurable) number of seconds; KILL.
I like to think it's pretty slick, but then I wrote it. The underlying operating system is most definitely non-free, but this tool is free (speech and beer; it's released under the Artistic License).
Go to http://sinenomine.net/vm/s5i and get it if you're interested. You have to register with the site to get to the download section, but registration's free.
A future development--not there yet--is the ability to submit commands from an external (non-VM) machine. This is going to involve NJE-over-TCP, and should let you control your VM services from any old TCP-networked workstation, assuming you're running RSCS on the VM box and have defined a link to the workstation. This ought to make life *really* easy for people wanting to control Virtual Penguin Farms from their desktops, without requiring them to be good at VM system administration.
No, it's not as slick as launchd, but it does at least provide real dependency tracking and contingent service startup.
Adam
This doesn't quite come out of nowhere. We've had a couple of indications in the series that River is very capable of surprisingly precisely targeted violence.
Pity there's no Book in the trailer, and they talk about the six people on Serenity in the trailer. I want to know Book's backstory.
Adam
The problem, really, was with management.
Tod Frye was told in September that he had to have Pac-Man done in mid-October so it could be in stores by Christmas.
He actually negotiated royalties on it (a first for Atari carts) and became a millionaire, because millions of us bought the damn thing even though it sucked.
For a game that he had to hammer out in something like five weeks, it's not all that bad, but of course the 1999 hack of the Ms. Pac-Man cart shows how it could have been done right.
Adam
Not exactly.
Princeton does not have any professional schools. There is no "Princeton Law" as there is, for example "Harvard Law."
However, Princeton, unlike many universities, actually has a rather strong tradition of backing up its faculty members against stupid-ass lawsuits. They've supported Ed Felten, and I can report that, as a graduate student, when I was harrassed and threatened with a lawsuit by net.kook Right Reverend Colin James III, they assured me that not only had I done nothing wrong, but that should he actually bring his threatened legal action, the University would stand behind me.
And Princeton has got *quite* deep pockets.
SunnComm doesn't realize yet that it probably picked the wrong target to threaten.
Adam
It's slightly more complicated than that (guests need to be shut down at least to single-user mode to pick up changes to, say, /usr, and depending on what libraries are in use you might as well just reboot the guest at a convenient time, and you'll want to stage your changes to the system disks so that everyone always has a consistent view of the disks--but since you can move device addresses around under VM, this is pretty easy, etc., etc., etc.), but, yes, that's a lot of it. A single shared /usr (plus other stuff if you're clever) linked read-only to a bunch of machines makes life tons easier.
Also, just *not dealing with hardware* is a bigger win than it seems like at first. You don't have to care what's running hot, how the cable management is working in the server room, finding the network cables/power cords/whatever that someone "borrowed" for their server two weeks ago. Want to restructure your network topology so you can do a backup across a nonrouted network, and you didn't design it into the original architecture? No problem. You don't have to worry that adding another 10 machines is going to overload your HVAC, or your power.
Plus, you can use something the RMFPMS collector for Linux data to use Performance Toolkit, and see, at a glance, how hard a Linux box *thinks* it's working as well as how hard it's really making the actual box work. This is great for doing consolidation. Tip one: your Linux virtual machines are too big (especially if you listen to the IBM guidelines, which are very conservative) and it's hurting your overall performance.
<religion>rpm -Fvh? Feh. apt-get update, please.</religion>
Adam
I've done plenty of these. I'm sure a little Googling will reveal who I work for and that I'm probably not lying. I'm also not an IBMer.
As with anything, "it depends." In my experience, L/390 under z/VM works best in I/O-intensive heavy-throughput roles. Do not throw CPU-intensive work at it. If you need CPU, either build an Intel farm, or use an architecture that's designed for serious computing, like a pSeries.
From a manageability standpoint, you will be flabbergasted how much easier it is to manage a z/VM box with 100 Linux instances on it than it is to maintain 100 rackmounted x86 boxes. And once you get your legs under you with VM, it's amazing how tunable the system parameters are. FCON/ESA (now Performance Toolkit, in z/VM 4.4) is really, really your friend in terms of determining where the system hotspots are. And once you've tasted how to deploy additional servers in two minutes without leaving your chair, it's really hard to go back to old-skool provisioning.
Adam
"...is that you can't easily learn as a hobbyist. You probably can't play with one at school, either."
Hercules.
Adam
17 inch LCD monitor--$400
This box--$400
Total--$800
17 inch LCD TV at Best Buy--$1200
This certainly looks like a much cheaper way of getting an LCD TV than actually buying one.
The following trace is from my IPLing Linux on Princeton's VM box yesterday. I don't have a root file system set up yet, so it bombs kind of early. But you can see what the first part of the boot sequence looks like: (I've added <br> tags to preserve the formatting)
ipl 191
Linux version 2.2.1 (root@cheapo.rvdheij.iae.nl) (gcc version egcs-2.91.66 19990 314 (egcs-1.1.2 release)) #58 Tue Nov 23 15:31:32 CET 1999
SAPL booting from VMLINUX MODULE dated 991129 152545
Command line: root=/dev/mem
ramdisk_cmsfile=0191:root.disk
register eckd0 at major=60 i_dev=0
Device 9 is console (5, 1)
register eckd1 at major=60 i_dev=0
register eckd2 at major=60 i_dev=0
register eckd3 at major=60 i_dev=0
register eckd4 at major=60 i_dev=0
register eckd5 at major=60 i_dev=0
vm_load_ramdisk()
Failed to load ROOT DISK (rc=1)
exit vm_load_ramdisk()
trap init with storage key=0
enter time init
exit time init
vid3270_putcs 1 chars at (0,0):
vid3270_putcs 1 chars at (0,0):
vid3270_putcs 79 chars at (0,1):
Console: mono vid3270 80x24
Calibrating delay loop... 1710.49 BogoMIPS
trap init with storage key=6
Memory: 9264k available (524k code, 356k data, 32k init)
Init Ramdisk: 0k [00000000,00000000]
kmem_create: Illgl flg 500 - signal_queue
POSIX conformance testing by UNIFIX
i370_kernel_thread
i370_sys_clone flags=0xf00
i370_copy_thread, usp=0xa1fe8
i370_copy_thread: finished swapper pid=1 regs=000fc764
i370_sys_clone(): after do_fork, res=1
i370_kernel_thread(): return from clone, pid=1
task switch swapper/0 -> swapper/1 PSW 0x3680000 0x80014716 cpu 0
current sp=0xa2420 next sp=0xfc828
i370_sys_clone(): after do_fork, res=0
i370_kernel_thread(): return from clone, pid=0
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
i370_kernel_thread
i370_sys_clone flags=0xf00
i370_copy_thread, usp=0xfc5e0
i370_copy_thread: finished swapper pid=2 regs=000f888c
i370_sys_clone(): after do_fork, res=2
i370_kernel_thread(): return from clone, pid=2
Starting kswapd v 1.5
i370_kernel_thread
i370_sys_clone flags=0xf00
i370_copy_thread, usp=0xfc5e0
i370_copy_thread: finished swapper pid=3 regs=009de88c
i370_sys_clone(): after do_fork, res=3
i370_kernel_thread(): return from clone, pid=3
vid3270_putcs 1 chars at (0,0):
vid3270_putcs 79 chars at (0,1):
Console: switching to mono vid3270 80x24
Keyboard hardware init
pty: 256 Unix98 ptys configured
RAM disk driver initialized: 16 RAM disks of 4096K size
VFS: Cannot open root device 00:00
Kernel panic: VFS: Unable to mount root fs on 00:00
HCPGIR450W CP entered; disabled wait PSW 000A0000 8000DEAD
The next question is, why would you ever want to run Linux on the bare metal?
You wouldn't.
At least, not if you had a real S/390.
But for those of us who don't, or who find it inconvenient to get to one, there's Hercules.
So if Linux/390 runs, even poorly, under Hercules (i.e., on the bare iron), I don't have to either work under x3270 on an actual mainframe, nor do I have to build a cross-compiling GCC to do development and porting on the Linux/390 platform.
Of course it'd be nice if IBM would start distributing evaluation, software-only versions of VM so I could load VM on Hercules and then Linux under VM. But now I'm just fantasizing.
Adam
Nevertheless, if I had to pick *one* large company right now that "gets" Open Source, and isn't attempting to cash in on it as a cynical ploy to get a lot of cannon fodder to throw at MS, it'd be IBM.
IBM is finally remembering that it is, and has always been, a service company, not a hardware, and not a software company. And, of course, there's the article over at Linux Today--I tipped /. off to it, but they haven't deigned to acknowledge the same: that IBM has ported Linux to the S/390. I know that some really smart people have been doing the same on their own: Linas Vepstas and friends. IBM would gain a lot from bundling Linux with a VM distribution, of course: that would stanch some of the flow of people off mainframes onto Unix boxes. Further: what are mainframes good at? That's right, I/O. What do you need for a heavily trafficked web site? Hunh. Funny thing that. An S/390 running Apache would be something to see. And for those of us who much prefer VM to OS/390...well, it'd be pretty nice if Linux/390 sat on top of VM but not OS/390. Especially if it could also run on the bare iron, so those of us with Linux boxes plus Hercules could run it at home, just for the "hey, wow!" factor.
I view Sun's latching on to Open Source as a self-evidently cynical ploy to get some attention. But as long as they are primarily software/hardware providers, they can't *really* get behind the penguin, because it's going to cut into their Solaris market. Watch: I give Star Office six months, and then they kill the standalone versions and only develop the Java client, which you can only use with the (Solaris-only, I bet) server piece, which will cost real money.
IBM, on the other hand, makes most of its money on service. Open Source is great for them, since it means they don't need to pay developers to write the stuff. They've got an army of people doing it for them, for free. And since their plan wasn't to make money selling the software in the first place, then it doesn't hurt them to give it away. They still sell you the service on it.
I don't trust Sun. They have every reason to turn around and screw us when the opportunity strikes. IBM, at least, has fewer such reasons.
Adam