Hey, don't you badmounth the giggly ones! Giggly teenagers can be a real asset!
Watching "I know what you did last summer" sitting right behind a gaggle of giggly girls was an experience to be treasured. I swear, you can THX me to death but you will never get close to the sound effects emanating from those kids.
Octophonic screams of terror! Trembling advice to the characters on screen! The thrills! The chills! The spills[1]! Oh, it was magnificent!
[1] The spills are why you want to sit behind, not in front, of the giggly gals.
In the one I live in, taking a bike from the rack outside a train station will get you hauled to court, you can only go 65 on the freeway, blonde comes out of a bottle, the beer you get with lunch is weak and dull and broadband costs an arm and a leg.
They're bothering with WEP because a lot of people use it and because WEP can be quite useful in many situations, as long as you know its limitations. WEP offers an appropriate level of security for many users.
Security, even wireless security, isn't black and white. It comes in shades of gray (not to mention mauve and chartreuse), and all of them are appropriate for some situation or other.
IEEE 802.11i uses AES, which is not a public key algorithm, but it does provide for a key exchange process which can be based on public key cryptography (but doesn't have to be).
As for hiding the SSID, I question the accuracy of tha article. It doesn't tally with what I've read about 802.11i over the last year. I don't think 802.11i provides for encryption of the entire frame any more than WEP or WPA does, and AFAIK it doesn't provide any security for management frames, so the SSID should still be in the open.
MAC-based authentication is useless for deterring a serious attacker, but 802.11i provides for 802.1x port-based authentication, which typically will operate at the user level.
Although 802.11i provides for generating the master key on-the-fly, I suspect that many installations (expecially home networks) will use pre-shared keys, which are usually hashed passwords and thus vulnerable to dictionary attacks.
Re:I doubt that the block cipher was the problem
on
IEEE Approves 802.11i
·
· Score: 1
One of the most serious problems with WEP was the presence of weak keys in RC4. To make a long story short, an attacker could exploit these to discover the WEP key.
With better protocol design, the problem would have been avoided, but the fact is that there WAS an exploitable weakness in the ciper that was used.
By the way, RC4 is a stream ciper, not a block cipher.
It's true that Windows has come a long way in a short time (longer than unix has in the same time frame), although it still seems to be a long way from unix in terms of automatability, but what about third-party Windows applications? The operating system itself causes only part of your TCO.
Installation and management of unix applications can typically be done from the command line, and many applications that normally use a GUI can at least perform some tasks from the command line. This allows not only operating-system-related tasks to be automated, but also allows application-level tasks to be automated.
I know that *some* applications on Windows behave like this too, but is it the norm (I really don't know)?
Of course Linux isn't free, and nobody who's not a total moron knows that. The question is whether the cost is higher or lower than the cost of Windows.
The pro-Windows camp likes to bring up the fact that you need educated system administrators to run a Unix shop, implying that you don't need skilled people to run a Windows shop, all the while neglecting to mention what happens if you place your Windows servers in the hands of an untrained system administrator.
The also like to rag on the command line, neglecting to mention that it enables Unix people to automate complex tasks and neglecting to mention that Windows admins are *also* tied to the command line, albeit a crappier one since You Should Be Using the GUI.
One thing I rarely hear the pro Windows crowd talk about is how many machines the average system administrator can manage. In my experience the number is far higher for Unix systems than it is for Windows.
We've known for years or even decades that people for whatever reason often won't change the default password of the default account.
Saying "change the password" in the manual in no way absolves the manufacturer of the responsibility to provide reasonable default, especially when they know that many of their customers won't change that default.
If you make a product for the mass market, design your product accordingly and make it easy for your customers to do the right thing and hard to do the wrong thing. Most people will take the path of least resistance. Make sure that path leads to a good place.
Linksys could have done better. They could have required a password change before allowing the access point to accept outside connections. To combat bad passwords they could warn users them. They could even *generate* good passwords and encourage home users to tape a note of the password under the access point.
And the fact that your CEO has a blank e-mail password does not imply that most people leave passwords blank. What we do know is that many people will choose weak passwords, but even weak passwords are better than blank defaults.
Back in 1987 the FORTRAN compiler i used generated code that prited the source-code location of all failures, and that feature was old news even then.
Besides, nontrivial bugs don't result in stack traces or crashes. They result in infrequent, hard-to-spot, anomoalies in the output. No amount of Java stack traces will help you find them.
The iBCS RPMs containing a number of the files they claim were "stolen" were available from SCOs FTP site yesterday and are signed with a SCO key. I know that for a fact. The "we didn't know we were distributing our own IP under that licence" argument sounds kind of weak when you continue to distribute the files in question long after you've identified which ones they are.
Yes, test-driven development should work OK with a distributed team. I'm not so sure about refactoring. Refactoring is changing the design, and it's the practice that lets hard-core XP-ers get away without doing detailed design.
But if single programmers can do unlimited refactoring, where are you? With XP you have your pair-programming buddy to keep you in check; to stop you from making changes that shouldn't be made. But who's going to keep that lone guy in Sweden from messing up the structure?
Collective code ownership is great and should work fine in a distributed environment if you make sure that developers talk to each other, communicate their changes and check in their code early and often. The nice thing about collective ownership is that it cuts down on pissing contests and ego trips, and that's quality-enhancing.
Speaking of testing, we had some interesting experiences with that.
Some people have claimed that it's better to write tests after the code is ready. That way you know what functions to call and what your data structures look like.
Wrong.
If you write the tests after the code, you'll end up with tests that avoid dodgy bits of code and not even notice it. If you write the tests first (and do a good job of it), that won't happen.
We found that our testing was at its most effective when we divided our module test into low-level tests and module-level functionality tests. The developers of a particular functionality would write the low-level tests, but we'd schedule the functionality tests as a separate task and have someone else do them.
The other thing we realized early on was that writing tests is no different from writing code, so we developed tests in pairs too. As with the other code, pair-developed tests vastly outperformed long-programmer-developed tests.
If your open source project is being developed by a team of people all sitting in the same building, directed by a customer who's paying for the software and who accepts XP, then yes, XP should work just fine.
If your open source project is being developed by volunteers all over the world in different time zones, then forget it. Getting XP to work in that situation is probably possible, but difficult and probably expensive.
But if you, like so many others, are using XP as an excuse for shoddy development practices (the "look, we don't need to do requirements analysis or design or documentation because we're using XP" syndrome), then by all means go ahead. It'll work just fine as an excuse.
So let's get to the details. I understand XP pretty darn well. We deployed it successfully at my shop, making all the classic mistakes (and some of our own) on the way. We finally got everything right, and once we did, it worked really well.
I'm going to assume that "open source project" means a project with volunteers all over the world (or all over the country), and no paying customer.
Problem 1: The customer role
The "customer" in XP is a person who represents the users and can make decisions regarding what to implement and when. It's not necessarily a paying customer or an outside person.
The customer is a key person in XP. If you don't have a customer, you can't do XP and if the developers don't do what the customer requires, you can't do XP.
Developers don't make good customers. They're too involved in the technical side of the project and rarely prioritize well. You really need an outsider who is focused only on the end result.
Developers have to listen to the customer. The customer decides what gets done. The developers have no choice in the matter. They can tell the customer how much it will cost to get something done, but in the end they have to do what the customer wants.
Do you have a customer on your project? Will your volunteer developers do what the customer wants? If either answer is no, forget about XP.
Problem 2: Pair programming
Pair programming gets left out of a lot of XP projects. That's unfortunate, because pair programming is a key ingredient of XP. Without it, the process hobbles along.
There are lots of reasons why people give up on pair programming. The poster mentions one: not leaving that big programmer ego at home (it's just programming, not personal). There are others.
What you need to understand is that pair programming is how knowledge and skills are communicated in an XP project. Pair programming compensates for lack of formal design and documentation. Pair programming cuts down on both trivial and serious bugs (the brain not writing the code is usually thinking about the big picture). We found that code written by pairs was consistently better by all subjective and objective criteria we used.
Can you do pair programming in your open source project? If your developers are all in one place and work at the same time, then it's easy. But if they're not, you'll find it very difficult. Instant messaging or even speakerphones don't really help much. And remember, pairs are supposed to be unstable. If you always work with the same person, you'll lose a lot of the benefits of pair programming.
Problem 3: Communication
XP developers tend to be pretty chatty, in my experience. At our shop, verbal communication was a very important component, and to ensure that it was easy, we all worked in the same room (no partitions at all).
How easy is it for your developers to communicate? Instant messaging helps, but isn't all that good since you can't count on instant feedback. A phone works pretty well, but it should be a speakerphone (a headset is OK, but less effective). Are your developers working at the same time? If they're not, how are they going to talk to each other while they work?
I've yet to see a single useful bounce generated by an AV scanner, because they insist on sending the bounce to the forged sender.
People using AV scanners need to hook them up to their SMTP servers so the SMTP server can reject the message as it is being sent. That way innocent people won't see a deluge of misdirected bounce messages.
I've gotten about a ton of bounces like that. But they've all been sent to the (forged) sender of the virus, so they're worse than useless.
The only acceptable way to generate a bounce of a virus message is as part of the SMTP dialog. That way the sending *server* will get the message, and it won't bother me.
While you go off and re-think your proposal, I'll just head over here and delete the last hundred or so of those cleaned bounce saying hey douchebad, you're infected.
Never forget that complexity accumulates. Fixing the bug itself probably costs about the same at every stage, but other costs are introduced as the project moves along, and peak after the software has been deployed.
A bug found after deployment has costs associated with it that a bug found during coding does not:
Cost of running integration and system tests again.
Cost of recertification (if you're in that kind of environment).
Cost of deploying the software again.
Support costs when only half your customers deploy the new version.
Indirect costs caused by using resources to fix bugs rather than implement revenue-generating features.
Liability for damages caused by the bug.
The cost of finding and fixing the bug may be negligible compared to other costs.
Another aspect of the issue is the nature of the bugs you find late. In my experience, bugs that survive testing and deployment tend to be either bugs in requirements or pretty subtle bugs that slipped through testing, and both are more expensive than the type of bugs commonly detected early on during development.
Those domains have been set up that way for years. I wager they've been set up since those ccTLDs became popular. And they don't respond to SMTP connections.
The com and net gTLDs have *not* been set up that way for year and we really don't want them to be.
That doesn't change the fact that Rose is shite. It can do all sorts of things, but I never found one it would do *well* (besides annoying me).
I agree that you need tools *like* Rose, but you sure don't need Rose.
Let's see what I've seen it do:
* Ruin hours of manual diagram layout by rerouting all associations because I had the audacity to move *one* class. Undo? Sure. Moved my class right back. Didn't restore any other part of the layout though.
* Refuse to save any files unless the user had administrative privileges under Windows NT.
* Destroy an entire model (it refused to read back the file it saved) when I pasted some classes from a different model into a class diagram.
* Throw away all my source code when I used the "round-trip" functionality. Thanks, Rational. I guess I didn't really need those method bodies.
And those are only the onese I remember after a couple of years of repressing memories of using Rational Rose.
My *best* Rose memory was sending a bunch of licenses back with a message saying that we couldn't accept the license agreement (which said that Rational wouldn't guarantee that our $12k of software would actually *do* anything). Man, that was fun. We went out and bought stuff from TogetherSoft instead.
No, it would not. The law, should the bill pass, would not apply outside the USA.
If an aussie hack a box in the USA, US courts will consider US law to apply. Conversely, if a damyankee hacks a box in Australia, aussie law applies.
Australian courts don't care if people in the US hack boxes in the US, and US courts don't care if people in Australia hack boxes in Australia. It's when you start crossing borders that things get interesting.
This is nothing new. If you travel to Yemen, Yemenite law applies. You can't do stuff and claim immunity because you're an american citizen (you could try, and I'm sure you'd find the experience... interesting).
In the short term GM corn may produce higher yield than domestic strains, which will encourage farmers to use GM corn, particularly if it is made available at an attractive price as part of an "aid" package.
In the short term this means more food, which is a good thing. In the long term this means that local strains will not be planted, some may diappear entirely, and there would certainly not be enough seed to replace the GM strains, should the country want to.
This isn't about spam. This is about an alternative to dead-tree-based mail. The way the system is built you sign up for what kind of messages you want, and from whom you want them. If you don't want virus-laden, web-bug-ridden breast-enlargement ads, don't sign up for them.
The thing is, this isn't SMTP e-mail. This is a closed messaging system. All messages in the system are digitally signed and authenticated. Sender's can't hide their identities, which means that it's easy for you to refuse mail from any particular sender.
The ISPs don't really enter into it since the service is accessed through the postal service's web servers. There isn't even forwarding (there is notification via regular e-mail).
To sum it up, this is a managed, secure, opt-in service. If you don't like the terms, you don't sign up and it won't cost you a dime. You can hardly expect a better deal than that.
Limiting text width to a set number of pixels is a bad idea. You have no way of knowing how large a font I use or what kind of resolution my screen has.
If I have a very large font, lines will be too short. If I have a very small font, lines will be too long, even if I use a very narrow browser window.
A government site should cater to *everyone*, not just those who use the standard settings in their standard browser.
Slashdot Mirror
Yes. It's called tex4ht and does a surprisingly good job of producing something that can be mangled into presentable shape in a finite amount of time.
Hey, don't you badmounth the giggly ones! Giggly teenagers can be a real asset!
Watching "I know what you did last summer" sitting right behind a gaggle of giggly girls was an experience to be treasured. I swear, you can THX me to death but you will never get close to the sound effects emanating from those kids.
Octophonic screams of terror! Trembling advice to the characters on screen! The thrills! The chills! The spills[1]! Oh, it was magnificent!
[1] The spills are why you want to sit behind, not in front, of the giggly gals.
Which Sweden did you visit?
In the one I live in, taking a bike from the rack outside a train station will get you hauled to court, you can only go 65 on the freeway, blonde comes out of a bottle, the beer you get with lunch is weak and dull and broadband costs an arm and a leg.
I want to go to *your* Sweden!
They're bothering with WEP because a lot of people use it and because WEP can be quite useful in many situations, as long as you know its limitations. WEP offers an appropriate level of security for many users.
Security, even wireless security, isn't black and white. It comes in shades of gray (not to mention mauve and chartreuse), and all of them are appropriate for some situation or other.
Sun was originally an acronym for "Stanford University Network" several of the founders were graduate students at Stanford.
You can take off that shiny hat now.
Stupid admins can mess anything up.
IEEE 802.11i uses AES, which is not a public key algorithm, but it does provide for a key exchange process which can be based on public key cryptography (but doesn't have to be).
As for hiding the SSID, I question the accuracy of tha article. It doesn't tally with what I've read about 802.11i over the last year. I don't think 802.11i provides for encryption of the entire frame any more than WEP or WPA does, and AFAIK it doesn't provide any security for management frames, so the SSID should still be in the open.
MAC-based authentication is useless for deterring a serious attacker, but 802.11i provides for 802.1x port-based authentication, which typically will operate at the user level.
Although 802.11i provides for generating the master key on-the-fly, I suspect that many installations (expecially home networks) will use pre-shared keys, which are usually hashed passwords and thus vulnerable to dictionary attacks.
One of the most serious problems with WEP was the presence of weak keys in RC4. To make a long story short, an attacker could exploit these to discover the WEP key.
With better protocol design, the problem would have been avoided, but the fact is that there WAS an exploitable weakness in the ciper that was used.
By the way, RC4 is a stream ciper, not a block cipher.
It's true that Windows has come a long way in a short time (longer than unix has in the same time frame), although it still seems to be a long way from unix in terms of automatability, but what about third-party Windows applications? The operating system itself causes only part of your TCO.
Installation and management of unix applications can typically be done from the command line, and many applications that normally use a GUI can at least perform some tasks from the command line. This allows not only operating-system-related tasks to be automated, but also allows application-level tasks to be automated.
I know that *some* applications on Windows behave like this too, but is it the norm (I really don't know)?
Of course Linux isn't free, and nobody who's not a total moron knows that. The question is whether the cost is higher or lower than the cost of Windows.
The pro-Windows camp likes to bring up the fact that you need educated system administrators to run a Unix shop, implying that you don't need skilled people to run a Windows shop, all the while neglecting to mention what happens if you place your Windows servers in the hands of an untrained system administrator.
The also like to rag on the command line, neglecting to mention that it enables Unix people to automate complex tasks and neglecting to mention that Windows admins are *also* tied to the command line, albeit a crappier one since You Should Be Using the GUI.
One thing I rarely hear the pro Windows crowd talk about is how many machines the average system administrator can manage. In my experience the number is far higher for Unix systems than it is for Windows.
I've been using Sun workstations with all of those keys except backwards and forwards (it has a couple of others instead) for over a decade now.
As for the mouse, IBM has the "TrackPoint Mouse" prototype, which has a trackpoint device instead of a wheel.
We've known for years or even decades that people for whatever reason often won't change the default password of the default account.
Saying "change the password" in the manual in no way absolves the manufacturer of the responsibility to provide reasonable default, especially when they know that many of their customers won't change that default.
If you make a product for the mass market, design your product accordingly and make it easy for your customers to do the right thing and hard to do the wrong thing. Most people will take the path of least resistance. Make sure that path leads to a good place.
Linksys could have done better. They could have required a password change before allowing the access point to accept outside connections. To combat bad passwords they could warn users them. They could even *generate* good passwords and encourage home users to tape a note of the password under the access point.
And the fact that your CEO has a blank e-mail password does not imply that most people leave passwords blank. What we do know is that many people will choose weak passwords, but even weak passwords are better than blank defaults.
Back in 1987 the FORTRAN compiler i used generated code that prited the source-code location of all failures, and that feature was old news even then.
Besides, nontrivial bugs don't result in stack traces or crashes. They result in infrequent, hard-to-spot, anomoalies in the output. No amount of Java stack traces will help you find them.
I'm going bowling with our super sunday morning. I'm going to watch our super bowl. And on monday I'm going to get sued for trademark violation :-)
Just one point in response to that.
:-)
The iBCS RPMs containing a number of the files they claim were "stolen" were available from SCOs FTP site yesterday and are signed with a SCO key. I know that for a fact. The "we didn't know we were distributing our own IP under that licence" argument sounds kind of weak when you continue to distribute the files in question long after you've identified which ones they are.
Put that in your analogy and smoke it!
Yes, test-driven development should work OK with a distributed team. I'm not so sure about refactoring. Refactoring is changing the design, and it's the practice that lets hard-core XP-ers get away without doing detailed design.
But if single programmers can do unlimited refactoring, where are you? With XP you have your pair-programming buddy to keep you in check; to stop you from making changes that shouldn't be made. But who's going to keep that lone guy in Sweden from messing up the structure?
Collective code ownership is great and should work fine in a distributed environment if you make sure that developers talk to each other, communicate their changes and check in their code early and often. The nice thing about collective ownership is that it cuts down on pissing contests and ego trips, and that's quality-enhancing.
Speaking of testing, we had some interesting experiences with that.
Some people have claimed that it's better to write tests after the code is ready. That way you know what functions to call and what your data structures look like.
Wrong.
If you write the tests after the code, you'll end up with tests that avoid dodgy bits of code and not even notice it. If you write the tests first (and do a good job of it), that won't happen.
We found that our testing was at its most effective when we divided our module test into low-level tests and module-level functionality tests. The developers of a particular functionality would write the low-level tests, but we'd schedule the functionality tests as a separate task and have someone else do them.
The other thing we realized early on was that writing tests is no different from writing code, so we developed tests in pairs too. As with the other code, pair-developed tests vastly outperformed long-programmer-developed tests.
If your open source project is being developed by a team of people all sitting in the same building, directed by a customer who's paying for the software and who accepts XP, then yes, XP should work just fine.
If your open source project is being developed by volunteers all over the world in different time zones, then forget it. Getting XP to work in that situation is probably possible, but difficult and probably expensive.
But if you, like so many others, are using XP as an excuse for shoddy development practices (the "look, we don't need to do requirements analysis or design or documentation because we're using XP" syndrome), then by all means go ahead. It'll work just fine as an excuse.
So let's get to the details. I understand XP pretty darn well. We deployed it successfully at my shop, making all the classic mistakes (and some of our own) on the way. We finally got everything right, and once we did, it worked really well.
I'm going to assume that "open source project" means a project with volunteers all over the world (or all over the country), and no paying customer.
Problem 1: The customer role
The "customer" in XP is a person who represents the users and can make decisions regarding what to implement and when. It's not necessarily a paying customer or an outside person.
The customer is a key person in XP. If you don't have a customer, you can't do XP and if the developers don't do what the customer requires, you can't do XP.
Developers don't make good customers. They're too involved in the technical side of the project and rarely prioritize well. You really need an outsider who is focused only on the end result.
Developers have to listen to the customer. The customer decides what gets done. The developers have no choice in the matter. They can tell the customer how much it will cost to get something done, but in the end they have to do what the customer wants.
Do you have a customer on your project? Will your volunteer developers do what the customer wants? If either answer is no, forget about XP.
Problem 2: Pair programming
Pair programming gets left out of a lot of XP projects. That's unfortunate, because pair programming is a key ingredient of XP. Without it, the process hobbles along.
There are lots of reasons why people give up on pair programming. The poster mentions one: not leaving that big programmer ego at home (it's just programming, not personal). There are others.
What you need to understand is that pair programming is how knowledge and skills are communicated in an XP project. Pair programming compensates for lack of formal design and documentation. Pair programming cuts down on both trivial and serious bugs (the brain not writing the code is usually thinking about the big picture). We found that code written by pairs was consistently better by all subjective and objective criteria we used.
Can you do pair programming in your open source project? If your developers are all in one place and work at the same time, then it's easy. But if they're not, you'll find it very difficult. Instant messaging or even speakerphones don't really help much. And remember, pairs are supposed to be unstable. If you always work with the same person, you'll lose a lot of the benefits of pair programming.
Problem 3: Communication
XP developers tend to be pretty chatty, in my experience. At our shop, verbal communication was a very important component, and to ensure that it was easy, we all worked in the same room (no partitions at all).
How easy is it for your developers to communicate? Instant messaging helps, but isn't all that good since you can't count on instant feedback. A phone works pretty well, but it should be a speakerphone (a headset is OK, but less effective). Are your developers working at the same time? If they're not, how are they going to talk to each other while they work?
In conclusion . . .
T
I've yet to see a single useful bounce generated by an AV scanner, because they insist on sending the bounce to the forged sender.
People using AV scanners need to hook them up to their SMTP servers so the SMTP server can reject the message as it is being sent. That way innocent people won't see a deluge of misdirected bounce messages.
I've gotten about a ton of bounces like that. But they've all been sent to the (forged) sender of the virus, so they're worse than useless.
The only acceptable way to generate a bounce of a virus message is as part of the SMTP dialog. That way the sending *server* will get the message, and it won't bother me.
While you go off and re-think your proposal, I'll just head over here and delete the last hundred or so of those cleaned bounce saying hey douchebad, you're infected.
Never forget that complexity accumulates. Fixing the bug itself probably costs about the same at every stage, but other costs are introduced as the project moves along, and peak after the software has been deployed.
A bug found after deployment has costs associated with it that a bug found during coding does not:
The cost of finding and fixing the bug may be negligible compared to other costs.
Another aspect of the issue is the nature of the bugs you find late. In my experience, bugs that survive testing and deployment tend to be either bugs in requirements or pretty subtle bugs that slipped through testing, and both are more expensive than the type of bugs commonly detected early on during development.
You got it in one.
Those domains have been set up that way for years. I wager they've been set up since those ccTLDs became popular. And they don't respond to SMTP connections.
The com and net gTLDs have *not* been set up that way for year and we really don't want them to be.
That doesn't change the fact that Rose is shite. It can do all sorts of things, but I never found one it would do *well* (besides annoying me).
I agree that you need tools *like* Rose, but you sure don't need Rose.
Let's see what I've seen it do:
* Ruin hours of manual diagram layout by rerouting all associations because I had the audacity to move *one* class. Undo? Sure. Moved my class right back. Didn't restore any other part of the layout though.
* Refuse to save any files unless the user had administrative privileges under Windows NT.
* Destroy an entire model (it refused to read back the file it saved) when I pasted some classes from a different model into a class diagram.
* Throw away all my source code when I used the "round-trip" functionality. Thanks, Rational. I guess I didn't really need those method bodies.
And those are only the onese I remember after a couple of years of repressing memories of using Rational Rose.
My *best* Rose memory was sending a bunch of licenses back with a message saying that we couldn't accept the license agreement (which said that Rational wouldn't guarantee that our $12k of software would actually *do* anything). Man, that was fun. We went out and bought stuff from TogetherSoft instead.
No, it would not. The law, should the bill pass, would not apply outside the USA.
... interesting).
If an aussie hack a box in the USA, US courts will consider US law to apply. Conversely, if a damyankee hacks a box in Australia, aussie law applies.
Australian courts don't care if people in the US hack boxes in the US, and US courts don't care if people in Australia hack boxes in Australia. It's when you start crossing borders that things get interesting.
This is nothing new. If you travel to Yemen, Yemenite law applies. You can't do stuff and claim immunity because you're an american citizen (you could try, and I'm sure you'd find the experience
It's not quite that simple.
In the short term GM corn may produce higher yield than domestic strains, which will encourage farmers to use GM corn, particularly if it is made available at an attractive price as part of an "aid" package.
In the short term this means more food, which is a good thing. In the long term this means that local strains will not be planted, some may diappear entirely, and there would certainly not be enough seed to replace the GM strains, should the country want to.
It seems a lot of people don't get it.
This isn't about spam. This is about an alternative to dead-tree-based mail. The way the system is built you sign up for what kind of messages you want, and from whom you want them. If you don't want virus-laden, web-bug-ridden breast-enlargement ads, don't sign up for them.
The thing is, this isn't SMTP e-mail. This is a closed messaging system. All messages in the system are digitally signed and authenticated. Sender's can't hide their identities, which means that it's easy for you to refuse mail from any particular sender.
The ISPs don't really enter into it since the service is accessed through the postal service's web servers. There isn't even forwarding (there is notification via regular e-mail).
To sum it up, this is a managed, secure, opt-in service. If you don't like the terms, you don't sign up and it won't cost you a dime. You can hardly expect a better deal than that.
Limiting text width to a set number of pixels is a bad idea. You have no way of knowing how large a font I use or what kind of resolution my screen has.
If I have a very large font, lines will be too short. If I have a very small font, lines will be too long, even if I use a very narrow browser window.
A government site should cater to *everyone*, not just those who use the standard settings in their standard browser.