I think that software companies should have to submit all source to the copyright office for exactly this reason. The concept of things falling into the public domain includes them being in a useful state when they do, and software won't be.
I agree, and there's a good public-policy argument to be made here. Too bad the "content industry" has convinced Congress that the purpose of copyright is to enrich them, and the "copyright bargain" has been completely forgotten. Of course, for this to work, you'd have to reverse the Berne convention and go back to requiring copyrights to be registered. (Which probably would be a good thing for the public interest as well, but that's another point.)
While punishment may not be a goal of antitrust action, restoring competition and denying the monopolist the fruits of their illegal behavior are both legitimate goals of antitrust action. The latter might be misinterpreted by some as punishment. It's not; why should a monopolist be allowed to retain benefits reaped from breaking the law? That serves as an incentive for lawbreaking, so the illicit benefits must be confiscated. This is not punitive action; it's "natural consequences" for breaking antitrust law.
I haven't read the code, but I don't use Python. To "clean-room" that file, you would need it written in Python from a description? I could do it in Perl, which you could port. How long/complex is the code?
As for legal disclaimers, the ALL CAPS is indeed ugly, Unfortunately, it's not pointless -- many laws require that certain disclaimers must be presented in all caps to be valid. (Yes, it's stupid; people get used to the caps and still tend not to really read it and realize what it says.) If you change those disclaimers from ALL CAPS to more readable mixed case, you may inadvertantly negate some of the legal protection they're meant to provide. (IANAL; this is not legal advice!)
Right click on the img, do "view image". I get a screenful of garbage as moz renders the PNG as text. How amusing;)
Well, that might have something to do with the fact that the webserver is returning a content-type of "text/html", not "image/png"...
Re:OFMG I thought it could never happen...
on
Google Experiments
·
· Score: 2
...but you've Slashdotted google!#*(@Q$#^$
wow.
This wasn't a production service. Google's production search engine is on a massive server farm that already takes so many hits that "slashdotting" Google probably wouldn't even be a blip on the radar. This wasn't even a beta service not in full production yet. The only thing that got Slashdotted was a single machine setup for experimental services. Since the services were purely experimental, they were NOT designed to take a production load. Of course a single box runnning experimental code can be Slashdotted. If they ever decide to turn any of these experimental services into production ones, you can bet the production platform won't be so easily brought down.
You think you can Slashdot Google? Feel free to try! Let me know when www.google.com is down. Taking down an experimental service is meaningless. (And might discourage them from offering experimental services for you to play with!)
Due to some sort of brain damage, www.ofx.net returns a redirect to "http://ofx/default.asp". On some browsers (Galeon, in this case), this ends up going to www.ofx.com instead. Until the OFX website fixes that link, try this one...
Sounds interesting...got some linkage you could share to elaborate?
After some searching on Google, it looks like he's probably referring to these cases, both of which involve attorneys filing patent infringement lawsuits without adequately investigating the infringement claims first:
I remember using SunView/SunWindows on a Sun 3/50 before NeWS came out. Slow hardware, yet it was VERY snappy. I used NeWS for as long as I had it available to me, but eventually I ended up using X11 by default. NeWS was quite a bit slower than SunView, but I didn't find it unacceptably slow. Today's machines are so fast that I can't imagine it would feel slow at all on a current system. (Porting it to run under Linux on an x86 system might take some effort, though.)
Even at the time (1988?), I wished that Sun would distribute NeWS as freely (source and binary) as X11 was, and I was sure that the difference in licensing would doom NeWS to an early demise. I wish I had been wrong about that one, but NeWS died much as I expected. I've always wanted to be able to go back to using NeWS, but without the code, it would require reimplementation of a clone. Even with Ghostscript available, that was a daunting project to consider, though I know that I'm not the only one who contemplated it.
Maybe we should take the hint and try to organize a group that would be willing to pick up NeWS and maintain it. I'll take a shot at coordinating such an effort. Anyone who is interested in seeing NeWS released, who would be willing to help maintain it (if we can get Sun to release it), please email me about it. Please be sure to include the word "NeWS" (in mixed case like that) somewhere in the Subject line, so my mail filter can catch the messages before they end up in a spam-catching folder!
Generally however we've found that the cost of open sourcing code for a proprietary product is non-trivial. I know it seems counter-intuitive but consider this: the reality is you can't just toss code over the fence. You have to first scrub it to make sure you have the rights to release it (your question acknowledges this difficulty). You also have to provide resources to answer questions and generally support those who are trying to pick up the code. Typically you have to develop additional documentation as well.
For a project like OpenOffice, this is true. What about dead products? If a product is no longer being sold or supported, why not just toss the code over the fence? Okay, you have to scan the code to make sure you own the copyright, but how difficult is that? Surely any file coming from another company will be clearly marked with a copyright notice? Rip out anything you don't own the rights to, add a couple lines in a README file to identify what was removed (if anything was), and then just toss the code (and any existing documentation) over the fence, gaping holes and all.
Don't spend a lot of time on the extras and supporting those who want to pick up the code, if it doesn't make business sense. Just toss it over the fence, unsupported, and leave it alone to find its own community. Maybe it will, or maybe it won't, but at least it'll have a chance.
If you don't release the code because there's no business justification to polishing it up and supporting the release, that just guarantees that nobody will benefit. If it's a dead product that's not making you any money anymore, what's to lose? A few hours scanning the code for copyright notices, and a few administrative and legal approvals to go ahead?
Why not give that code a chance for a second life as free software, if it has reached the end of its days as a commercial product? The sunk costs of developing the software are already gone, and there's always the chance that the code could become something worthwhile. It certainly can't hurt, and it could potentially benefit you, in PR value if nowhere else.
Let me give a concrete example. I'd like to see Sun's old NeWS (Network-extensible Windowing System) codebase released as free software. Not the bastardized X11/NeWS merged server, but the old NeWS 1.1 standalone server. It was mostly (if not entirely) Sun's code, and it ran remarkably well, even on the anemic machines of its day. On a present-day machine, it would be quite snappy indeed. The NeWS code could probably be merged with Ghostscript to make a very powerful Display PostScript-like windowing system. Another attempt could even be made to merge it with X11, if that's what people wanted to do with it. NeWS was a very promising technology that was never supported much by Sun, and it was clobbered by X11 mostly because X11 was free and NeWS was proprietary. Like the VHS vs. Betamax wars, the inferior but cheaper product won. X11 has improved greatly in the past decade, but there are still things it can't do that NeWS did in the late 80's.
NeWS is a dead product and it's not making Sun any money, which makes all the effort that went into it wasted. Why not toss it over the fence? Even if nobody picks it up, the code would be better off "in the wild" than locked up in Suns vaults!
Lastly there's the issue of ongoing liability. Large companies have deep pockets. When a company releases a product it at times comes with a warranty which the company is willing to offer because the risk is offset by revenue. There has to be some significant value to the licensor to justify the risk. Make no mistake, whenever a large company converts a product to Open Source it's because that strategy has in some way been positively tied to the bottom line.
What liability? If you're tossing the code over the fence, obviously that's not a release where you would choose to offer a warranty. Even commercial software is usually plastered with warnings about how it comes with NO WARRANTY, etc. This sounds like a red herring. Do you know of any actual examples of such liability actually having a material effect? A large company sued (successfully) over software that was released with NO WARRANTY disclaimers? Or is this just paranoid legal speculation that there could be some sort of theoretical liability, so we have to run far, far away from it?
And really, if it's such a risk, SELL the rights to a small company (for $1), who can then toss it over the fence and take the risk of someone suing them, with their smaller pockets...
What about the AMA or the AAUP? Do doctors and university professors qualify as "skilled workers"? How about state bar associations? Are lawyers skilled enough for you?
I don't think there's any inherent reason why skilled workers can't be organized into unions, but getting from here to there might be easier said than done. Like it or not, many HR departments view IT workers as fungible resources, even if they're not. If some IT workers try to unionize, chances are good that the company would fire the lot of them and find replacements. Unless you're indispensible and they know it, forget about trying to form an IT union.
Now, whether or not unionizing IT workers would be good or bad for them, I don't know. Like most things, it would probably have pros (job security) and cons (union scale pay). Of course, with the levels of job security recently, maybe IT workers will start to change their priorities?
I live about 10 minutes from the Springdale, OH theater, but they have nothing like that (and its only a couple years old).
I live in Greenhills, which is within 10 minutes of that Springdale theater. I wasn't aware that they have a DLP projector, but they do. In fact, my wife saw a digital movie projected by their DLP projector; she said it was incredible, and she was very disappointed with the quality next time she saw a normal film. (I guess I'll have to make a point of going to see a digital movie there soon!)
I wish the publishers would wisen up and include with the paper book a CD containing an e-book version
It's rare, but not unheard of. Adobe has included CD-ROMs with the paper editions of PostScript Language Reference Manual and the PDF Reference, both of which contain the full text of the book in PDF format. In fact, Adobe also makes those books (and other information) available for download from their website...
While it's important to have the proper security checks, this article only focuses on *possibilities*
Moreover, why focus on MP3 players and digital cameras? If someone really wants to smuggle in some sort of cracking tool, what's the most obvious way to do it? On a CD-R. Heck, they could even burn music on it as a mixed-mode disc and use that to hide its true purpose. "This is a mix CD of my favorite songs -- here, listen to it on my walkman!"
If you can't trust your employees, you've got a serious problem, period. They'll probably find a way around whatever restrictions you try to place on them -- it would be better to treat employees right so they won't want to screw you...
At the price of absolutely terrible performance and scalability. UDI support has been soundly rejected by Linus Torvalds, Alan Cox, Peter Anvin, et al every time it's been brought up.
It doesn't seem like they've really given it a fair chance. From what I heard, they looked at it a little, decided it looked complicated (which it is) and presumed that complicated == slow (which is an unwarranted presumption), decided that the whole UDI thing was just a ploy by Intel to get Linux folks to do all their driver work for them (Intel was late to the game), and started railing against what a terrible idea UDI support was.
And, of course, once a determination like that has been made, everyone's going to be even more close-minded about evaluating it in the future, preferring to rely on their bad first impression than look closer at it.
I've heard the comment that a 5% loss in performance would be so terrible that it wouldn't be worth using UDI if it made things that "slow". Nevermind that native drivers could run alongside UDI drivers in the cases where performance really matters that much...
According to the UDI developers, they're getting equal or better performance on Unixware compared to native drivers, despite the extra overhead of layering the UDI environment on top of those same native drivers! It should be possible to make a more efficient implementation that is faster yet. The UDI design always had performance and scalability in mind.
It's not just Linux developers who think the idea sucks, either -- that's why it's not supported by other OSes as well.
Stop the presses! People don't want to chuck out legacy interfaces and have to learn something new? Who could have imagined that would happen?
Of course UDI has an adoption problem. Everyone wants to keep doing things the way that's always worked for them, regardless of what's best for themselves and the industry in the long run.
UDI offers 100% portability from one OS to the next. Plenty of Linux users have complained bitterly when no Linux driver is available for their hardware -- you think they wouldn't be happy with a working driver, even if it's a little slower than a native driver might be? Yes, we're starting to see some native Linux drivers written by hardware vendors, but more often they expect the Linux community to do the actual work anyhow.
What about other alternative operating systems? If every Linux driver was available as a UDI driver, those drivers could be used on FreeBSD, BeOS, GNU HURD, or any other operating system -- just write a UDI environment for that OS once and all the UDI drivers suddenly become available. Richard Stallman should jump at this, but instead he decided it was a ploy by Intel to leech free driver efforts from free software developers. Why should those developers waste time porting each driver to each OS? What a waste of talent!
Linux is in a stronger position than it used to be; hardware driver support isn't as comprehensive as for Windows, but it's probably #2 now. That doesn't really help HURD, FreeBSD, OpenBSD, NetBSD, BeOS, and every other alternative OS out there, and the closed-source Linux drivers out there couldn't even be ported. UDI drivers could run unmodified across a range of OS platforms.
UDI also offers many safety and security benefits that native Linux drivers don't have. Misbehaving UDI drivers could be killed and restarted by the OS without harming the system, if the environment implements such protections -- the drivers could even be implemented in user mode if desired. Hardware drivers are often blamed for system crashes, especially on Windows -- wouldn't it be great to be able to protect the system from any drivers which couldn't be trusted not to misbehave? (Performance-critical drivers could be configured not to be protected as much.)
There are a lot of good reasons to support UDI, and the main objections (performance, scalability, etc.) all seem to be based more on perception than actual experience with UDI. That's unfortunate, because the potential benefits are enormous, and everyone is too busy dismissing the idea out of hand to even try to make it work.
Don't we all know what it's like to be the underdogs in terms of hardware support? Many other alternative OS users are much worse off than Linux users in this. Must we forever have this morass of legacy driver interfaces and eschew fundamental advancements in the state of the art? (UDI is a clear advancement, at least in interoperability, and possibly in design as well.)
There's some pretty sharp people working on the Linux kernel. I bet they could make some highly efficient UDI implementations, if they wanted to. The design always had performance in mind (zero copy, DMA, etc.) but the prototypes and reference implementation were never highly performance-oriented. The portability of UDI has been proven, and even without a focus on performance, they've been able to rival the performance of native drivers. Imagine what the Linux kernel hackers could do if they did focus on performance in a UDI implementation?
There are good, technical reasons dealing with maintenance going forward for not wanting to enable closed source drivers.
Could that be because so many Linux kernel changes have required mass updates of driver code to match? UDI is designed to abstract out all of that stuff into the UDI environment on the OS side. Old drivers should continue to work as well as they ever did, since the UDI interface is more stable than the Linux internals...
But there are two sides to an interface: the driver and the OS.
How well can UDI cope with the ferment that is the Linux kernel: things changing to make them faster, cleaner, etc.
Everything OS-specific is encapsulated within the "UDI environment", which is the OS side of the UDI implementation. An environment needs to be created to allow an OS to use UDI drivers, and this might be relatively difficult to do at first, but it only needs to be done once for the OS.
When something changes in the OS requiring a change to the device drivers, that change occurs once in the UDI environment, rather than repeatedly for every relevant driver. That's the advantage of using a clean API...
I suppose it's reasonable to expect a company to produce drivers for Linux, but remember, there are umpteen billion operating systems out there, and these companies don't have the time or resources to develop for all of them.
That's why we should all be supporting Project UDI (Uniform Driver Interface). You write a hardware driver once and it works (unchanged) on all UDI-enabled operating systems. What could be better?
I'm a network admin for a city govt. MS audited us last year. They found that we actually had a surplus of licenses above and beyond what software we had deployed. What prompted them to audit us? I highly suspect it is because we had been very vocal, anti-MS bashing to everyone we talked to and loudly announcing our plans to deploy as much Linux and phase out all MS products as we possibly could. The MS/BSA goons were furious when they couldn't find anything out of compliance.
I love it! That's as good as getting audited by the IRS and receiving a refund in response. Now, if only more audits would have these results... (You probably had better bookkeeping than most; it's common for documentation of licenses and purchases to be misplaced, unfortunately...)
Anyone out there have a hack for sendmail that will simply blackhole mail bound for a given address? Just drop the connection when the offending RCPT command is received?
If you want to key on sender address or domain, the "access" database can contain a REJECT or DISCARD entry. (With DISCARD, it will seem to be accepted but get silently discarded.)
To blackhole all inbound email to a given address, the simplest solution is simply to alias that address to "/dev/null". If it starts with a "/", sendmail will use the *file* mailer, which will append the message to the file like it does with a normal Unix mailbox. Of course, with/dev/null as the pathname of the mailbox...
If you're tired of obvious patents like this, then do something about it! This patent is a golden opportunity to shine some light on the disgrace that the patent office has become. This is a smoking gun!
The computer industry suffers increasingly from bad patents being granted on obvious techniques which are far from novel. This trend is obvious to us, but not so clearcut to those outside the industry. An XOR cursor may be obvious to a programmer, but sounds quite novel and non-obvious to a layperson. This patent should be blatently obvious to anyone, including your elected representatives!
Everyone who reads Slashdot and hates to see obvious patents should print out this patent, schedule a face-to-face meeting with their elected representatives, show them this ridiculous patent and use it to drive home the point we've been trying to make for years -- that the patent office is out of control and completely ignoring the "novel and non-obvious" standards that the law sets before patent protection is warranted. If enough of us do this, Congress might actually get the hint and start taking patent reform seriously. And this patent doesn't require them to take our word for it; they can see for themselves how absurd this patent is! It doesn't matter if this patent was requested as a lark; it was granted and has the full force of law behind it.
We need Congress to be outraged about this patent as an example of the corruption in the system. Whether or not this particular patent could or would ever be enforced is irrelevant; if patents are granted on obvious methods, it harms the public interest by granting a legal monopoly on the obvious. That impedes progress and economic growth, endangers companies and jobs, and erodes public trust and confidence in the government -- all things that Congress ought to care about...
I don't recall the actual buildings, but I believe some monument has an Al top part
You're thinking of the Washington Monument. Apparently it cost $225 (in 1884) and was actually intended as part of a lightning rod system for the structure, not as a tribute. (Not as good of a story, I admit!)
GPL is an
enabling license. It allows people to do things with code that they usually are not allowed to do. It's not as enabling as the BSD license, but very deliberately so.
Yes, it enables you to do things you otherwise couldn't, but it comes with a steep price. The GPL attempts to enforce a monoculture. Even if it's one with high-minded, altruistic ideals, that doesn't mean that having a monoculture is a good thing.
What is this possible danger you speak of?
The danger is that the GPL codebase could eventually outstrip the capabilities of all commercial software out there. Right now, this sounds like a great thing; we don't really care for the restrictions on proprietary software. However, what happens if the economic costs of redevelopment force most developers to use GPL code, when the cost of commercial software makes it impossible to compete with GPL code?
Who will fund development of GPL software for the good of all when it's not important enough for anyone to fund on their own? The danger is that we'll be less likely to see any "spectacular" software because most developers will stop at "good enough" instead, assuming they get that far.
A world with a lot of GPL software does not preclude commercial (non-GPL) development. It does make it harder for companies to sell crap. To me this seems like a good thing for all parties, save for those in the business of marketting sows' ears as silk purses. And good riddance to them.
There's certainly a lot of crappy proprietary software out there. There's also some spectacular proprietary software, such as Google's search engine. There's plenty of crappy free software out there along with some spectacular free software. Neither side has consistent quality. Anyhow, I agree -- good riddance to those companies selling crap software. (SoftRAM is an excellent example -- their product was flashy but completely worthless.)
What about companies who want to sell good software? How will they make enough money to defray the cost of software development if free software is the norm, and anyone can get their software free from a buddy instead of paying for it? When no customers are willing to pay for proprietary software because they've bought into Stallman's rhetoric? Those companies would be doomed, no matter how good their software may be.
Stallman would be pleased, of course. He wants to obliterate proprietary software from the world, and the GPL is his chosen weapon to perform this genocide. Stallman's goal is an all-out war, with the GPL and "free software" on one side and all proprietary software on the other side. There can be no doubt on this point; he wrote articles about Why Software Should Not Have Owners and Why Software Should Be Free which make his hatred for proprietary software quite clear. Choice quotes include:
there is no limit to the harm that proprietary software development can do - A rather strong statement considering that the usual argument in defense of the viral nature of the GPL is that one can pretend it doesn't exist and do without it. One could equally pretend proprietary software doesn't exist, yet there is "no limit" to the harm it can do?
since the owner has a monopoly on changes, the fee tends to be large - Maybe, or maybe it's expensive because custom programming is difficult work that takes a lot of skilled labor, of which there is a limited supply? (Did Stallman make a living charging nominal fees for custom work? Or did he charge $300/hour?)
society shouldn't have owners for programs - This is a pretty unambiguous statement of his viewpoint and goals.
programmers often work for the Foundation for half of what they could make elsewhere - So programmers should have to sacrifice their income for the good of all? Stallman says $35,000/year should be sufficient incentive to program for a living; did he ever do custom programming work for $17.50/hour?
[a moral obligation to support developers] does not apply to proprietary software developers, since obstructionism deserves a punishment rather than a reward - Now he's not just saying to prefer free software over proprietary software, but that those proprietary software developers deserved to be punished for their "obstructionism"? That sure sounds like "fighting words" to me...
the users will learn to support developers without coercion, just as they have learned to support public radio and television stations - If the public is so willing to support public radio and television "without coercion", why must they inevitably resort to pledge drives?
withholding information that could help everyone advance is a form of combat - The GPL does exactly such withholding from proprietary developers, hence the GPL is a form of combat. Again, there's no doubt that proprietary software is an enemy here, not just something to coexist with.
if we are to judge views by their resemblance to Russian Communism, it is the software owners who are the Communists - This is a bizarre accusation, and hypocritical, considering the diatribe elsewhere about "name calling".
most of what I have to say is addressed only to those who share the premises I use - Nobody is allowed to question the premises used; let's just preach to the choir.
the owner can lose only if the person who made the copy would otherwise have paid for one from the owner - True, but most people won't pay if they don't have to. When free software is the norm and the vast majority won't pay, how will development be funded?
society needs to encourage the spirit of voluntary cooperation in its citizens - Great sentiment, and a wonderful ideal. Unfortunately, nobody has found a way to implement such a utopia. It seems that individuals are too self-interested to do what's best for everyone, most of the time.
if your friend asks to make a copy [of proprietary software], it would be wrong to refuse - So now it's immoral not to break the law? If the law is wrong (not a given), then civil disobediance should be a choice, not a moral obligation...
Stallman treats this as a war, make no mistake about it.
The benefits are a much better educated programming community. Even if one is developing commercial software, one can learn from the wide availability of source in a GPL-rich world. Sure you can't copy that source, but it's not like you can now, anyway.
This goal could be achieved by convincing proprietary developers to go back to the old ways and start distributing source code with their products again. They could also allow their customers to modify that code to repair bugs or add features according to that customer's needs. They could even be allowed to redistribute such changes to other customers. These are good things, and there's no reason not to encourage them; they pose no inherent danger to the industry.
The problem is not with the users getting source; the problem is with demanding that all users be allowed to give the software away at will to those who've never paid anything for it. This destroys the market for that software. Nobody has proven that altruism works on a large scale. No rational person (or company) would shoulder the burden of funding development for everyone when that burden will exceed the value to that person or company, no matter how valuable it might be to the world.
Stallman claims his goal is the empowerment of the users. This is partly true, but the fatal flaw in his philosophy is demanding the right to give away the work of others for free. That's just a form of neo-communism, and no matter how lofty the ideals, there's no proof that it can work as a viable economic model. Many nation-states have tried, none have been very successful. Why should we believe that the GPL's form of communism will be more successful than those nation-states?
If Stallman truly wants to empower the users, he should focus on the value of sharing source and allowing modifications, not his neo-communist ideas about how we're morally obligated to share anything we have with our friends on request...
Microsoft is saying exactly the same thing. If you don't want to use their technology, use something else instead. If you do want to use it, you have to abide by their license.
That's a valid point. Is turnabout fair play? Since the GPL deliberately refuses to "play nice" with proprietary software, and the GPL codebase is starting to grow to a point where Microsoft feels threatened, is it any wonder that Microsoft wants to keep their technologies from "playing nice" with the GPL as well? Yes, Microsoft is a dangerous monopoly that needs to be reigned in, and the remaining states have the right idea. Nevertheless, Microsoft has some valid concerns about the GPL. The GPL has always been the underdog, but an all-GPL world may well be as dangerous as an all-Microsoft world, albeit in different ways.
We scoff at the obtuseness of Microsoft apologists who fail to see the obvious (to us) dangers of an all-Microsoft world. At the same time, we have GPL zealots eagerly awaiting an all-GPL world, turning a blind eye to the ramifications and possible dangers therein. Some will consider this heresy, but could we perhaps be as myopic as the Microsoft apologists we scorn so easily? Who will pay for polished end-user software to be developed when there's no money to be made from sales?
We may like and support free software, but do we actually want ALL software in the world to be viral free software? In the end, is pro-GPL extremism really any better than pro-Microsoft extremism?
What I do want is toilets that flush completely in only 1.6 gallons of water per flush.
Having grown sick and tired of plunging our old crappy toilet (so to speak!), I went looking for a new one that would (hopefully) save me from that sort of hassle. After some research online, I went with a Toto toilet. Not one with all of the fancy electronics described in the story (this has none), but one with a glazed computer-designed trapway and a very powerful flush.
This is a gravity-powered model, not pressure-assisted, so it's quiet. It flushes fast (3-5 seconds) and powerfully because it uses a 3-inch valve in the tank instead of the usual 2-inch one. (That's over twice as much area.) It's officially a 1.6-gallon flush, but you can hold down the handle longer for more water if you want.
High-tech toilets are worthwhile to me to the extent that they can save me from plunging. Seat warmers and spray jets and electronic controls seem like overkill to me. So far, we haven't had any problems at all with this toilet, but we've only had it a week. If a year goes by without having to use a plunger, then I might buy another one for our second bathroom. (But they're expensive; if it doesn't live up to its claims, I'll not make the same mistake twice.) Despite the low water usage, this thing is astonishingly powerful, and the siphon jet creates some serious suction that just pulls everything down the drain. (If you press the handle too quick, it won't wash the bowl much, but that can be solved by making sure you press the handle all the way down.)
Since I've only had one week of experience with this toilet, it's too early for me to recommend it, but I've seen others recommend it highly, so far it's working well in my experience. Ask me in a year...
Slashdot Mirror
I think that software companies should have to submit all source to the copyright office for exactly this reason. The concept of things falling into the public domain includes them being in a useful state when they do, and software won't be.
I agree, and there's a good public-policy argument to be made here. Too bad the "content industry" has convinced Congress that the purpose of copyright is to enrich them, and the "copyright bargain" has been completely forgotten. Of course, for this to work, you'd have to reverse the Berne convention and go back to requiring copyrights to be registered. (Which probably would be a good thing for the public interest as well, but that's another point.)
While punishment may not be a goal of antitrust action, restoring competition and denying the monopolist the fruits of their illegal behavior are both legitimate goals of antitrust action. The latter might be misinterpreted by some as punishment. It's not; why should a monopolist be allowed to retain benefits reaped from breaking the law? That serves as an incentive for lawbreaking, so the illicit benefits must be confiscated. This is not punitive action; it's "natural consequences" for breaking antitrust law.
I haven't read the code, but I don't use Python. To "clean-room" that file, you would need it written in Python from a description? I could do it in Perl, which you could port. How long/complex is the code?
As for legal disclaimers, the ALL CAPS is indeed ugly, Unfortunately, it's not pointless -- many laws require that certain disclaimers must be presented in all caps to be valid. (Yes, it's stupid; people get used to the caps and still tend not to really read it and realize what it says.) If you change those disclaimers from ALL CAPS to more readable mixed case, you may inadvertantly negate some of the legal protection they're meant to provide. (IANAL; this is not legal advice!)
Right click on the img, do "view image". I get a screenful of garbage as moz renders the PNG as text. How amusing ;)
Well, that might have something to do with the fact that the webserver is returning a content-type of "text/html", not "image/png"...
wow.
This wasn't a production service. Google's production search engine is on a massive server farm that already takes so many hits that "slashdotting" Google probably wouldn't even be a blip on the radar. This wasn't even a beta service not in full production yet. The only thing that got Slashdotted was a single machine setup for experimental services. Since the services were purely experimental, they were NOT designed to take a production load. Of course a single box runnning experimental code can be Slashdotted. If they ever decide to turn any of these experimental services into production ones, you can bet the production platform won't be so easily brought down.
You think you can Slashdot Google? Feel free to try! Let me know when www.google.com is down. Taking down an experimental service is meaningless. (And might discourage them from offering experimental services for you to play with!)
Due to some sort of brain damage, www.ofx.net returns a redirect to "http://ofx/default.asp". On some browsers (Galeon, in this case), this ends up going to www.ofx.com instead. Until the OFX website fixes that link, try this one...
Sounds interesting...got some linkage you could share to elaborate?
After some searching on Google, it looks like he's probably referring to these cases, both of which involve attorneys filing patent infringement lawsuits without adequately investigating the infringement claims first:
Judin v. United States (1997)
Antonious v. Spalding (2002)
I remember using SunView/SunWindows on a Sun 3/50 before NeWS came out. Slow hardware, yet it was VERY snappy. I used NeWS for as long as I had it available to me, but eventually I ended up using X11 by default. NeWS was quite a bit slower than SunView, but I didn't find it unacceptably slow. Today's machines are so fast that I can't imagine it would feel slow at all on a current system. (Porting it to run under Linux on an x86 system might take some effort, though.)
Even at the time (1988?), I wished that Sun would distribute NeWS as freely (source and binary) as X11 was, and I was sure that the difference in licensing would doom NeWS to an early demise. I wish I had been wrong about that one, but NeWS died much as I expected. I've always wanted to be able to go back to using NeWS, but without the code, it would require reimplementation of a clone. Even with Ghostscript available, that was a daunting project to consider, though I know that I'm not the only one who contemplated it.
Maybe we should take the hint and try to organize a group that would be willing to pick up NeWS and maintain it. I'll take a shot at coordinating such an effort. Anyone who is interested in seeing NeWS released, who would be willing to help maintain it (if we can get Sun to release it), please email me about it. Please be sure to include the word "NeWS" (in mixed case like that) somewhere in the Subject line, so my mail filter can catch the messages before they end up in a spam-catching folder!
Generally however we've found that the cost of open sourcing code for a proprietary product is non-trivial. I know it seems counter-intuitive but consider this: the reality is you can't just toss code over the fence. You have to first scrub it to make sure you have the rights to release it (your question acknowledges this difficulty). You also have to provide resources to answer questions and generally support those who are trying to pick up the code. Typically you have to develop additional documentation as well.
For a project like OpenOffice, this is true. What about dead products? If a product is no longer being sold or supported, why not just toss the code over the fence? Okay, you have to scan the code to make sure you own the copyright, but how difficult is that? Surely any file coming from another company will be clearly marked with a copyright notice? Rip out anything you don't own the rights to, add a couple lines in a README file to identify what was removed (if anything was), and then just toss the code (and any existing documentation) over the fence, gaping holes and all.
Don't spend a lot of time on the extras and supporting those who want to pick up the code, if it doesn't make business sense. Just toss it over the fence, unsupported, and leave it alone to find its own community. Maybe it will, or maybe it won't, but at least it'll have a chance.
If you don't release the code because there's no business justification to polishing it up and supporting the release, that just guarantees that nobody will benefit. If it's a dead product that's not making you any money anymore, what's to lose? A few hours scanning the code for copyright notices, and a few administrative and legal approvals to go ahead?
Why not give that code a chance for a second life as free software, if it has reached the end of its days as a commercial product? The sunk costs of developing the software are already gone, and there's always the chance that the code could become something worthwhile. It certainly can't hurt, and it could potentially benefit you, in PR value if nowhere else.
Let me give a concrete example. I'd like to see Sun's old NeWS (Network-extensible Windowing System) codebase released as free software. Not the bastardized X11/NeWS merged server, but the old NeWS 1.1 standalone server. It was mostly (if not entirely) Sun's code, and it ran remarkably well, even on the anemic machines of its day. On a present-day machine, it would be quite snappy indeed. The NeWS code could probably be merged with Ghostscript to make a very powerful Display PostScript-like windowing system. Another attempt could even be made to merge it with X11, if that's what people wanted to do with it. NeWS was a very promising technology that was never supported much by Sun, and it was clobbered by X11 mostly because X11 was free and NeWS was proprietary. Like the VHS vs. Betamax wars, the inferior but cheaper product won. X11 has improved greatly in the past decade, but there are still things it can't do that NeWS did in the late 80's.
NeWS is a dead product and it's not making Sun any money, which makes all the effort that went into it wasted. Why not toss it over the fence? Even if nobody picks it up, the code would be better off "in the wild" than locked up in Suns vaults!
Lastly there's the issue of ongoing liability. Large companies have deep pockets. When a company releases a product it at times comes with a warranty which the company is willing to offer because the risk is offset by revenue. There has to be some significant value to the licensor to justify the risk. Make no mistake, whenever a large company converts a product to Open Source it's because that strategy has in some way been positively tied to the bottom line.
What liability? If you're tossing the code over the fence, obviously that's not a release where you would choose to offer a warranty. Even commercial software is usually plastered with warnings about how it comes with NO WARRANTY, etc. This sounds like a red herring. Do you know of any actual examples of such liability actually having a material effect? A large company sued (successfully) over software that was released with NO WARRANTY disclaimers? Or is this just paranoid legal speculation that there could be some sort of theoretical liability, so we have to run far, far away from it?
And really, if it's such a risk, SELL the rights to a small company (for $1), who can then toss it over the fence and take the risk of someone suing them, with their smaller pockets...
What about the AMA or the AAUP? Do doctors and university professors qualify as "skilled workers"? How about state bar associations? Are lawyers skilled enough for you?
I don't think there's any inherent reason why skilled workers can't be organized into unions, but getting from here to there might be easier said than done. Like it or not, many HR departments view IT workers as fungible resources, even if they're not. If some IT workers try to unionize, chances are good that the company would fire the lot of them and find replacements. Unless you're indispensible and they know it, forget about trying to form an IT union.
Now, whether or not unionizing IT workers would be good or bad for them, I don't know. Like most things, it would probably have pros (job security) and cons (union scale pay). Of course, with the levels of job security recently, maybe IT workers will start to change their priorities?
Small world, huh?
I live about 10 minutes from the Springdale, OH theater, but they have nothing like that (and its only a couple years old).
I live in Greenhills, which is within 10 minutes of that Springdale theater. I wasn't aware that they have a DLP projector, but they do. In fact, my wife saw a digital movie projected by their DLP projector; she said it was incredible, and she was very disappointed with the quality next time she saw a normal film. (I guess I'll have to make a point of going to see a digital movie there soon!)
I wish the publishers would wisen up and include with the paper book a CD containing an e-book version
It's rare, but not unheard of. Adobe has included CD-ROMs with the paper editions of PostScript Language Reference Manual and the PDF Reference, both of which contain the full text of the book in PDF format. In fact, Adobe also makes those books (and other information) available for download from their website...
While it's important to have the proper security checks, this article only focuses on *possibilities*
Moreover, why focus on MP3 players and digital cameras? If someone really wants to smuggle in some sort of cracking tool, what's the most obvious way to do it? On a CD-R. Heck, they could even burn music on it as a mixed-mode disc and use that to hide its true purpose. "This is a mix CD of my favorite songs -- here, listen to it on my walkman!"
If you can't trust your employees, you've got a serious problem, period. They'll probably find a way around whatever restrictions you try to place on them -- it would be better to treat employees right so they won't want to screw you...
At the price of absolutely terrible performance and scalability. UDI support has been soundly rejected by Linus Torvalds, Alan Cox, Peter Anvin, et al every time it's been brought up.
It doesn't seem like they've really given it a fair chance. From what I heard, they looked at it a little, decided it looked complicated (which it is) and presumed that complicated == slow (which is an unwarranted presumption), decided that the whole UDI thing was just a ploy by Intel to get Linux folks to do all their driver work for them (Intel was late to the game), and started railing against what a terrible idea UDI support was.
And, of course, once a determination like that has been made, everyone's going to be even more close-minded about evaluating it in the future, preferring to rely on their bad first impression than look closer at it.
I've heard the comment that a 5% loss in performance would be so terrible that it wouldn't be worth using UDI if it made things that "slow". Nevermind that native drivers could run alongside UDI drivers in the cases where performance really matters that much...
According to the UDI developers, they're getting equal or better performance on Unixware compared to native drivers, despite the extra overhead of layering the UDI environment on top of those same native drivers! It should be possible to make a more efficient implementation that is faster yet. The UDI design always had performance and scalability in mind.
It's not just Linux developers who think the idea sucks, either -- that's why it's not supported by other OSes as well.
Stop the presses! People don't want to chuck out legacy interfaces and have to learn something new? Who could have imagined that would happen?
Of course UDI has an adoption problem. Everyone wants to keep doing things the way that's always worked for them, regardless of what's best for themselves and the industry in the long run.
UDI offers 100% portability from one OS to the next. Plenty of Linux users have complained bitterly when no Linux driver is available for their hardware -- you think they wouldn't be happy with a working driver, even if it's a little slower than a native driver might be? Yes, we're starting to see some native Linux drivers written by hardware vendors, but more often they expect the Linux community to do the actual work anyhow.
What about other alternative operating systems? If every Linux driver was available as a UDI driver, those drivers could be used on FreeBSD, BeOS, GNU HURD, or any other operating system -- just write a UDI environment for that OS once and all the UDI drivers suddenly become available. Richard Stallman should jump at this, but instead he decided it was a ploy by Intel to leech free driver efforts from free software developers. Why should those developers waste time porting each driver to each OS? What a waste of talent!
Linux is in a stronger position than it used to be; hardware driver support isn't as comprehensive as for Windows, but it's probably #2 now. That doesn't really help HURD, FreeBSD, OpenBSD, NetBSD, BeOS, and every other alternative OS out there, and the closed-source Linux drivers out there couldn't even be ported. UDI drivers could run unmodified across a range of OS platforms.
UDI also offers many safety and security benefits that native Linux drivers don't have. Misbehaving UDI drivers could be killed and restarted by the OS without harming the system, if the environment implements such protections -- the drivers could even be implemented in user mode if desired. Hardware drivers are often blamed for system crashes, especially on Windows -- wouldn't it be great to be able to protect the system from any drivers which couldn't be trusted not to misbehave? (Performance-critical drivers could be configured not to be protected as much.)
There are a lot of good reasons to support UDI, and the main objections (performance, scalability, etc.) all seem to be based more on perception than actual experience with UDI. That's unfortunate, because the potential benefits are enormous, and everyone is too busy dismissing the idea out of hand to even try to make it work.
Don't we all know what it's like to be the underdogs in terms of hardware support? Many other alternative OS users are much worse off than Linux users in this. Must we forever have this morass of legacy driver interfaces and eschew fundamental advancements in the state of the art? (UDI is a clear advancement, at least in interoperability, and possibly in design as well.)
There's some pretty sharp people working on the Linux kernel. I bet they could make some highly efficient UDI implementations, if they wanted to. The design always had performance in mind (zero copy, DMA, etc.) but the prototypes and reference implementation were never highly performance-oriented. The portability of UDI has been proven, and even without a focus on performance, they've been able to rival the performance of native drivers. Imagine what the Linux kernel hackers could do if they did focus on performance in a UDI implementation?
There are good, technical reasons dealing with maintenance going forward for not wanting to enable closed source drivers.
Could that be because so many Linux kernel changes have required mass updates of driver code to match? UDI is designed to abstract out all of that stuff into the UDI environment on the OS side. Old drivers should continue to work as well as they ever did, since the UDI interface is more stable than the Linux internals...
But there are two sides to an interface: the driver and the OS.
How well can UDI cope with the ferment that is the Linux kernel: things changing to make them faster, cleaner, etc.
Everything OS-specific is encapsulated within the "UDI environment", which is the OS side of the UDI implementation. An environment needs to be created to allow an OS to use UDI drivers, and this might be relatively difficult to do at first, but it only needs to be done once for the OS.
When something changes in the OS requiring a change to the device drivers, that change occurs once in the UDI environment, rather than repeatedly for every relevant driver. That's the advantage of using a clean API...
I suppose it's reasonable to expect a company to produce drivers for Linux, but remember, there are umpteen billion operating systems out there, and these companies don't have the time or resources to develop for all of them.
That's why we should all be supporting Project UDI (Uniform Driver Interface). You write a hardware driver once and it works (unchanged) on all UDI-enabled operating systems. What could be better?
I'm a network admin for a city govt. MS audited us last year. They found that we actually had a surplus of licenses above and beyond what software we had deployed. What prompted them to audit us? I highly suspect it is because we had been very vocal, anti-MS bashing to everyone we talked to and loudly announcing our plans to deploy as much Linux and phase out all MS products as we possibly could. The MS/BSA goons were furious when they couldn't find anything out of compliance.
I love it! That's as good as getting audited by the IRS and receiving a refund in response. Now, if only more audits would have these results... (You probably had better bookkeeping than most; it's common for documentation of licenses and purchases to be misplaced, unfortunately...)
Anyone out there have a hack for sendmail that will simply blackhole mail bound for a given address? Just drop the connection when the offending RCPT command is received?
/dev/null as the pathname of the mailbox...
If you want to key on sender address or domain, the "access" database can contain a REJECT or DISCARD entry. (With DISCARD, it will seem to be accepted but get silently discarded.)
To blackhole all inbound email to a given address, the simplest solution is simply to alias that address to "/dev/null". If it starts with a "/", sendmail will use the *file* mailer, which will append the message to the file like it does with a normal Unix mailbox. Of course, with
If you're tired of obvious patents like this, then do something about it! This patent is a golden opportunity to shine some light on the disgrace that the patent office has become. This is a smoking gun!
The computer industry suffers increasingly from bad patents being granted on obvious techniques which are far from novel. This trend is obvious to us, but not so clearcut to those outside the industry. An XOR cursor may be obvious to a programmer, but sounds quite novel and non-obvious to a layperson. This patent should be blatently obvious to anyone, including your elected representatives!
Everyone who reads Slashdot and hates to see obvious patents should print out this patent, schedule a face-to-face meeting with their elected representatives, show them this ridiculous patent and use it to drive home the point we've been trying to make for years -- that the patent office is out of control and completely ignoring the "novel and non-obvious" standards that the law sets before patent protection is warranted. If enough of us do this, Congress might actually get the hint and start taking patent reform seriously. And this patent doesn't require them to take our word for it; they can see for themselves how absurd this patent is! It doesn't matter if this patent was requested as a lark; it was granted and has the full force of law behind it.
We need Congress to be outraged about this patent as an example of the corruption in the system. Whether or not this particular patent could or would ever be enforced is irrelevant; if patents are granted on obvious methods, it harms the public interest by granting a legal monopoly on the obvious. That impedes progress and economic growth, endangers companies and jobs, and erodes public trust and confidence in the government -- all things that Congress ought to care about...
I don't recall the actual buildings, but I believe some monument has an Al top part
You're thinking of the Washington Monument. Apparently it cost $225 (in 1884) and was actually intended as part of a lightning rod system for the structure, not as a tribute. (Not as good of a story, I admit!)
Who will fund development of GPL software for the good of all when it's not important enough for anyone to fund on their own? The danger is that we'll be less likely to see any "spectacular" software because most developers will stop at "good enough" instead, assuming they get that far.There's certainly a lot of crappy proprietary software out there. There's also some spectacular proprietary software, such as Google's search engine. There's plenty of crappy free software out there along with some spectacular free software. Neither side has consistent quality. Anyhow, I agree -- good riddance to those companies selling crap software. (SoftRAM is an excellent example -- their product was flashy but completely worthless.)
What about companies who want to sell good software? How will they make enough money to defray the cost of software development if free software is the norm, and anyone can get their software free from a buddy instead of paying for it? When no customers are willing to pay for proprietary software because they've bought into Stallman's rhetoric? Those companies would be doomed, no matter how good their software may be.
Stallman would be pleased, of course. He wants to obliterate proprietary software from the world, and the GPL is his chosen weapon to perform this genocide. Stallman's goal is an all-out war, with the GPL and "free software" on one side and all proprietary software on the other side. There can be no doubt on this point; he wrote articles about Why Software Should Not Have Owners and Why Software Should Be Free which make his hatred for proprietary software quite clear. Choice quotes include:
- there is no limit to the harm that proprietary software development can do - A rather strong statement considering that the usual argument in defense of the viral nature of the GPL is that one can pretend it doesn't exist and do without it. One could equally pretend proprietary software doesn't exist, yet there is "no limit" to the harm it can do?
- since the owner has a monopoly on changes, the fee tends to be large - Maybe, or maybe it's expensive because custom programming is difficult work that takes a lot of skilled labor, of which there is a limited supply? (Did Stallman make a living charging nominal fees for custom work? Or did he charge $300/hour?)
- society shouldn't have owners for programs - This is a pretty unambiguous statement of his viewpoint and goals.
- programmers often work for the Foundation for half of what they could make elsewhere - So programmers should have to sacrifice their income for the good of all? Stallman says $35,000/year should be sufficient incentive to program for a living; did he ever do custom programming work for $17.50/hour?
- [a moral obligation to support developers] does not apply to proprietary software developers, since obstructionism deserves a punishment rather than a reward - Now he's not just saying to prefer free software over proprietary software, but that those proprietary software developers deserved to be punished for their "obstructionism"? That sure sounds like "fighting words" to me...
- the users will learn to support developers without coercion, just as they have learned to support public radio and television stations - If the public is so willing to support public radio and television "without coercion", why must they inevitably resort to pledge drives?
- withholding information that could help everyone advance is a form of combat - The GPL does exactly such withholding from proprietary developers, hence the GPL is a form of combat. Again, there's no doubt that proprietary software is an enemy here, not just something to coexist with.
- if we are to judge views by their resemblance to Russian Communism, it is the software owners who are the Communists - This is a bizarre accusation, and hypocritical, considering the diatribe elsewhere about "name calling".
- most of what I have to say is addressed only to those who share the premises I use - Nobody is allowed to question the premises used; let's just preach to the choir.
- the owner can lose only if the person who made the copy would otherwise have paid for one from the owner - True, but most people won't pay if they don't have to. When free software is the norm and the vast majority won't pay, how will development be funded?
- society needs to encourage the spirit of voluntary cooperation in its citizens - Great sentiment, and a wonderful ideal. Unfortunately, nobody has found a way to implement such a utopia. It seems that individuals are too self-interested to do what's best for everyone, most of the time.
- if your friend asks to make a copy [of proprietary software], it would be wrong to refuse - So now it's immoral not to break the law? If the law is wrong (not a given), then civil disobediance should be a choice, not a moral obligation...
Stallman treats this as a war, make no mistake about it.This goal could be achieved by convincing proprietary developers to go back to the old ways and start distributing source code with their products again. They could also allow their customers to modify that code to repair bugs or add features according to that customer's needs. They could even be allowed to redistribute such changes to other customers. These are good things, and there's no reason not to encourage them; they pose no inherent danger to the industry.The problem is not with the users getting source; the problem is with demanding that all users be allowed to give the software away at will to those who've never paid anything for it. This destroys the market for that software. Nobody has proven that altruism works on a large scale. No rational person (or company) would shoulder the burden of funding development for everyone when that burden will exceed the value to that person or company, no matter how valuable it might be to the world.
Stallman claims his goal is the empowerment of the users. This is partly true, but the fatal flaw in his philosophy is demanding the right to give away the work of others for free. That's just a form of neo-communism, and no matter how lofty the ideals, there's no proof that it can work as a viable economic model. Many nation-states have tried, none have been very successful. Why should we believe that the GPL's form of communism will be more successful than those nation-states?
If Stallman truly wants to empower the users, he should focus on the value of sharing source and allowing modifications, not his neo-communist ideas about how we're morally obligated to share anything we have with our friends on request...
Microsoft is saying exactly the same thing. If you don't want to use their technology, use something else instead. If you do want to use it, you have to abide by their license.
That's a valid point. Is turnabout fair play? Since the GPL deliberately refuses to "play nice" with proprietary software, and the GPL codebase is starting to grow to a point where Microsoft feels threatened, is it any wonder that Microsoft wants to keep their technologies from "playing nice" with the GPL as well? Yes, Microsoft is a dangerous monopoly that needs to be reigned in, and the remaining states have the right idea. Nevertheless, Microsoft has some valid concerns about the GPL. The GPL has always been the underdog, but an all-GPL world may well be as dangerous as an all-Microsoft world, albeit in different ways.
We scoff at the obtuseness of Microsoft apologists who fail to see the obvious (to us) dangers of an all-Microsoft world. At the same time, we have GPL zealots eagerly awaiting an all-GPL world, turning a blind eye to the ramifications and possible dangers therein. Some will consider this heresy, but could we perhaps be as myopic as the Microsoft apologists we scorn so easily? Who will pay for polished end-user software to be developed when there's no money to be made from sales?
We may like and support free software, but do we actually want ALL software in the world to be viral free software? In the end, is pro-GPL extremism really any better than pro-Microsoft extremism?
What I do want is toilets that flush completely in only 1.6 gallons of water per flush.
Having grown sick and tired of plunging our old crappy toilet (so to speak!), I went looking for a new one that would (hopefully) save me from that sort of hassle. After some research online, I went with a Toto toilet. Not one with all of the fancy electronics described in the story (this has none), but one with a glazed computer-designed trapway and a very powerful flush.
This is a gravity-powered model, not pressure-assisted, so it's quiet. It flushes fast (3-5 seconds) and powerfully because it uses a 3-inch valve in the tank instead of the usual 2-inch one. (That's over twice as much area.) It's officially a 1.6-gallon flush, but you can hold down the handle longer for more water if you want.
High-tech toilets are worthwhile to me to the extent that they can save me from plunging. Seat warmers and spray jets and electronic controls seem like overkill to me. So far, we haven't had any problems at all with this toilet, but we've only had it a week. If a year goes by without having to use a plunger, then I might buy another one for our second bathroom. (But they're expensive; if it doesn't live up to its claims, I'll not make the same mistake twice.) Despite the low water usage, this thing is astonishingly powerful, and the siphon jet creates some serious suction that just pulls everything down the drain. (If you press the handle too quick, it won't wash the bowl much, but that can be solved by making sure you press the handle all the way down.)
Since I've only had one week of experience with this toilet, it's too early for me to recommend it, but I've seen others recommend it highly, so far it's working well in my experience. Ask me in a year...