Because, ultimately, the end user has little control over how much bandwidth they use. A Pandora's box was opened when the Internet was targeted as a way to deliver rich multimedia instead of text. Even the links featured on/. are usually a few bytes of content surrounded by many kilobytes of ads, spread over multiple pages. Compared to analog television and telephony, the quality of online video and voice communications is horrendous, but demand is only a tiny fraction of what it's going to be. The ISPs promote multimedia heavily when they sell connectivity, so they're just as culpable as the content providers. Throttling bandwidth at today's poor quality is not going to be a satisfactory solution for consumers. Increasing capacity is the only solution. I have a family of four, and when each of us want to experience the rich content we were promised (like VOIP, online productivity applications, video-on-demand, and streaming music), you're going to call us bandwidth hogs? I don't think so.
This is just another way to provide hooks to advertising, which Microsoft is exploring in order to compete against Google. The ultimate targeted marketing will reach its zenith when your toilet performs urinalysis in order to provide you with appropriate advertising, emergency services, and insurance quotes.
Digital content is as plentiful as water. In my neighborhood, the tapwater is excellent. It tastes fine, and is purified to the highest standards. If that isn't good enough, I can filter it even more. The best part is that it's virtually free, and delivery requires no effort on my part beyond turning a faucet handle. Nonetheless, there is a thriving business for bottled water, with water trucks making daily deliveries. Everyone I know buys bottled water at comparitively outrageous prices. Some of that water is pumped directly from springs, but a good portion of it is simply another municipality's tap water. Strangely enough, there is also water that is bottled halfway around the world, then transported over the ocean (more water) and sold at astronomically high prices in area stores. Are you ready to be stunned? In my neighborhood, water actually falls out of the sky. I'm not kidding! We call it rain. It's entirely free for the taking, but that doesn't stop anyone from buying water.
Digital content is pouring down on us like rain. I'm sorry, but I don't have the time to determine if I have the right to enjoy it or not. Frankly, I'm having a hard time filtering all the content being streamed at me at any given time in favor of a single stream I'd actually enjoy (or even silence, for that matter). I can guarantee one thing, though, and that's that if people will buy ordinary water in designer bottles at outrageous prices when it's available for free, they'll do the same for DRM-free digital content.
A fictional depiction of something isn't prior art. For example, H.G. Wells' "The Time Machine" would not invalidate the patent for a real time machine.
I'm currently evaluating Eventum for both IT support and generic issue tracking for service departments with no IT component. The only thing that feels beta about it is its obvious origin as a software issue tracker, but it won't require much modification to support generic issue tracking. Other than that, it is very stable, and customizable in a good way, not an evil, "I can't use this unless I completely rewrite the source code" kind of way.
I have experience with RT, and have installed it for clients who absolutely love it. But if you're an admin who finds supporting RT to be a little traumatic, you owe it to yourself to try Eventum. I was able to download and install Eventum in a typically provisioned LAMP environment in 5 minutes without any problems at all. Like RT, configuration requires a thorough understanding of the options, but I had a working evaluation system in much less time than it normally takes me to configure RT. So far, source code edits appear to be necessary only for designing more complex workflow patterns, and I'm guessing that will be integrated into the admin interface before long.
While I haven't properly evaluated email integration, Eventum is appealing because it can handle incoming mail via IMAP. I wish more issue trackers would do this, since I already have a robust email system that works great. I might as well be able to use it without rerouting support addresses through pipes, or creating complicated aliases (though it looks like Eventum supports this, as well).
I'm not done evaluating Eventum, but I didn't want its mention to go unnoticed due to its recent release and small user base. I'm looking for an issue tracker that allows technical and nontechnical support staff alike handle tickets behind the scenes without a requirement for a public interface for the client, other than the email responses we generate. Eventum has a simple but powerful search interface, graphical statistics, reports, internal FAQ, canned responses, phone logging, and time tracking, among other features. The fact that it's offered by a popular opensource software vendor, MySQL, lends hope that it will be actively developed and maintained if it becomes successful. It's so easy to install, it's worth taking a look.
As one of my teachers used to say when asked how long an essay should be, "As long as a piece of string." In other words, it should be as long as it needs to be to serve the subject. We've long overcome such limitations as the standard terminal size, and your document, whatever it is, can be as many columns as you want it to be, and often this can be adjusted by the reader (for example, the columns used to format markup code like this very HTML page you are reading are unrelated to the number of columns that are displayed). The only place I think this still matters is when preparing plain text documents, which are very readable at 80 columns. Unfortunately, content exists (like some URLs) that will always exceed the number of columns selected for readability. The optimum number of columns isn't something that scales infinitely with improvements in technology, it's a usability issue.
Having an open document format protects user data and improves portability. As long as the end result conforms to the standard, who cares what tool was used to create it? Promoting the format is a big win for the end user, as they will no longer be locked into one company's product, and can exchange documents more freely. This could even simplify electronic communications, allowing users to express themselves in whatever style they'd like, as long as they package it in a standard format that everyone agrees upon. I'd love to see government and academic institutions mandate the use of ODF, now that a free plugin for Word exists, removing one of the largest barriers to adoption.
1: too #$%) hard for a new admin. It requires a lot of arcane skills to get set up properly - skills that don't come cheap, and are hard to find in the marketplace.
True. At least, I think it's true that skilled professionals tend to use more arcane tools, no matter what the discipline, as part of the search for excellence. As always, talent is hard to find in the marketplace, and replacing a highly skilled professional is never easy. Don't blame it on the tools used. A gifted, efficient employee is always going to leave a void.
2: No dependency management. Debian- and RH-based distros have had dependency tracking for ages, and the capabilities of up2date, yum, and apt-get are far in advance of what you can do with any slackware package management system. Plus, there is literally nothing in Slackware that matches RHN.
Thank God! While I think apt-get is one of the absolute best admin tools for people who want to keep a vanilla system well-maintained, it's still a ball-and-chain (and sometimes that's a good thing). But RHN? It's been a few years since I dumped RH for Debian (then dumped that for Slackware), but I've seen too many admins trapped in a corner by the RH package management system, left with a system they can't comprehend enough to repair.
3: Proprietary software. Although with enough hacking, you can get a lot of it to run on Slack, the provider will not give you any support. And without that, you're hosed. We've ended up using RHEL on a Websense box because they would not recognize a bug that showed up in CentOS. You know what? The bug went away on RHEL.
Absolutely true. Proprietary vendors tend to support only 2 or 3 of the top distributions, mainly to contain development and support costs. As you said earlier, the required skills don't come cheap, and are hard to find, so this makes good business sense. It takes a lot of courage to toss away that support, unless you've determined that you're gaining a more stable environment that decreases your dependence on the vendor (and I mean that, you really have to prove it's going to work). On the other hand, one of the reasons I like to use Slackware is because I have a better chance of fixing the bugs myself, and I share these fixes upstream so they'll improve the product on all platforms. It may be "harder", but I've also made my job easier by solving my own problems quickly. In the process, I've improved my skill set, which makes me a more valuable employee to current and (potentially) future employers.
It all boils down to the right people choosing the right tool for the right job. Let's face it, there's no more difference between choosing a "business" OS (Windows, Solaris, RHEL, Slackware, etc.) than there really is for choosing a "business" computer (Dell, HP, Apple, Sun, etc.). The important thing is that you select then leverage your talent for as long as you have them. Let them develop and refine your business infrastructure using the tools they know and trust. Slackware is as capable as any other Linux in a business environment, and no distribution/OS automatically gives you a larger pool of true talent.
...the anti-rain crowd cite the umbrella as an alternative to getting wet, without any sense of the ironic fact that umbrellas can't exist without rain. They're proposing a solution while simultaneously complaining about the weather. While using an umbrella is less restrictive than staying indoors, it must be held at the proper angle in order to offer any protection. It is a way to keep dry. But without rain, umbrellas would never be opened.
Can I offer you a tip? Ask your alumni parents to write this letter and send it to the board of trustees, university president, and provost. You see, you and your fellow students aren't really that influential, and won't be until you are in a position to donate money. You might even be lucky enough to have parents that feel it could inspire you to get off your ass and protest the fundamental abuses of power that make this type of strong-arming possible, along with other human rights violations and a seemingly interminable war fought in your name. You know, like they did when they were in college and had the energy and freedom to care.
unless I'm mistaken, the current human-power plan involves a foot pump
Yes, that's to make it easier to move the kids between sewing machines, looms, and computers, to more flexibly meet the demands of outsourcing. Human-power!
Actually, these are exactly the people who will most benefit from improvements in graphics subsystems (and displays). Sure, we can sit back and be amazed by the awesome rendering in the latest shoot-em-up or the crisp detail in an HD-DVD or Blue-ray movie, but it's readers whose needs aren't even close to being met by today's technology. Just take a look at the crappy fonts you're viewing right now on your monitor, and realize that we are probably decades away from anything remotely resembling print. Let's see, 1985: 640x480, 2007: 1280x1084. Yep, sounds about right.
I use EncFS http://arg0.net/encfs on Linux every day and love it. Even root can't snoop a mounted directory (but could delete the encrypted source directory). How is TrueCrypt better?
I'm the author, and currently advise against using Unlisting, in spite of its effectiveness. It is prone to block mail from sites that use a certain kind of load balancing, and subject to denial of service attacks. If you are considering a technique like Unlisting, please read the article for a description of some of the issues I've encountered after months of testing, and a brief rollout on a few production servers. I'd love to hear suggestions for overcoming these hurdles.
Nolisting, on the other hand, is a passive technique that doesn't share these weaknesses. So far, I've found it to be safe.
...and encourage readers to RTFA, where I've addressed many of the issues brought up in these comments. I also encourage people to try the technique, if they are in the position to do so (admins only, this is not a solution for endusers), and evaluate it for themselves. Or not. It's true that most new antispam solutions are dreamed up by crackpots. I might be a crackpot. If this possibility concerns you, don't be an early adopter. Wait and see.
It's true, in my experience, that Nolisting stops some spam with no false positives (in my experience). And that's a Good Thing. But it doesn't stop significantly more spam than a combination of other techniques, which I also implement. Some of those techniques use a lot of resources, such as content filters (often powered by perl) and virus scanners. Nolisting provides a way to free up some of those resources, possibly resulting in better performance and even hardware savings. These savings can be significant at large sites that currently scan each and every message that arrives.
Nolisting can be bypassed. I don't make any wild claims. Spammers can get past it easily by going directly to the secondary MX. Guess what? They already do that, and have been doing that well before greylisting was introduced. Nolisting significantly reduces the percentage of spam my MX processes, thereby freeing up resources. It's just one part of a layered solution.
I've limited secondary MX access by extending Nolisting into Unlisting (Port Knocking for SMTP): http://www.joreybump.com/code/howto/unlisting.html . It's wildly effective, except for one serious problem: A retry might originate from a different IP. This appears to be legal, and seems to be the result of load balancing strategies adopted by some important sites. For that reason I don't recommend it. It will randomly block messages from gmail, for example. You can't reasonably predict the IP a multihomed host will use for a retry, so be very skeptical of any approach that claims to have solved this problem.
Unwanted email is annoying. When it carries a payload, it is potentially dangerous. But I don't really view this as a security issue. I don't buy the argument that Nolisting is security by obscurity, and therefore bad. It's a form of access control, a gatekeeper, a prophylactic. It's an apple a day, not a cure for cancer. It's not addicting, fattening, or life-threatening. Try it, if you're looking for ways to improve the health of your mail system. Discontinue use immediately at the first sign of complications. Side effects include more sleep and time spent with your kids.
Nolisting rarely introduces delays. As I point out in the article, most relays retry immediately. Any relay that cannot get beyond Nolisting is seriously, seriously noncompliant. While I don't suggest Nolisting as a complete replacement for Greylisting, it is a viable alternative for sites that experience problems with Greylisting and find the delays it introduces to be unacceptable. As the name implies, Nolisting is meant to used without dependence on whitelists. Wider adoption and testing will determine if this ideal has been realized.
Like Greylisting, Nolisting breaks infrastructure to some degree. Many admins find this distasteful. I know I do. If Nolisting becomes widely adopted, logs will become fatter with "Connection refused" errors when the primary MX doesn't respond. I'm sorry for that. But our logs are already fat with 45x errors from Greylisting, RBL disconnections, SpamAssassin scores, etc. Nolisting might even help to make logs smaller, if you currently see a lot of these messages. Time will tell. Keep an open mind, and remember that we often make concessions to improve a system's overall health. Just reducing the possibility of another zombie being created on the Internet creates benefits for everyone.
Slashdot Mirror
The important distinction is that, in this case, censorship adds value for some consumers, while DRM does not.
Because, ultimately, the end user has little control over how much bandwidth they use. A Pandora's box was opened when the Internet was targeted as a way to deliver rich multimedia instead of text. Even the links featured on /. are usually a few bytes of content surrounded by many kilobytes of ads, spread over multiple pages. Compared to analog television and telephony, the quality of online video and voice communications is horrendous, but demand is only a tiny fraction of what it's going to be. The ISPs promote multimedia heavily when they sell connectivity, so they're just as culpable as the content providers. Throttling bandwidth at today's poor quality is not going to be a satisfactory solution for consumers. Increasing capacity is the only solution. I have a family of four, and when each of us want to experience the rich content we were promised (like VOIP, online productivity applications, video-on-demand, and streaming music), you're going to call us bandwidth hogs? I don't think so.
This is just another way to provide hooks to advertising, which Microsoft is exploring in order to compete against Google. The ultimate targeted marketing will reach its zenith when your toilet performs urinalysis in order to provide you with appropriate advertising, emergency services, and insurance quotes.
It would be interesting to see the impact of putting UNIX in the public domain, with no licensing restrictions at all.
Digital content is as plentiful as water. In my neighborhood, the tapwater is excellent. It tastes fine, and is purified to the highest standards. If that isn't good enough, I can filter it even more. The best part is that it's virtually free, and delivery requires no effort on my part beyond turning a faucet handle. Nonetheless, there is a thriving business for bottled water, with water trucks making daily deliveries. Everyone I know buys bottled water at comparitively outrageous prices. Some of that water is pumped directly from springs, but a good portion of it is simply another municipality's tap water. Strangely enough, there is also water that is bottled halfway around the world, then transported over the ocean (more water) and sold at astronomically high prices in area stores. Are you ready to be stunned? In my neighborhood, water actually falls out of the sky. I'm not kidding! We call it rain. It's entirely free for the taking, but that doesn't stop anyone from buying water.
Digital content is pouring down on us like rain. I'm sorry, but I don't have the time to determine if I have the right to enjoy it or not. Frankly, I'm having a hard time filtering all the content being streamed at me at any given time in favor of a single stream I'd actually enjoy (or even silence, for that matter). I can guarantee one thing, though, and that's that if people will buy ordinary water in designer bottles at outrageous prices when it's available for free, they'll do the same for DRM-free digital content.
A fictional depiction of something isn't prior art. For example, H.G. Wells' "The Time Machine" would not invalidate the patent for a real time machine.
I'm currently evaluating Eventum for both IT support and generic issue tracking for service departments with no IT component. The only thing that feels beta about it is its obvious origin as a software issue tracker, but it won't require much modification to support generic issue tracking. Other than that, it is very stable, and customizable in a good way, not an evil, "I can't use this unless I completely rewrite the source code" kind of way.
I have experience with RT, and have installed it for clients who absolutely love it. But if you're an admin who finds supporting RT to be a little traumatic, you owe it to yourself to try Eventum. I was able to download and install Eventum in a typically provisioned LAMP environment in 5 minutes without any problems at all. Like RT, configuration requires a thorough understanding of the options, but I had a working evaluation system in much less time than it normally takes me to configure RT. So far, source code edits appear to be necessary only for designing more complex workflow patterns, and I'm guessing that will be integrated into the admin interface before long.
While I haven't properly evaluated email integration, Eventum is appealing because it can handle incoming mail via IMAP. I wish more issue trackers would do this, since I already have a robust email system that works great. I might as well be able to use it without rerouting support addresses through pipes, or creating complicated aliases (though it looks like Eventum supports this, as well).
I'm not done evaluating Eventum, but I didn't want its mention to go unnoticed due to its recent release and small user base. I'm looking for an issue tracker that allows technical and nontechnical support staff alike handle tickets behind the scenes without a requirement for a public interface for the client, other than the email responses we generate. Eventum has a simple but powerful search interface, graphical statistics, reports, internal FAQ, canned responses, phone logging, and time tracking, among other features. The fact that it's offered by a popular opensource software vendor, MySQL, lends hope that it will be actively developed and maintained if it becomes successful. It's so easy to install, it's worth taking a look.
Compatibility depends on faithfully following open standards. If you're truly interested in an email client that:
then don't use software that ignores the standards that were meant to make this possible.
As one of my teachers used to say when asked how long an essay should be, "As long as a piece of string." In other words, it should be as long as it needs to be to serve the subject. We've long overcome such limitations as the standard terminal size, and your document, whatever it is, can be as many columns as you want it to be, and often this can be adjusted by the reader (for example, the columns used to format markup code like this very HTML page you are reading are unrelated to the number of columns that are displayed). The only place I think this still matters is when preparing plain text documents, which are very readable at 80 columns. Unfortunately, content exists (like some URLs) that will always exceed the number of columns selected for readability. The optimum number of columns isn't something that scales infinitely with improvements in technology, it's a usability issue.
Having an open document format protects user data and improves portability. As long as the end result conforms to the standard, who cares what tool was used to create it? Promoting the format is a big win for the end user, as they will no longer be locked into one company's product, and can exchange documents more freely. This could even simplify electronic communications, allowing users to express themselves in whatever style they'd like, as long as they package it in a standard format that everyone agrees upon. I'd love to see government and academic institutions mandate the use of ODF, now that a free plugin for Word exists, removing one of the largest barriers to adoption.
True. At least, I think it's true that skilled professionals tend to use more arcane tools, no matter what the discipline, as part of the search for excellence. As always, talent is hard to find in the marketplace, and replacing a highly skilled professional is never easy. Don't blame it on the tools used. A gifted, efficient employee is always going to leave a void.
Thank God! While I think apt-get is one of the absolute best admin tools for people who want to keep a vanilla system well-maintained, it's still a ball-and-chain (and sometimes that's a good thing). But RHN? It's been a few years since I dumped RH for Debian (then dumped that for Slackware), but I've seen too many admins trapped in a corner by the RH package management system, left with a system they can't comprehend enough to repair.
Absolutely true. Proprietary vendors tend to support only 2 or 3 of the top distributions, mainly to contain development and support costs. As you said earlier, the required skills don't come cheap, and are hard to find, so this makes good business sense. It takes a lot of courage to toss away that support, unless you've determined that you're gaining a more stable environment that decreases your dependence on the vendor (and I mean that, you really have to prove it's going to work). On the other hand, one of the reasons I like to use Slackware is because I have a better chance of fixing the bugs myself, and I share these fixes upstream so they'll improve the product on all platforms. It may be "harder", but I've also made my job easier by solving my own problems quickly. In the process, I've improved my skill set, which makes me a more valuable employee to current and (potentially) future employers.
It all boils down to the right people choosing the right tool for the right job. Let's face it, there's no more difference between choosing a "business" OS (Windows, Solaris, RHEL, Slackware, etc.) than there really is for choosing a "business" computer (Dell, HP, Apple, Sun, etc.). The important thing is that you select then leverage your talent for as long as you have them. Let them develop and refine your business infrastructure using the tools they know and trust. Slackware is as capable as any other Linux in a business environment, and no distribution/OS automatically gives you a larger pool of true talent.
...the anti-rain crowd cite the umbrella as an alternative to getting wet, without any sense of the ironic fact that umbrellas can't exist without rain. They're proposing a solution while simultaneously complaining about the weather. While using an umbrella is less restrictive than staying indoors, it must be held at the proper angle in order to offer any protection. It is a way to keep dry. But without rain, umbrellas would never be opened.
Can I offer you a tip? Ask your alumni parents to write this letter and send it to the board of trustees, university president, and provost. You see, you and your fellow students aren't really that influential, and won't be until you are in a position to donate money. You might even be lucky enough to have parents that feel it could inspire you to get off your ass and protest the fundamental abuses of power that make this type of strong-arming possible, along with other human rights violations and a seemingly interminable war fought in your name. You know, like they did when they were in college and had the energy and freedom to care.
Yes, that's to make it easier to move the kids between sewing machines, looms, and computers, to more flexibly meet the demands of outsourcing. Human-power!
Actually, these are exactly the people who will most benefit from improvements in graphics subsystems (and displays). Sure, we can sit back and be amazed by the awesome rendering in the latest shoot-em-up or the crisp detail in an HD-DVD or Blue-ray movie, but it's readers whose needs aren't even close to being met by today's technology. Just take a look at the crappy fonts you're viewing right now on your monitor, and realize that we are probably decades away from anything remotely resembling print. Let's see, 1985: 640x480, 2007: 1280x1084. Yep, sounds about right.
I use EncFS http://arg0.net/encfs on Linux every day and love it. Even root can't snoop a mounted directory (but could delete the encrypted source directory). How is TrueCrypt better?
I was reading the article, and suddenly port knocking came to mind.
It's no wonder, since the article ends with a link to Unlisting - Port Knocking for SMTP: http://www.joreybump.com/code/howto/unlisting.html . :)
I'm the author, and currently advise against using Unlisting, in spite of its effectiveness. It is prone to block mail from sites that use a certain kind of load balancing, and subject to denial of service attacks. If you are considering a technique like Unlisting, please read the article for a description of some of the issues I've encountered after months of testing, and a brief rollout on a few production servers. I'd love to hear suggestions for overcoming these hurdles.
Nolisting, on the other hand, is a passive technique that doesn't share these weaknesses. So far, I've found it to be safe.
...and encourage readers to RTFA, where I've addressed many of the issues brought up in these comments. I also encourage people to try the technique, if they are in the position to do so (admins only, this is not a solution for endusers), and evaluate it for themselves. Or not. It's true that most new antispam solutions are dreamed up by crackpots. I might be a crackpot. If this possibility concerns you, don't be an early adopter. Wait and see.
It's true, in my experience, that Nolisting stops some spam with no false positives (in my experience). And that's a Good Thing. But it doesn't stop significantly more spam than a combination of other techniques, which I also implement. Some of those techniques use a lot of resources, such as content filters (often powered by perl) and virus scanners. Nolisting provides a way to free up some of those resources, possibly resulting in better performance and even hardware savings. These savings can be significant at large sites that currently scan each and every message that arrives.
Nolisting can be bypassed. I don't make any wild claims. Spammers can get past it easily by going directly to the secondary MX. Guess what? They already do that, and have been doing that well before greylisting was introduced. Nolisting significantly reduces the percentage of spam my MX processes, thereby freeing up resources. It's just one part of a layered solution.
I've limited secondary MX access by extending Nolisting into Unlisting (Port Knocking for SMTP): http://www.joreybump.com/code/howto/unlisting.html . It's wildly effective, except for one serious problem: A retry might originate from a different IP. This appears to be legal, and seems to be the result of load balancing strategies adopted by some important sites. For that reason I don't recommend it. It will randomly block messages from gmail, for example. You can't reasonably predict the IP a multihomed host will use for a retry, so be very skeptical of any approach that claims to have solved this problem.
Unwanted email is annoying. When it carries a payload, it is potentially dangerous. But I don't really view this as a security issue. I don't buy the argument that Nolisting is security by obscurity, and therefore bad. It's a form of access control, a gatekeeper, a prophylactic. It's an apple a day, not a cure for cancer. It's not addicting, fattening, or life-threatening. Try it, if you're looking for ways to improve the health of your mail system. Discontinue use immediately at the first sign of complications. Side effects include more sleep and time spent with your kids.
Nolisting rarely introduces delays. As I point out in the article, most relays retry immediately. Any relay that cannot get beyond Nolisting is seriously, seriously noncompliant. While I don't suggest Nolisting as a complete replacement for Greylisting, it is a viable alternative for sites that experience problems with Greylisting and find the delays it introduces to be unacceptable. As the name implies, Nolisting is meant to used without dependence on whitelists. Wider adoption and testing will determine if this ideal has been realized.
Like Greylisting, Nolisting breaks infrastructure to some degree. Many admins find this distasteful. I know I do. If Nolisting becomes widely adopted, logs will become fatter with "Connection refused" errors when the primary MX doesn't respond. I'm sorry for that. But our logs are already fat with 45x errors from Greylisting, RBL disconnections, SpamAssassin scores, etc. Nolisting might even help to make logs smaller, if you currently see a lot of these messages. Time will tell. Keep an open mind, and remember that we often make concessions to improve a system's overall health. Just reducing the possibility of another zombie being created on the Internet creates benefits for everyone.
Try it before you draw a c