That's *exactly* what Microsoft did. Way back when, because "Windows" was clearly too genericd to trademark, and the word too widely in use in the computer indusry (X and the Apple II both come to mind), they made a big fuss about the trademark being for "Microsoft Windows," and pointing out that this would stop, say "DRI Windows," or "Desqview Windows" from being produced.
Um, did you mean to say that this would not stop "DRI Windows" from being produced? (If it would, how would this not be claiming a trademark on the generic word?)
Okay, I just read through the remedy proposal from the remaining states. Wow! They've hit the nail on the head here. Why couldn't the DOJ have come up with this proposal the first time around?
Splitting up Microsoft was too simplistic, and would have just created several little monopolies in place of one large one. It was totally unclear how this was supposed to remedy the antitrust violations and restore competition. The Court of Appeals confirmed that Microsoft broke the law, but they were also unconvinced that the original remedy would be effective.
Of course, the DOJ settlement proposal is much worse, offering a slap on the wrist to a convicted criminal after the conviction is upheld on appeal. Microsoft effectively murdered a number of other companies (such as Be) -- can you imagine a state prosecutor getting a murder conviction, which gets upheld on appeal, and then accepting a plea bargain for manslaughter with a suspended sentence? That's about as bad as what the DOJ is doing here. They should be ashamed.
The remaining states at least have the guts to push on, but the new judge seems predisposed to get rid of this case expeditiously, regardless of whether a settlement would be in the public interest, or whether it would remedy Microsoft's illegal conduct, deny them the fruits of their statutory violations, or restore competition in the computer industry.
Judge Jackson would have happily endorsed this proposed remedy -- why did he have to get so careless and get himself removed when his wisdom and insight are so desperately needed most to ensure justice is done? *sigh* I hope the new judge changes her tune -- the remaining states got the proper remedy exactly right this time.
Here's a summary of the states' proposed remedy:
Require Microsoft to unbundle Internet Explorer and other middleware from Windows and offer a reduced price for versions without the extra features.
Mandated uniform, non-discriminatory licensing of Windows to OEMs and other third parties.
Continued licensing of previous Windows versions for 5 years after a new version is released at the same price.
Mandatory and timely disclosure of technical information to ensure interoperability.
Prohibition on knowingly interfering with the performance of non-Microsoft middleware without good cause.
Ban on (anti-competitive) exclusive dealing.
Ban on contractual tying.
Ban on retaliation for supporting competing products or engaging in (this) litigation.
Microsoft must respect OEM, user and third-party licensee choices if they want to make a non-Microsoft product the default middleware (e.g. Netscape browser).
Prohibition on agreements not to compete (like their attempt to divide the browser market with Netscape between Microsoft and non-Microsoft platforms).
Compulsory open-source licensing of Internet Explorer (to deny Microsoft the benefits of their illegally-gained browser monopoly).
Mandatory distribution of a Sun-compatible Java JVM with Windows and IE (to give Java the widespread distribution it could have had without Microsoft's illegal behavior).
Mandatory continued porting and support of Microsoft Office for the Macintosh platform.
Mandatory auction of at least three licenses to allow porting of Microsoft Office to other platforms, and to provide all necessary information (including file formats) for doing so.
Mandatory licensing of any Intellectual Property rights necessary for the effective implementation of this remedy proposal.
Mandatory actual compliance with any industry standards that Microsoft claims to comply with, or de facto standards where justifiable. (Proprietary extensions allowed, but the industry-standard part must work correctly.)
Appointment of an internal Compliance Officer within Microsoft to ensure compliance with the final judgement.
Appointment of a Special Master empowered to investigate and resolve complaints quickly while minimizing demand on judicial resources.
Establish consequences for patterns of non-compliance to discourage such behavior.
Disclosure of certain information related to acquisitions to enable appropriate government oversight.
This is a well-thought-out, carefully-drafted remedy that would actually have a good chance of restoring competition and serving as a true remedy for Microsoft's established illegal behavior. This is the remedy we need, not splitting the company into "Baby Bills", each with its own ready-made monopoly to leverage...
I don't think the lawyers are officers of the court. The court is part of the judicial system. The prosecuting attorneys (those not part of DoJ, anyway) would be in the executive branch. The defense attorneys aren't part of anything but their paychecks.
At any rate, lawyers in a case do not testify. As such, they're not under oath and thus cannot, by definition, commit perjury.
Guess again. According to this, "Upon admission to the bar an attorney normally must take an oath declaring his or her obligations to the court, state, and country as an officer of the court, register with the court, and receive a license to practice." (Emphasis added.) I'm not a lawyer myself, but that web page (from Cornell Law) clearly indicates that any practicing attorney is under oath and considered an officer of the court. As such, they do have a legal obligation to the truth and the integrity of the judicial process, which takes predence over their paychecks.
I'm leery of "dual licenses" because it seems to voilate one important part of Open Software(let alone Free Software as the Gnu philosophy defines it).
It's not as idealistic as Free Software. It's more realistic. Let's face it, companies exist to make money, and if they can exploit the hard work of volunteers to make an easy profit, they will. Most companies won't contribute back out of "social conscience" like individuals might -- if they did, they could even get sued by stockholders for breach of fiduciary duty for not seeking the maximum profit possible.
The companies that do contribute back to the community do it to the degree they feel it will be advantageous (to the company and its stockholders) in terms of saved development costs (avoiding the need to maintain a forked tree) and/or public relations/marketing benefits of appearing to be a "good corporate citizen". If a contribution back to the community would sacrifice a significant competitive advantage, it probably won't be contributed back unless it's forced (by the GPL, for example).
Open Software should be available for ***everyone*** to use. Single users to multiple users. Non-profit to big profit. None of that should matter if you really want "open" software. Restricting it to be open for some (non profits and profits that pay) but not others has all sorts of dubious problems.
The GPL isn't really open in that way. The GPL demands that you "play nice" if you want to use GPL'd code -- by releasing your code under the GPL as well. For many proprietary vendors, this is a completely unacceptable demand, so they avoid GPL code like the plague. The "dual licensing" model offers an alternative -- if you won't "play nice" by opening up your own code, you can pay for the privilege of using the code anyway -- and that money will be used to fund improvements in the software for everyone.
This is a win-win situation. Those who are willing to release their code can freely use it, and get the benefit of development which likely wouldn't have occurred without funding. Those who aren't willing to "play nice" must pay, but they also benefit from that development work in the long term, and they still save money over redeveloping the same functionality.
The GPL's approach to proprietary software is "I'm going to take my ball and go home." This dual-licensing approach is "if you don't want to play nice, then pay me to make it worth my while." This is pragmatic rather than petulant.
I do recognize that some groups do need to make money but I think that APIs/library usage are the wrong places to do it for Open Software.
On the contrary! This is the best place to do it because there is leverage in this area. If you make a good library (like Berkeley DB), proprietary vendors will be interested in building products around it because it will save them money to pay for working code (and support) rather than trying to reimplement the same functionality from scratch. They won't reinvent the wheel if paying for a proprietary license is cheaper, and the revenue from the proprietary licensing can fund new development work.
Now, consider an end-user application, such as a word processor. It's something end users want and need, but other proprietary vendors have no reason to pay for a proprietary license if the application is available under an Open Source license, because there's no need to build a larger product around it. There's no leverage, so it would be very difficult to support a business and fund new development work if nobody is willing to pay for it.
Free Software and Open Source Software are great, but they tend to ignore a basic problem -- while distribution of software is cheap, production of new software is expensive. If nobody is paying for the distribution of the software, how do you fund the development?
Stallman suggests writing new software as consulting gigs, and requiring it be placed under the GPL. That may work for him, but it won't work for most programmers. Most of us have to work full-time jobs to support ourselves, and often only get to work on Free Software by sacrificing our "free time" to the cause. That's no way to have a life, even if it does get some software written and released.
We need a solution which allows talented developers to spend their days programming for the common good without starving in the process. I'm not sure yet what that solution might be, but I'm quite certain that spending all your time writing software that will be given away (and in some cases exploited) isn't the answer. Maybe one more copy of a program isn't worth a lot, but the time the programmer spent crafting that program is a valuable, scarce resource. And the economics just aren't working.
And you know the really sad part about this situation? If someone does come up with a solution, it will necessarily have to take a different form than Free Software currently does, which will anger all the zealots who demand that everything must be free and GPL'd, but who refuse to examine the fundamental problem which has yet to be addressed. Of course, many of these people claim to be fighting for "free speech" when they're really more interested in "free beer", truth be known...
I don't see how this differs practically from offering it under the LGPL while offering commercial terms as an alternative. Both provide a free version licensed under "viral terms", and both would require copyright assignation from all contributors.
The LGPL would allow proprietary vendors to exploit the Wine developers by linking a proprietary product to Winelib, distributing it for profit, and not giving anything back to the community. The only area where this isn't the case is when that product requires the core Wine code to be patched to work -- those patches would have to be contributed back under the LGPL. However, the better and better Wine gets, the less proprietary vendors will need to give back and the more effectively they'll be able to exploit the hard work of the Wine contributors...
The full GPL would be more effective, since it would apply to the entire application, and give vendors an incentive to pay for an alternative.
As for "choosing which viral license", the GPL is one of the few copyleft licenses which demands that other code use the exact same license -- many other Open Source licenses demand characteristics of the other license(s) such as source code availability (like Sleepycat does), which allows you to mix-and-match licenses to a certain degree.
Well I don't claim to know much about wine but I was under the impression that it was primarily created to allow Win32 applications to run under x86-Linux/Unix so it would be quite useless if only open source Win32 apps were allowed to use it without a special arrangement, after all I doubt MS will buy a license so Office can run under Linux!
I'm thinking of cases like Corel's WordPerfect Office 2000 for Linux, which shipped with Wine as part of the product -- those should require a proprietary license if they don't want to release the source code to the Office suite.
Anything which is distributed for Windows and just being used with Wine incidentally (like Microsoft Office) should be usable for free, though perhaps a clause in the license would be needed to make that explicit?
There are simple answers to this. Sleepycat is a company, WINE isn't. Sleepycat owns the copyright to all the code in Berkeley DB. Copyright to WINE code is owned by numerous developers around the world, not all of whom would agree on proprietary licensing terms.
Sleepycat is a company that was formed for the purpose of developing and marketing the Berkeley DB codebase. Why not a similar company for Wine? Yes, it would be necessary to get copyrights assigned to such a company from many contributors, or at least relicensing rights, but to change to a license like LGPL requires the same cooperation from contributors. If some disagree, perhaps those parts could be reimplemented.
If necessary, the company could be designated as a non-profit to ensure that revenue received would not be used to line anybody's pockets. There could even be clauses in the corporate charter to prevent later conversion to for-profit status, I imagine.
If such a corporation could afford to hire developers full-time who currently can only afford to work on Wine in their spare time, wouldn't that be a Good Thing?
Berkeley DB started as a small embedded database library which only supported hash tables and btrees. Since it was written for BSD Unix as a replacement, it was released under the BSD license. After a few years, it was widely used, but it still only offered access methods. When Netscape wanted more features, such as transactions, disaster recovery and multiple-user support, Sleepycat Software was founded to further develop Berkeley DB (on the strength of a licensing deal with Netscape).
The new version of the software was released under the Sleepycat license, an OSI-approved license which allows Open Source applications to use Berkeley DB, but (unlike the GPL) appears to be compatible with any Open Source license. For proprietary applications, Sleepycat offers a more traditional licensing option to companies who don't wish to distribute their source code. Revenue from such licensing funds additional development of Berkeley DB, to the benefit of all. (For example, Berkeley DB 4.x adds replication and high-availability functionality that surely would not exist without the funding received through this dual licensing.)
Perhaps the Wine project should follow this example? Wine could be placed under a license like Sleepycat's, which would allow Wine to be freely used by Open Source projects (whether GPL or not), and proprietary companies could pay for a license which allows proprietary use. Funding from such licensing could be used to further develop Wine, to the benefit of proprietary and Open Source users alike.
BSD or LGPL licensing allows proprietary companies to profit from the hard work of the Open Source developers without giving anything back. Sleepycat's licensing model forces them to give something back, either by contributing more Open Source code back to the community, or by paying cash for the privilege of avoiding that -- which could then be used to fund development that would benefit the Open Source community.
It's a win-win situation, and it would ensure that contributors don't get exploited. It could also lead to funding that might greatly accelerate the development of Wine, even more than relying on companies like Corel to contribute back changes they've made to the codebase.
I'm not a contributor to Wine, but I'd suggest they consider following Sleepycat's example -- it appears to work well for them, why not for Wine?
Desktop Unix is dead. Sun lost that battle ten years ago.
I think this statement is premature. Desktop Unix isn't dead. Maybe GNOME and KDE aren't ready for the mainstream, but Mac OS X certainly is, and it's indisputably a Desktop Unix system...
I really wanted to submit comments about the settlement, but I knew it would require effort to compose a good comment about it, so I hadn't gotten around to it yet. A recent story reminded me that the deadline was imminent, so I wanted to make it a priority to make sure I didn't forget -- I kept a browser window open to a page about it, so I would not forget to get back to it before the deadline.
Nevertheless, I missed the deadline. Why? Because Mozilla crashed and lost all my open browser windows! I had no idea what pages those windows were open to, so I couldn't recover from the crash. All of that state information was lost forever, including the page that was up to remind me to submit a comment about the proposed Microsoft settlement...
I find it rather ironic that I didn't get to send in a comment about Microsoft crushing Netscape -- because Mozilla crashed! *sigh*
BAD idea. Throwing in all the major architectural changes at once will result in total chaos that is going to be next to impossible to fix.
Well, I was just trying to come up with something that could be used for the Linux kernel, and which would hopefully reflect the existing development process to some degree. Unfortunately, it appears that "total chaos" is the usual state of the Linux kernel soon after forking off a new development series. (Didn't early 1.1.x, 1.3.x, 2.1,x and 2.3.x kernels all have this sort of chaos?)
And yes, it's hard to fix -- which might explain why it seems to take 2-3 years to get from one stable series to the next! A more controlled development process might work better, but that's not up to me...
In the end, I abandoned this all-numeric version numbering scheme anyhow. I'm trying a different scheme now, but I haven't nailed down all the details or written it up yet...
I hope you moderators appreciate this is just this guy's idea, and not actually the current release versioning system used for 2.5. The fact that he made 2.5.3 bold would lead you to believe otherwise.
Actually, it was my idea (posted to the linux-kernel mailing list on May 10, 2000), but the other poster above didn't bother to attribute credit for it. (Although I think it was really more of a sarcastic comment on 2.5.3's stability, the way that section was bolded.)
That was an idea I came up with off the top of my head, looking for a way to move the "should be stable but oops, not" kernels out of the "stable" series into the "development" series (thinking of 2.2.0 for example) -- by adding a fourth digit to indicate the status, so that release candidates could get production testing before getting branded as "stable". Once a fourth digit was added, I figured that I might as well try to fill in the other numbers with vague-but-useful state indicators for earlier stages of development. That post to linux-kernel was my first attempt, off the top of my head.
I developed this idea further, in response to some of the discussion on linux-kernel about my idea, but in the end I decided against using it. My brother convinced me that encoding this much meaning into numeric identifiers required a lot of advance knowledge about the system to make any sense of the version numbers, and harried system administrators wouldn't take the time to learn.
I finally decided to use a different approach, where "stable" releases are all-numeric numbers (e.g. 1.0.0) while "development" releases always contain an alphabetic intended-state tag (e.g. 1.0.0.beta.1) and discarding the even/odd notion from Linux. This way, development versions are more self-identifying, and release candidates (suitable for production testing) would have an "rc" tag (e.g. 1.0.0.rc.3).
The idea is that the "stable" release (e.g. 1.0.0) would be completely identical to the last "rc" release (e.g. 1.0.0.rc.3) except for the version number change. If there's a temptation to add "one last patch" (no matter how minor), make a new "rc" version and let it make the rounds first. This would avoid embarassments like 2.2.0 and certain 2.4.x releases, which are marked "stable" by their version number, but were quite unstable in practice...
I tried to include my writeup of the all-numeric system I ended up with before I gave up on it, but Slashdot's "lameness filter" rejected it. Maybe it's a sign.:-) (Interested parties can send me email and I'll mail a copy of the writeup...)
Who said they were dropping MPEG? They've agreed to use RealNetworks technology for music management, not to replace the video codec for recording television programs!
We had a very clear picture of the features for 1.0. When the decoder was feature complete and frozen, we called the release RC1. As far as implementors are concerned, this is a feature complete release.
I have to agree with the previous poster. This is nitpicking, for which I apologize, but making substantial changes to the encoder between "release candidates" just doesn't make sense. In my mind, a "release candidate" should only be used for final bugfixes before a release. That's clearly not what's happening here, or you wouldn't see any improvement in audio quality between the RC1 and RC4 encoders.
Don't get me wrong; I fully support wanting to get the quality to a particular level before blessing a final 1.0 release. That's great! But please don't call it a "release candidate" if you're still tweaking the encoder.
It would be better to go through a series of "final" 0.x releases (each with its own release candidate(s) to fix bugs) with progressively better encoders, and not declare a 1.0 release candidate until you're satisfied with the encoder and have no intent to tweak it further before the final 1.0 release.
Of course, it's a bit late for that now. But it's food for thought -- it would have been a lot less confusing to have 0.9.1 instead of RC1, 0.9.2 instead of RC2, etc. When people see RC1 vs. RC3 they tend to assume they're functionally equivalent, but with more bugs squashed in RC3.
That's not what we have here, and some people who have RC1 working acceptably might not even realize it's worth upgrading to RC3, RC4 or the final 1.0 release. After all, if you're not tripping over any of the bugs in the release candidate, why worry about upgrading it?
I'm afraid it's just confusing, and it doesn't seem necessary to confuse people like that...
Watch TiVo in 3x with Closed Captioning...
on
Comparing the DVRs?
·
· Score: 2
in microserfs they cottoned on to playing subtitled movies at 2x which was still comfortable enough to read (no chipmunking of voices). can't do this with a tivo though as the status bar comes exactly where the subtitles usually are.
Of course you can do this with a TiVo. No, not at 2x, but you could do it at 3x, the slowest fast-forward speed. The status bar clears after a second or two at this speed, which would allow you to see subtitles. You can also clear it manually (in any fast-forward/rewind/pause mode) by pressing the Clear button.
The best trick? Turn on Closed Captioning in your TV, and watch it at 3x. The TiVo is clever enough to play back CC data even at 3x, which really lets you catch up fast. (If you skip commercials, you could probably watch a 1-hour program in 14-17 minutes.) If there's a lot of talking, it might not be able to keep up with the CC data, but usually it works pretty well.
Can UltimateTV display CC data at an accelerated rate like this?
Transferring lifetime TiVo subscriptions...
on
Comparing the DVRs?
·
· Score: 2
No, you can't transfer the lifetime subscription to another unit, but you can transfer it to a new owner. It will be worth just as much to the next owner of the unit as buying it himself would be worth, which might even be more than it is now, if the price goes up again. So, even if you expect to sell the box within 2 years, it's still a no-brainer to get the lifetime service...
The only real danger is if the box breaks before the 2 years are up, and you don't have warranty coverage. If you insist on voiding your warranty, you might want to pay monthly until you've done the upgrade and give it a month or three to run, then buy the lifetime service when you're pretty sure it will last a couple more years.
If you're going to void the warranty, be prepared for the risk that entails. (Some have claimed that upgrading the TiVo unit doesn't void Circuit City's extended warranty, but I'm not sure I believe that...)
The point about GNU/Linux is not to demand credit. The point is simply that the system is called GNU, and its kernel is called Linux. You don't call OS X "Darwin", do you? Technically, GNU/Linux is simply the correct term. That's all. If you prefer to call the system Linux, simply ignore RMS.
The correct term is "OS X" only because that's what Apple decided to call the system. If they had decided to call the system "Darwin", then that would be the correct term. Apple made the OS X system, so they call it whatever they want. They don't have to call it "BSD/OS X" just because it depends heavily on BSD, and I don't hear any BSD zealots demanding that they change the name to "BSD/OS X". The BSD folks are happy to know that OS X wouldn't exist without BSD.
Technically, "GNU/Linux" is simply not a correct term, unless you're referring to a Debian distribution. I'm not aware of any other Linux distribution that uses "GNU/Linux" in its name. "GNU/Linux" is an attention-grabbing term invented by RMS because he feels slighted that Linux gets more attention than the GNU system.
He's being disrespectful to the distribution authors who chose not to use "GNU/Linux" in the name, by demanding that others corrupt the name in reference to any of those distributions. Whoever makes a complete system (e.g. any Linux distribution) has the right to name that system. RMS has no right to demand naming rights on any system created by someone else.
RMS could have had the FSF jump on Linux and build the first Linux distribution. They could have called that distribution "the GNU system" and never mentioned Linux in the name. Chances are, "GNU" would be getting all the attention instead of "Linux" if he had done so.
Instead, the FSF was convinced that the HURD was a better kernel, even if it wasn't quite finished. Rather than seize a golden opportunity to complete their GNU system and set the naming example for others to follow, they ignored Linux entirely. As a result, distributions like "Slackware Linux" and "Red Hat Linux" followed.
If RMS wasn't so fixated on the presumed superiority of the HURD over Linux, might we instead have "Slackware GNU" and "Red Hat GNU" now? And RMS might be the folk hero instead of Linus Torvalds? Basically, RMS squandered a golden opportunity, and his insistence on "GNU/Linux" is just sour graps on his part.
All my Linux boxes have GNU software on them. Not all have X. Why would I credit X with being part of the system when it often isn't?
Because X Windows is considered part of the "GNU system" even though it's not GNU software. I quote:
GNU software and the GNU system
Developing a whole system is a very large project. To bring it into reach, I decided to adapt and use existing pieces of free software wherever that was possible. For example, I decided at the very beginning to use TeX as the principal text formatter; a few years later, I decided to use the X Window System rather than writing another window system for GNU.
Because of this decision, the GNU system is not the same as the collection of all GNU software. The GNU system includes programs that are not GNU software, programs that were developed by other people and projects for their own purposes, but which we can use because they are free software.
Okay, now. If what RMS is saying there is okay, and "X Windows" becomes part of the "GNU system" (Not the "GNU/X-Windows system", mind you), then how would the following hypothetical quote be any less reasonable?
GNU software and the Linux system
Developing a whole system is a very large project. To bring it into reach, I decided to adapt and use existing pieces of free software wherever that was possible. For example, I decided to use the X Window System and the Unix-style GNU utilities rather than writing a window system and similar utilities for Linux.
Because of this decision, the Linux system is not the same as the collection of all Linux software. The Linux system includes programs that are not Linux software, programs that were developed by other people and projects for their own purposes, but which we can use because they are free software.
RMS can't have it both ways. If he wants to adopt the X Window System like that as part of the "GNU system", then he has no right to complain that most of the pieces of the GNU system were adopted in the same way for the "Linux system". Maybe RMS feels that the GNU system was appropriated for Linux, and perhaps it was. But RMS set the precedent!
If you have a Linux system with no GNU software on it, call it Linux, and even RMS will have to admit you are right.
If I have a Linux system, that's what I'll call it, whether or not it has GNU software. RMS isn't the only one with the right to give an overall name to a system he creates without regard to the source of each component of the system....
I have little doubt it's being exploited -- I've received several mystery emails with apparent "WAV files" in them. Since I'm using Pine under Linux, it's not being executed, but when I save the file and look at it with "less", this supposed audio file contains the text "This program requires Microsoft Windows." Obviously it's a Windows executable, and why else would I receive it tagged as an audio file unless that would exploit a bug to allow an executable to run instead of playing an audio file?
Not true. I have IE running on my Solaris box. Nothing windows related on it. There is no autoexec.bat file, or anyhing else that looks like it belongs in windows.
I heard that Microsoft basically implemented the entire Win32 API on top of Solaris, then linked IE (using Win32 calls) to that API implementation to make a workable but inefficient binary. I don't know if this is true, but it doesn't seem unlikely. You wouldn't necessarily be able to tell, since it could all be linked into the single executable from a static library...
Somehow I doubt RMS sees the irony. I wrote a short piece about this back on March 31, 1999: Why "GNU/Linux" is a Misnomer In the 2.5 years since then, the FSF still has not released a GNU distribution, relying instead on the Debian project to do what they won't.
Given that "The GNU Project" doesn't credit the X Window System anywhere in its name, RMS has no moral high ground to stand on when he demands that all Linux-based systems be referred to as "GNU/Linux" systems.
It's doubly ironic that the older BSD license was incompatible with the GPL specifically because of the so-called "advertising clause" that requires credit be given for the BSD-licensed software.
Isn't it funny how RMS feels it isn't necessary to credit BSD or X Windows, yet demands such credit for the GNU project? It's disingenuous hypocrisy, through and through. If someone makes a free software distribution, they should be able to call it anything they want, whether "GNU", "Linux", "BSD" or anything else is included in the name.
After all, wasn't this all supposed to be about freedom? I guess that doesn't include the freedom to choose the name...
Among those forces: the coming version 6 of Sun Microsystems' StarOffice package of office software, which many believe will be a more capable product than the bulky current version and thus a more credible alternative to Microsoft's Office; burdensome Microsoft licensing fees during a time of economic austerity; and the overall price tag of Windows and Office.
OK, I'm not sure that I can agree that StarOffice is or will be more capable than MS Office, but with the current economic times, the price is certainly much more attractive. And if you look at what most people actually use an Office Suite for, you'll find that almost all of them will more than have their needs met with Star Office 6.0.
The original quote wasn't suggesting that Star Office 6.0 would be better than Microsoft Office -- it was suggesting that Star Office 6.0 would be better than "the bulky current version" (Star Office 5.2) "and thus a more credible alternative to Microsoft's Office." Star Office 6.0 doesn't need to be better than Microsoft Office, but it needs to be good enough. Star Office 5.2 is clunky enough that many people don't consider it quite good enough. 6.0 may change that...
Wouldn't this kind of money be better spent paying good programmers to work on Linux full-time to close the gap? Just think how easily Linux could take the desktop if it could run Windows applications as well as Windows 98 (or even Windows 95).
The API is less of a moving target now that Microsoft's having more and more trouble getting people to upgrade to newer versions of Windows. If Wine could achieve a near-perfect level of Windows 98 compatibility (business apps especially, not just games), then people would have little excuse not to run Linux on the desktop.
Forget a WSJ ad -- that's just a flashy stunt. Remember how fast all those dot-coms started tanking after they overextended themselves to advertise in the Super Bowl? (Like pets.com?) Instead of wasting serious money on ephemeral advertising, use it to pay highly-skilled programmers to do the unsexy work that needs to be done, which won't get done (or not well) by a developer "scratching his own itch".
I'm starting to wonder if some sort of not-quite-open source model would be more effective. Charge a modest membership fee (maybe $10-20/month for individuals, more for companies) to "join the club" and allow unlimited use and access to source code for club members, who could share improvements with each other. Use the membership fees to fund new development.
There are millions of people using Linux every day. Heck, even if you only charged $20/year, you could fund a lot of development with over $20 million in annual funding... (To be credible, such a scheme would need to be operated on a nonprofit basis, and all the better if greater contributions could be tax-deductable...) Okay, maybe it's a pipe dream. And it doesn't really mesh well with the altruistic intent of Free Software. (But code could be automatically re-licensed to become true Free Software as it's replaced with newer versions, like Alladin vs. GNU Ghostscript...)
Don't flame me for this, it's just an idea. Even though millions of people benefit from existing free software, most of whom could afford at least a small contribution to bettering that software, we always seem to rely heavily on unpaid volunteer work, despite the fact that those volunteers need to eat and pay their bills. This often means they need a day job, and can only do so much work on the free software in their "free time". Most free software programmers can't rely on consulting income (insisting on free software) like RMS can. And for-profit companies like Red Hat certainly don't redistribute their profits to the volunteers who made their business possible, even if they do give them a whack at an IPO. (That's a gamble, look at VA Linux at IPO time and now...)
If people could pay for something similar to free software, with the money going to improve that software rather than to line the pockets of corporate shareholders, wouldn't that be preferable to being cornered into using commercial software because adequate free replacements aren't quite ready for prime time yet?
Re:Stupidity runs rampant in our industry
on
MySQL 4.0 Released
·
· Score: 2
So I said: "I cannot help you..." And I walked off the gig.
You did the right thing. Too bad that level of integrity isn't universal; your replacement was probably foolish enough to go along with it.
I have to wonder what the FDA, HHS, HCFA and other Federal agencies would think about such reckless disregard for patient safety. I suspect various regulators might take an issue with it. Even if they didn't, it's just begging for a multimillion-dollar "wrongful death" civil suit, sooner or later.
With the health-care industry's penchant for "risk management", you'd think they would jump at the opportunity to avoid potential future lawsuits by designing in more data integrity from the start, expecially when advised to do so by the experts they hire. Go figure...
Slashdot Mirror
That's *exactly* what Microsoft did. Way back when, because "Windows" was clearly too genericd to trademark, and the word too widely in use in the computer indusry (X and the Apple II both come to mind), they made a big fuss about the trademark being for "Microsoft Windows," and pointing out that this would stop, say "DRI Windows," or "Desqview Windows" from being produced.
Um, did you mean to say that this would not stop "DRI Windows" from being produced? (If it would, how would this not be claiming a trademark on the generic word?)
Splitting up Microsoft was too simplistic, and would have just created several little monopolies in place of one large one. It was totally unclear how this was supposed to remedy the antitrust violations and restore competition. The Court of Appeals confirmed that Microsoft broke the law, but they were also unconvinced that the original remedy would be effective.
Of course, the DOJ settlement proposal is much worse, offering a slap on the wrist to a convicted criminal after the conviction is upheld on appeal. Microsoft effectively murdered a number of other companies (such as Be) -- can you imagine a state prosecutor getting a murder conviction, which gets upheld on appeal, and then accepting a plea bargain for manslaughter with a suspended sentence? That's about as bad as what the DOJ is doing here. They should be ashamed.
The remaining states at least have the guts to push on, but the new judge seems predisposed to get rid of this case expeditiously, regardless of whether a settlement would be in the public interest, or whether it would remedy Microsoft's illegal conduct, deny them the fruits of their statutory violations, or restore competition in the computer industry.
Judge Jackson would have happily endorsed this proposed remedy -- why did he have to get so careless and get himself removed when his wisdom and insight are so desperately needed most to ensure justice is done? *sigh* I hope the new judge changes her tune -- the remaining states got the proper remedy exactly right this time.
Here's a summary of the states' proposed remedy:
- Require Microsoft to unbundle Internet Explorer and other middleware from Windows and offer a reduced price for versions without the extra features.
- Mandated uniform, non-discriminatory licensing of Windows to OEMs and other third parties.
- Continued licensing of previous Windows versions for 5 years after a new version is released at the same price.
- Mandatory and timely disclosure of technical information to ensure interoperability.
- Prohibition on knowingly interfering with the performance of non-Microsoft middleware without good cause.
- Ban on (anti-competitive) exclusive dealing.
- Ban on contractual tying.
- Ban on retaliation for supporting competing products or engaging in (this) litigation.
- Microsoft must respect OEM, user and third-party licensee choices if they want to make a non-Microsoft product the default middleware (e.g. Netscape browser).
- Prohibition on agreements not to compete (like their attempt to divide the browser market with Netscape between Microsoft and non-Microsoft platforms).
- Compulsory open-source licensing of Internet Explorer (to deny Microsoft the benefits of their illegally-gained browser monopoly).
- Mandatory distribution of a Sun-compatible Java JVM with Windows and IE (to give Java the widespread distribution it could have had without Microsoft's illegal behavior).
- Mandatory continued porting and support of Microsoft Office for the Macintosh platform.
- Mandatory auction of at least three licenses to allow porting of Microsoft Office to other platforms, and to provide all necessary information (including file formats) for doing so.
- Mandatory licensing of any Intellectual Property rights necessary for the effective implementation of this remedy proposal.
- Mandatory actual compliance with any industry standards that Microsoft claims to comply with, or de facto standards where justifiable. (Proprietary extensions allowed, but the industry-standard part must work correctly.)
- Appointment of an internal Compliance Officer within Microsoft to ensure compliance with the final judgement.
- Appointment of a Special Master empowered to investigate and resolve complaints quickly while minimizing demand on judicial resources.
- Establish consequences for patterns of non-compliance to discourage such behavior.
- Disclosure of certain information related to acquisitions to enable appropriate government oversight.
This is a well-thought-out, carefully-drafted remedy that would actually have a good chance of restoring competition and serving as a true remedy for Microsoft's established illegal behavior. This is the remedy we need, not splitting the company into "Baby Bills", each with its own ready-made monopoly to leverage...I don't think the lawyers are officers of the court. The court is part of the judicial system. The prosecuting attorneys (those not part of DoJ, anyway) would be in the executive branch. The defense attorneys aren't part of anything but their paychecks.
At any rate, lawyers in a case do not testify. As such, they're not under oath and thus cannot, by definition, commit perjury.
Guess again. According to this, "Upon admission to the bar an attorney normally must take an oath declaring his or her obligations to the court, state, and country as an officer of the court, register with the court, and receive a license to practice." (Emphasis added.) I'm not a lawyer myself, but that web page (from Cornell Law) clearly indicates that any practicing attorney is under oath and considered an officer of the court. As such, they do have a legal obligation to the truth and the integrity of the judicial process, which takes predence over their paychecks.
Have you made the code (procmail & VB script) available for this? It might help a LOT of other people...
I'm leery of "dual licenses" because it seems to voilate one important part of Open Software(let alone Free Software as the Gnu philosophy defines it).
It's not as idealistic as Free Software. It's more realistic. Let's face it, companies exist to make money, and if they can exploit the hard work of volunteers to make an easy profit, they will. Most companies won't contribute back out of "social conscience" like individuals might -- if they did, they could even get sued by stockholders for breach of fiduciary duty for not seeking the maximum profit possible.
The companies that do contribute back to the community do it to the degree they feel it will be advantageous (to the company and its stockholders) in terms of saved development costs (avoiding the need to maintain a forked tree) and/or public relations/marketing benefits of appearing to be a "good corporate citizen". If a contribution back to the community would sacrifice a significant competitive advantage, it probably won't be contributed back unless it's forced (by the GPL, for example).
Open Software should be available for ***everyone*** to use. Single users to multiple users. Non-profit to big profit. None of that should matter if you really want "open" software. Restricting it to be open for some (non profits and profits that pay) but not others has all sorts of dubious problems.
The GPL isn't really open in that way. The GPL demands that you "play nice" if you want to use GPL'd code -- by releasing your code under the GPL as well. For many proprietary vendors, this is a completely unacceptable demand, so they avoid GPL code like the plague. The "dual licensing" model offers an alternative -- if you won't "play nice" by opening up your own code, you can pay for the privilege of using the code anyway -- and that money will be used to fund improvements in the software for everyone.
This is a win-win situation. Those who are willing to release their code can freely use it, and get the benefit of development which likely wouldn't have occurred without funding. Those who aren't willing to "play nice" must pay, but they also benefit from that development work in the long term, and they still save money over redeveloping the same functionality.
The GPL's approach to proprietary software is "I'm going to take my ball and go home." This dual-licensing approach is "if you don't want to play nice, then pay me to make it worth my while." This is pragmatic rather than petulant.
I do recognize that some groups do need to make money but I think that APIs/library usage are the wrong places to do it for Open Software.
On the contrary! This is the best place to do it because there is leverage in this area. If you make a good library (like Berkeley DB), proprietary vendors will be interested in building products around it because it will save them money to pay for working code (and support) rather than trying to reimplement the same functionality from scratch. They won't reinvent the wheel if paying for a proprietary license is cheaper, and the revenue from the proprietary licensing can fund new development work.
Now, consider an end-user application, such as a word processor. It's something end users want and need, but other proprietary vendors have no reason to pay for a proprietary license if the application is available under an Open Source license, because there's no need to build a larger product around it. There's no leverage, so it would be very difficult to support a business and fund new development work if nobody is willing to pay for it.
Free Software and Open Source Software are great, but they tend to ignore a basic problem -- while distribution of software is cheap, production of new software is expensive. If nobody is paying for the distribution of the software, how do you fund the development?
Stallman suggests writing new software as consulting gigs, and requiring it be placed under the GPL. That may work for him, but it won't work for most programmers. Most of us have to work full-time jobs to support ourselves, and often only get to work on Free Software by sacrificing our "free time" to the cause. That's no way to have a life, even if it does get some software written and released.
We need a solution which allows talented developers to spend their days programming for the common good without starving in the process. I'm not sure yet what that solution might be, but I'm quite certain that spending all your time writing software that will be given away (and in some cases exploited) isn't the answer. Maybe one more copy of a program isn't worth a lot, but the time the programmer spent crafting that program is a valuable, scarce resource. And the economics just aren't working.
And you know the really sad part about this situation? If someone does come up with a solution, it will necessarily have to take a different form than Free Software currently does, which will anger all the zealots who demand that everything must be free and GPL'd, but who refuse to examine the fundamental problem which has yet to be addressed. Of course, many of these people claim to be fighting for "free speech" when they're really more interested in "free beer", truth be known...
I don't see how this differs practically from offering it under the LGPL while offering commercial terms as an alternative. Both provide a free version licensed under "viral terms", and both would require copyright assignation from all contributors.
The LGPL would allow proprietary vendors to exploit the Wine developers by linking a proprietary product to Winelib, distributing it for profit, and not giving anything back to the community. The only area where this isn't the case is when that product requires the core Wine code to be patched to work -- those patches would have to be contributed back under the LGPL. However, the better and better Wine gets, the less proprietary vendors will need to give back and the more effectively they'll be able to exploit the hard work of the Wine contributors...
The full GPL would be more effective, since it would apply to the entire application, and give vendors an incentive to pay for an alternative.
As for "choosing which viral license", the GPL is one of the few copyleft licenses which demands that other code use the exact same license -- many other Open Source licenses demand characteristics of the other license(s) such as source code availability (like Sleepycat does), which allows you to mix-and-match licenses to a certain degree.
Well I don't claim to know much about wine but I was under the impression that it was primarily created to allow Win32 applications to run under x86-Linux/Unix so it would be quite useless if only open source Win32 apps were allowed to use it without a special arrangement, after all I doubt MS will buy a license so Office can run under Linux!
I'm thinking of cases like Corel's WordPerfect Office 2000 for Linux, which shipped with Wine as part of the product -- those should require a proprietary license if they don't want to release the source code to the Office suite.
Anything which is distributed for Windows and just being used with Wine incidentally (like Microsoft Office) should be usable for free, though perhaps a clause in the license would be needed to make that explicit?
There are simple answers to this. Sleepycat is a company, WINE isn't. Sleepycat owns the copyright to all the code in Berkeley DB. Copyright to WINE code is owned by numerous developers around the world, not all of whom would agree on proprietary licensing terms.
Sleepycat is a company that was formed for the purpose of developing and marketing the Berkeley DB codebase. Why not a similar company for Wine? Yes, it would be necessary to get copyrights assigned to such a company from many contributors, or at least relicensing rights, but to change to a license like LGPL requires the same cooperation from contributors. If some disagree, perhaps those parts could be reimplemented.
If necessary, the company could be designated as a non-profit to ensure that revenue received would not be used to line anybody's pockets. There could even be clauses in the corporate charter to prevent later conversion to for-profit status, I imagine.
If such a corporation could afford to hire developers full-time who currently can only afford to work on Wine in their spare time, wouldn't that be a Good Thing?
The Wine project might be well served by imitating Sleepycat and their dual-licensing model for Berkeley DB.
Berkeley DB started as a small embedded database library which only supported hash tables and btrees. Since it was written for BSD Unix as a replacement, it was released under the BSD license. After a few years, it was widely used, but it still only offered access methods. When Netscape wanted more features, such as transactions, disaster recovery and multiple-user support, Sleepycat Software was founded to further develop Berkeley DB (on the strength of a licensing deal with Netscape).
The new version of the software was released under the Sleepycat license, an OSI-approved license which allows Open Source applications to use Berkeley DB, but (unlike the GPL) appears to be compatible with any Open Source license. For proprietary applications, Sleepycat offers a more traditional licensing option to companies who don't wish to distribute their source code. Revenue from such licensing funds additional development of Berkeley DB, to the benefit of all. (For example, Berkeley DB 4.x adds replication and high-availability functionality that surely would not exist without the funding received through this dual licensing.)
Perhaps the Wine project should follow this example? Wine could be placed under a license like Sleepycat's, which would allow Wine to be freely used by Open Source projects (whether GPL or not), and proprietary companies could pay for a license which allows proprietary use. Funding from such licensing could be used to further develop Wine, to the benefit of proprietary and Open Source users alike.
BSD or LGPL licensing allows proprietary companies to profit from the hard work of the Open Source developers without giving anything back. Sleepycat's licensing model forces them to give something back, either by contributing more Open Source code back to the community, or by paying cash for the privilege of avoiding that -- which could then be used to fund development that would benefit the Open Source community.
It's a win-win situation, and it would ensure that contributors don't get exploited. It could also lead to funding that might greatly accelerate the development of Wine, even more than relying on companies like Corel to contribute back changes they've made to the codebase.
I'm not a contributor to Wine, but I'd suggest they consider following Sleepycat's example -- it appears to work well for them, why not for Wine?
Desktop Unix is dead. Sun lost that battle ten years ago.
I think this statement is premature. Desktop Unix isn't dead. Maybe GNOME and KDE aren't ready for the mainstream, but Mac OS X certainly is, and it's indisputably a Desktop Unix system...
I really wanted to submit comments about the settlement, but I knew it would require effort to compose a good comment about it, so I hadn't gotten around to it yet. A recent story reminded me that the deadline was imminent, so I wanted to make it a priority to make sure I didn't forget -- I kept a browser window open to a page about it, so I would not forget to get back to it before the deadline.
Nevertheless, I missed the deadline. Why? Because Mozilla crashed and lost all my open browser windows! I had no idea what pages those windows were open to, so I couldn't recover from the crash. All of that state information was lost forever, including the page that was up to remind me to submit a comment about the proposed Microsoft settlement...
I find it rather ironic that I didn't get to send in a comment about Microsoft crushing Netscape -- because Mozilla crashed! *sigh*
BAD idea. Throwing in all the major architectural changes at once will result in total chaos that is going to be next to impossible to fix.
Well, I was just trying to come up with something that could be used for the Linux kernel, and which would hopefully reflect the existing development process to some degree. Unfortunately, it appears that "total chaos" is the usual state of the Linux kernel soon after forking off a new development series. (Didn't early 1.1.x, 1.3.x, 2.1,x and 2.3.x kernels all have this sort of chaos?)
And yes, it's hard to fix -- which might explain why it seems to take 2-3 years to get from one stable series to the next! A more controlled development process might work better, but that's not up to me...
In the end, I abandoned this all-numeric version numbering scheme anyhow. I'm trying a different scheme now, but I haven't nailed down all the details or written it up yet...
I hope you moderators appreciate this is just this guy's idea, and not actually the current release versioning system used for 2.5. The fact that he made 2.5.3 bold would lead you to believe otherwise.
:-) (Interested parties can send me email and I'll mail a copy of the writeup...)
Actually, it was my idea (posted to the linux-kernel mailing list on May 10, 2000), but the other poster above didn't bother to attribute credit for it. (Although I think it was really more of a sarcastic comment on 2.5.3's stability, the way that section was bolded.)
That was an idea I came up with off the top of my head, looking for a way to move the "should be stable but oops, not" kernels out of the "stable" series into the "development" series (thinking of 2.2.0 for example) -- by adding a fourth digit to indicate the status, so that release candidates could get production testing before getting branded as "stable". Once a fourth digit was added, I figured that I might as well try to fill in the other numbers with vague-but-useful state indicators for earlier stages of development. That post to linux-kernel was my first attempt, off the top of my head.
I developed this idea further, in response to some of the discussion on linux-kernel about my idea, but in the end I decided against using it. My brother convinced me that encoding this much meaning into numeric identifiers required a lot of advance knowledge about the system to make any sense of the version numbers, and harried system administrators wouldn't take the time to learn.
I finally decided to use a different approach, where "stable" releases are all-numeric numbers (e.g. 1.0.0) while "development" releases always contain an alphabetic intended-state tag (e.g. 1.0.0.beta.1) and discarding the even/odd notion from Linux. This way, development versions are more self-identifying, and release candidates (suitable for production testing) would have an "rc" tag (e.g. 1.0.0.rc.3).
The idea is that the "stable" release (e.g. 1.0.0) would be completely identical to the last "rc" release (e.g. 1.0.0.rc.3) except for the version number change. If there's a temptation to add "one last patch" (no matter how minor), make a new "rc" version and let it make the rounds first. This would avoid embarassments like 2.2.0 and certain 2.4.x releases, which are marked "stable" by their version number, but were quite unstable in practice...
I tried to include my writeup of the all-numeric system I ended up with before I gave up on it, but Slashdot's "lameness filter" rejected it. Maybe it's a sign.
Please, PLEASE, TiVo, stay with MPEG!
Who said they were dropping MPEG? They've agreed to use RealNetworks technology for music management, not to replace the video codec for recording television programs!
We had a very clear picture of the features for 1.0. When the decoder was feature complete and frozen, we called the release RC1. As far as implementors are concerned, this is a feature complete release.
I have to agree with the previous poster. This is nitpicking, for which I apologize, but making substantial changes to the encoder between "release candidates" just doesn't make sense. In my mind, a "release candidate" should only be used for final bugfixes before a release. That's clearly not what's happening here, or you wouldn't see any improvement in audio quality between the RC1 and RC4 encoders.
Don't get me wrong; I fully support wanting to get the quality to a particular level before blessing a final 1.0 release. That's great! But please don't call it a "release candidate" if you're still tweaking the encoder.
It would be better to go through a series of "final" 0.x releases (each with its own release candidate(s) to fix bugs) with progressively better encoders, and not declare a 1.0 release candidate until you're satisfied with the encoder and have no intent to tweak it further before the final 1.0 release.
Of course, it's a bit late for that now. But it's food for thought -- it would have been a lot less confusing to have 0.9.1 instead of RC1, 0.9.2 instead of RC2, etc. When people see RC1 vs. RC3 they tend to assume they're functionally equivalent, but with more bugs squashed in RC3.
That's not what we have here, and some people who have RC1 working acceptably might not even realize it's worth upgrading to RC3, RC4 or the final 1.0 release. After all, if you're not tripping over any of the bugs in the release candidate, why worry about upgrading it?
I'm afraid it's just confusing, and it doesn't seem necessary to confuse people like that...
in microserfs they cottoned on to playing subtitled movies at 2x which was still comfortable enough to read (no chipmunking of voices). can't do this with a tivo though as the status bar comes exactly where the subtitles usually are.
Of course you can do this with a TiVo. No, not at 2x, but you could do it at 3x, the slowest fast-forward speed. The status bar clears after a second or two at this speed, which would allow you to see subtitles. You can also clear it manually (in any fast-forward/rewind/pause mode) by pressing the Clear button.
The best trick? Turn on Closed Captioning in your TV, and watch it at 3x. The TiVo is clever enough to play back CC data even at 3x, which really lets you catch up fast. (If you skip commercials, you could probably watch a 1-hour program in 14-17 minutes.) If there's a lot of talking, it might not be able to keep up with the CC data, but usually it works pretty well.
Can UltimateTV display CC data at an accelerated rate like this?
No, you can't transfer the lifetime subscription to another unit, but you can transfer it to a new owner. It will be worth just as much to the next owner of the unit as buying it himself would be worth, which might even be more than it is now, if the price goes up again. So, even if you expect to sell the box within 2 years, it's still a no-brainer to get the lifetime service...
The only real danger is if the box breaks before the 2 years are up, and you don't have warranty coverage. If you insist on voiding your warranty, you might want to pay monthly until you've done the upgrade and give it a month or three to run, then buy the lifetime service when you're pretty sure it will last a couple more years.
If you're going to void the warranty, be prepared for the risk that entails. (Some have claimed that upgrading the TiVo unit doesn't void Circuit City's extended warranty, but I'm not sure I believe that...)
The point about GNU/Linux is not to demand credit. The point is simply that the system is called GNU, and its kernel is called Linux. You don't call OS X "Darwin", do you? Technically, GNU/Linux is simply the correct term. That's all. If you prefer to call the system Linux, simply ignore RMS.
The correct term is "OS X" only because that's what Apple decided to call the system. If they had decided to call the system "Darwin", then that would be the correct term. Apple made the OS X system, so they call it whatever they want. They don't have to call it "BSD/OS X" just because it depends heavily on BSD, and I don't hear any BSD zealots demanding that they change the name to "BSD/OS X". The BSD folks are happy to know that OS X wouldn't exist without BSD.
Technically, "GNU/Linux" is simply not a correct term, unless you're referring to a Debian distribution. I'm not aware of any other Linux distribution that uses "GNU/Linux" in its name. "GNU/Linux" is an attention-grabbing term invented by RMS because he feels slighted that Linux gets more attention than the GNU system.
He's being disrespectful to the distribution authors who chose not to use "GNU/Linux" in the name, by demanding that others corrupt the name in reference to any of those distributions. Whoever makes a complete system (e.g. any Linux distribution) has the right to name that system. RMS has no right to demand naming rights on any system created by someone else.
RMS could have had the FSF jump on Linux and build the first Linux distribution. They could have called that distribution "the GNU system" and never mentioned Linux in the name. Chances are, "GNU" would be getting all the attention instead of "Linux" if he had done so.
Instead, the FSF was convinced that the HURD was a better kernel, even if it wasn't quite finished. Rather than seize a golden opportunity to complete their GNU system and set the naming example for others to follow, they ignored Linux entirely. As a result, distributions like "Slackware Linux" and "Red Hat Linux" followed.
If RMS wasn't so fixated on the presumed superiority of the HURD over Linux, might we instead have "Slackware GNU" and "Red Hat GNU" now? And RMS might be the folk hero instead of Linus Torvalds? Basically, RMS squandered a golden opportunity, and his insistence on "GNU/Linux" is just sour graps on his part.
Because X Windows is considered part of the "GNU system" even though it's not GNU software. I quote:Okay, now. If what RMS is saying there is okay, and "X Windows" becomes part of the "GNU system" (Not the "GNU/X-Windows system", mind you), then how would the following hypothetical quote be any less reasonable?RMS can't have it both ways. If he wants to adopt the X Window System like that as part of the "GNU system", then he has no right to complain that most of the pieces of the GNU system were adopted in the same way for the "Linux system". Maybe RMS feels that the GNU system was appropriated for Linux, and perhaps it was. But RMS set the precedent!
If you have a Linux system with no GNU software on it, call it Linux, and even RMS will have to admit you are right.
If I have a Linux system, that's what I'll call it, whether or not it has GNU software. RMS isn't the only one with the right to give an overall name to a system he creates without regard to the source of each component of the system....
I have little doubt it's being exploited -- I've received several mystery emails with apparent "WAV files" in them. Since I'm using Pine under Linux, it's not being executed, but when I save the file and look at it with "less", this supposed audio file contains the text "This program requires Microsoft Windows." Obviously it's a Windows executable, and why else would I receive it tagged as an audio file unless that would exploit a bug to allow an executable to run instead of playing an audio file?
Not true. I have IE running on my Solaris box. Nothing windows related on it. There is no autoexec.bat file, or anyhing else that looks like it belongs in windows.
I heard that Microsoft basically implemented the entire Win32 API on top of Solaris, then linked IE (using Win32 calls) to that API implementation to make a workable but inefficient binary. I don't know if this is true, but it doesn't seem unlikely. You wouldn't necessarily be able to tell, since it could all be linked into the single executable from a static library...
Somehow I doubt RMS sees the irony. I wrote a short piece about this back on March 31, 1999: Why "GNU/Linux" is a Misnomer In the 2.5 years since then, the FSF still has not released a GNU distribution, relying instead on the Debian project to do what they won't.
Given that "The GNU Project" doesn't credit the X Window System anywhere in its name, RMS has no moral high ground to stand on when he demands that all Linux-based systems be referred to as "GNU/Linux" systems.
It's doubly ironic that the older BSD license was incompatible with the GPL specifically because of the so-called "advertising clause" that requires credit be given for the BSD-licensed software.
Isn't it funny how RMS feels it isn't necessary to credit BSD or X Windows, yet demands such credit for the GNU project? It's disingenuous hypocrisy, through and through. If someone makes a free software distribution, they should be able to call it anything they want, whether "GNU", "Linux", "BSD" or anything else is included in the name.
After all, wasn't this all supposed to be about freedom? I guess that doesn't include the freedom to choose the name...
Wouldn't this kind of money be better spent paying good programmers to work on Linux full-time to close the gap? Just think how easily Linux could take the desktop if it could run Windows applications as well as Windows 98 (or even Windows 95).
The API is less of a moving target now that Microsoft's having more and more trouble getting people to upgrade to newer versions of Windows. If Wine could achieve a near-perfect level of Windows 98 compatibility (business apps especially, not just games), then people would have little excuse not to run Linux on the desktop.
Forget a WSJ ad -- that's just a flashy stunt. Remember how fast all those dot-coms started tanking after they overextended themselves to advertise in the Super Bowl? (Like pets.com?) Instead of wasting serious money on ephemeral advertising, use it to pay highly-skilled programmers to do the unsexy work that needs to be done, which won't get done (or not well) by a developer "scratching his own itch".
I'm starting to wonder if some sort of not-quite-open source model would be more effective. Charge a modest membership fee (maybe $10-20/month for individuals, more for companies) to "join the club" and allow unlimited use and access to source code for club members, who could share improvements with each other. Use the membership fees to fund new development.
There are millions of people using Linux every day. Heck, even if you only charged $20/year, you could fund a lot of development with over $20 million in annual funding... (To be credible, such a scheme would need to be operated on a nonprofit basis, and all the better if greater contributions could be tax-deductable...) Okay, maybe it's a pipe dream. And it doesn't really mesh well with the altruistic intent of Free Software. (But code could be automatically re-licensed to become true Free Software as it's replaced with newer versions, like Alladin vs. GNU Ghostscript...)
Don't flame me for this, it's just an idea. Even though millions of people benefit from existing free software, most of whom could afford at least a small contribution to bettering that software, we always seem to rely heavily on unpaid volunteer work, despite the fact that those volunteers need to eat and pay their bills. This often means they need a day job, and can only do so much work on the free software in their "free time". Most free software programmers can't rely on consulting income (insisting on free software) like RMS can. And for-profit companies like Red Hat certainly don't redistribute their profits to the volunteers who made their business possible, even if they do give them a whack at an IPO. (That's a gamble, look at VA Linux at IPO time and now...)
If people could pay for something similar to free software, with the money going to improve that software rather than to line the pockets of corporate shareholders, wouldn't that be preferable to being cornered into using commercial software because adequate free replacements aren't quite ready for prime time yet?
So I said: "I cannot help you..." And I walked off the gig.
You did the right thing. Too bad that level of integrity isn't universal; your replacement was probably foolish enough to go along with it.
I have to wonder what the FDA, HHS, HCFA and other Federal agencies would think about such reckless disregard for patient safety. I suspect various regulators might take an issue with it. Even if they didn't, it's just begging for a multimillion-dollar "wrongful death" civil suit, sooner or later.
With the health-care industry's penchant for "risk management", you'd think they would jump at the opportunity to avoid potential future lawsuits by designing in more data integrity from the start, expecially when advised to do so by the experts they hire. Go figure...