Hydrogen as a fuel is often pushed by tree-huggers with arts degrees as being a panacea, a clean source of energy. It's not. Like a rechargeable battery, it's merely a tool to store energy.
The energy to split the hydrogen out of compounds must be coming from somewhere. How do you do it? Primarily with existing electric generation techniques - coal, nuclear, hydroelectric dams... there's no free lunch, and solar, wind, wave power have yet to demonstrate economic or even environmental viability despite Greenpeace and David Suzuki jumping up and down telling us to use them.
Two points:
While it's factually accurate that hydrogen is primarily an energy storage medium and not a generation technology, your use of derogatory terms such as "tree-huggers" and "people with arts degrees" simply diminishes your argument.
Fossil fuels are a finite resource. As they grow scarce fossil fuels energy rates will rise beyond the price of wind/solar/hydroelectric/geothermal/tidal/nuclear. At this point it will be cheaper to extract the hydrogen via electrolysis or steam powered by electricity rather than converting directly from fossil fuels.
Whether hydrogen is the best available energy transport medium for vehicles and home heat remains to be seen. It appears that the Bush administration has set a policy goal of developing the vehicle technology and creating the necessary fueling infrastructure to support hydrogen at the pump. This is the important decision since it will affect transportation policy for the next hundred years or more. How we convert available energy to hydrogen is a moot point until the rest of the infrastructure has been developed. Though I would argue that traditional green technology will likely be cheaper long term than traditional light water nuclear, and we're quickly nearing the inflection point whereby fossil fuels will be uneconomical for hydrogen conversion due to scarcity.
A good argument could be made for biodiesel as an alternative to hydrogen. But that Bush made a decision, any decision, toward a new fueling infrastructure long term is a good thing.
Not being an attorney I'll defer if you so wish to claim you are one, however:
1) SCO's claim is breach of copyright. Your trade secret point is thus irrelevant.
2) You seem to be saying that the owner of a copyright would have the burden of proof in its claim that said code was released inadvertently, and is thus not covered under the license upon which it was released. I'm not sure if this is reasonable or not, honestly, but I do think that if the owner can provide reasonable evidence that an employee acted without authority when releasing the code, the license on which the employee released would be null and void. At least that's the outcome I would expect. Certainly a buyer of stolen goods doesn't expect relief from the original wronged party, it's the thief who is responsible.
3) Note that when discussing licensing I'm being explicit in limiting the discussion to duplication rights, which do have a long history WRT copyright law. That is, there is long standing precedent which allows the copyright holder to stipulate restrictions for duplication rights; this is what the GPL does. However, if due to special circumstances the licensing contract (GPL) is termed invalid, does that not mean that the recipient has no duplication rights whatsoever? Isn't the result the same?
So we get a best case for SCO, where they prove their case anc get a total legal victory and are unable to collect damages from anyone other than IBM. And IBM can keep the case on appeal until sometime after the final trump blows so they get no money and end up bankrupt.
I previously wrote:
Should it turn out that some small portion of the kernel contains illegally expropriated code copyrighted by SCO, then rip it out and recode ASAP. Remove the illegal code from all previous copies in the masters and mirrors. Minimize the damage once it's discovered and plead to the judge that the principal authors didn't and couldn't have known. Point out that the plagiarizing author, the one who submitted whatever infringing code in bad faith, should be the responsible party. Let SCO sue that infringer, the person who willfully broke the law, and then let it drop. SCO winds up with little or no money, the principal authors keep their good name and reputation, and Linux continues on it's merry way.
SCO seems to be forgetting, they can indemnify their users against the use of SCO IP, but they cannot do that with all the rest of the linux code, which is legitimately GPLed. As if only their IP is of concern.
I agree with this. They can't both knowingly release the proprietary code falsely under the GPL, while also indemnifying their customers from copyright infringement from using their proprietary code. Though they could release it under a dual GPL and proprietary license, this wouldn't have the desired efffect.
If their code derives from a previously GPL'd application they must either GPL their code or stop distribution. If someone elses code under the GPL which illegally derives from their code, they must inform the infringer(s) and take legal action to safeguard their IP. They cannot have it both ways. --M
Corporations are artificial entities: they can have no more actual "knowledge" than can my coffee maker. However, if the employee who released the code had so much as "apparent" authority (i.e., wrt to outsiders relying on the act) then its tough beans for the corp.: It's GPL City. What constitutes apparent authority may vary from case to case but if releasing software under open licenses (or otherwise) is what the employee generally does, or if the corp. lacks any diligence in preventing/detecting/remedying the problem, or if the reliance and detriment to outsiders is great, the corp. is going to have a long long row to hoe in order to get any relief from a corp. Contractual mistakes are often made but relief therefrom is seldom granted.
I think you're mistaken. There are two separate fallacies here:
a) That because a corporation is an artificial entity it lacks legal relief from employee theft. This is clearly not the case. I suggest you try lifting office supplies in front of your boss sometime for further proof.
b) Your second point presumes that the employee who released lib 'a' as a GPL's library had the authority to do so. I never said he did. In fact, I assume that the employee had no right to release any code whatsoever, as would normally be the case with any company creating a propritary application.
While a corporation may not have "knowledge" or any sense of "conscious awareness" like a human being, it's policies are set by a board of humans who's policies are acted upon by management (other humans). Without an explicite directive from management, who have due authority given to them by the board of directors, an employee would have no right to set arbitary Intellectual Property policies or act of their own accord to release Intellectual Property (or any other type of property).
So, are you saying that a company should lose their property in the event that an employee releases proprietary code, without corporate permission, and that code now in the wild winds up included in a GPL'd app which his/her company happens to distribute? Does that mean the previously propritary code is now covered under the GPL even though the IP holder doesn't indend this to be so? Is this a proper outcome for copyright law? I certainly don't think so.
"[Huges] had this to offer about the GPL and SCO: "The GPL, by its terms, only applies to software programs or works which contain a notice "placed
by the copyright holder saying it may be distributed under the terms of this General Public License. (emphasis by him)"
This is perfectly reasonable. We're all so pissed of at SCO that we forget to think of the potential consequences of taking this line of thought to its logical conclusion. Rip SCO out and reconsider this statement:
I own a company which writes a proprietary application sold to the public. It contains lib 'a' which is used for manipulating the general class of 'foo', something very useful. One of my employees releases the lib 'a' source under the GPL without corporate knowledge or acquiescence. This is then incorporated into several other GPL'd applications, one of which we happen to distribute without knowing that a part of this application contains our source. Is lib 'a' now covered under the GPL because of our mistake?
I certainly hope not. I doubt this would be rms's or the FSF's attorney wish either. Such a conclusion goes against the grain of allowing the copyright holder to designate contractual licenses limiting duplication rights. Note that I don't say right to use, but basic duplication rights. The eventual outcome of that would be a loophole which could dilute basic copyright law; the very foundation of the GPL.
Whatever of SCO's code that may or may not be in the generic Linux Kernel, it's perfectly clear that only the owner of a copyright may specify the contractual terms of licensing. Simply put, if someone other than the owner contributed code which was accepted into the kernel tree (or distributed said code as a patch), the owner shouldn't be held to account for having also distributed their own code by accident; code which they didn't knowingly or purposefully contribute.
Screwing SCO on a 'gotcha' because they continued to distribute the Linux kernel after they filed the lawsuit may seem like just deserts, but long term it could have damaging consequences to the Free Software community after the fact. We should instead be looking for prior examples of development and ownership for everything SCO claims copyright over. If everything they claim can be proven factually false, their case dies a just death. The way to win is to show that SCO has no legal basis for claiming copyright infringement: that they, as SCO, never created whatever code they claim as theirs is in the Linux kernel; nor could they have since the historical timeline clearly shows developments by a wide range of authors who have no connection to IBM, HP, or SCO (or Project Monterey, SCO OpenServer, and/or UNIXWare). Kill their idiotic suit with facts and they will shut up and die already.
Should it turn out that some small portion of the kernel contains illegally expropriated code copyrighted by SCO, then rip it out and recode ASAP. Remove the illegal code from all previous copies in the masters and mirrors. Minimize the damage once it's discovered and plead to the judge that the principal authors didn't and couldn't have known. Point out that the plagiarizing author, the one who submitted whatever infringing code in bad faith, should be the responsible party. Let SCO sue that infringer, the person who willfully broke the law, and then let it drop. SCO winds up with little or no money, the principal authors keep their good name and reputation, and Linux continues on it's merry way.
I used to leave all sorts of machines running 24/7 in my apartment. Several Suns, a couple PCs running Linux and BSD, an SGI, blah blah blah. I did take care to turn monitors off though. I kept this up until I turned off all my systems (except the mail server) for a two week vacation: I was shocked to discover the next electric bill arrived a good $80 cheaper. I've since cut back to a single machine which I turn off at night. No more crazy uptimes, but honestly - I'll take the money. I wish there was consumer demand for low power destop computing. I guess I'll just have to migrate to a good laptop for the low power option. But you're absolutely right: a few computers can suck up a lot of power, with damaging results to one's electric bill. --M
...But retained the SCO name for marketing purposes. --M
hypothetical totally irrelevant
on
OSI vs SCO
·
· Score: 2, Insightful
My argument is that people are currently running around and claiming that this is pretty much a cut and dried case, and SCO has lost already. "There is no SCO code in Linux. Even if there was, SCO distributed Linux, so the code in question is under the GPL. QED" is the basic argument. Even ESR is using it now.
Wow. I just finished reading the entire paper and I didn't read into it anything of the sort. He most certainly did NOT say that because Caldera released Caldera Network Desktop and Caldera OpenLinux that whatever SCO codebase may or may not be in the Linux Kernel is somehow covered under the GPL. You're mixing up the timeline of ownership such that it obfuscates Caldera's direct contributions to the Linux kernel as part of their business plan.
Let's review some basic UNIX history:
- early '80s: SCO bought the rights to Unix V. 7 from AT&T and developed XENIX (one of many x86 UNIX derivatives), with Microsoft as a partner.
- Across the '80s many other developers developed UNIX on Intel, as well as UNIX on other chip platforms such as 68K. This includes Sun, SGI, HP, Sequent, IBM, etc etc etc.
- The trademark for "UNIX" was sold to X/Open in the early '90s. X/Open then renamed themselves "The Open Group". They still own the trademark.
- In '91 Linus released the first Linux Kernel to the hacking community. He wrote this on his own and is a derivative of nothing other than his own work.
- In '93 Novel purchased USL (AT&T)s stake in the UNIX codebase.
- In '94 Berkeley and AT&T/USL settled an ongoing copyright infringement lawsuit over the rights to those portions of the BSD codebase which contained original AT&T Version 7 code. A few files in BSD were removed, rewritten, and then BSD was rereleased as BSD-4.4Lite. (This had nothing to do with Linux).
- By '95 Caldera was actively contributing source code to the Linux Kernel, along with dual CPU hardware, to further community development of a product line they were actively engaged in selling. All of this code was released under the GPL with full knowledge and intent of management as part of their business plan.
- in '95 Novel purchased the rights to the original UNIX codebase from USL
- By '96, when Kernel 2.0 was released, Linux had basic support for SMP in the kernel.
- In '98 Novel sold the UNIX codebase to SCO (previously SCO had only a source license from AT&T). SCO, IBM, and others began Project Monterey to unify an single UNIX source tree among many hardware vendors.
- In '99 - 2000: Kernel 2.2 was released which included many new SMP features. By this time independent of project Monterey Linux developers were coding in beta their own journaled filesystems, Logical Volume support, clustering failover, and very early NUMA support.
- 2001: SCO split into Tarantella (a web services company) and the original SCO name w/ original AT&T UNIX tree. Along with this was the original SCO Openserver codebase and UNIXWARE. Linux had by that time far surpassed UNIXWARE in SMP scaling, along with most other enterprise features, and all of this had happened before IBM invested in Linux and dumped project Monterey.
Thus, one sees from the history of Linux development, all relevant "enterprise" features were developed independent of IBM and the project Monterey codetree. The assertion that "SCO released code which accidentally made it into the kernel tree" and "loosers weepers" is completely irrelevant to the facts at hand. None of that happened, thus the hypothetical doesn't matter.
ESR makes all of this perfectly clear in his position paper.
Cheers, --Maynard
How about being a bit more specific
on
OSI vs SCO
·
· Score: 1
Yes that is true, and my argument still stands; this is a legal grey area where their IP may or may not now fall under the GPL even though they unknowingly distributed it. If SCO were to claim that they did not agree to the GPL in full then that is a seperate action that Linus and the other copyright holders must undertake against SCO for infringment.
Since prior to the acquisition of SCO by Caldera, SCO never contributed to the Linux kernel or released any code under the GPL (that I am aware of), why not limit the discussion thusly:
- Any code or file released by Caldera and accepted by Linus into the kernel tree with the copyright notice "Copyright Caldera Corporation, All rights reserved. This file is released under the General Public License..."
Is deemed released on purpose, retains its license under the GPL, and cannot be used ex-post-facto for tort under copyright or breach of contract law.
I think you underestimate the render extensions. Why generate Postscript, which is interpreted and in turn writes to a canvas, when you can write to the canvas directly?
Because writing directly to the canvas implies you're writing to the local framebuffer, which tosses the whole point behind network transparency. Device independent rendering and display side server applets are the two things that DPS does really well. Of course, that doesn't mean that a toolkit will necessarily use those features, but it's a cool thing to have available. X is FUBAR'd at the protocol level because of how it handles event processing (just one of many reasons), so no matter what one does above at the toolkit level it will always be a network hog. There were more elegant solutions before Project Athena released X fifteen years back. Adding a new toolkit layer simply won't resolve this fundamental brokenness - even if it has access to all the cool framebuffer features through RENDER. Though I agree that DPS is a somewhat overly complex protocol, it can do stuff simply and elegantly that X can't even come close to doing even after jumping through multiple layers of rendering and toolkit libs hoops. JMO.
I'm sure they could take advantage of the RENDER extension, but I don't really see the advantage of a whole Postscript interpreter under there.
One of the big advantages to DPS and DPDF is the device independence in rendering text and other objects. That is, it's truly WYSIWYG - what's rendered on the screen is exactly what will be rendered to print (or any other device). For DPS you also have the option of writing applet procedures which run on the display server, similar to the old Sun NEWS system. So, for example, one could write a terminal emulator in postscript and have it run in the display server, thus reducing network load by cutting out most of the transmission of event processing between client and server during a remote display session. This solves the biggest complaint about network transparent X sessions, that being it's a network hog and has terrible latency.
X is fine for what it does - especially given the price - but it saddens me to no end to see the DGS render extension die because no one seems to care, while at the same time everyone bitches about slow old X. GnuStep with Display Ghostscript would certainly have been a better solution than completely rewriting a new display server and the rewriting the windowing environment all over yet again.
So now someone is selling cool new desktop that will never cross the threshold of users necessary to replace X, while others keep dumping more intellectual energy in bogus free X desktops that 'kindof' work. How many times have we done this? How many widget toolkits does X really need? Athena, Motif, TK, QT, GTK... on and on and on. None of them work well together, everyone needs applications that cross toolkit boundaries, and users are left completely in the dark on how to do the simplest thing like cut and paste non-text between applications. Wasn't Simpson Garfinkle bitching about just this in the UNIX Haters Handbook ten years ago?!?!? And everyone laughed because it was true while nothing changed. Feh.
We're long past the point where the history of X, and ridiculous backward compatibility, is impeding growth toward something new and better. Gnome and/or KDE ain't the solution. Nor is GnuStep rendering through xlib. Feh, what a mess.
I fiddled with both FreeSWAN and the OpenBSD implementation of IPSEC. Trying to get them to interoperate was a total nightmare, primarily because of the differing key exchange protocols. At the time I wanted to use OpenBSD server side because it supported hardware crypto cards while Linux didn't, which is now a non-issue with current Linux kernels.
I still think that straight IKE (Internet Key Exchange) is a better method of handling key exchange than DNS - it just seems like we're adding too many unrelated record types to DNS, which is leaving us with a mess of clients/servers that can and cannot understand certain records. The AFS folks have done the same thing, yet I don't see AFS records in DNS maps all over the place. One point I'll make about this, we used to have hesiod records in our DNS maps which we had to rip out when we last upgraded BIND because it didn't understand the record type and would puke and die on startup. DNSSEC only makes the problem worse - unless everyone agrees to support the new record types and upgrades.
OTOH: automagically performing a key exchange and then setting up a transport mode point to point IPSEC exchange is a very cool thing! Most people think IPSEC is about tunneling whole IP networks within the IPSEC protocol, but ubiquitous transport mode is really the holy grail of IPSEC. Basically it allows one to encrypt any TCP/UDP stream without regard to the underlying port side protocol - thus making ssh, httpssl, ftpssl, etc redundant. Telnet, ftp. http, etc suddenly becomes secure by default without the user having to do or know a damn thing! This is a far more elegant general purpose solution than the variety of encryption schemes we use today, each with their own idiosyncrasies, potential security holes, and command line switches.
I have an HDTV. I live in the Boston area, so I am lucky in that every one of my local broadcast stations are currently broadcasting a digital signal, which include NBC, ABC, CBS, FOX, WB, UPN and PBS. CBS broadcasts almost their entire evening lineup in HD. ABC and NBC broadcast their most popular programs in HD. The second/third tier networks either broadcast widescreen 480p or the occasional HD program. After going through the trouble of installing an antenna on my roof I'm getting all the channels without signal loss or artifacting.
I also have DirecTV and have recently tried Comcast HD service. Here's the lowdown:
Dealing with Comcast CS was like pulling teeth without anesthetics, they had no idea what they were selling and misrepresented the service when I was finally forwarded up through the CS clue-chain. When the installer came out they cut my Internet connection by accident. When I finally cancelled out of disgust, a service rep came and installed a filter on my Satellite line! And yes, it was a straight run from the dish to my TV, the filter being placed right next to the dish. Asshole.
Both DBS and cable offer HD Showtime and HBO, though Comcast also offered a select few local channels in HD. DBS continues to be significantly cheaper per month for far more SDTV channels, though the premium stuff is priced about the same. DirecTV also offers HDNet, which broadcasts a good deal of sports and the occasional HD transfer of Hogan's Heros. Can't wait for I Dream of Jeannie. DBS currently offers no local HD channels.
Comparing image quality of broadcast vs. Cable shows a significant decline in image quality with Cable. DBS doesn't offer local channels in HD yet, but it too suffers from over-compression problems. I assume this is because of higher compression... I think the cable companies are using a 6Mb stream compared to a 14Mb stream over PBS and full 19Mb stream for CBS. You really notice the difference. Since DBS has the same compression issues, HBOHD/ShowtimeHD have about the same image quality over DBS as cable.
Showtime and HBO are just that. The programming isn't that exciting, though getting recent Soprano's in HD is pretty nice. One positive for Showtime is that they actually letterbox 2.85:1 films instead of mauling the film to 1.85:1 like HBO.
In short, putting up a good antenna on your roof ensures the best image quality possible. If you care about HBO/Showtime you might want to consider DBS or cable, I personally would recommend DBS over cable at the moment for both price/performance and CS quality. Finally, HDTV is good.:)
>>Last I heard, the redhat cds contained proprietary software.
>That's not true, and has never been true.
Yes they did. For example, Redhat 4.x shipped with a commercial X server, Metro X and BRU backup tool. They also had a distribution which included Motif development libraries, as well as a secondary product line which included just the runtime libs as well as the runtime and development libs. Redhat 5.x continued shipping Metro X, but not BRU if I remember correctly. This policy was primarily a response to Caldera's bundling commercial software with the original Candera Network Desktop and Caldera OpenLinux productline. Not that Redhat Linux does bundle commercial software with the product - I haven't seen it so I can't comment on that. However, Redhat most certainly did bundle commercial applications with their product line at one point in time. --M
DPS is indeed part of XFree-4.3. But as you point out, the main sourceforge DPS site has announced that it is obsolete due to the X Render extension. This is a real shame as DPS does stuff far more elegantly than X Render and is of extreme importance to the GNUStep project. *sigh* --M
You personally may not care about that, but there's a huge number of people who do. You may not like supporting MS, but if you're a gamer then that $90 'tax' is not entirely a bad thing.
Those who want or need Windows have a plethora of vendors available to choose from. Enjoy! My point was that it's 'Great news!' that someone was finally selling a laptop without Windows bundled with the hardware, because there are many folks who have no use for Windows and better use for the money Microsoft (bundled through the vendor) charges. Frankly, I resent being forced to pay for something I don't use and don't want, and as such I consider it a 'tax' every time I must pay for a thing that's bundled with something I do need. I'm glad that a company is finally catering to my desire for a product sans the cost of Windows and hope they succeed with their business plan. There's nothing in my statement which suggests that those who prefer to purchase Windows should be prevented from making their choice. --M
Wow, you just don't stop, do you? I - duh - have better uses for my money. How I use my money is irrelevant to the discussion beyond the fact that I would prefer not to be forced into purchasing Windows every time I buy a laptop. You want to buy Windows? More power to you. Do not share and enjoy! --M
What I'm saying is: "You might save $90, but you lose more than you think."
Guess that all depends on what one uses their laptop for, huh? I seem to remember the term "Windows Tax" going back to 1994, and I certianly wasn't the originator. In my situation being forced to pay for Windows is most certainly a tax I don't need. --M
This is the first time I've seen anyone offer a laptop sans OS. $789 looks to be a good deal for the hardware, and I think most of us would have no trouble installing our favorite Linux or BSD distribution. This can only be construed as GOOD NEWS! Finally, a laptop without the Windows tax! (and reasonably cheap too) --M
...So if I want to run linux, I'm effectively paying $200 for GNU software. I don't quite understand how that works within the GPL. Please explain it to me.
All you need do is ask Sony for their source diffs and cross compile for MIPS. See? They follow the letter of the GPL and you're left wasting a bunch of time figuring out how to boot the sucker. Good luck! --M
I really disagree. No AFS implementation I've seen is useable for enterprise-quality network filesystems because none can handle files larger than 2 GBs.
...but on Intel you're limited to a signed 32bit (2GB) filesize anyway (which I agree makes Linux thoroughly broken for all sorts of useful stuff). The OpenAFS folks are working to resolve that problem, so it should go away soon enough. And the system management advantages of AFS over everything else out there outweigh that little problem. Honestly, show me another rock solid network filesystem which allows for live volume migration from server to server, multiply redundant RO volumes for failover, kerberos security, and encryption over the wire. It's good stuff. --M
If you move video drivers into the kernel then you risk kernel stability!
The big controversy was Microsoft moving GDI and other aspects of the windowing system into kernel space, not physical device driver support. I'm talking about initializing the physical device and managing video device registers, blitting, etc. in kernel space, while userspace apps (or better, a general purpose library) use traditional system calls to handle userspace communication to the device. This was hashed out repeatedly long ago (with many flame wars ensuing) on the lkml. Unfortunately it was a good idea that never happened.
Think about it like this: you wouldn't want your IDE device driver running as a deamon with root privs in userspace, would you? So why should your X Server do the same? Why should you have ten different X servers tailored to every popular video card on the market? Have you ever switched from an X session to a virtual terminal only to see your console completely hosed? I can't count the number of times I've seen this and wondered 'Why the fuck hasn't this been fixed yet?!?!?!' XF4.x with its modular device drivers notwithstanding, this is still a serious issue.
Managing hardware recognition, initialization, and physical attributes in kernel space is cleaner than having a bunch of usespace apps doing the same in ways that are almost certainly mutually exclusive. It's supposed to be the kernel's job to handle simultaneous contention for a device between various apps. That was the point behind GGI, and is currently the point behind the Linux kernel Frame Buffer support. Unfortunately, Frame Buffer device drivers are horribly out of date so people just use X instead.
Of course, this is JMO and many people (including Linus at the time) completely disagreed many years back. I, however, think the GGI folks were completely right and wish Linus had given their ideas a better chance at kernel inclusion. OTOH, you don't see my name in the kernel tree and there's a good reason for that: I'm not qualified. So take my opinion with a grain of salt.:)
Slashdot Mirror
- While it's factually accurate that hydrogen is primarily an energy storage medium and not a generation technology, your use of derogatory terms such as "tree-huggers" and "people with arts degrees" simply diminishes your argument.
- Fossil fuels are a finite resource. As they grow scarce fossil fuels energy rates will rise beyond the price of wind/solar/hydroelectric/geothermal/tidal/nuclear
. At this point it will be cheaper to extract the hydrogen via electrolysis or steam powered by electricity rather than converting directly from fossil fuels.
Whether hydrogen is the best available energy transport medium for vehicles and home heat remains to be seen. It appears that the Bush administration has set a policy goal of developing the vehicle technology and creating the necessary fueling infrastructure to support hydrogen at the pump. This is the important decision since it will affect transportation policy for the next hundred years or more. How we convert available energy to hydrogen is a moot point until the rest of the infrastructure has been developed. Though I would argue that traditional green technology will likely be cheaper long term than traditional light water nuclear, and we're quickly nearing the inflection point whereby fossil fuels will be uneconomical for hydrogen conversion due to scarcity.A good argument could be made for biodiesel as an alternative to hydrogen. But that Bush made a decision, any decision, toward a new fueling infrastructure long term is a good thing.
JMO,
-Maynard
Not being an attorney I'll defer if you so wish to claim you are one, however:
1) SCO's claim is breach of copyright. Your trade secret point is thus irrelevant.
2) You seem to be saying that the owner of a copyright would have the burden of proof in its claim that said code was released inadvertently, and is thus not covered under the license upon which it was released. I'm not sure if this is reasonable or not, honestly, but I do think that if the owner can provide reasonable evidence that an employee acted without authority when releasing the code, the license on which the employee released would be null and void. At least that's the outcome I would expect. Certainly a buyer of stolen goods doesn't expect relief from the original wronged party, it's the thief who is responsible.
3) Note that when discussing licensing I'm being explicit in limiting the discussion to duplication rights, which do have a long history WRT copyright law. That is, there is long standing precedent which allows the copyright holder to stipulate restrictions for duplication rights; this is what the GPL does. However, if due to special circumstances the licensing contract (GPL) is termed invalid, does that not mean that the recipient has no duplication rights whatsoever? Isn't the result the same?
Cheers,
--Maynard
If their code derives from a previously GPL'd application they must either GPL their code or stop distribution. If someone elses code under the GPL which illegally derives from their code, they must inform the infringer(s) and take legal action to safeguard their IP. They cannot have it both ways. --M
a) That because a corporation is an artificial entity it lacks legal relief from employee theft. This is clearly not the case. I suggest you try lifting office supplies in front of your boss sometime for further proof.
b) Your second point presumes that the employee who released lib 'a' as a GPL's library had the authority to do so. I never said he did. In fact, I assume that the employee had no right to release any code whatsoever, as would normally be the case with any company creating a propritary application.
While a corporation may not have "knowledge" or any sense of "conscious awareness" like a human being, it's policies are set by a board of humans who's policies are acted upon by management (other humans). Without an explicite directive from management, who have due authority given to them by the board of directors, an employee would have no right to set arbitary Intellectual Property policies or act of their own accord to release Intellectual Property (or any other type of property).
So, are you saying that a company should lose their property in the event that an employee releases proprietary code, without corporate permission, and that code now in the wild winds up included in a GPL'd app which his/her company happens to distribute? Does that mean the previously propritary code is now covered under the GPL even though the IP holder doesn't indend this to be so? Is this a proper outcome for copyright law? I certainly don't think so.
--Maynard
Whatever of SCO's code that may or may not be in the generic Linux Kernel, it's perfectly clear that only the owner of a copyright may specify the contractual terms of licensing. Simply put, if someone other than the owner contributed code which was accepted into the kernel tree (or distributed said code as a patch), the owner shouldn't be held to account for having also distributed their own code by accident; code which they didn't knowingly or purposefully contribute.
Screwing SCO on a 'gotcha' because they continued to distribute the Linux kernel after they filed the lawsuit may seem like just deserts, but long term it could have damaging consequences to the Free Software community after the fact. We should instead be looking for prior examples of development and ownership for everything SCO claims copyright over. If everything they claim can be proven factually false, their case dies a just death. The way to win is to show that SCO has no legal basis for claiming copyright infringement: that they, as SCO, never created whatever code they claim as theirs is in the Linux kernel; nor could they have since the historical timeline clearly shows developments by a wide range of authors who have no connection to IBM, HP, or SCO (or Project Monterey, SCO OpenServer, and/or UNIXWare). Kill their idiotic suit with facts and they will shut up and die already.
Should it turn out that some small portion of the kernel contains illegally expropriated code copyrighted by SCO, then rip it out and recode ASAP. Remove the illegal code from all previous copies in the masters and mirrors. Minimize the damage once it's discovered and plead to the judge that the principal authors didn't and couldn't have known. Point out that the plagiarizing author, the one who submitted whatever infringing code in bad faith, should be the responsible party. Let SCO sue that infringer, the person who willfully broke the law, and then let it drop. SCO winds up with little or no money, the principal authors keep their good name and reputation, and Linux continues on it's merry way.
JMO,
--Maynard
I used to leave all sorts of machines running 24/7 in my apartment. Several Suns, a couple PCs running Linux and BSD, an SGI, blah blah blah. I did take care to turn monitors off though. I kept this up until I turned off all my systems (except the mail server) for a two week vacation: I was shocked to discover the next electric bill arrived a good $80 cheaper. I've since cut back to a single machine which I turn off at night. No more crazy uptimes, but honestly - I'll take the money. I wish there was consumer demand for low power destop computing. I guess I'll just have to migrate to a good laptop for the low power option. But you're absolutely right: a few computers can suck up a lot of power, with damaging results to one's electric bill. --M
...But retained the SCO name for marketing purposes. --M
Let's review some basic UNIX history:
- early '80s: SCO bought the rights to Unix V. 7 from AT&T and developed XENIX (one of many x86 UNIX derivatives), with Microsoft as a partner.
- Across the '80s many other developers developed UNIX on Intel, as well as UNIX on other chip platforms such as 68K. This includes Sun, SGI, HP, Sequent, IBM, etc etc etc.
- The trademark for "UNIX" was sold to X/Open in the early '90s. X/Open then renamed themselves "The Open Group". They still own the trademark.
- In '91 Linus released the first Linux Kernel to the hacking community. He wrote this on his own and is a derivative of nothing other than his own work.
- In '93 Novel purchased USL (AT&T)s stake in the UNIX codebase.
- In '94 Berkeley and AT&T/USL settled an ongoing copyright infringement lawsuit over the rights to those portions of the BSD codebase which contained original AT&T Version 7 code. A few files in BSD were removed, rewritten, and then BSD was rereleased as BSD-4.4Lite. (This had nothing to do with Linux).
- By '95 Caldera was actively contributing source code to the Linux Kernel, along with dual CPU hardware, to further community development of a product line they were actively engaged in selling. All of this code was released under the GPL with full knowledge and intent of management as part of their business plan.
- in '95 Novel purchased the rights to the original UNIX codebase from USL
- By '96, when Kernel 2.0 was released, Linux had basic support for SMP in the kernel.
- In '98 Novel sold the UNIX codebase to SCO (previously SCO had only a source license from AT&T). SCO, IBM, and others began Project Monterey to unify an single UNIX source tree among many hardware vendors.
- In '99 - 2000: Kernel 2.2 was released which included many new SMP features. By this time independent of project Monterey Linux developers were coding in beta their own journaled filesystems, Logical Volume support, clustering failover, and very early NUMA support.
- 2001: SCO split into Tarantella (a web services company) and the original SCO name w/ original AT&T UNIX tree. Along with this was the original SCO Openserver codebase and UNIXWARE. Linux had by that time far surpassed UNIXWARE in SMP scaling, along with most other enterprise features, and all of this had happened before IBM invested in Linux and dumped project Monterey.
Thus, one sees from the history of Linux development, all relevant "enterprise" features were developed independent of IBM and the project Monterey codetree. The assertion that "SCO released code which accidentally made it into the kernel tree" and "loosers weepers" is completely irrelevant to the facts at hand. None of that happened, thus the hypothetical doesn't matter.
ESR makes all of this perfectly clear in his position paper.
Cheers,
--Maynard
- Any code or file released by Caldera and accepted by Linus into the kernel tree with the copyright notice "Copyright Caldera Corporation, All rights reserved. This file is released under the General Public License..."
Is deemed released on purpose, retains its license under the GPL, and cannot be used ex-post-facto for tort under copyright or breach of contract law.
Do you agree with that statement?
--Maynard
I think you underestimate the render extensions. Why generate Postscript, which is interpreted and in turn writes to a canvas, when you can write to the canvas directly?
Because writing directly to the canvas implies you're writing to the local framebuffer, which tosses the whole point behind network transparency. Device independent rendering and display side server applets are the two things that DPS does really well. Of course, that doesn't mean that a toolkit will necessarily use those features, but it's a cool thing to have available. X is FUBAR'd at the protocol level because of how it handles event processing (just one of many reasons), so no matter what one does above at the toolkit level it will always be a network hog. There were more elegant solutions before Project Athena released X fifteen years back. Adding a new toolkit layer simply won't resolve this fundamental brokenness - even if it has access to all the cool framebuffer features through RENDER. Though I agree that DPS is a somewhat overly complex protocol, it can do stuff simply and elegantly that X can't even come close to doing even after jumping through multiple layers of rendering and toolkit libs hoops. JMO.
Cheers,
--Maynard
I'm sure they could take advantage of the RENDER extension, but I don't really see the advantage of a whole Postscript interpreter under there.
One of the big advantages to DPS and DPDF is the device independence in rendering text and other objects. That is, it's truly WYSIWYG - what's rendered on the screen is exactly what will be rendered to print (or any other device). For DPS you also have the option of writing applet procedures which run on the display server, similar to the old Sun NEWS system. So, for example, one could write a terminal emulator in postscript and have it run in the display server, thus reducing network load by cutting out most of the transmission of event processing between client and server during a remote display session. This solves the biggest complaint about network transparent X sessions, that being it's a network hog and has terrible latency.
X is fine for what it does - especially given the price - but it saddens me to no end to see the DGS render extension die because no one seems to care, while at the same time everyone bitches about slow old X. GnuStep with Display Ghostscript would certainly have been a better solution than completely rewriting a new display server and the rewriting the windowing environment all over yet again.
So now someone is selling cool new desktop that will never cross the threshold of users necessary to replace X, while others keep dumping more intellectual energy in bogus free X desktops that 'kindof' work. How many times have we done this? How many widget toolkits does X really need? Athena, Motif, TK, QT, GTK... on and on and on. None of them work well together, everyone needs applications that cross toolkit boundaries, and users are left completely in the dark on how to do the simplest thing like cut and paste non-text between applications. Wasn't Simpson Garfinkle bitching about just this in the UNIX Haters Handbook ten years ago?!?!? And everyone laughed because it was true while nothing changed. Feh.
We're long past the point where the history of X, and ridiculous backward compatibility, is impeding growth toward something new and better. Gnome and/or KDE ain't the solution. Nor is GnuStep rendering through xlib. Feh, what a mess.
JMO,
--Maynard
I fiddled with both FreeSWAN and the OpenBSD implementation of IPSEC. Trying to get them to interoperate was a total nightmare, primarily because of the differing key exchange protocols. At the time I wanted to use OpenBSD server side because it supported hardware crypto cards while Linux didn't, which is now a non-issue with current Linux kernels.
I still think that straight IKE (Internet Key Exchange) is a better method of handling key exchange than DNS - it just seems like we're adding too many unrelated record types to DNS, which is leaving us with a mess of clients/servers that can and cannot understand certain records. The AFS folks have done the same thing, yet I don't see AFS records in DNS maps all over the place. One point I'll make about this, we used to have hesiod records in our DNS maps which we had to rip out when we last upgraded BIND because it didn't understand the record type and would puke and die on startup. DNSSEC only makes the problem worse - unless everyone agrees to support the new record types and upgrades.
OTOH: automagically performing a key exchange and then setting up a transport mode point to point IPSEC exchange is a very cool thing! Most people think IPSEC is about tunneling whole IP networks within the IPSEC protocol, but ubiquitous transport mode is really the holy grail of IPSEC. Basically it allows one to encrypt any TCP/UDP stream without regard to the underlying port side protocol - thus making ssh, httpssl, ftpssl, etc redundant. Telnet, ftp. http, etc suddenly becomes secure by default without the user having to do or know a damn thing! This is a far more elegant general purpose solution than the variety of encryption schemes we use today, each with their own idiosyncrasies, potential security holes, and command line switches.
Go FreeSWAN team!
--Maynard
I also have DirecTV and have recently tried Comcast HD service. Here's the lowdown:
- Dealing with Comcast CS was like pulling teeth without anesthetics, they had no idea what they were selling and misrepresented the service when I was finally forwarded up through the CS clue-chain. When the installer came out they cut my Internet connection by accident. When I finally cancelled out of disgust, a service rep came and installed a filter on my Satellite line! And yes, it was a straight run from the dish to my TV, the filter being placed right next to the dish. Asshole.
- Both DBS and cable offer HD Showtime and HBO, though Comcast also offered a select few local channels in HD. DBS continues to be significantly cheaper per month for far more SDTV channels, though the premium stuff is priced about the same. DirecTV also offers HDNet, which broadcasts a good deal of sports and the occasional HD transfer of Hogan's Heros. Can't wait for I Dream of Jeannie. DBS currently offers no local HD channels.
- Comparing image quality of broadcast vs. Cable shows a significant decline in image quality with Cable. DBS doesn't offer local channels in HD yet, but it too suffers from over-compression problems. I assume this is because of higher compression... I think the cable companies are using a 6Mb stream compared to a 14Mb stream over PBS and full 19Mb stream for CBS. You really notice the difference. Since DBS has the same compression issues, HBOHD/ShowtimeHD have about the same image quality over DBS as cable.
- Showtime and HBO are just that. The programming isn't that exciting, though getting recent Soprano's in HD is pretty nice. One positive for Showtime is that they actually letterbox 2.85:1 films instead of mauling the film to 1.85:1 like HBO.
In short, putting up a good antenna on your roof ensures the best image quality possible. If you care about HBO/Showtime you might want to consider DBS or cable, I personally would recommend DBS over cable at the moment for both price/performance and CS quality. Finally, HDTV is good.Cheers,
--Maynard
>>Last I heard, the redhat cds contained proprietary software.
>That's not true, and has never been true.
Yes they did. For example, Redhat 4.x shipped with a commercial X server, Metro X and BRU backup tool. They also had a distribution which included Motif development libraries, as well as a secondary product line which included just the runtime libs as well as the runtime and development libs. Redhat 5.x continued shipping Metro X, but not BRU if I remember correctly. This policy was primarily a response to Caldera's bundling commercial software with the original Candera Network Desktop and Caldera OpenLinux productline. Not that Redhat Linux does bundle commercial software with the product - I haven't seen it so I can't comment on that. However, Redhat most certainly did bundle commercial applications with their product line at one point in time. --M
It looks as though both of you are right:
DPS portion of XFree86-4.3.x manual
DPS is indeed part of XFree-4.3. But as you point out, the main sourceforge DPS site has announced that it is obsolete due to the X Render extension. This is a real shame as DPS does stuff far more elegantly than X Render and is of extreme importance to the GNUStep project. *sigh* --M
"You recieve benefit from [Windows], whether you realize it or not. It's not a complete waste of money."
"sig: If it's theft to listen to music before buying it, then it's theft to refuse returns on albums that suck."
Best,
--Maynard
You personally may not care about that, but there's a huge number of people who do. You may not like supporting MS, but if you're a gamer then that $90 'tax' is not entirely a bad thing.
Those who want or need Windows have a plethora of vendors available to choose from. Enjoy! My point was that it's 'Great news!' that someone was finally selling a laptop without Windows bundled with the hardware, because there are many folks who have no use for Windows and better use for the money Microsoft (bundled through the vendor) charges. Frankly, I resent being forced to pay for something I don't use and don't want, and as such I consider it a 'tax' every time I must pay for a thing that's bundled with something I do need. I'm glad that a company is finally catering to my desire for a product sans the cost of Windows and hope they succeed with their business plan. There's nothing in my statement which suggests that those who prefer to purchase Windows should be prevented from making their choice. --M
$90 buys you a date?
Wow, you just don't stop, do you? I - duh - have better uses for my money. How I use my money is irrelevant to the discussion beyond the fact that I would prefer not to be forced into purchasing Windows every time I buy a laptop. You want to buy Windows? More power to you. Do not share and enjoy! --M
Me, I'll choose a nice dinner out with fine wine for me and a date. --M
What I'm saying is: "You might save $90, but you lose more than you think."
Guess that all depends on what one uses their laptop for, huh? I seem to remember the term "Windows Tax" going back to 1994, and I certianly wasn't the originator. In my situation being forced to pay for Windows is most certainly a tax I don't need. --M
This is the first time I've seen anyone offer a laptop sans OS. $789 looks to be a good deal for the hardware, and I think most of us would have no trouble installing our favorite Linux or BSD distribution. This can only be construed as GOOD NEWS! Finally, a laptop without the Windows tax! (and reasonably cheap too) --M
...So if I want to run linux, I'm effectively paying $200 for GNU software. I don't quite understand how that works within the GPL. Please explain it to me.
All you need do is ask Sony for their source diffs and cross compile for MIPS. See? They follow the letter of the GPL and you're left wasting a bunch of time figuring out how to boot the sucker. Good luck! --M
If you move video drivers into the kernel then you risk kernel stability!
:)
The big controversy was Microsoft moving GDI and other aspects of the windowing system into kernel space, not physical device driver support. I'm talking about initializing the physical device and managing video device registers, blitting, etc. in kernel space, while userspace apps (or better, a general purpose library) use traditional system calls to handle userspace communication to the device. This was hashed out repeatedly long ago (with many flame wars ensuing) on the lkml. Unfortunately it was a good idea that never happened.
Think about it like this: you wouldn't want your IDE device driver running as a deamon with root privs in userspace, would you? So why should your X Server do the same? Why should you have ten different X servers tailored to every popular video card on the market? Have you ever switched from an X session to a virtual terminal only to see your console completely hosed? I can't count the number of times I've seen this and wondered 'Why the fuck hasn't this been fixed yet?!?!?!' XF4.x with its modular device drivers notwithstanding, this is still a serious issue.
Managing hardware recognition, initialization, and physical attributes in kernel space is cleaner than having a bunch of usespace apps doing the same in ways that are almost certainly mutually exclusive. It's supposed to be the kernel's job to handle simultaneous contention for a device between various apps. That was the point behind GGI, and is currently the point behind the Linux kernel Frame Buffer support. Unfortunately, Frame Buffer device drivers are horribly out of date so people just use X instead.
Of course, this is JMO and many people (including Linus at the time) completely disagreed many years back. I, however, think the GGI folks were completely right and wish Linus had given their ideas a better chance at kernel inclusion. OTOH, you don't see my name in the kernel tree and there's a good reason for that: I'm not qualified. So take my opinion with a grain of salt.
Cheers,
--Maynard