If you run an infrastructure with clients who frequently need factory resets and re-activations, either you've just stumbled across a huge batch of faulty devices, or you're doing it wrong.
Lets not allow an incompetent sysadmin get in the way of trashing a platform that works great for millions though. Right?
Installing postgres is also a nightmare compared to MySQL.
You mean in a download-the-msi-and-double-click-on-it way, or the apt-get-install-it way?
To sum up: free > $millions, easy > full-featured (in many circumstances).
Well, it's fully-featured, but not necessarily all of those features at the same time. Try doing full-text indexing on a database with foreign-keys on it in MySQL sometime.
Indeed, but there's a difference between a factor that causes an accident and a factor that changes the severity of an accident. The 'lets ban speeding' crowd seem to want to reduce the severity of accidents, whereas the 'lets actually spend time looking at other parts of road safety' want to reduce accidents alltogether.
Usually, I prefer to spend money solving problems that actually make a significant impact rather than waste money on problems which are perceived to be 'easy' but actually have a negligable impact.
What I mean by input validation is aborting with an error if the user has submitted invalid data, e.g. entering "foo" in an e-mail address field. Nothing is encoded or escaped at this point. If I need to store it in a database, the data is stored as-is, using the Perl DBI's automatic escaping feature to make sure SQL injection attacks aren't possible (I can think of one occasion [phroggy.com] when this wasn't adequate and I had to wring my own routine). Whatever else I need to do with the data, any necessary escaping gets done only as the data is being used, it's never stored that way. If I need to send it back to the browser, HTML escaping doesn't happen until I actually print the HTML, or immediately before.
If more devs coded like this, I would be a happier person:) The number of times I see devs coding themselves into a corner when they don't even understand why they're doing what they're doing is horrific.
That's a very interesting idea. Because I use Perl's DBI, I don't normally worry about SQL injection, because I so rarely include a raw variable in a query string (and I'm very careful if I do - for example, I might use a variable that's looping through a list of field names, but the list isn't user-submitted, it's hard-coded into the script).
SQL injection isn't the only way an attacker could stick data in your database, but it's probably one of the easiest if you're vulnerable. The code for the MS library is fairly trivial, you can look at it with a.NET reflector and then implement in any language you want. Basically, it says that if the ASCII code of the input character is between a certain safe range [A-Za-z0-9] then return as is. Any other character, return the HTML-encoded version.
I find it easiest to not validate anything on input, because I don't know what my output is necessarily going to be - could be HTML, could be PDF (for example). If I am outputting to non-HTML I don't want to wade through HTML-encoded soup to get something sensible back out.
If I'm outputting to web, I then always validate / encode *all* content, usually using something like the Microsoft AntiXSS library. This stops user-inputted markup from being rendered, but it also stops markup that's been maliciously inserted into your database from being remembered. Remember the SQL injection attack that appended a javascript snippet to every field it could find? It was looking to do an XSS attack.
If you need to chuck out user-generated markup, make sure you contstruct your whitelist and ruleset very carefully.
Just to add, I've had the beta running on my 901 for a while and have been very happy with it. Can't testify as to whether it boots of the SD card, but wireless works flawlessly (although I did replace the wifi card, so that might not mean anything).
Other thing I love is how the 3G support is amazing. No more messing around with ppp or weird vodafone apps, just plug the dongle in, pick your network and go. Really smooth.
You're confusing the content and the information about the people accessing the content. If I publish a web-page, that is public (copyright me). Anyone can read it. However, what isn't public is the list of IP addresses that accessed that content. When reading a webpage, you don't get to know who else has read that webpage.
Phorm gets to know who else read that webpage. And any other HTTP-only webpage.
I'd argue that there's a gigantic chasm of difference between the headaches you get with installing and configuring Postgres to those you get when installing and configuring Oracle. I've done both. I'd only happily do one of them repeatedly.
I'm also curious as to what exactly is more difficult about Postgres compared with MySQL to install? Maybe I've done it so many times I know what I'm doing, but there seems little difference.
Beat them round the face and tell them they're doing it wrong?
I'd *love* to see a virus or worm that exploits those who have NAT as a critical security measure, and doesn't affect those who know what a firewall is, and how to use it properly. If only to get people to do things properly.
And I'm saying the point is irrelevant. You could categorise broadband consumers as (a) those who need more than one computer to access the internet and (b) those who don't. (a)-type users need a router anyway, and (b) type users don't - they can just plug their modem into their PC.
Users in the first category only need NAT because their ISP gives them one IP address. If they got a ipv6/64, they would still need a router, and would be able to buy one with a firewall on it. Users in the second category don't need NAT, or a router.
Changing the IP addresses of potentially thousands of nodes on a network, as well as re-writing routing information on the routers isn't a particularly trivial task.
And, no offense, but just because you don't understand why ex-company A would ever want to talk to ex-company B, doesn't mean that the requirement doesn't exist:) Think things like shared continuous build environments that dev groups in both networks would like to access. Or document repositories and databases containing information that needs to be shared across both companies. There's plenty more examples.
And if everyone could have as many IPV4 addresses as they wanted, you could still probably buy a $50 appliance that had a firewall configured to deny everything incoming except established traffic out of the box.
NAT exists entirely because of the need to provide point to point routing with a shortage of IP addresses. Remove the shortage and you remove the point of NAT.
We went through a big merger about a year ago, and we're now in the situation where we need to get 2 large internal networks talking to each other. Problem is, they're both in the 10.0.0.0/8 IP address range, so there's zero chance of getting end-to-end routability for everything (everything overlaps with everything else). If someone in ex-company-A wants to talk to a box in ex-company-B's network, it's a 5 day turnaround to get the network guys figure out, assign and implement a static NAT so that they can talk to each other.
It's a great big clusterfuck and wouldn't cost the company as much money if everything could just route to everything else. Seriously, if you're using NAT as anything other than a completely broken fudge, you're doing it wrong.
Well, I'd argue that we want actual well-managed security, instead of just a sense of one. Show me a network admin that's relying on NAT for security, and I'll show you an incompetent network admin.
NAT doesn't give you anything over a well-configured firewall. And if you run NAT instead of a well-configured firewall, then you're not taking 'security' very seriously.
Slashdot Mirror
You make your point well sir. :)
Why RAID your backups? Why bother?
Again, why bring RAID into it? A disk combined with a decent snapshotting system can function as an excellent backup system.
RAID use is orthogonal to backup strategy. The two have nothing to do with each other. RAID helps availability, and sometimes performance.
So why use RAID? Why not have an offline storage... you know... disk?
Exactly. Right tool for the job and all that.
If you run an infrastructure with clients who frequently need factory resets and re-activations, either you've just stumbled across a huge batch of faulty devices, or you're doing it wrong.
Lets not allow an incompetent sysadmin get in the way of trashing a platform that works great for millions though. Right?
It's made by Apple. Of course Apple would rather decide for you what you want on your phone. It's all about the *experience* remember?
I've heard the arguments that postgres is as easy as MySQL, and they're bullshit.
Lets see:
Postgres has no good GUI applications that can compare with MySQL's
Why you need more than one is beyond me. Isn't Pgadmin enough?
their command line application is just as good in its own way
Well, ok. Whatever 'in its own way' means.
and the market share that ensures you need to google multiple times to find the info you're looking for.
Postgres has some of the best documentation of any open source project I've seen. Sure, MySQL is good as well, but lets not spread bullshit here.
Installing postgres is also a nightmare compared to MySQL.
You mean in a download-the-msi-and-double-click-on-it way, or the apt-get-install-it way?
To sum up: free > $millions, easy > full-featured (in many circumstances).
Well, it's fully-featured, but not necessarily all of those features at the same time. Try doing full-text indexing on a database with foreign-keys on it in MySQL sometime.
As it happens, I did go for a job in the UK government. They didn't want me.
Indeed, but there's a difference between a factor that causes an accident and a factor that changes the severity of an accident. The 'lets ban speeding' crowd seem to want to reduce the severity of accidents, whereas the 'lets actually spend time looking at other parts of road safety' want to reduce accidents alltogether.
Usually, I prefer to spend money solving problems that actually make a significant impact rather than waste money on problems which are perceived to be 'easy' but actually have a negligable impact.
If more devs coded like this, I would be a happier person :) The number of times I see devs coding themselves into a corner when they don't even understand why they're doing what they're doing is horrific.
SQL injection isn't the only way an attacker could stick data in your database, but it's probably one of the easiest if you're vulnerable. The code for the MS library is fairly trivial, you can look at it with a .NET reflector and then implement in any language you want. Basically, it says that if the ASCII code of the input character is between a certain safe range [A-Za-z0-9] then return as is. Any other character, return the HTML-encoded version.
I find it easiest to not validate anything on input, because I don't know what my output is necessarily going to be - could be HTML, could be PDF (for example). If I am outputting to non-HTML I don't want to wade through HTML-encoded soup to get something sensible back out.
If I'm outputting to web, I then always validate / encode *all* content, usually using something like the Microsoft AntiXSS library. This stops user-inputted markup from being rendered, but it also stops markup that's been maliciously inserted into your database from being remembered. Remember the SQL injection attack that appended a javascript snippet to every field it could find? It was looking to do an XSS attack.
If you need to chuck out user-generated markup, make sure you contstruct your whitelist and ruleset very carefully.
Except that spam causes my mailserver to use more CPU cycles, more power and therefore gives me a bigger electricity bill.
Bandwidth I'm with you on, partly, as long as you manage it sensibly.
Just to add, I've had the beta running on my 901 for a while and have been very happy with it. Can't testify as to whether it boots of the SD card, but wireless works flawlessly (although I did replace the wifi card, so that might not mean anything).
Other thing I love is how the 3G support is amazing. No more messing around with ppp or weird vodafone apps, just plug the dongle in, pick your network and go. Really smooth.
You're confusing the content and the information about the people accessing the content. If I publish a web-page, that is public (copyright me). Anyone can read it. However, what isn't public is the list of IP addresses that accessed that content. When reading a webpage, you don't get to know who else has read that webpage.
Phorm gets to know who else read that webpage. And any other HTTP-only webpage.
I'd argue that there's a gigantic chasm of difference between the headaches you get with installing and configuring Postgres to those you get when installing and configuring Oracle. I've done both. I'd only happily do one of them repeatedly.
I'm also curious as to what exactly is more difficult about Postgres compared with MySQL to install? Maybe I've done it so many times I know what I'm doing, but there seems little difference.
Beat them round the face and tell them they're doing it wrong?
I'd *love* to see a virus or worm that exploits those who have NAT as a critical security measure, and doesn't affect those who know what a firewall is, and how to use it properly. If only to get people to do things properly.
There's a Gmail labs plugin that alerts you if you write the word 'attach' in the email and then don't attach anything. Useful.
And I'm saying the point is irrelevant. You could categorise broadband consumers as (a) those who need more than one computer to access the internet and (b) those who don't. (a)-type users need a router anyway, and (b) type users don't - they can just plug their modem into their PC.
/64, they would still need a router, and would be able to buy one with a firewall on it. Users in the second category don't need NAT, or a router.
Users in the first category only need NAT because their ISP gives them one IP address. If they got a ipv6
Changing the IP addresses of potentially thousands of nodes on a network, as well as re-writing routing information on the routers isn't a particularly trivial task.
:) Think things like shared continuous build environments that dev groups in both networks would like to access. Or document repositories and databases containing information that needs to be shared across both companies. There's plenty more examples.
And, no offense, but just because you don't understand why ex-company A would ever want to talk to ex-company B, doesn't mean that the requirement doesn't exist
And if everyone could have as many IPV4 addresses as they wanted, you could still probably buy a $50 appliance that had a firewall configured to deny everything incoming except established traffic out of the box.
NAT exists entirely because of the need to provide point to point routing with a shortage of IP addresses. Remove the shortage and you remove the point of NAT.
My company. Huge problem.
We went through a big merger about a year ago, and we're now in the situation where we need to get 2 large internal networks talking to each other. Problem is, they're both in the 10.0.0.0/8 IP address range, so there's zero chance of getting end-to-end routability for everything (everything overlaps with everything else). If someone in ex-company-A wants to talk to a box in ex-company-B's network, it's a 5 day turnaround to get the network guys figure out, assign and implement a static NAT so that they can talk to each other.
It's a great big clusterfuck and wouldn't cost the company as much money if everything could just route to everything else. Seriously, if you're using NAT as anything other than a completely broken fudge, you're doing it wrong.
Well, I'd argue that we want actual well-managed security, instead of just a sense of one. Show me a network admin that's relying on NAT for security, and I'll show you an incompetent network admin.
NAT doesn't give you anything over a well-configured firewall. And if you run NAT instead of a well-configured firewall, then you're not taking 'security' very seriously.