No, having and stating an opinion is not defamatory. At least not in and of itself. And nobody should be subject to massive legal bills just because someone else doesn't like their opinion.
Now, if the owner can show that the stated opinion is false (no reasonable person would have believed the place was unsanitary) and that the opinion was stated with the intention of harming his business, then he's got a case for defamation. But he hasn't even attempted that. All he's done is state his opinion of the posts. And if the posts are defamatory, then his statements about the poster are also defamatory by the same standard.
Nowhere in the law does it say you've a right to never have anybody say anything you don't like.
My opinion: the judge should require the plaintiff here to first prove that the statements were defamatory. You don't need to know who said them to do that, the statements stand on their own. Once the owner has a ruling that the statements were in fact defamatory, then demand the identity of the person who made them so they can be held to account for them.
Interesting that you say that. I never used to get the flu shot (I haven't gotten the flu in probably 25 years), but now I'm required to get it because my wife is on immune-suppressing medication. So I think flu vaccine might actually be category 2.
For you, yes. That's why the caveat in the original post about checking with your doctor. Flu is, as a general rule, a minor thing for a healthy adult, but every general rule has exceptions and it's important to know which exceptions you fall into.
As for chicken pox, yes you lose immunity over time. This wasn't seen as a problem since adults and other children tended to get repeated low-level exposure from kids who were getting it, maintaining immunity (and incidentally apparently reducing their chances of getting shingles later in life). Of course, once most kids were vaccinated that repeated low-level exposure went away, and nothing replaced it. As a software engineer I'm all too familiar with the situation, where because of lack of understanding or just plain carelessness a change to fix one problem creates an even bigger problem.
There's a lot that do fall into category 3, though. Measles and smallpox, for instance, and certain forms of cervical cancer. And some that're minor for children are more serious for teenagers and/or adults, so while I'd skip the vaccine for a kid I'd make sure if they hadn't caught it as a kid they got the appropriate vaccination by the time they were old enough for it to be a problem.
Flu, for instance. There's strains that're virulent enough to fall into category 1, but I'm adult and healthy so most strains will just put me out sick from work for a couple of days at the most (as long as I keep an eye on symptoms for signs it's getting too bad and I need real medical attention). So I can mostly skip the vaccinations except if a category-1 strain's circulating.
Chicken pox. Again, unless you're one of the minority for whom it'll be a major problem, the worst it does is keep you home for a week or two. Unless someone in the family's pregnant or planning to be, in which case the risks for a pregnant woman suggest vaccination of the kids to help keep her from being exposed to contagious cases.
You see the kinds of stuff that falls into category 3. And as always, I don't blindly ignore vaccinations. It's always based on "What are the risks of getting the disease, and the consequences short- and long-term?". And if I have to argue with my doctor about explaining those, I find a better doctor.
On the first item, bear in mind that the RIAA has sent cease-and-desist letters to laser printers stating that the RIAA had proof the printer had been sharing files on a P2P network. The laser printer in question didn't have any sort of P2P software at all in it's on-board ROMs. This would indicate to me that the RIAA's methods aren't reliable and that their claims are probably not any indication of actual activity.
It's not just muscles. If you look in the literature, they've found most of the other systems in the body respond in analogous ways. Bone that gets stressed regularly gets stronger. If you regularly do mental problem-solving of various types, your brain becomes better and better at it. And we know the immune system does learn which things to attack and which to ignore by being exposed to them. I'd say it's reasonable that it probably follows a similar pattern: the more it gets to recognize and respond to things, the better it's going to get and the more accurately it's going to learn to respond. And on a more basic level, the immune system evolved to do it's job. I can't help but think that, given our current lack of understanding of how and why it does what it does and what causes various malfunctions, it's probably best to let it do it's thing without interference absent a really compelling reason to poke at it. The less often you mess with it, the less likely the times you do mess with it are to mess it up.
My rule of thumb on vaccines is to look at how bad it'll be to get whatever you're vaccinating against. Generally they fall into three categories:
Things that, if you get them at all, will be a serious threat to your life and/or long-term health.
Things that, while they may not be a serious threat to you, will pose a serious threat to others that can't be mitigated by isolation (either because of how contagious they are or because you'll be contagious well before you show symptoms yourself).
Things that aren't a serious threat to you directly and that you can protect others from simply by staying away from them until you're not contagious.
The first two are things to get vaccinated against. The third... don't bother. I'm a firm believer in letting your immune system handle normally everything it's reasonable to let it handle. It's good excercise for it, and it'll teach it not to over- or under-react to threats. Reserve the external help for the things where you can't risk having it make a mistake. It's the same as any kind of excercise: you get some pain and effort up-front, but reap far more in benefits over the long run.
Caveat: talk to your doctor before you decide which category something falls into. Some things that're not normally a problem can be a big problem for certain people.
C/C++ for heavy-duty programming. C's the lingua franca of Unix development, and C++ (if you don't go overboard) offers some useful extensions.
Shell for light-duty scripting. You'll be using it a lot for small, quick scripts to automate minor tasks that don't need a more powerful scripting language. There's two variants, Bourne and C Shell. Learn Bourne first, and the Bash shell, it's the most commonly used and available one on Linux. I also group the pipeline-based tools (cut, paste, grep, awk, sed, tr, etc. etc.) here, they tend to be used by scripts a lot to manipulate data into a convenient form.
Perl's showing it's age, but it's one of the most common scripting languages for more complicated work, particularly for Web jobs.
Java's fairly closely related to C++ in syntax, and gets used a lot in Web applications and for cross-platform work in the Unix world.
Python or Ruby have significant niches too, again particularly for Web work. Personally I'd pick up Python, it's also used as an extension language by several major tools.
Regular expressions. As complex as they are, I consider them a specialized language. You'll find them incredibly useful for pattern-matching tasks.
If you use Emacs you'll also want to learn at least the basics of the Elisp language it's written in. You'll need it for customization and, once you've gotten a bit of it, you can write some really useful programs to automate common tasks.
The "right" way often isn't. For instance, take a Web-analytics server (which I know well, having written one). You have shared data in the 1.5-2 gigabyte neighborhood. It should be pretty obvious that you can't give each thread their own copy of that structure. More importantly, every thread must update entries in that data structure. If they don't, then the thread that handles the next request won't have the updates from this thread to work with. You won't be able to hand the entire sequence of page hits off to a single thread to handle, since page hits are independent in HTTP and the browser doesn't (or at least can't be assumed to) maintain a single connection for the entire sequence. At the same time, the whole program's the poster child for massively parallel programming: an extremely large number (2000 or more per second) of transactions that can be in large part handled independently, it's only at the very end when they store their results that they hit a shared data structure. Languages like Haskell would be ideal for it, except that they impose unacceptably high overhead for things that need to be done for the program to function. So we end up doing it in C. It's not the best tool for the job, it's merely the only tool that lets you get the job done (where the job is defined not just by the processing but also by being able to do it fast enough to keep up with the required traffic volume using a small enough number of cheap enough machines to fit within budget).
NB: one comment I've made about developing software: "You don't pay me the big bucks to know it all. You don't pay me even for knowing exactly which kind of wrench, screwdriver etc. to use on which figurative bolt in the software machinery. You pay me to know when to chuck the wrenches and take an E-Z-Out and a tap to that sucker. And when not to.".
That's a standard concept for multi-threaded programming in any language, though. I was doing it in C back when fork() actually let you modify your siblings' (and parent's) memory. It's even taught in every basic programming course: avoid global variables, stick to local variables only so you don't have to worry about side effects and synchronization. So why hasn't this taken the world by storm at any point in the last 30 years?
Hint: look at the data requirements of large sets of interesting programs.
The big problem won't be moving to FP. The big problem will be that many common programs simply aren't massively parallel. If your job doesn't involve many parallel tasks, you can't take advantage of multiple cores in it.
Of course, you don't have to move to FP to take advantage of multiple cores. You just need to move to multi-threaded programming. I've been doing that for 20 years now. It takes a different approach to breaking down problems into implementable units, that's all. Certain algorithms are easier to expess in a functional language, but that's more a matter of the algorithm than multi-threaded vs. single-threaded. And multi-threaded is hard. It's not a matter of the language, it's a matter of having to remember that other things may have their fingers in your data, or of designing things so they don't. That's what gives most programmers fits, and I don't see FP making that any easier because it happens before you've gotten to the code.
This thing isn't installed via Firefox's add-on process, or even by Firefox at all. It's installed by other malware that's already infected your system. Not hard, just write a few files into Firefox's add-on directory and then edit Firefox's configuration files to register the new add-on by hand. Any competent programmer with some experience with XML processing could code that up in an afternoon.
According to the description, you have to get infected with some other malware first which would then stuff this thing into Firefox's folders and hook it in by manipulating the configuration. So my first thought is that the primary risk is (yet again) Windows users. They're the ones who'll be the targets of the initial malware. Even if you're a Windows user, if you aren't already having a problem with being regularly infected by malware you aren't at great risk. And if you are currently being regularly infected with malware, one more probably isn't your biggest problem. So a lot of sound and fury, signifying nothing we didn't already know and presenting no risk we haven't had for years.
One of the things that'll protect you is that, even in the case of a deceptive trojan, you don't have permission to install things into the system. That's one of the key differences between Windows and the rest of the world: the rest of the world doesn't treat every ordinary user as an administrator by default. So someone may trick you into running the installer for that rootkit, but the installer can't then put the rootkit into the system areas. The OS simply won't allow it to write to those areas. So it'll either fail, or it'll have to have the OS prompt you to allow it to mess with the system areas. Or it'll have to limit itself to installing only into user-accessible areas, in which case it won't be able to hide from utilities running from the administrative side of the system which don't access anything in your user-local areas. That makes it much easier to detect and clean up the infestation.
And on most non-Windows systems, something asking to install itself into the system area is an unusual event. It happens, but rarely enough that most people stop and go "WTF? That's not supposed to happen..." and start poking around to see what's up. On Windows it's normal for an application to write libraries into the Windows system directories. Anywhere else, the automatic reaction to that is "OK, how'd I give it the wrong installation path?". That difference in expectations goes a long way to making life more difficult for trojans.
Simple: at that level default routes don't exist. All routes are manually configured in BGP. And IIRC Cogent had it set so their BGP configuration didn't have any routes for the Sprint AS except through the peering interconnect to Sprint. So when Sprint pulled the plug, Cogent's routers simply wouldn't try sending Sprint traffic through any other network. Cogent was, I think, betting (correctly, it appears) that Sprint would be hurt a lot worse by this than they would.
I'd be hard pressed to envision a scenario where field validation is logically a -view- function.
You've never programmed for a 3270 workstation, then. Basic field validation was part of it's firmware for the simple reason that users wanted fast, immediate feedback for basic errors (like trying to enter letters into a numeric field, or trying to put too many characters into a text field with a maximum size), and with block-mode communication between the workstation and the server that meant the workstation had to do that validation. You simply couldn't submit the entire form back to the server on each and every keystroke without killing performance. So the IBM designers gave the 3270 enough intelligence to do some of the processing locally, without having to send anything back to the server, and added a simple language to the form definition to allow for programming the workstation to do the needed validation.
He was simplifying, and you can see it by looking at what happens before packet loss starts. When traffic loads increase, routers don't immediately start dropping packets. First they start queueing packets up for handling, trying their best to avoid packet loss. Only when their queues fill up do they start discarding packets. TCP waits until that's happened before it starts backing off. A better way is what uTP sounds like it's designed to do: watch for the increasing latency that signals routers are starting to queue packets up, and start backing off before the routers have to start dropping packets. Ideally you avoid ever overflowing the routers' queues and causing packet loss in the first place.
Historical note: TCP uses packet loss because the early routers didn't queue. As soon as they hit 100% of capacity they started dropping packets. It's worked acceptably up until now because another aspect, the adjustable transmit window size (which varies based on round-trip time), that was designed to avoid flooding the receive queue on the destination host also compensates for queues in the intermediate routers. But with more knowledge of how modern infrastructure has evolved, it's possible to do better. Especially when you're designing for a single purpose (uTP won't have to handle small-packet-size latency-sensitive protocols like telnet).
Won't work. First, how do you plan on supporting the variety of OSes out there? I'm not running Windows, so any Windows-based software won't work. Second, how do you plan on getting your scanner to scan the large parts of my system that my user account doesn't have even read-only access to? Proper internal access controls mean my user account doesn't need access to large swathes of the system, so it doesn't get it and it's not going to get it. What can't be read can't be stolen or misused. And no, your scanner doesn't get administrative access. No external software gets administrative access, period, end of discussion. And third, how do you propose to get my browser to run your scanner? Common sense says you lock down your browser from automatically running outside software, that way you don't need to worry as much about how the bad guys are sneaking stuff onto your system. So your scanner will need to be packaged (for a wide variety of OSes) for download and local installation. And it won't be able to integrate with the browser after installation, see above about restricted access to the system (I'm not installing your scanner as root, and my user account doesn't have write access to the Firefox installation directories).
Your proposed solution depends entirely on the very things that make computers vulnerable to compromise in the first place. It's not going to work.
F/OSS isn't a threat to professional software developers. They'll have plenty of work doing the customization and custom programming needed by the companies that use software in their business. The place I work employs 30 full-time developers just at the office I'm at to develop software for in-house use. We make extensive use of F/OSS for the parts that aren't specific to our business, it's cheaper than commercial software and we're legally allowed to change the software to fix bugs and add things we need. That's a lot better than say Oracle, where the turnaround time on bugs is somewhere the high side of 50 weeks for the 1 bug in 10 they actually fix.
Now, software development companies have a problem here. F/OSS is churning out for free what they want to charge people for. A maker I know runs into this in other areas. He's got a small CNC machine shop, a professional-grade print shop, a professional-quality photography setup, and his latest acquisition is a laser-engraving rig. He runs into very hostile reactions from "professional" businesses built around buying those expensive tools/machines and giving customers access to them (spreading the cost over multiple customers in the process), who are having big problems now that their tools aren't that expensive and hobbyists and amateurs can afford them. Those amateurs often do better work than the "professionals", because they're in it for pride or for fun, not just the money. He summed up the "professional" reaction thus: "But they can't own tool! Ogg is only one to own tool!".
The problem here is that there's 3 parties, not two: the person wanting support, the Alfresco partner potentially providing support, and the Alfresco owner. The question is whether the Alfresco partner can be denied the right to provide support to the person wanting it. The answer there is, there isn't an answer. The question is incomplete, it's missing information about what the partner has agreed to. In this case, the partner as part of their partnership agreement signed away their right to support the GPL'd version in return for rights to support the enterprise version they wouldn't have had otherwise. It's not just legal for them to do that, it's entirely reasonable and right for them to be able to do that. It's their business, it's their right to decide that the income from enterprise support is greater than the potential loss from not being able to provide support for the GPL'd version. Someone else may think their decision is dumb, but it's their decision to make.
From the standpoint of the person wanting support, legitimate and fair don't enter into it. They're not a party to the partnership agreement, they're not qualified to decide whether Alfresco is treating it's partners fairly or not. It is, however, rather unusual for open-source companies to deny their partners the right to work on the GPL'd version. RedHat, Sourceforge and the like don't impose any such restrictions that I know of. The most they may do is prohibit partners from making use of any non-GPL'd stuff they have access to in the GPL'd projects. I suspect Alfresco is doing this to try and induce people to use the enterprise version instead of the GPL'd version (if you use the GPL'd version, you lose access to the best sources of support). That'd make me twitchy about using their software.
I know how I'd handle it on Unix. Removeable drives get mounted with the noexec option (or an equivalent set of permissions for filesystem types that don't have the concept of an execute bit). If users aren't allowed to install software on their own, then/home gets mounted that way too. Then it doesn't matter what tricks the user plays or what they rename the file to, the filesystem won't permit the execute permission bit to be set and without that bit the system won't treat the file as executable. You can usually run scripts by feeding them as input files to the appropriate interpreter program (/bin/sh,/usr/bin/perl or similar), but actual programs are right out.
And if they did write such software, they'd surely not survive the ridicule and public humiliation of having their efforts graded against standards developed over 30 years of malicious pranksters with Computer Science degrees and way too much time on their hands trying to get access to the system to guarantee themselves an A (or at least get copies of the professor's answer sheet for the final). Which is in the end the reason Unix is more resistant to attack than Windows: Windows attempts to add security to a system developed for a trusted environment, while Unix is adding convenience onto a system developed for a fundamentally hostile environment.
Slashdot Mirror
No, having and stating an opinion is not defamatory. At least not in and of itself. And nobody should be subject to massive legal bills just because someone else doesn't like their opinion.
Now, if the owner can show that the stated opinion is false (no reasonable person would have believed the place was unsanitary) and that the opinion was stated with the intention of harming his business, then he's got a case for defamation. But he hasn't even attempted that. All he's done is state his opinion of the posts. And if the posts are defamatory, then his statements about the poster are also defamatory by the same standard.
Nowhere in the law does it say you've a right to never have anybody say anything you don't like.
My opinion: the judge should require the plaintiff here to first prove that the statements were defamatory. You don't need to know who said them to do that, the statements stand on their own. Once the owner has a ruling that the statements were in fact defamatory, then demand the identity of the person who made them so they can be held to account for them.
Yeah, I'd gotten my lists backwards. Those are ones in category 1 or 2.
Interesting that you say that. I never used to get the flu shot (I haven't gotten the flu in probably 25 years), but now I'm required to get it because my wife is on immune-suppressing medication. So I think flu vaccine might actually be category 2.
For you, yes. That's why the caveat in the original post about checking with your doctor. Flu is, as a general rule, a minor thing for a healthy adult, but every general rule has exceptions and it's important to know which exceptions you fall into.
As for chicken pox, yes you lose immunity over time. This wasn't seen as a problem since adults and other children tended to get repeated low-level exposure from kids who were getting it, maintaining immunity (and incidentally apparently reducing their chances of getting shingles later in life). Of course, once most kids were vaccinated that repeated low-level exposure went away, and nothing replaced it. As a software engineer I'm all too familiar with the situation, where because of lack of understanding or just plain carelessness a change to fix one problem creates an even bigger problem.
There's a lot that do fall into category 3, though. Measles and smallpox, for instance, and certain forms of cervical cancer. And some that're minor for children are more serious for teenagers and/or adults, so while I'd skip the vaccine for a kid I'd make sure if they hadn't caught it as a kid they got the appropriate vaccination by the time they were old enough for it to be a problem.
Flu, for instance. There's strains that're virulent enough to fall into category 1, but I'm adult and healthy so most strains will just put me out sick from work for a couple of days at the most (as long as I keep an eye on symptoms for signs it's getting too bad and I need real medical attention). So I can mostly skip the vaccinations except if a category-1 strain's circulating.
Chicken pox. Again, unless you're one of the minority for whom it'll be a major problem, the worst it does is keep you home for a week or two. Unless someone in the family's pregnant or planning to be, in which case the risks for a pregnant woman suggest vaccination of the kids to help keep her from being exposed to contagious cases.
You see the kinds of stuff that falls into category 3. And as always, I don't blindly ignore vaccinations. It's always based on "What are the risks of getting the disease, and the consequences short- and long-term?". And if I have to argue with my doctor about explaining those, I find a better doctor.
On the first item, bear in mind that the RIAA has sent cease-and-desist letters to laser printers stating that the RIAA had proof the printer had been sharing files on a P2P network. The laser printer in question didn't have any sort of P2P software at all in it's on-board ROMs. This would indicate to me that the RIAA's methods aren't reliable and that their claims are probably not any indication of actual activity.
It's not just muscles. If you look in the literature, they've found most of the other systems in the body respond in analogous ways. Bone that gets stressed regularly gets stronger. If you regularly do mental problem-solving of various types, your brain becomes better and better at it. And we know the immune system does learn which things to attack and which to ignore by being exposed to them. I'd say it's reasonable that it probably follows a similar pattern: the more it gets to recognize and respond to things, the better it's going to get and the more accurately it's going to learn to respond. And on a more basic level, the immune system evolved to do it's job. I can't help but think that, given our current lack of understanding of how and why it does what it does and what causes various malfunctions, it's probably best to let it do it's thing without interference absent a really compelling reason to poke at it. The less often you mess with it, the less likely the times you do mess with it are to mess it up.
My rule of thumb on vaccines is to look at how bad it'll be to get whatever you're vaccinating against. Generally they fall into three categories:
The first two are things to get vaccinated against. The third... don't bother. I'm a firm believer in letting your immune system handle normally everything it's reasonable to let it handle. It's good excercise for it, and it'll teach it not to over- or under-react to threats. Reserve the external help for the things where you can't risk having it make a mistake. It's the same as any kind of excercise: you get some pain and effort up-front, but reap far more in benefits over the long run.
Caveat: talk to your doctor before you decide which category something falls into. Some things that're not normally a problem can be a big problem for certain people.
Depending on the task:
The "right" way often isn't. For instance, take a Web-analytics server (which I know well, having written one). You have shared data in the 1.5-2 gigabyte neighborhood. It should be pretty obvious that you can't give each thread their own copy of that structure. More importantly, every thread must update entries in that data structure. If they don't, then the thread that handles the next request won't have the updates from this thread to work with. You won't be able to hand the entire sequence of page hits off to a single thread to handle, since page hits are independent in HTTP and the browser doesn't (or at least can't be assumed to) maintain a single connection for the entire sequence. At the same time, the whole program's the poster child for massively parallel programming: an extremely large number (2000 or more per second) of transactions that can be in large part handled independently, it's only at the very end when they store their results that they hit a shared data structure. Languages like Haskell would be ideal for it, except that they impose unacceptably high overhead for things that need to be done for the program to function. So we end up doing it in C. It's not the best tool for the job, it's merely the only tool that lets you get the job done (where the job is defined not just by the processing but also by being able to do it fast enough to keep up with the required traffic volume using a small enough number of cheap enough machines to fit within budget).
NB: one comment I've made about developing software: "You don't pay me the big bucks to know it all. You don't pay me even for knowing exactly which kind of wrench, screwdriver etc. to use on which figurative bolt in the software machinery. You pay me to know when to chuck the wrenches and take an E-Z-Out and a tap to that sucker. And when not to.".
That's a standard concept for multi-threaded programming in any language, though. I was doing it in C back when fork() actually let you modify your siblings' (and parent's) memory. It's even taught in every basic programming course: avoid global variables, stick to local variables only so you don't have to worry about side effects and synchronization. So why hasn't this taken the world by storm at any point in the last 30 years?
Hint: look at the data requirements of large sets of interesting programs.
The big problem won't be moving to FP. The big problem will be that many common programs simply aren't massively parallel. If your job doesn't involve many parallel tasks, you can't take advantage of multiple cores in it.
Of course, you don't have to move to FP to take advantage of multiple cores. You just need to move to multi-threaded programming. I've been doing that for 20 years now. It takes a different approach to breaking down problems into implementable units, that's all. Certain algorithms are easier to expess in a functional language, but that's more a matter of the algorithm than multi-threaded vs. single-threaded. And multi-threaded is hard. It's not a matter of the language, it's a matter of having to remember that other things may have their fingers in your data, or of designing things so they don't. That's what gives most programmers fits, and I don't see FP making that any easier because it happens before you've gotten to the code.
This thing isn't installed via Firefox's add-on process, or even by Firefox at all. It's installed by other malware that's already infected your system. Not hard, just write a few files into Firefox's add-on directory and then edit Firefox's configuration files to register the new add-on by hand. Any competent programmer with some experience with XML processing could code that up in an afternoon.
According to the description, you have to get infected with some other malware first which would then stuff this thing into Firefox's folders and hook it in by manipulating the configuration. So my first thought is that the primary risk is (yet again) Windows users. They're the ones who'll be the targets of the initial malware. Even if you're a Windows user, if you aren't already having a problem with being regularly infected by malware you aren't at great risk. And if you are currently being regularly infected with malware, one more probably isn't your biggest problem. So a lot of sound and fury, signifying nothing we didn't already know and presenting no risk we haven't had for years.
One of the things that'll protect you is that, even in the case of a deceptive trojan, you don't have permission to install things into the system. That's one of the key differences between Windows and the rest of the world: the rest of the world doesn't treat every ordinary user as an administrator by default. So someone may trick you into running the installer for that rootkit, but the installer can't then put the rootkit into the system areas. The OS simply won't allow it to write to those areas. So it'll either fail, or it'll have to have the OS prompt you to allow it to mess with the system areas. Or it'll have to limit itself to installing only into user-accessible areas, in which case it won't be able to hide from utilities running from the administrative side of the system which don't access anything in your user-local areas. That makes it much easier to detect and clean up the infestation.
And on most non-Windows systems, something asking to install itself into the system area is an unusual event. It happens, but rarely enough that most people stop and go "WTF? That's not supposed to happen..." and start poking around to see what's up. On Windows it's normal for an application to write libraries into the Windows system directories. Anywhere else, the automatic reaction to that is "OK, how'd I give it the wrong installation path?". That difference in expectations goes a long way to making life more difficult for trojans.
Simple: at that level default routes don't exist. All routes are manually configured in BGP. And IIRC Cogent had it set so their BGP configuration didn't have any routes for the Sprint AS except through the peering interconnect to Sprint. So when Sprint pulled the plug, Cogent's routers simply wouldn't try sending Sprint traffic through any other network. Cogent was, I think, betting (correctly, it appears) that Sprint would be hurt a lot worse by this than they would.
I'd be hard pressed to envision a scenario where field validation is logically a -view- function.
You've never programmed for a 3270 workstation, then. Basic field validation was part of it's firmware for the simple reason that users wanted fast, immediate feedback for basic errors (like trying to enter letters into a numeric field, or trying to put too many characters into a text field with a maximum size), and with block-mode communication between the workstation and the server that meant the workstation had to do that validation. You simply couldn't submit the entire form back to the server on each and every keystroke without killing performance. So the IBM designers gave the 3270 enough intelligence to do some of the processing locally, without having to send anything back to the server, and added a simple language to the form definition to allow for programming the workstation to do the needed validation.
He was simplifying, and you can see it by looking at what happens before packet loss starts. When traffic loads increase, routers don't immediately start dropping packets. First they start queueing packets up for handling, trying their best to avoid packet loss. Only when their queues fill up do they start discarding packets. TCP waits until that's happened before it starts backing off. A better way is what uTP sounds like it's designed to do: watch for the increasing latency that signals routers are starting to queue packets up, and start backing off before the routers have to start dropping packets. Ideally you avoid ever overflowing the routers' queues and causing packet loss in the first place.
Historical note: TCP uses packet loss because the early routers didn't queue. As soon as they hit 100% of capacity they started dropping packets. It's worked acceptably up until now because another aspect, the adjustable transmit window size (which varies based on round-trip time), that was designed to avoid flooding the receive queue on the destination host also compensates for queues in the intermediate routers. But with more knowledge of how modern infrastructure has evolved, it's possible to do better. Especially when you're designing for a single purpose (uTP won't have to handle small-packet-size latency-sensitive protocols like telnet).
Won't work. First, how do you plan on supporting the variety of OSes out there? I'm not running Windows, so any Windows-based software won't work. Second, how do you plan on getting your scanner to scan the large parts of my system that my user account doesn't have even read-only access to? Proper internal access controls mean my user account doesn't need access to large swathes of the system, so it doesn't get it and it's not going to get it. What can't be read can't be stolen or misused. And no, your scanner doesn't get administrative access. No external software gets administrative access, period, end of discussion. And third, how do you propose to get my browser to run your scanner? Common sense says you lock down your browser from automatically running outside software, that way you don't need to worry as much about how the bad guys are sneaking stuff onto your system. So your scanner will need to be packaged (for a wide variety of OSes) for download and local installation. And it won't be able to integrate with the browser after installation, see above about restricted access to the system (I'm not installing your scanner as root, and my user account doesn't have write access to the Firefox installation directories).
Your proposed solution depends entirely on the very things that make computers vulnerable to compromise in the first place. It's not going to work.
F/OSS isn't a threat to professional software developers. They'll have plenty of work doing the customization and custom programming needed by the companies that use software in their business. The place I work employs 30 full-time developers just at the office I'm at to develop software for in-house use. We make extensive use of F/OSS for the parts that aren't specific to our business, it's cheaper than commercial software and we're legally allowed to change the software to fix bugs and add things we need. That's a lot better than say Oracle, where the turnaround time on bugs is somewhere the high side of 50 weeks for the 1 bug in 10 they actually fix.
Now, software development companies have a problem here. F/OSS is churning out for free what they want to charge people for. A maker I know runs into this in other areas. He's got a small CNC machine shop, a professional-grade print shop, a professional-quality photography setup, and his latest acquisition is a laser-engraving rig. He runs into very hostile reactions from "professional" businesses built around buying those expensive tools/machines and giving customers access to them (spreading the cost over multiple customers in the process), who are having big problems now that their tools aren't that expensive and hobbyists and amateurs can afford them. Those amateurs often do better work than the "professionals", because they're in it for pride or for fun, not just the money. He summed up the "professional" reaction thus: "But they can't own tool! Ogg is only one to own tool!".
The problem here is that there's 3 parties, not two: the person wanting support, the Alfresco partner potentially providing support, and the Alfresco owner. The question is whether the Alfresco partner can be denied the right to provide support to the person wanting it. The answer there is, there isn't an answer. The question is incomplete, it's missing information about what the partner has agreed to. In this case, the partner as part of their partnership agreement signed away their right to support the GPL'd version in return for rights to support the enterprise version they wouldn't have had otherwise. It's not just legal for them to do that, it's entirely reasonable and right for them to be able to do that. It's their business, it's their right to decide that the income from enterprise support is greater than the potential loss from not being able to provide support for the GPL'd version. Someone else may think their decision is dumb, but it's their decision to make.
From the standpoint of the person wanting support, legitimate and fair don't enter into it. They're not a party to the partnership agreement, they're not qualified to decide whether Alfresco is treating it's partners fairly or not. It is, however, rather unusual for open-source companies to deny their partners the right to work on the GPL'd version. RedHat, Sourceforge and the like don't impose any such restrictions that I know of. The most they may do is prohibit partners from making use of any non-GPL'd stuff they have access to in the GPL'd projects. I suspect Alfresco is doing this to try and induce people to use the enterprise version instead of the GPL'd version (if you use the GPL'd version, you lose access to the best sources of support). That'd make me twitchy about using their software.
I know how I'd handle it on Unix. Removeable drives get mounted with the noexec option (or an equivalent set of permissions for filesystem types that don't have the concept of an execute bit). If users aren't allowed to install software on their own, then /home gets mounted that way too. Then it doesn't matter what tricks the user plays or what they rename the file to, the filesystem won't permit the execute permission bit to be set and without that bit the system won't treat the file as executable. You can usually run scripts by feeding them as input files to the appropriate interpreter program (/bin/sh, /usr/bin/perl or similar), but actual programs are right out.
And if they did write such software, they'd surely not survive the ridicule and public humiliation of having their efforts graded against standards developed over 30 years of malicious pranksters with Computer Science degrees and way too much time on their hands trying to get access to the system to guarantee themselves an A (or at least get copies of the professor's answer sheet for the final). Which is in the end the reason Unix is more resistant to attack than Windows: Windows attempts to add security to a system developed for a trusted environment, while Unix is adding convenience onto a system developed for a fundamentally hostile environment.
It isn't. But BitTorrent's also used for illegal file sharing, so any blocking of it to prevent illegal use also blocks legal use.
That's because Blizzard uses BitTorrent for their WoW updater, IIRC.