Games were responsible for creating the market which enabled 3dfx and NVidia to mass-product $100 graphics chips which outperform $100,000 Silicon Graphics workstations. In terms of technological progress, we game developers are way more influential than most of us realize.
My father has argued for years that the ``real purpose'' of the personal computer is gaming. Everything else is just an excuse to develop and buy these fabulously expensive toys.
For a long time, I thought it was a pretty funny joke, but a couple of years ago I realized that he was exactly right in a very real sense. No other market drives the demand for powerful hardware as much as the game market. There are few applications that really demand such high processor speeds or bus clock rates or monster graphics cards, and those applications tend to be special-purpose high-end professional tools like CAD or scientific visualization software. Gaming is an end-user luxury market, and is the chief reason for the constantly increasing bleeding edge of the computer hardware market.
It's true. The real reason that the personal computer exists is so that we can play games. It's very fortunate that we have been able to construct this multi-billion-dollar industry to hide that fact.
If I remember right, DeCSS is released under GPL. If it is, then publishing the sources as part of the case documents still falls under the GPL's legalize; nothing in DeCSS has changed because the sources were published in a legal document.
IANAL and all that, but I don't think this analysis makes sense. Slapping the GPL on a piece of software is meaningless if you don't have the right to license it in the first place.
This case is all about determining who has the legal right to write, reverse engineer, or distribute CSS code. If the courts determine that reverse engineering CSS was a violation of the DVD user license, I believe that would make DeCSS the property of DVD-CCA even though the code was written by Jon Johansen. That, in turn, would mean that no one else, including Jon Johansen, has the right to license the code, making the version that appeared under the GPL null and void.
Ergo, we cannot safely assume that DeCSS is a GPLed document just because it says it is. The legal status of DeCSS is exactly what is at stake here.
The Slashdot crowd enjoyed making fun of this when it was first posted here, but like it or not, there are some real concerns that need to be answered.
Telecommuting is expected to continue rising in popularity. Employers could find themselves obliged to offer telecommuting benefits in order to attract good people (if this is not already happening). If it becomes widespread enough, they will surely seek ways to reduce or minimize costs.
For employers not to be held liable for preventable home-office injuries would be nothing less than a cash cow for corporations. It is not hard to imagine Fortune 1000 companies offering generous telecommuting plans in order to encourage employees to work at home, and thereby excusing themselves from any responsibility for their safety. Then, if you wind up with an RSI due to poor working conditions at home, the company takes no blame despite having pushed you into that situation.
It is exactly this sort of Catch-22 for employees that only regulation can prevent. While this is not an issue today, it may well be a problem soon. It is entirely appropriate for OSHA to consider the liabilities associated with telecommuting.
The OSHA decision may seem nutty, but there are some real issues that need to be addressed.
Telecommuting is expected to increase drastically in popularity over the next few years. It could lead to considerable savings in workplace maintenance costs if it really takes off. That gives employers an incentive to encourage telecommuting.
Now suppose that employers were not held responsible for injuries incurred in a home office. That would be a winning lottery ticket for any big corporation. They would cream their jeans over that. They couldn't encourage telecommuting fast enough if they had that out. Working 16 hours a day gave you a bad case of carpal tunnel? Sorry, not our fault, you did it at home! Got migraines from straining to read that 13" monitor? Sucks to be you, since you did it at home and not here.
From a safety standpoint, the home office must be considered part of the workplace in order to avoid giving the corporate sector an incredible opportunity to save big bucks at the expense of their employees' health. This is exactly the sort of thing that OSHA is supposed to be doing.
One of the more alarming trends in online censorship is the tendency for libraries, schools and school districts to enforce the use of censorware on their computers.
What are generally the most effective strategies for discouraging censorware in public institutions? Is it useful to document the famous false positives of censorware (e.g. tools which block the National Gay and Lesbian Task Force, the National Organization for Women, or the ACLU)? What other techniques have been persuasive?
If you intend to make your software as useful as it can be to as many people as you can, then you should make it free software. Which is a terrible word, because of word games from the FSF. I mean free as in "gift". As in "free of restrictions" or as in "no strings attached".
Speaking of word games, there is no such thing as a "license" which is "free of restrictions." To license your software ipso facto restricts the way it is used, copied or distributed; if there were no restrictions on these things, there would be no need to license it.
If you want your software to be free of restrictions, place it in the public domain. Anything else is a restricted license and is "non-free" by this definition. I happen to think that's a silly, pointless way to define "free", but YMMV.
Emacs was an editor made by RMS before he founded the FSF. (And in my opinion it's only fair to call it a Free Software project rather than an Open Source.) As to its developments after it was licensed under the GPL, make no mistake, it was very much a cathedral style project. It's developers were an elitist group, and most certainly did not accept patches from anyone.
I'm amazed at how far the disinformation campaign has come.
I am looking at the documentation for Emacs 20.3. The Acknowledgements chapter thanks over 200 people by name for their contributions to Emacs over the years. I am quite sure that those people were not all principal maintainers of Emacs. Most of them are credited with contributing only one feature, which indicates that they were not part of some rarified Emacs Clique but merely randoms who had good ideas.
Every piece of evidence I can find indicates that RMS recognized the technical value of free software from the very beginning. From the GNU Manifesto:
Once GNU is written.... much wasteful duplication of system programming effort will be avoided.
I would like to see GNU development supported by gifts from many manufacturers and users, reducing the cost to each.
Other people may use the GNU system simply because it is technically superior.
Even just the free support that consists of my fixing bugs people report to me and incorporating that in the next release has given people a good level of support.
I find it mystifying that Linus is getting credited with inventing these concepts.
[Linus] was surprised when people started turning in patches, his only ambition he'd only expected people to say good or bad. The development style came from nowhere, but make no mistake, it was new.
It was not new. Linus knew perfectly well in 1991 that people who liked the software they were using would contribute bug fixes and improvements. This pattern was, indeed, commonplace even then. What surprised him, as he's said before, was the enthusiasm with which people took to his project, not the mere fact that someone would choose to submit a patch.
Linux as an OS certainly won't last forever, but in the long run Linus just might be remembered not for writing an OS but for creating a whole new kind of development process, one that isn't going away.
The whole idea of 'release early, release often', invite patches from everybody, and huge-team development was actually pretty different from the way even gnu worked at the time.
This is essentially a myth. In The Cathedral and the Bazaar, ESR argues the merits of a "bazaar" model by contrasting it with a "cathedral" model of closed software development. The examples of "bazaar" development he presents are Linux and fetchmail to represent the "bazaar," and his example of a "cathedral" project is.... Emacs.
How's that again? Emacs is not an open source project? It does not invite patches from everybody? It does not incorporate contributions from an army of individual hackers? It has not made all its bugs shallow by offering its source code to millions of eyeballs?
The plain weirdness of this comparison still leaves me puzzled. What is it supposed to mean, in a paper whose thesis is the fundamental superiority of open source over closed source? That Emacs is essentially a closed-source project? That it has more in common with NT than it does with vi? These notions are absurd, but it is hard to draw a different conclusion.
The truth is that these development models are quantitatively different, but not qualitatively different. While Linux development is more frenetic than that of FSF mainstays like Emacs or GCC, nightly snapshots and frequent releases are only modest differences in style. They are essentially personality differences; even GNU and BSD projects include nightly snapshots, after all. They don't constitute a sea change in software design.
While no one invented the open source software ethic, it appears likely that Richard Stallman will get more credit than any other individual, which is IMHO as it should be. Many, many people created projects, but Stallman created the movement. More people became conscious of free software and open source as a philosophy through Project GNU than through any other source, Linux included. Linus didn't create the development process; Stallman did.
Sendmail is really not a bad choice. If you can get over your fear of the sendmail.cf language, it's very servicable on a modern machine.
Sendmail's "insecurity" is largely a myth at this point. I do not recall seeing a root exploit since Sendmail-8.8, which was about three years ago. While qmail and Postfix can legitimately brag about being designed for security from the ground up, the sendmail team has done a pretty good cleanup job.
Doubting Thomases should consider that OpenBSD, the famously "ultra-secure" operating system, ships with sendmail, not qmail. How many people think that Theo de Raadt would put up with shipping software that has known exploits?
We use sendmail to run one of the largest mailing list sites in the world. My experiments with qmail were pretty hideous; qmail has serious problems out of the box with high-volume delivery. The mail queue backed up by several thousand messages, and one big list actually caused the server to crash. (I am told that there are patches available to improve qmail's performance on very-high-volume sites. We have not had the opportunity to try them, but given my experience I am not sure that we want to.)
I'm actually not a big fan of sendmail qua sendmail. But anti-sendmail sentiment is just pretty overblown these days, and the rebellion hype is not convincing. Sendmail is one of the classic open source success stories, it is a fine piece of software with a great future, and an excellent choice for a project to support.
I believe this is correct. If the reason that Corel added the "not a minor" clause to their EULA is that minors cannot enter into contracts, then they might as well have added a clause that said, "I am legally able to enter into this contract." Like the liar who always says he tells the truth, this is a meaningless clause -- what is to prevent a minor from signing the contract with or without this clause? It is still not binding.
The whole issue seems completely bogus. I don't trust the conventional wisdom.
What I found interesting is how short the interview was, and how little discussion there was about WC3 standards. In order to maintain control ov the client side of the net, it will be very important to be at least minimaly complient with the specs.
Of course it'll be minimally compliant; it has to interpret pages that were written for MSIE and Navigator and make them look attractive. This isn't particularly relevant to the Linux port of Opera.
Re:Check out the very funny STAND campaign website
on
Waiting for the Knock
·
· Score: 1
Their latest bit of campaigning was to send Jack Straw a letter which, if the legislation were to pass as proposed, would leave him liable for a two year jail sentence.
"Dear Mr Straw,
Please find at the end of the letter a confession to a crime, which has been affirmed by Statutory Declaration. The Commissioner of the Metropolitan Police has been informed that you are in possession of this information.
This seems like an insanely stupid stunt. Why is this not simply going to provide the key escrow crowd with more ammunition?
The computer magazines of the 1970s and early 1980s were better than almost anything I have read since. For example, SoftSide and 80 Micro, the old TRS-80 rags, were amazingly valuable sources of information. They covered everything, from useful machine language subroutines to undocumented operating system features to the occasional hardware hack. I still miss Jake Commander's columns on the TRS-80 CoCo ROM, and Dennis Báthory-Kitsz's homebrew kit articles.
For years, these magazines were essentially the only broadcast outlet for source code among hobbyists. You could legitimately put these magazines among open source pioneers -- in those days, publishing source essentially was the only way to make your software available to a wide audience, and infused many of us with a healthy respect for the value of making source code available to everyone.
Not many magazines carry on the same sort of anything-goes attitude. Dr. Dobb's Journal comes close, and they usually provide an interesting read, but they often seem too easily distracted by vaporware and buzzware to be really compelling. The Perl Journal was pretty promising when I last saw it (but who has time to read magazines these days?)
...with the GPL people can modify your work and distribute those modifications. This has practical value in the software community, but in the music community people want their work to remain unique and intact. I assume that authors would feel the same way.
That's very strange. I would have said that the exact opposite is true.
There is a great tradition in music of creating new derivative works from earlier songs. These days we mostly get "cover songs" that are usually heavily bastardized versions of classic popular songs, not really worthwhile, but jazz and blues music is deeply rooted in a history of borrowing, begging and stealing music. Jimi Hendrix's cover of The Star-Spangled Banner is a good well-known example.
That is not to say that the GPL would be a good model to use for music, just that musicians are hardly averse to reusing and reinterpreting each others' work.
or start a seperate protest website for this stuff?
The League for Programming Freedom was once upon a time the chief organization that fought software patents. For a time they kind of dissipated, but can now be found at http://lpf.ai.mit.edu/.
The LPF now chiefly appears to be a news site. If there are Slashdotters who have financial, political or legal expertise to throw at this problem, contributing those gifts to LPF would be a wonderful and important thing to do.
Authentication in the real world today generally means Social Security Numbers. If you hand over an SSN, you can find out just about anything you want to know on someone's medical or bank records. The really sophisticated places might want to know your mother's maiden name or something.
Nearly anything is better than an SSN-based security system, even vanilla HTTP usernames and passwords. I would be frankly grateful to learn that my doctor was doing something like this. Obviously banks should be using real crypto, since financial institutions are much more likely to attract sniffers, but I'm unconvinced that hospitals need the same level of security.
That said, it seems like layering this on top of SSL should not be particularly difficult, and obviously makes the transaction much safer. The world is growing larger; while sniffers and crackers are unlikely to go after medical data today, it's unclear what the black market will pay for a year from now.
This wouldn't be so bad, except for the fact that somebody switched my full name and password around - so whenever I send mail through their relay, my password shows up on in the #$@! headers.
That's a shame, but it's still MediaOne's fault and not MAPS's.
The canonical Turing biography is Alan Turing: The Enigma by Andrew Hodges. The excellent play Breaking the Code was inspired by this book.
PBS also adapted the play, so you might also be able to find a copy of that if you hunt around. It stars Derek Jacobi, who also played Turing on the stage (in a fantastic performance).
One is that it is not easy to get into the RBL. First, someone who has received spam from your site needs to write up a nomination. It has to include not only a record of the spam itself, but also a description of attempts that they have made to contact your site, explain the problem and to resolve it.
If repeated attempts to resolve the problem with the site fails, then MAPS will consider the RBL nomination. An RBL staffer or volunteer will follow up and try to explain the gravity of the situation with the responsible people at your site, and will make it clear what an RBL listing means. Only at that point is it possible to add a site's network to the RBL.
The RBL is just about the most fastidiously maintained abuse tracking system on the Internet. In fact, that is the chief reason that it is used so widely -- a network doesn't get on the RBL unless it has proved itself to be really irresponsibly run.
The other salient point is that participation in the RBL is voluntary. No site is required to use MAPS' abuse lists. They do so because they need to block spam and find that MAPS fills that need.
Ultimately your complaints are better directed at your mother's ISP, for using the RBL, and (most of all) at your own ISP, for failing to run their systems responsibly. Blaming MAPS is like blaming Ralph Nader for making your seatbelt too tight.
Second, alot of ISP's subscribe to the DUL - which has the unfortunate effect of making my e-mail from my home box here (on a dialup) impossible to deliver to some locations.
Signal11 is talking about MAPS' Dialup User List, which helps a mail server identify a connection directly from a dialup IP at a remote site. Because legitimate users generally send mail through their ISP's own mail server, mail coming direct from a dialup account is almost always spam.
You need to learn about smarthosts (or whatever the equivalent is if you're using a trendy new MTA). If you route all of your mail traffic through your ISP's mail server, instead of connecting directly to remote MXes, your mail won't be blocked by dialup lists like the MAPS DUL. End of problem.
Ellen and I knew each other in passing from netnews. We were both news admins and hung out in soc.motss. True story: one summer I was experimenting with Usenet control messages and sent a botched newgroup message for alt.great-ass.swedish-chef. I got flames from three or four other admins and a note from Ellen saying, "Cut it out." That was the first mail she ever sent me.
So eventually I overcame the first impression and we became friends. In April 1993, we learned that we both planned to be at the March on Washington, and arranged to meet on the Mall. I am still not quite sure how we managed to find each other on the Mall in the middle of about three hundred thousand other people, but we did.
I never really believed in the phrase "love at first sight" before, but I do now. After that day, I went back to Massachusetts and she went back to Chicago. A little more than a year later, I drove across country and moved in with her. That was six years ago. We've been married now for four and have a son.
An important point is that this was not an "online relationship." We met, grew to know each other and became infatuated online, the first year of our relationship was spent a thousand miles apart, but it was fundamentally a real-life long distance relationship. The Internet precipitated bringing us together but was essentially the tool by which we remained in touch. Our first face-to-face meeting, and the ability to meet in person occasionally, was absolutely crucial to the development of our relationship. This would not have bloomed if we had carried it out exclusively online.
It's just a "Finding of Fact" from the Judge - he's selected all the facts presented to him, and determined what he finds to be true, and supported by the arguments presented.
I am not a lawyer, but I know enough to realize that this is not a final verdict, and that this trial could still go anywhere from this point on.
This isn't a jury trial. Jackson's word is final. The Finding of Fact represents a great deal of what the trial is all about, and his final ruling is going to stem directly from these findings.
It is very clear that Jackson's ruling is not going to be pro-Microsoft.
AOL will probably argue that it needs to rely on an image-heavy layout in order to stay competitive, but that's a hard thing to actually prove.
It's worth noting that some of the most successful sites on the web, such as Yahoo, use images only sparingly. I don't think it will be difficult to demonstrate that designing a site for accessibility does not mean sacrificing either content or competitive advantage.
Slashdot Mirror
Games were responsible for creating the market which enabled 3dfx and NVidia to mass-product $100 graphics chips which outperform $100,000 Silicon Graphics workstations. In terms of technological progress, we game developers are way more influential than most of us realize.
My father has argued for years that the ``real purpose'' of the personal computer is gaming. Everything else is just an excuse to develop and buy these fabulously expensive toys.
For a long time, I thought it was a pretty funny joke, but a couple of years ago I realized that he was exactly right in a very real sense. No other market drives the demand for powerful hardware as much as the game market. There are few applications that really demand such high processor speeds or bus clock rates or monster graphics cards, and those applications tend to be special-purpose high-end professional tools like CAD or scientific visualization software. Gaming is an end-user luxury market, and is the chief reason for the constantly increasing bleeding edge of the computer hardware market.
It's true. The real reason that the personal computer exists is so that we can play games. It's very fortunate that we have been able to construct this multi-billion-dollar industry to hide that fact.
If I remember right, DeCSS is released under GPL. If it is, then publishing the sources as part of the case documents still falls under the GPL's legalize; nothing in DeCSS has changed because the sources were published in a legal document.
IANAL and all that, but I don't think this analysis makes sense. Slapping the GPL on a piece of software is meaningless if you don't have the right to license it in the first place.
This case is all about determining who has the legal right to write, reverse engineer, or distribute CSS code. If the courts determine that reverse engineering CSS was a violation of the DVD user license, I believe that would make DeCSS the property of DVD-CCA even though the code was written by Jon Johansen. That, in turn, would mean that no one else, including Jon Johansen, has the right to license the code, making the version that appeared under the GPL null and void.
Ergo, we cannot safely assume that DeCSS is a GPLed document just because it says it is. The legal status of DeCSS is exactly what is at stake here.
The Slashdot crowd enjoyed making fun of this when it was first posted here, but like it or not, there are some real concerns that need to be answered.
Telecommuting is expected to continue rising in popularity. Employers could find themselves obliged to offer telecommuting benefits in order to attract good people (if this is not already happening). If it becomes widespread enough, they will surely seek ways to reduce or minimize costs.
For employers not to be held liable for preventable home-office injuries would be nothing less than a cash cow for corporations. It is not hard to imagine Fortune 1000 companies offering generous telecommuting plans in order to encourage employees to work at home, and thereby excusing themselves from any responsibility for their safety. Then, if you wind up with an RSI due to poor working conditions at home, the company takes no blame despite having pushed you into that situation.
It is exactly this sort of Catch-22 for employees that only regulation can prevent. While this is not an issue today, it may well be a problem soon. It is entirely appropriate for OSHA to consider the liabilities associated with telecommuting.
The OSHA decision may seem nutty, but there are some real issues that need to be addressed.
Telecommuting is expected to increase drastically in popularity over the next few years. It could lead to considerable savings in workplace maintenance costs if it really takes off. That gives employers an incentive to encourage telecommuting.
Now suppose that employers were not held responsible for injuries incurred in a home office. That would be a winning lottery ticket for any big corporation. They would cream their jeans over that. They couldn't encourage telecommuting fast enough if they had that out. Working 16 hours a day gave you a bad case of carpal tunnel? Sorry, not our fault, you did it at home! Got migraines from straining to read that 13" monitor? Sucks to be you, since you did it at home and not here.
From a safety standpoint, the home office must be considered part of the workplace in order to avoid giving the corporate sector an incredible opportunity to save big bucks at the expense of their employees' health. This is exactly the sort of thing that OSHA is supposed to be doing.
One of the more alarming trends in online censorship is the tendency for libraries, schools and school districts to enforce the use of censorware on their computers.
What are generally the most effective strategies for discouraging censorware in public institutions? Is it useful to document the famous false positives of censorware (e.g. tools which block the National Gay and Lesbian Task Force, the National Organization for Women, or the ACLU)? What other techniques have been persuasive?
If you intend to make your software as useful as it can be to as many people as you can, then you should make it free software. Which is a terrible word, because of word games from the FSF. I mean free as in "gift". As in "free of restrictions" or as in "no strings attached".
Speaking of word games, there is no such thing as a "license" which is "free of restrictions." To license your software ipso facto restricts the way it is used, copied or distributed; if there were no restrictions on these things, there would be no need to license it.
If you want your software to be free of restrictions, place it in the public domain. Anything else is a restricted license and is "non-free" by this definition. I happen to think that's a silly, pointless way to define "free", but YMMV.
Emacs was an editor made by RMS before he founded the FSF. (And in my opinion it's only fair to call it a Free Software project rather than an Open Source.) As to its developments after it was licensed under the GPL, make no mistake, it was very much a cathedral style project. It's developers were an elitist group, and most certainly did not accept patches from anyone.
I'm amazed at how far the disinformation campaign has come.
I am looking at the documentation for Emacs 20.3. The Acknowledgements chapter thanks over 200 people by name for their contributions to Emacs over the years. I am quite sure that those people were not all principal maintainers of Emacs. Most of them are credited with contributing only one feature, which indicates that they were not part of some rarified Emacs Clique but merely randoms who had good ideas.
Every piece of evidence I can find indicates that RMS recognized the technical value of free software from the very beginning. From the GNU Manifesto:
From Stallman's interview in BYTE in 1986:
I find it mystifying that Linus is getting credited with inventing these concepts.
[Linus] was surprised when people started turning in patches, his only ambition he'd only expected people to say good or bad. The development style came from nowhere, but make no mistake, it was new.
It was not new. Linus knew perfectly well in 1991 that people who liked the software they were using would contribute bug fixes and improvements. This pattern was, indeed, commonplace even then. What surprised him, as he's said before, was the enthusiasm with which people took to his project, not the mere fact that someone would choose to submit a patch.
Linux as an OS certainly won't last forever, but in the long run Linus just might be remembered not for writing an OS but for creating a whole new kind of development process, one that isn't going away.
The whole idea of 'release early, release often', invite patches from everybody, and huge-team development was actually pretty different from the way even gnu worked at the time.
This is essentially a myth. In The Cathedral and the Bazaar, ESR argues the merits of a "bazaar" model by contrasting it with a "cathedral" model of closed software development. The examples of "bazaar" development he presents are Linux and fetchmail to represent the "bazaar," and his example of a "cathedral" project is.... Emacs.
How's that again? Emacs is not an open source project? It does not invite patches from everybody? It does not incorporate contributions from an army of individual hackers? It has not made all its bugs shallow by offering its source code to millions of eyeballs?
The plain weirdness of this comparison still leaves me puzzled. What is it supposed to mean, in a paper whose thesis is the fundamental superiority of open source over closed source? That Emacs is essentially a closed-source project? That it has more in common with NT than it does with vi? These notions are absurd, but it is hard to draw a different conclusion.
The truth is that these development models are quantitatively different, but not qualitatively different. While Linux development is more frenetic than that of FSF mainstays like Emacs or GCC, nightly snapshots and frequent releases are only modest differences in style. They are essentially personality differences; even GNU and BSD projects include nightly snapshots, after all. They don't constitute a sea change in software design.
While no one invented the open source software ethic, it appears likely that Richard Stallman will get more credit than any other individual, which is IMHO as it should be. Many, many people created projects, but Stallman created the movement. More people became conscious of free software and open source as a philosophy through Project GNU than through any other source, Linux included. Linus didn't create the development process; Stallman did.
I am told that there are patches available to improve qmail's performance on very-high-volume sites.
The correct URL for patches is, of course, http://www.qmail.org/, not http://www.quaker.org. I blame the Scotch.
Sendmail is really not a bad choice. If you can get over your fear of the sendmail.cf language, it's very servicable on a modern machine.
Sendmail's "insecurity" is largely a myth at this point. I do not recall seeing a root exploit since Sendmail-8.8, which was about three years ago. While qmail and Postfix can legitimately brag about being designed for security from the ground up, the sendmail team has done a pretty good cleanup job.
Doubting Thomases should consider that OpenBSD, the famously "ultra-secure" operating system, ships with sendmail, not qmail. How many people think that Theo de Raadt would put up with shipping software that has known exploits?
We use sendmail to run one of the largest mailing list sites in the world. My experiments with qmail were pretty hideous; qmail has serious problems out of the box with high-volume delivery. The mail queue backed up by several thousand messages, and one big list actually caused the server to crash. (I am told that there are patches available to improve qmail's performance on very-high-volume sites. We have not had the opportunity to try them, but given my experience I am not sure that we want to.)
I'm actually not a big fan of sendmail qua sendmail. But anti-sendmail sentiment is just pretty overblown these days, and the rebellion hype is not convincing. Sendmail is one of the classic open source success stories, it is a fine piece of software with a great future, and an excellent choice for a project to support.
I believe this is correct. If the reason that Corel added the "not a minor" clause to their EULA is that minors cannot enter into contracts, then they might as well have added a clause that said, "I am legally able to enter into this contract." Like the liar who always says he tells the truth, this is a meaningless clause -- what is to prevent a minor from signing the contract with or without this clause? It is still not binding.
The whole issue seems completely bogus. I don't trust the conventional wisdom.
What I found interesting is how short the interview was, and how little discussion there was about WC3 standards. In order to maintain control ov the client side of the net, it will be very important to be at least minimaly complient with the specs.
Of course it'll be minimally compliant; it has to interpret pages that were written for MSIE and Navigator and make them look attractive. This isn't particularly relevant to the Linux port of Opera.
Their latest bit of campaigning was to send Jack Straw a letter which, if the legislation were to pass as proposed, would leave him liable for a two year jail sentence.
"Dear Mr Straw,
Please find at the end of the letter a confession to a crime, which has been affirmed by Statutory Declaration. The Commissioner of the Metropolitan Police has been informed that you are in possession of this information.
This seems like an insanely stupid stunt. Why is this not simply going to provide the key escrow crowd with more ammunition?
The computer magazines of the 1970s and early 1980s were better than almost anything I have read since. For example, SoftSide and 80 Micro, the old TRS-80 rags, were amazingly valuable sources of information. They covered everything, from useful machine language subroutines to undocumented operating system features to the occasional hardware hack. I still miss Jake Commander's columns on the TRS-80 CoCo ROM, and Dennis Báthory-Kitsz's homebrew kit articles.
For years, these magazines were essentially the only broadcast outlet for source code among hobbyists. You could legitimately put these magazines among open source pioneers -- in those days, publishing source essentially was the only way to make your software available to a wide audience, and infused many of us with a healthy respect for the value of making source code available to everyone.
Not many magazines carry on the same sort of anything-goes attitude. Dr. Dobb's Journal comes close, and they usually provide an interesting read, but they often seem too easily distracted by vaporware and buzzware to be really compelling. The Perl Journal was pretty promising when I last saw it (but who has time to read magazines these days?)
...with the GPL people can modify your work and distribute those modifications. This has practical value in the software community, but in the music community people want their work to remain unique and intact. I assume that authors would feel the same way.
That's very strange. I would have said that the exact opposite is true.
There is a great tradition in music of creating new derivative works from earlier songs. These days we mostly get "cover songs" that are usually heavily bastardized versions of classic popular songs, not really worthwhile, but jazz and blues music is deeply rooted in a history of borrowing, begging and stealing music. Jimi Hendrix's cover of The Star-Spangled Banner is a good well-known example.
That is not to say that the GPL would be a good model to use for music, just that musicians are hardly averse to reusing and reinterpreting each others' work.
or start a seperate protest website for this stuff?
The League for Programming Freedom was once upon a time the chief organization that fought software patents. For a time they kind of dissipated, but can now be found at http://lpf.ai.mit.edu/.
The LPF now chiefly appears to be a news site. If there are Slashdotters who have financial, political or legal expertise to throw at this problem, contributing those gifts to LPF would be a wonderful and important thing to do.
Authentication in the real world today generally means Social Security Numbers. If you hand over an SSN, you can find out just about anything you want to know on someone's medical or bank records. The really sophisticated places might want to know your mother's maiden name or something.
Nearly anything is better than an SSN-based security system, even vanilla HTTP usernames and passwords. I would be frankly grateful to learn that my doctor was doing something like this. Obviously banks should be using real crypto, since financial institutions are much more likely to attract sniffers, but I'm unconvinced that hospitals need the same level of security.
That said, it seems like layering this on top of SSL should not be particularly difficult, and obviously makes the transaction much safer. The world is growing larger; while sniffers and crackers are unlikely to go after medical data today, it's unclear what the black market will pay for a year from now.
This wouldn't be so bad, except for the fact that somebody switched my full name and password around - so whenever I send mail through their relay, my password shows up on in the #$@! headers.
That's a shame, but it's still MediaOne's fault and not MAPS's.
The canonical Turing biography is Alan Turing: The Enigma by Andrew Hodges. The excellent play Breaking the Code was inspired by this book.
PBS also adapted the play, so you might also be able to find a copy of that if you hunt around. It stars Derek Jacobi, who also played Turing on the stage (in a fantastic performance).
One is that it is not easy to get into the RBL. First, someone who has received spam from your site needs to write up a nomination. It has to include not only a record of the spam itself, but also a description of attempts that they have made to contact your site, explain the problem and to resolve it.
If repeated attempts to resolve the problem with the site fails, then MAPS will consider the RBL nomination. An RBL staffer or volunteer will follow up and try to explain the gravity of the situation with the responsible people at your site, and will make it clear what an RBL listing means. Only at that point is it possible to add a site's network to the RBL.
The RBL is just about the most fastidiously maintained abuse tracking system on the Internet. In fact, that is the chief reason that it is used so widely -- a network doesn't get on the RBL unless it has proved itself to be really irresponsibly run.
The other salient point is that participation in the RBL is voluntary. No site is required to use MAPS' abuse lists. They do so because they need to block spam and find that MAPS fills that need.
Ultimately your complaints are better directed at your mother's ISP, for using the RBL, and (most of all) at your own ISP, for failing to run their systems responsibly. Blaming MAPS is like blaming Ralph Nader for making your seatbelt too tight.
Signal11 is talking about MAPS' Dialup User List, which helps a mail server identify a connection directly from a dialup IP at a remote site. Because legitimate users generally send mail through their ISP's own mail server, mail coming direct from a dialup account is almost always spam.
You need to learn about smarthosts (or whatever the equivalent is if you're using a trendy new MTA). If you route all of your mail traffic through your ISP's mail server, instead of connecting directly to remote MXes, your mail won't be blocked by dialup lists like the MAPS DUL. End of problem.
So eventually I overcame the first impression and we became friends. In April 1993, we learned that we both planned to be at the March on Washington, and arranged to meet on the Mall. I am still not quite sure how we managed to find each other on the Mall in the middle of about three hundred thousand other people, but we did.
I never really believed in the phrase "love at first sight" before, but I do now. After that day, I went back to Massachusetts and she went back to Chicago. A little more than a year later, I drove across country and moved in with her. That was six years ago. We've been married now for four and have a son.
An important point is that this was not an "online relationship." We met, grew to know each other and became infatuated online, the first year of our relationship was spent a thousand miles apart, but it was fundamentally a real-life long distance relationship. The Internet precipitated bringing us together but was essentially the tool by which we remained in touch. Our first face-to-face meeting, and the ability to meet in person occasionally, was absolutely crucial to the development of our relationship. This would not have bloomed if we had carried it out exclusively online.
The thing was a complete piece of junk. Programming it was like using a combination of assembler and APL, ...
You say that like it's a bad thing or something.
It's just a "Finding of Fact" from the Judge - he's selected all the facts presented to him, and determined what he finds to be true, and supported by the arguments presented.
I am not a lawyer, but I know enough to realize that this is not a final verdict, and that this trial could still go anywhere from this point on.
This isn't a jury trial. Jackson's word is final. The Finding of Fact represents a great deal of what the trial is all about, and his final ruling is going to stem directly from these findings.
It is very clear that Jackson's ruling is not going to be pro-Microsoft.
AOL will probably argue that it needs to rely on an image-heavy layout in order to stay competitive, but that's a hard thing to actually prove.
It's worth noting that some of the most successful sites on the web, such as Yahoo, use images only sparingly. I don't think it will be difficult to demonstrate that designing a site for accessibility does not mean sacrificing either content or competitive advantage.