As someone else has pointed out, virtually all of the proprietary Unix implementations are derived from BSD. Solaris, Irix, AIX, etc, etc. In fact, the BSD licensing terms are what allowed Unix to fragment into dozens of incompatable operating systems, and created a mess that the industry is still struggling to overcome. How many hardware vendors ship their systems with stock, vanilla, unmodified BSD? None? I'd say that the instances are extremely numerous, if not nearly 100%.
I don't know if anyone has seriously forked the TCP/IP stack, but I somehow doubt that you can compile the AIX TCP/IP source code and link the binary against a Solaris kernel. I don't know if there are differences in the programming API across the different Unix platforms or not. What criteria for incompatability would apply in this argument anyway?
If a programmer at a small company...takes 10 lines of code from a GPLd project... the whole library or program could be forced into a GPL licence;
The "GPL is VIRAL" argument doesn't stand up. It's FUD, designed to scare companies away from GPLed software. This scenario isn't going to happen. In fact, the GPL has language that would almost direct the outcome of such a case:
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.
The most likely scenario, as I see it, is that the company would testify that they decline to accept the license, and the court would then find that the company had committed copyright infringement.
Once the court had defined the issue as simple copyright infringment, it would most likely order the company to cease distribution of the offending software until the company either agreed to the GPL licensing terms, or removed/replaced the offending portions of GPLed code from their software, and possibly order the company to pay damages to the copyright owners, depending on the usual criteria in such cases -- the extent of the infringement, whether the infringement was intentional or unintentional, and all the details and arguments that keep copyright lawyers busy and prosperous.
I can't seriously see a court forcing a company to accept a license that contains the provision, You are not required to accept this License.
In fact, I wish that this exact scenario would play out, because it would remove this common source of FUD about GPL/Free software.
Of course, if the company decided to play hardball, and testified that they DO accept the GPL terms, then directly attack the provisions of the GPL itself, then we would have a true test of the validity of the GPL.
Let RMS spew all he wants about freedom. The license speaks for itself. You want freedom, use the BSD license. You want proprietary software, use the GPL.
It's more like, "You want your software to remain free, and evolve as free software, use the GPL. You want to watch your free software turn into multiple incompatable branches of proprietary, closed-source software, use the BSD license."
Microsoft in fact is not forcing anyone to use their products. The problem with Microsoft is that they manipulated the PC market in order to force everyone to buy their products, whether they wanted them or not. Different issue.
It took a number of readings of this to pick out what I believe is a single, fatal technical flaw:
First the author writes: Attaching the cut-away rail car bases to the Chevy frame was pretty easy too. Jimmy stressed the importance of getting the two sets of wheels precisely aligned, but it wasn't that hard. The old Chevy frame had plenty of places for bolts and welds, so picking spots where the wheels would line up was a snap. And since the Impala was already up on blocks, it was no problem to slide the wheel frames underneath and lift them into place with a floor jack, then weld away.
Ok... so the railroad car wheel assemblies are welded directly to the auto frame, not to the auto axle assemblies. Now here's where he describes how the brakes were attached to the rocket car: Beck's idea was simple, elegant, and easy to put into practice. I'd install the air shocks on the Rocket Car normally, just as if the car would be riding on pavement instead of rails. But I'd also bolt a pair of wooden beams onto the belly of the car, runners that were placed exactly between the front and rear train wheels. Each runner would be thick enough to reach almost all the way down to the tracks, and the bottom would be covered with rubber cut from old tires.
Look at figures two and three. See the problem? The figure shows the car body moving up and down relative to the railroad car wheel assemblies, yet earlier he said that the wheel assemblies were welded to the frame, so they shouldn't have been able to move up and down at all.
Other then that, a masterful telling of the rocket car story!
Your terms of service read, in your license section: You agree to return any and all copies of the Service Software and related documentation upon termination.
Please explain this clause. The only software distributed with the i-opener is integrated into the appliance itself. Are you saying that the end user agrees to return the appliance itself upon contract termination? If not, what does this clause mean and how would a person return the service software without returning the appliance?
Absent any explanation, this looks like a sneaky way of your claiming continued ownership of the appliance even after proper cancellation of the service contract.
I think that it shows the extent that Microsoft has distorted the entire PC computer industry.
For all practical purposes, Microsoft has completely owned the PC software market for years. You'd have to go all the way back to the early 80s to find a genuine free market in personal computer operating systems. Since then, there's been Windows, and things that don't directly compete with Windows.
What happens to companies that attempt to compete head-to-head with Microsoft? Simple. Microsoft copies their work and gives it away with Windows. Then their company goes under. This has been going on for so many years that it's become a given in the software industry.
With Microsoft pouring money from Windows sales into attempting to dominate the internet, we have actually reached a situation where the only viable internet business plan is to give your product away for free, tack on advertising, and hope to hell you can hold onto market share when Microsoft inevitably clones your product and distributes it free with Windows, or as a free download.
You either work with Microsoft, stay well out of their way, or your company will be crippled or destroyed. Compete with Microsoft, and you'll be cut out of the loop. You won't get beta versions of Windows to make sure your software continues to work. You might actually find that the next version of Windows searches for your software, and deliberately malfunctions when end users try and run it. This stuff is all in the trial documents. You couldn't make this stuff up.
That's some seriously messed up economics, and it's led to a seriously distorted PC software market, where the big players are only big because it suits Microsoft's business plan to allow them to continue to exist. A cozy deal with Microsoft is worth far more then a good product, and a good product that Microsoft perceives as a threat is as good as dead. Whether your mousetrap is better is irrelevant... or has been up until now.
Raw power and complete market domination is easy to understand when planning an investment strategy.
What we are seeing here is a weakening of Microsoft's power, which could change all the rules. The one constant in the PC industry has been the monopolistic power of Microsoft, and their ability to control other software companies through the threat of duplicating their products and giving them away for free with Windows.
Judge Jackson's ruling is creating the perception of a power vacuum. The stock market is chaotic because no one knows what is going to happen next and no one knows how to plan. It's been so long since there's been a free market in personal computer operating systems that for all practical purposes it has never existed.
It's been said that when Josef Stalin died, his corpse lay in his bed for days, because he was so feared that no one dared enter the room. I think there's a little of that sort of fear among investors, most of whom don't understand the dynamic of the alternative-operating-system market, and only half-believe that it even exists.
Another thing to consider is that the S/360, S370, and S/390 processors and operating systems have maintained object code compatability for over 30 years. This drastically simplifies processor upgrades, which is something to consider.
You don't need to use LPAR. In fact, we ran VM native on our 3090 with no LPAR, and ran MVS as a guest. We could have run VM and MVS in their own partitions, but LPAR requires you to dedicate resources, and running MVS under VM allowed all of the resources to be used by either operating system on a demand basis.
Actually, in your example of dedicating an entire box to Linux, there would be no reason to use LPAR. You could switch off LPAR and get a slight performance improvement.
Rumors are that LPAR was an internal strategy within IBM to try and eliminate the need for VM on customer machines, at a time when there was considerable infighting between the MVS group and VM groups. As in the MVS people wanted VM eliminated. LPAR mode is nowhere near as flexible as VM and isn't a substitute. About the most that can be said for LPAR is that it gives you an extremely limited subset of VM's capabilities without your having to have VM.
Something that hasn't been mentioned here is that VM has an interesting configuration option called "V=R", which stands for "virtual (storage) = real (storage) that allows you to run a single virtual machine in real memory starting at address zero, eliminating VM's page tables for that virtual machine!
This can be a huge win if that single virtual machine happens to maintain its own page tables (like VM, MVS, or Linux.) Normally, VM itself has to maintain what are called "shadow tables" -- a set of real page tables that map the virtual page tables in your virtual machine to the real hardware memory pages. Every time your virtual machine changes its page tables, it issues a "purge translate lookaside buffer" instruction. This privileged instruction is intercepted by the CP nucleus, which has to then re-examine your virtual page tables and recreate the shadow tables for the real hardware.
Say you want to give your MVS virtual machine 256 megs of memory. There is a way to tell VM to load its kernel above the 256 meg line, and not use the memory below 256M. Now, when you start your specially-identified MVS guest, because that virtual machine is assigned contiguous memory starting at location zero, VM no longer has to maintain shadow tables for that virtual machine; it can allow the V=R guest to directly manipulate the page table registers when it runs (subject to hardware bounds-checking, of course, to make sure the guest stays in its assigned memory), and that virtual machine can run that much faster.
This is something that isn't even an issue with Linux, because Linux doesn't allow your processes to maintain page tables. There's no notion of virtualizing the paging hardware, and no need for something like a V=R guest.
I don't know if V=R mode works with Linux. I'd be interested to find out, and to compare V=R Linux virtual machine performance with native "bare iron" performance. I bet there isn't much difference.
How would you feel if you knew that a person using a public telephone and a disposable calling card, paid for in cash, had made possible an act that led to the deaths of innocents, or other such atrocities?
That's the beauty of VM. When you log onto a VM system, your operating system is "booted up", using the same software programming techniques as if you were booting off the bare iron.
However, there are many facilities that VM provides that the native hardware does not provide. Things like inter-virtual-machine communication, etc. However, if you restrict yourself to only using programming facilities defined in "S/390 Principles of Operation" (the processor manual), then your operating system should, and generally does, run correctly on the bare iron.
As for whether you'd want to do that, in some cases, you can actually obtain a performance improvement by using VM instead of running on the bare iron. For instance, if you are overcommitting memory, you will generally get better performance by giving a flat address space to your virtual machine and letting VM do demand paging then you would by letting the host operating system do its own paging.
Plus, the 40000+ Linuxes in a box was a stunt -- done to show that it could be done. No one in their right mind would *want* to do this in a production environment. Four or five Linux images would be more realistic.
A production VM, a testing VM, and a developmental VM for each of your developers. Your developers can do whatever they want to their own image of Linux. Play with the kernel, crash it five times a day, reload it from a backup in minutes. As your developers develop stable code, they implement it on the testing VM, and the "beta testing" takes place there. Once they are confident, they put their work on the production Linux.
Note that since VM can easily share disk space, you don't have to necessarily FTP anything around. You could just dismount a filesystem from one VM with one command, detach the virtual disk drive from that machine and attach it to another virtual machine, and mount the file system on the other system, all in a few seconds.
You gain a lot by running VM, and many sites do so because the advantages gained easily overwhelm the slight performance hit, if any.
Here is the quote you are referring to, from Supreme Court Justice Holmes, as given in Schenck v. United States (1919): "The most stringent protection of free speech would not protect a man in falsely shouting fire in a theater and causing panic."
If you were to stand up in a crowded theatre today, and yell "fire", most likely the people around you would look at you like you were an idiot, then tell you to shut up.
This analogy dates back to when theatres were firetraps, and a theatre fire could take hundreds of lives. Take for instance, the Iroquois Theater fire of December 30, 1903. During a matinee performance, a piece of scenery caught fire. The doors to the theatre were locked, and over 600 people were killed in approximately 15 minutes.
Theatre fires were the airline crashes of the time. They killed hundreds of people at a time, and in many cases, when a fire became apparent, people were crushed to death in the stampede towards the exits.
What Justice Holmes was saying was obvious to his contemporaries. You are not allowed to falsely create irrational panic in a situation where the panic is likely to lead to death. For instance, if you were to observe someone standing at the edge of a roof, peering over the edge, you would not be allowed to sneak up behind him, scream "LOOK OUT" in his ear, then claim first amendment protection for your actions when he jumped to his death.
Note that Justice Holmes even qualified his statement by stating that a false cry of fire would not be protected speech. If there really was a fire, you would be completely justified in yelling "fire!"
Now that theatres are basically safe places, with wide outward-opening doors, sprinker systems, fire-proof curtains, electric lights instead of white-hot carbon arcs, and safety film instead of explosive nitrate film, the analogy doesn't really mean much anymore. However, the quote lives on, and is regularly misapplied.
Justice Holmes didn't mean that you aren't allowed to yell "fire" because it's annoying, he meant that you falsely use speech to cause panic, resulting in possible injury or death, then 1st amendment protection of free speech does not apply.
Anyway, this common-sense interpretation of the first amendment has nothing to do with DeCSS. The only "irrational panic" here is on the part of the MPAA, and it's not likely to lead to imminent death or injury.
Is CPHACK an original program, or a disassembly?
on
'Battling Censorware'
·
· Score: 2
Something I hadn't thought of... can anyone answer this question... is cphack an original program that implements the encryption algorithm used by CP, or did the authors disassemble the encryption algorithm, then convert the assembly to C?
There is a difference... if cphack was written from scratch to implement the algorithm, then Mattel should have no basis to claim copyright infringement. If cphack is merely a translation of the Mattel written subroutine from machine language to C, then I'd have to agree that the distribution of cphack is probably copyright infringement. I mean, if you were to take a binary of the Linux kernel, disassemble it, and convert it back into readable C code, that wouldn't magically remove the copyright on Linux, would it?
Of course, if the case were to be tried in court, a fair use defense could be raised, but that option disappeared when the programmers cut their deal with Mattel.
The best part of the article is how Mattel is expecting to take a HUGE loss on the company. Put another way, former CEO Jill Barad paid about $3.5 billion for The Learning Co. (TLC), which is now reportedly expected to fetch between $500 million and $1 billion.
And, as icing on the cake, Mattel has associated their company and name brand with repressive censorship. I won't be buying anything with the "Mattel" name on it ever again.
Another option would be a free DVD player with a dummy DeCSS stub routine. Such a player would only decode CSS encoded material if the end user compiled in the much-maligned decss subroutine.
Copyright is a legal right, and cannot be circumvented by technical means. If you make a copy of a copyrighted work, that work is still fully copyrighted. The copyright owner has lost none of his legal rights.
"copyright protection" is a phrase invented by the industry to create confusion in the public mind between copyright and copy protection.
It doesn't make any sense because it's propaganda. It's an industry-promoted lie.
Region coding has nothing to do with copyright. It is 100% about market control.
Just like copy protection has nothing whatsoever to do with copyright, yet the industry calls it "copyright protection" in an effort to confuse the two in the public mind.
God, I spent weeks studying that instruction, trying to figure out how to out it to work. IBM put out an entire BOOK on that instruction. It's basically a huge chunk of microcode that emulates a small piece of the VM kernel. It's pretty much useless for hacking/play purposes, unless you want to design around the instruction.
I had better luck playing with the vector instructions. I had a very fast fractal generator:)
You wouldn't even need to do that. Say your failed radius server was named RADIUS. You would type, from the operator console,
force radius autolog radius
and you would get the same effect as a power cycle on a standalone machine, but without the time wasted on hardware and memory self-tests, SCSI bus initialization, etc. You go straight from the autolog command to kernel initialization instantly, so you could be back up and running in a few seconds, depending on how long it takes for linux to start up and your radius server to initialize.
It would depend on what you were doing on that machine. There are at least two cases where Linux under VM will probably beat out native Linux.
o) You have an application that wants to spin off a large number of separate tasks. Your Linux kernel will not perform well under these circumstances, but if you built a virtual beowulf cluster of many Linux images, each running four or five active tasks per image, then each Linux image will run smoothly and efficiently -- within its design parameters.
2) You want to run a task that requires a huge address space -- far exceeding your real memory.
First off, things aren't so bad, because by using a shared segment, VM can use one shared-memory copy for all of those Linux kernel images, saving a lot of memory.
Also, mainframes can page so efficiently that they can massively overcommit memory without taking a performance hit. They were designed for this. The normal configuration of a VM system is thousands of users at terminals, each with their own virtual machine, running CMS. Each virtual machine might have two or three megs of shared program code, and however much private data they happen to be using at the moment. VM was designed to support a massive overcommittment of memory. Mainframes even have special paging storage, called expanded storage, and a set of hardware instructions for performing quick paging back and forth between real and expanded storage. Think of it as a fast ramdisk, attached right to the CPU bus.
The end effect is that you can actually get an improvement in performance by turning off your own paging, and relying on VM's native paging facilities. MVS sites discovered this years ago.
Say you want to provide 2 gigs of storage to an application, but your mainframe has only 1 gig of memory, you would have two options:
1) Allocate about 1 gig to the Linux image, and create paging space within Linux. The Linux kernel handles all the paging.
2) Allocate 2 gigs to the Linux image, so that Linux never has to page, and let VM handle the paging.
You'll get better performance using method 2.
The biggest strengths of mainframe designs go right to the heart of your objections. It's what VM was designed to do, and it does it very well.
Another reason to run a cluster within a single machine is to circumvent bottlenecks within Linux. If you have an application that insists on forking off dozens and dozens of tasks, you will start to run into the Linux scheduling algorithms, which are performance-optimized for a small number of tasks.
If you create multiple Linux images using the zero-latency networking capabilities that VM gives you, you can split up your application until there are a small enough number of tasks per Linux image to run smoothly.
Another good reason is, as AC says, if some users need root access for some reason. You can set up a system as a virtual machine, give them root access to that image, and nothing they can do will affect any other virtual machine in the system. Great for testing new Linux kernels. In fact, VM was designed specifically for this purpose -- except that it was used to debug new OS/390 (MVS) kernels instead.
Right. VM has shared memory across virtual machines. Even though there are 41,400 images of Linux, there need be only one copy of the code in storage, shared by all of those virtual machines.
If one of those virtual machines were to attempt to write to a memory page, CP would simply fork off a private copy of that page, and continue on.
I believe that Linux (and most unixes) do the same thing -- one read-only copy for each currently running executable, shared between all processes running that executable.
I'm not involved in this work; I wish I was. However, I'm very familiar with VM/ESA and the low-level programming facilities that are being used to pull of this 41,000 Linux virtual machine cluster. I used to write assembly language programs that used IUCV and virtual CTCAs, and what they are doing is crystal clear.
First off, this setup is running under VM/ESA. This is NOT the same operating system as OS/390. Diehard VM'ers tend to view OS/390 about as fondly as Linux users view Windows. OS/390 is the huge, IBM-management-approved operating system with JCL, that evolved out of OS/360. VM is the back-room project that IBM management has tried to kill, over and over, but can't kill, because it's needed for OS/390 development, IBM developers demand it, and many customers demand it. OS/390 is what management wants to sell -- it's the "strategic" operating system. VM/CMS is what the IBM development teams use because it was designed, from the bottom up, by IBM's best software developers, specifically as a platform for software development. Really. I used it for 15 years. If you're developing or debugging IBM assembly code, it's just the best. VM was a skunkworks project, and a damn fine one. It's a shame that it isn't that well known.
The two operating systems should NOT be confused. Different operating systems. Entirely. OS/390 can run as a guest under VM/ESA, but not vice versa.
That said, VM has a HORRIBLE native TCP/IP implementation. It's a big program, written in Pascal, and it's a dog. In fact, it's about the weakest part of VM. It never got much attention, because mainframe networking has always been driven by SNA, VTAM, etc. and IBM development is traditionally done on a 3270 style terminal. All the tools, XEDIT, the mail system, etc, are all designed for 3270, block mode terminals. VM is lacking in TCP/IP support for the same reason that Unix systems are lacking in SNA support, because no one wanted it. This is changing.
The VM TCP/IP implementation is a standalone program. The TCP/IP program runs in its own virtual machine. When someone wants to connect to TCP/IP, they use a system call to establish a connection between their virtual machine and the TCP/IP virtual machine using a facility called IUCV -- Inter User Communication Vehicle.
IUCV is a very fast, block-oriented, secure, unspoofable point to point protocol for establishing data links between virtual machines. A programmer using IUCV starts by creating a link to the target, then sends blocked data by making a system call with the address/length of the data. The CP nucleus (their word for the kernel) copies the data into the system address space, synthesises and schedules an interrupt for the target virtual machine, and immediately reschedules the source virtual machine. The target virtual machine receives the interrupt, issues an IUCV receive system call, and CP copies the data into the target machine address space. This is all done completely asynchronously. It's extremely fast, and utterly secure. Zero-latency networking is a nice thing to have.
Which leads to something very cool. IP over IUCV.
I don't know exactly how they set their system up, but here are the basic tools that they have to work with:
1) TCP/IP to the outside world can be handled in at least two ways:
o Through a native Linux network device driver. In VM, physical peripheral devices are assigned to individual virtual machines. A virtual machine with a physical network interface attached to it simply uses it as an ordinary I/O device.
o Via a connection to a native TCP/IP virtual machine, using a special device driver that knows the native IP-via-IUCV protocol.
2) Connections between virtual Linux machines can be handled in a couple of ways:
o through a virtual (or real) CTCA (Channel to Channel adapter.) a CTCA is a high speed parallel interface used to connect mainframes together, point to point, very fast. If you use virtual CTCAs, you can move Linux images from one machine to another without having to ever reconfigure anything within the Linux images themselves simply by replacing the virtual CTCAs with an attached real CTCA and changing the directory entry of the virtual machine.
o Using an IUCV driver, one can interconnect all of the internal Linux images via virtual point-to-point lines. This is much faster then virtual CTCAs. The drawback being that you need to configure IUCV links within a virtual machine, so changing things around requires reconfiguration within the linux image itself, and IUCV is designed to work efficiently within a single system, not across multiple systems. It can be done, but it's a hack, and it's inefficient.
o Through an obsolete API called VMCF, which was superceded by IUCV.
The big innovation going on here is the realization that by running multiple Linux images on a single machine, or multiple Linux images on multiple machines, using mostly IUCV links, one can almost eliminate the network latency, because the data transfers are simply memory copies, and one can eliminate the network collision problem, and the network traffic problems. If you have 100 machines sitting on a fast ethernet, and you start getting a lot of inter-machine traffic, you are going to have collisions, and each machine has to waste a fair amount of time evaluating which packets are his. This removes the biggest bottleneck in large clusters of small machines, Also, an IUCV connection is guaranteed to never drop a packet, and always transmits packets in order, so TCP over IUCV proceeds smoothly and efficiently.
This gives you lots of scaling options for your virtual Linux network.
One more point.
There was an article that came out two days ago, but due to a slashdot bug never appeared on the main page, but proceeded directly to the "older news" catagory. In it, the author wrote: An S/390 running a light load will not run as quickly as a fast PC server under a light load, according to Courtney. The difference between the two systems will not be apparent until the load is much larger.
"The PC will begin to degrade and will typically reach a point where it avalanches down in performance as its load limit is exceeded. The mainframe starts out at a lower performance level, from the standpoint of an individual program task, but degrades much more slowly and much more linearly as the load increases," he says.
Revisiting my previous comment in this thread, I remember, a while ago, reading in another article about a difference of opinion between some IBM programmers and the kernel maintainers. Supposedly, IBM was complaining that Linux performance went south when the number of running tasks became large, and proposed some scheduler changes, but the kernel developers didn't want to change it because the changes would have slowed the kernel down in the "normal" case of only a few active processes. Does anyone have a link to this or remember what I'm talking about?
Sounds like this article is describing the same known effect. However, by running multiple images of Linux under VM, one obtains a workaround for the problem. If a Linux virtual machine is overloaded, create a new virtual machine image, and offload one or more of the biggest processes to run on the new machine.
This is all very interesting stuff. Don't forget, the stuff we're just discovering now in the Linux world, is largely stuff that the IBMers, and especially the VMers have been working on and perfecting for about 30 years. I'd love to see a Linux kernel that can run 41,000 tasks, with a linear performance degradation curve. Until then, at least there is a way to run Linux on an operating system that has those characteristics.
And the fact that their operating system can run 41000+ simultaneous tasks without disintegrating, but ours can't, should eventually get under someone's skin and prompt efforts to make the Linux kernel scale better under heavy multitasking loads. Why should they have all the fun?
Slashdot Mirror
As someone else has pointed out, virtually all of the proprietary Unix implementations are derived from BSD. Solaris, Irix, AIX, etc, etc. In fact, the BSD licensing terms are what allowed Unix to fragment into dozens of incompatable operating systems, and created a mess that the industry is still struggling to overcome. How many hardware vendors ship their systems with stock, vanilla, unmodified BSD? None? I'd say that the instances are extremely numerous, if not nearly 100%.
I don't know if anyone has seriously forked the TCP/IP stack, but I somehow doubt that you can compile the AIX TCP/IP source code and link the binary against a Solaris kernel. I don't know if there are differences in the programming API across the different Unix platforms or not. What criteria for incompatability would apply in this argument anyway?
If a programmer at a small company ...takes 10 lines of code from a GPLd project ... the whole library or program could be forced into a GPL licence;
The "GPL is VIRAL" argument doesn't stand up. It's FUD, designed to scare companies away from GPLed software. This scenario isn't going to happen. In fact, the GPL has language that would almost direct the outcome of such a case:
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.
The most likely scenario, as I see it, is that the company would testify that they decline to accept the license, and the court would then find that the company had committed copyright infringement.
Once the court had defined the issue as simple copyright infringment, it would most likely order the company to cease distribution of the offending software until the company either agreed to the GPL licensing terms, or removed/replaced the offending portions of GPLed code from their software, and possibly order the company to pay damages to the copyright owners, depending on the usual criteria in such cases -- the extent of the infringement, whether the infringement was intentional or unintentional, and all the details and arguments that keep copyright lawyers busy and prosperous.
I can't seriously see a court forcing a company to accept a license that contains the provision, You are not required to accept this License.
In fact, I wish that this exact scenario would play out, because it would remove this common source of FUD about GPL/Free software.
Of course, if the company decided to play hardball, and testified that they DO accept the GPL terms, then directly attack the provisions of the GPL itself, then we would have a true test of the validity of the GPL.
Let RMS spew all he wants about freedom. The license speaks for itself. You want freedom, use the BSD license. You want proprietary software, use the GPL.
It's more like, "You want your software to remain free, and evolve as free software, use the GPL. You want to watch your free software turn into multiple incompatable branches of proprietary, closed-source software, use the BSD license."
Microsoft in fact is not forcing anyone to use their products. The problem with Microsoft is that they manipulated the PC market in order to force everyone to buy their products, whether they wanted them or not. Different issue.
It took a number of readings of this to pick out what I believe is a single, fatal technical flaw:
... so the railroad car wheel assemblies are welded directly to the auto frame, not to the auto axle assemblies. Now here's where he describes how the brakes were attached to the rocket car:
First the author writes:
Attaching the cut-away rail car bases to the Chevy frame was pretty easy too. Jimmy stressed the importance of getting the two sets of wheels precisely aligned, but it wasn't that hard. The old Chevy frame had plenty of places for bolts and welds, so picking spots where the wheels would line up was a snap. And since the Impala was already up on blocks, it was no problem to slide the wheel frames underneath and lift them into place with a floor jack, then weld away.
Ok
Beck's idea was simple, elegant, and easy to put into practice. I'd install the air shocks on the Rocket Car normally, just as if the car would be riding on pavement instead of rails. But I'd also bolt a pair of wooden beams onto the belly of the car, runners that were placed exactly between the front and rear train wheels. Each runner would be thick enough to reach almost all the way down to the tracks, and the bottom would be covered with rubber cut from old tires.
Look at figures two and three. See the problem? The figure shows the car body moving up and down relative to the railroad car wheel assemblies, yet earlier he said that the wheel assemblies were welded to the frame, so they shouldn't have been able to move up and down at all.
Other then that, a masterful telling of the rocket car story!
I just wanted to say that you guys have the coolest logo ever!
As near as I can tell, it's Jesus spanking a snake with a lit sparkler. Ogg, the symbolism!!
Your terms of service read, in your license section:
You agree to return any and all copies of the Service Software and related documentation upon termination.
Please explain this clause. The only software distributed with the i-opener is integrated into the appliance itself. Are you saying that the end user agrees to return the appliance itself upon contract termination? If not, what does this clause mean and how would a person return the service software without returning the appliance?
Absent any explanation, this looks like a sneaky way of your claiming continued ownership of the appliance even after proper cancellation of the service contract.
I think that it shows the extent that Microsoft has distorted the entire PC computer industry.
... or has been up until now.
For all practical purposes, Microsoft has completely owned the PC software market for years. You'd have to go all the way back to the early 80s to find a genuine free market in personal computer operating systems. Since then, there's been Windows, and things that don't directly compete with Windows.
What happens to companies that attempt to compete head-to-head with Microsoft? Simple. Microsoft copies their work and gives it away with Windows. Then their company goes under. This has been going on for so many years that it's become a given in the software industry.
With Microsoft pouring money from Windows sales into attempting to dominate the internet, we have actually reached a situation where the only viable internet business plan is to give your product away for free, tack on advertising, and hope to hell you can hold onto market share when Microsoft inevitably clones your product and distributes it free with Windows, or as a free download.
You either work with Microsoft, stay well out of their way, or your company will be crippled or destroyed. Compete with Microsoft, and you'll be cut out of the loop. You won't get beta versions of Windows to make sure your software continues to work. You might actually find that the next version of Windows searches for your software, and deliberately malfunctions when end users try and run it. This stuff is all in the trial documents. You couldn't make this stuff up.
That's some seriously messed up economics, and it's led to a seriously distorted PC software market, where the big players are only big because it suits Microsoft's business plan to allow them to continue to exist. A cozy deal with Microsoft is worth far more then a good product, and a good product that Microsoft perceives as a threat is as good as dead. Whether your mousetrap is better is irrelevant
Raw power and complete market domination is easy to understand when planning an investment strategy.
What we are seeing here is a weakening of Microsoft's power, which could change all the rules. The one constant in the PC industry has been the monopolistic power of Microsoft, and their ability to control other software companies through the threat of duplicating their products and giving them away for free with Windows.
Judge Jackson's ruling is creating the perception of a power vacuum. The stock market is chaotic because no one knows what is going to happen next and no one knows how to plan. It's been so long since there's been a free market in personal computer operating systems that for all practical purposes it has never existed.
It's been said that when Josef Stalin died, his corpse lay in his bed for days, because he was so feared that no one dared enter the room. I think there's a little of that sort of fear among investors, most of whom don't understand the dynamic of the alternative-operating-system market, and only half-believe that it even exists.
Step 1: Invent the replicator. Society's problems are mostly due to limited resources.
Sorry, but replicator technology is prohibited by the Digital Millenium Copyright Act.
Another thing to consider is that the S/360, S370, and S/390 processors and operating systems have maintained object code compatability for over 30 years. This drastically simplifies processor upgrades, which is something to consider.
You don't need to use LPAR. In fact, we ran VM native on our 3090 with no LPAR, and ran MVS as a guest. We could have run VM and MVS in their own partitions, but LPAR requires you to dedicate resources, and running MVS under VM allowed all of the resources to be used by either operating system on a demand basis.
Actually, in your example of dedicating an entire box to Linux, there would be no reason to use LPAR. You could switch off LPAR and get a slight performance improvement.
Rumors are that LPAR was an internal strategy within IBM to try and eliminate the need for VM on customer machines, at a time when there was considerable infighting between the MVS group and VM groups. As in the MVS people wanted VM eliminated. LPAR mode is nowhere near as flexible as VM and isn't a substitute. About the most that can be said for LPAR is that it gives you an extremely limited subset of VM's capabilities without your having to have VM.
Something that hasn't been mentioned here is that VM has an interesting configuration option called "V=R", which stands for "virtual (storage) = real (storage) that allows you to run a single virtual machine in real memory starting at address zero, eliminating VM's page tables for that virtual machine!
This can be a huge win if that single virtual machine happens to maintain its own page tables (like VM, MVS, or Linux.) Normally, VM itself has to maintain what are called "shadow tables" -- a set of real page tables that map the virtual page tables in your virtual machine to the real hardware memory pages. Every time your virtual machine changes its page tables, it issues a "purge translate lookaside buffer" instruction. This privileged instruction is intercepted by the CP nucleus, which has to then re-examine your virtual page tables and recreate the shadow tables for the real hardware.
Say you want to give your MVS virtual machine 256 megs of memory. There is a way to tell VM to load its kernel above the 256 meg line, and not use the memory below 256M. Now, when you start your specially-identified MVS guest, because that virtual machine is assigned contiguous memory starting at location zero, VM no longer has to maintain shadow tables for that virtual machine; it can allow the V=R guest to directly manipulate the page table registers when it runs (subject to hardware bounds-checking, of course, to make sure the guest stays in its assigned memory), and that virtual machine can run that much faster.
This is something that isn't even an issue with Linux, because Linux doesn't allow your processes to maintain page tables. There's no notion of virtualizing the paging hardware, and no need for something like a V=R guest.
I don't know if V=R mode works with Linux. I'd be interested to find out, and to compare V=R Linux virtual machine performance with native "bare iron" performance. I bet there isn't much difference.
How would you feel if you knew that a person using a public telephone and a disposable calling card, paid for in cash, had made possible an act that led to the deaths of innocents, or other such atrocities?
Anonymity in and of itself is ethically neutral.
That's the beauty of VM. When you log onto a VM system, your operating system is "booted up", using the same software programming techniques as if you were booting off the bare iron.
However, there are many facilities that VM provides that the native hardware does not provide. Things like inter-virtual-machine communication, etc. However, if you restrict yourself to only using programming facilities defined in "S/390 Principles of Operation" (the processor manual), then your operating system should, and generally does, run correctly on the bare iron.
As for whether you'd want to do that, in some cases, you can actually obtain a performance improvement by using VM instead of running on the bare iron. For instance, if you are overcommitting memory, you will generally get better performance by giving a flat address space to your virtual machine and letting VM do demand paging then you would by letting the host operating system do its own paging.
Plus, the 40000+ Linuxes in a box was a stunt -- done to show that it could be done. No one in their right mind would *want* to do this in a production environment. Four or five Linux images would be more realistic.
A production VM, a testing VM, and a developmental
VM for each of your developers. Your developers can do whatever they want to their own image of Linux. Play with the kernel, crash it five times a day, reload it from a backup in minutes. As your developers develop stable code, they implement it on the testing VM, and the "beta testing" takes place there. Once they are confident, they put their work on the production Linux.
Note that since VM can easily share disk space, you don't have to necessarily FTP anything around. You could just dismount a filesystem from one VM with one command, detach the virtual disk drive from that machine and attach it to another virtual machine, and mount the file system on the other system, all in a few seconds.
You gain a lot by running VM, and many sites do so because the advantages gained easily overwhelm the slight performance hit, if any.
- John
Here is the quote you are referring to, from Supreme Court Justice Holmes, as given in Schenck v. United States (1919):
"The most stringent protection of free speech would not protect a man in falsely shouting fire in a theater and causing panic."
If you were to stand up in a crowded theatre today, and yell "fire", most likely the people around you would look at you like you were an idiot, then tell you to shut up.
This analogy dates back to when theatres were firetraps, and a theatre fire could take hundreds of lives. Take for instance, the Iroquois Theater fire of December 30, 1903. During a matinee performance, a piece of scenery caught fire. The doors to the theatre were locked, and over 600 people were killed in approximately 15 minutes.
Theatre fires were the airline crashes of the time. They killed hundreds of people at a time, and in many cases, when a fire became apparent, people were crushed to death in the stampede towards the exits.
What Justice Holmes was saying was obvious to his contemporaries. You are not allowed to falsely create irrational panic in a situation where the panic is likely to lead to death. For instance, if you were to observe someone standing at the edge of a roof, peering over the edge, you would not be allowed to sneak up behind him, scream "LOOK OUT" in his ear, then claim first amendment protection for your actions when he jumped to his death.
Note that Justice Holmes even qualified his statement by stating that a false cry of fire would not be protected speech. If there really was a fire, you would be completely justified in yelling "fire!"
Now that theatres are basically safe places, with wide outward-opening doors, sprinker systems, fire-proof curtains, electric lights instead of white-hot carbon arcs, and safety film instead of explosive nitrate film, the analogy doesn't really mean much anymore. However, the quote lives on, and is regularly misapplied.
Justice Holmes didn't mean that you aren't allowed to yell "fire" because it's annoying, he meant that you falsely use speech to cause panic, resulting in possible injury or death, then 1st amendment protection of free speech does not apply.
Anyway, this common-sense interpretation of the first amendment has nothing to do with DeCSS. The only "irrational panic" here is on the part of the MPAA, and it's not likely to lead to imminent death or injury.
Something I hadn't thought of ... can anyone answer this question ... is cphack an original program that implements the encryption algorithm used by CP, or did the authors disassemble the encryption algorithm, then convert the assembly to C?
... if cphack was written from scratch to implement the algorithm, then Mattel should have no basis to claim copyright infringement. If cphack is merely a translation of the Mattel written subroutine from machine language to C, then I'd have to agree that the distribution of cphack is probably copyright infringement. I mean, if you were to take a binary of the Linux kernel, disassemble it, and convert it back into readable C code, that wouldn't magically remove the copyright on Linux, would it?
There is a difference
Of course, if the case were to be tried in court, a fair use defense could be raised, but that option disappeared when the programmers cut their deal with Mattel.
The article URL has changed. Here is the new link
The best part of the article is how Mattel is expecting to take a HUGE loss on the company.
Put another way, former CEO Jill Barad paid about $3.5 billion for The Learning Co. (TLC), which is now reportedly expected to fetch between $500 million and $1 billion.
And, as icing on the cake, Mattel has associated their company and name brand with repressive censorship. I won't be buying anything with the "Mattel" name on it ever again.
Nice job with the lawyers, guys.
Another option would be a free DVD player with a dummy DeCSS stub routine. Such a player would only decode CSS encoded material if the end user compiled in the much-maligned decss subroutine.
Copy protection is a physical mechanism.
Copyright is a legal right, and cannot be circumvented by technical means. If you make a copy of a copyrighted work, that work is still fully copyrighted. The copyright owner has lost none of his legal rights.
"copyright protection" is a phrase invented by the industry to create confusion in the public mind between copyright and copy protection.
Don't buy into their propaganda and use the term.
It doesn't make any sense because it's propaganda. It's an industry-promoted lie.
Region coding has nothing to do with copyright. It is 100% about market control.
Just like copy protection has nothing whatsoever to do with copyright, yet the industry calls it "copyright protection" in an effort to confuse the two in the public mind.
God, I spent weeks studying that instruction, trying to figure out how to out it to work. IBM put out an entire BOOK on that instruction. It's basically a huge chunk of microcode that emulates a small piece of the VM kernel. It's pretty much useless for hacking/play purposes, unless you want to design around the instruction.
:)
I had better luck playing with the vector instructions. I had a very fast fractal generator
You wouldn't even need to do that. Say your failed radius server was named RADIUS. You would type, from the operator console,
force radius
autolog radius
and you would get the same effect as a power cycle on a standalone machine, but without the time wasted on hardware and memory self-tests, SCSI bus initialization, etc. You go straight from the autolog command to kernel initialization instantly, so you could be back up and running in a few seconds, depending on how long it takes for linux to start up and your radius server to initialize.
It would depend on what you were doing on that machine. There are at least two cases where Linux under VM will probably beat out native Linux.
o) You have an application that wants to spin off a large number of separate tasks. Your Linux kernel will not perform well under these circumstances, but if you built a virtual beowulf cluster of many Linux images, each running four or five active tasks per image, then each Linux image will run smoothly and efficiently -- within its design parameters.
2) You want to run a task that requires a huge address space -- far exceeding your real memory.
First off, things aren't so bad, because by using a shared segment, VM can use one shared-memory copy for all of those Linux kernel images, saving a lot of memory.
Also, mainframes can page so efficiently that they can massively overcommit memory without taking a performance hit. They were designed for this. The normal configuration of a VM system is thousands of users at terminals, each with their own virtual machine, running CMS. Each virtual machine might have two or three megs of shared program code, and however much private data they happen to be using at the moment. VM was designed to support a massive overcommittment of memory. Mainframes even have special paging storage, called expanded storage, and a set of hardware instructions for performing quick paging back and forth between real and expanded storage. Think of it as a fast ramdisk, attached right to the CPU bus.
The end effect is that you can actually get an improvement in performance by turning off your own paging, and relying on VM's native paging facilities. MVS sites discovered this years ago.
Say you want to provide 2 gigs of storage to an application, but your mainframe has only 1 gig of memory, you would have two options:
1) Allocate about 1 gig to the Linux image, and create paging space within Linux. The Linux kernel handles all the paging.
2) Allocate 2 gigs to the Linux image, so that Linux never has to page, and let VM handle the paging.
You'll get better performance using method 2.
The biggest strengths of mainframe designs go right to the heart of your objections. It's what VM was designed to do, and it does it very well.
Another reason to run a cluster within a single machine is to circumvent bottlenecks within Linux. If you have an application that insists on forking off dozens and dozens of tasks, you will start to run into the Linux scheduling algorithms, which are performance-optimized for a small number of tasks.
If you create multiple Linux images using the zero-latency networking capabilities that VM gives you, you can split up your application until there are a small enough number of tasks per Linux image to run smoothly.
Another good reason is, as AC says, if some users need root access for some reason. You can set up a system as a virtual machine, give them root access to that image, and nothing they can do will affect any other virtual machine in the system. Great for testing new Linux kernels. In fact, VM was designed specifically for this purpose -- except that it was used to debug new OS/390 (MVS) kernels instead.
Right. VM has shared memory across virtual machines. Even though there are 41,400 images of Linux, there need be only one copy of the code in storage, shared by all of those virtual machines.
If one of those virtual machines were to attempt to write to a memory page, CP would simply fork off a private copy of that page, and continue on.
I believe that Linux (and most unixes) do the same thing -- one read-only copy for each currently running executable, shared between all processes running that executable.
I'm not involved in this work; I wish I was. However, I'm very familiar with VM/ESA and the low-level programming facilities that are being used to pull of this 41,000 Linux virtual machine cluster. I used to write assembly language programs that used IUCV and virtual CTCAs, and what they are doing is crystal clear.
First off, this setup is running under VM/ESA. This is NOT the same operating system as OS/390. Diehard VM'ers tend to view OS/390 about as fondly as Linux users view Windows. OS/390 is the huge, IBM-management-approved operating system with JCL, that evolved out of OS/360. VM is the back-room project that IBM management has tried to kill, over and over, but can't kill, because it's needed for OS/390 development, IBM developers demand it, and many customers demand it. OS/390 is what management wants to sell -- it's the "strategic" operating system. VM/CMS is what the IBM development teams use because it was designed, from the bottom up, by IBM's best software developers, specifically as a platform for software development. Really. I used it for 15 years. If you're developing or debugging IBM assembly code, it's just the best. VM was a skunkworks project, and a damn fine one. It's a shame that it isn't that well known.
The two operating systems should NOT be confused. Different operating systems. Entirely. OS/390 can run as a guest under VM/ESA, but not vice versa.
That said, VM has a HORRIBLE native TCP/IP implementation. It's a big program, written in Pascal, and it's a dog. In fact, it's about the weakest part of VM. It never got much attention, because mainframe networking has always been driven by SNA, VTAM, etc. and IBM development is traditionally done on a 3270 style terminal. All the tools, XEDIT, the mail system, etc, are all designed for 3270, block mode terminals. VM is lacking in TCP/IP support for the same reason that Unix systems are lacking in SNA support, because no one wanted it. This is changing.
The VM TCP/IP implementation is a standalone program. The TCP/IP program runs in its own virtual machine. When someone wants to connect to TCP/IP, they use a system call to establish a connection between their virtual machine and the TCP/IP virtual machine using a facility called IUCV -- Inter User Communication Vehicle.
IUCV is a very fast, block-oriented, secure, unspoofable point to point protocol for establishing data links between virtual machines. A programmer using IUCV starts by creating a link to the target, then sends blocked data by making a system call with the address/length of the data. The CP nucleus (their word for the kernel) copies the data into the system address space, synthesises and schedules an interrupt for the target virtual machine, and immediately reschedules the source virtual machine. The target virtual machine receives the interrupt, issues an IUCV receive system call, and CP copies the data into the target machine address space. This is all done completely asynchronously. It's extremely fast, and utterly secure. Zero-latency networking is a nice thing to have.
Which leads to something very cool. IP over IUCV.
I don't know exactly how they set their system up, but here are the basic tools that they have to work with:
1) TCP/IP to the outside world can be handled in at least two ways:
o Through a native Linux network device driver. In VM, physical peripheral devices are assigned to individual virtual machines. A virtual machine with a physical network interface attached to it simply uses it as an ordinary I/O device.
o Via a connection to a native TCP/IP virtual machine, using a special device driver that knows the native IP-via-IUCV protocol.
2) Connections between virtual Linux machines can be handled in a couple of ways:
o through a virtual (or real) CTCA (Channel to Channel adapter.) a CTCA is a high speed parallel interface used to connect mainframes together, point to point, very fast. If you use virtual CTCAs, you can move Linux images from one machine to another without having to ever reconfigure anything within the Linux images themselves simply by replacing the virtual CTCAs with an attached real CTCA and changing the directory entry of the virtual machine.
o Using an IUCV driver, one can interconnect all of the internal Linux images via virtual point-to-point lines. This is much faster then virtual CTCAs. The drawback being that you need to configure IUCV links within a virtual machine, so changing things around requires reconfiguration within the linux image itself, and IUCV is designed to work efficiently within a single system, not across multiple systems. It can be done, but it's a hack, and it's inefficient.
o Through an obsolete API called VMCF, which was superceded by IUCV.
The big innovation going on here is the realization that by running multiple Linux images on a single machine, or multiple Linux images on multiple machines, using mostly IUCV links, one can almost eliminate the network latency, because the data transfers are simply memory copies, and one can eliminate the network collision problem, and the network traffic problems. If you have 100 machines sitting on a fast ethernet, and you start getting a lot of inter-machine traffic, you are going to have collisions, and each machine has to waste a fair amount of time evaluating which packets are his. This removes the biggest bottleneck in large clusters of small machines, Also, an IUCV connection is guaranteed to never drop a packet, and always transmits packets in order, so TCP over IUCV proceeds smoothly and efficiently.
This gives you lots of scaling options for your virtual Linux network.
One more point.
There was an article that came out two days ago, but due to a slashdot bug never appeared on the main page, but proceeded directly to the "older news" catagory. In it, the author wrote:
An S/390 running a light load will not run as quickly as a fast PC server under a light load, according to Courtney. The difference between the two systems will not be apparent until the load is much larger.
"The PC will begin to degrade and will typically reach a point where it avalanches down in performance as its load limit is exceeded. The mainframe starts out at a lower performance level, from the standpoint of an individual program task, but degrades much more slowly and much more linearly as the load increases," he says.
Revisiting my previous comment in this thread, I remember, a while ago, reading in another article about a difference of opinion between some IBM programmers and the kernel maintainers. Supposedly, IBM was complaining that Linux performance went south when the number of running tasks became large, and proposed some scheduler changes, but the kernel developers didn't want to change it because the changes would have slowed the kernel down in the "normal" case of only a few active processes. Does anyone have a link to this or remember what I'm talking about?
Sounds like this article is describing the same known effect. However, by running multiple images of Linux under VM, one obtains a workaround for the problem. If a Linux virtual machine is overloaded, create a new virtual machine image, and offload one or more of the biggest processes to run on the new machine.
This is all very interesting stuff. Don't forget, the stuff we're just discovering now in the Linux world, is largely stuff that the IBMers, and especially the VMers have been working on and perfecting for about 30 years. I'd love to see a Linux kernel that can run 41,000 tasks, with a linear performance degradation curve. Until then, at least there is a way to run Linux on an operating system that has those characteristics.
And the fact that their operating system can run 41000+ simultaneous tasks without disintegrating, but ours can't, should eventually get under someone's skin and prompt efforts to make the Linux kernel scale better under heavy multitasking loads. Why should they have all the fun?
- John