However, I'd absolutely rather have messy data: imagine some type of glitch occurs (yes, unavoidable when working on anything with "serious" volume) and you end up performing the credit card charge but some part of the insert fails. In that case I want a partial transaction because there really was a partial transaction. It will aid in identifiying that something happened, and also in figuring out what it was.
So you do it in multiple transactions then. Transaction 1 inserts the order data, transaction 2 processes the payment, transaction 3 updates statistics, with each saving a note somewhere of how far it got.
This way you have both things: consistency, and the possibility to have a partially complete (but cut off at a well determined point) operations.
Yes, I do log errors elsewhere. But if you've worked on anything "serious" you'll know that there's always an error case that can come up aside from what you're able to log well.
That's easy, in my application I just log all of the requests headers and POST data. That's step 1, and will always succeed unless the database is down, as it's nice and simple.
Step 2 is processing it, in one transaction. If it fails, I can retry the operation.
I've come accross other examples, like making inventory records that don't have a foreign key because it's better than having no record at all.
Why? In a well designed database, things don't just vanish. What happens is that it returns an error to the user, who knows it wasn't saved at all, instead of being in some half-saved state the user may not be able to recover from. Then the user can retry saving it, knowing that unless the database says it's good, nothing gets written, and so there won't be 20 half-written records in the database due to the previous attempts.
But this isn't really related to the discussion at hand.
At least in my case, the database enforces integrity. The business layer is there, but: It doesn't have to remain being the only one (eg, I might want to migrate to a more modern system at some point), and it's pretty thin. My business layer basically provides a friendly interface. If the database says "foreign key violation" the business layer would translate that "That user doesn't exist".
That's the reason OOP is there:-) Database abstraction, DAO's and Model's (POxO/DTO/whatever) can be responsible for storing/validating data and reused in other app's (as webservices, libraries,...)
None of this applies when somebody logs in with psql/enterprise manager/whatever and updates something in the database by hand. You can have all the OO and libraries you want, but it doesn't help if the new application doesn't use it. Yesterday we had code in VB6, today we have it in C#. Application is completely different. Guaranteeing that all the VB code will be exactly translated to C# is very, very hard.
On the other hand, the database remains being the same, and all the constraints it has don't care about which language, methodology or whatever is being used. VB, C#, Perl, PHP, are all automatically held to the same constraints.
You can have N account types (customer, broker, corporate,...) Each account type have it's own set of "valid data" constraints. And even inside the same "account type", the validation can change (if an account was opened before date XX, it's permitted to do bla). You just can't do that using simple foreign keys. And if you want to ensure your data is consistent, you *will* need Stored Procedures and Triggers.
And what's the problem with that? Use stored procedures and triggers then. Seriously, in a database of any size, forget about any attempts at compatibility with other databases. It only works on very, very trivial applications.
Just take postgres and mysql. PostgreSQL loves big transactions. The overhead for a transaction is high, but it's perfectly happy with large, long running transactions, and the more the better. PostgreSQL will be slow if you have a transaction per statement.
On the other hand, databases like mySQL want tiny transactions because the locks are really problematic. Leave a transaction uncommitted, and quickly things will grind to a halt. On the other hand, on postgresql the worst problem will be the lack of vacuum, which will gradually slow things down, but doesn't cause immediate problems.
If you make it for mySQL, without a redesign it'll suck on postgres and viceversa. If you try to make it for both, it'll be suboptimal on both.
You don't need to pay in Second Life to have furniture, there's plenty of it that's free. Now, if you want custom furniture and no artistic ability you can pay somebody to make it for you. Or you can buy something commercial, which is generally better made. But there's quite a lot of decent free stuff, if you can find it among the pile of various free crap.
OSS won't do anything to change that situation, really.
The one thing you HAVE to pay for is land, but land happens to translate to server resources, so open source or not it has to be paid for anyway.
1. MySQL's locking is VASTLY inferior to MVCC 2. Many of MySQL's users are complete morons
Locking: MVCC allows really good concurrency, to the point where SELECT * FROM table is a perfectly good backup strategy. This kills row locking databases like mysql because this results in locking the whole table, as rows are overwritten in place, and you can't allow them changing under you while reading the table.
2. MANY MySQL users have no idea of what a decent database should be like, and to boot use it in completely braindead ways. Many of those applications are coded with no regard for the underlying DB (locking issues) and general DB practices (normalization, not requesting more than you need).
For example, somebody else here posted about an application that does a "SELECT * FROM table" then only uses the 5 first rows. Let's compare what happens:
MySQL: Whole table locked while reading, absolutely lousy concurrency as no concurrency is possible on that table.
PostgreSQL: Not very good performance due to reading more than necessary, but no concurrency problems at all.
My guess is that the test you mention had something of the sort. MySQL got bogged down with locks and ground to a halt, while postgres continued chugging along just fine.
Well, I sure hope you never work on anything serious.
The database's function is to provide a RELIABLE storage for your data. Part of the whole reliability thing is making sure crap can't get in, because once it's there everything goes to heck.
For instance, let's take a shopping cart. Can an order be for a negative quantity? If your app doesn't work that way (it could, using a negative amount for returns for example), and you still allow it in the DB, then all your reporting goes to heck, as SELECT SUM... now returns the wrong thing.
A proper database is set up in such a way that every piece of data in it makese sense. This means for instance not having things like orders hanging around without in the void without being linked to some client. This is something easily ensured by foreign keys. Otherwise you have an utter mess - the total of the orders in the database doesn't match the sum of the orders of all clients!
If you put your checks in the database, you have a guarantee that when somebody else codes another frontend to it (say, you had a website and now are making a special version for PDAs), if the application does the wrong thing, the database simply won't let it happen. This may cost a bit of speed, but I assure you that peace, your sanity and your ASS (if you have a boss and he's got any sense, he's not going to like it at ALL if it turns out that reports don't match reality, and that reality can't be even easily extracted) is far, far more valuable.
I have flexibility without issues like that. I use Perl.
Let's look at the issues:
magic_quotes: Problem that doesn't exist in Perl. The way you do things is: my $sth = $dbh->prepare('SELECT foo FROM bar WHERE id = ?'); $sth->execute($id);
No manual quoting needed, no SQL injection issues. Perfect security. Notice the '' quoting, it prevents variables in strings from working.
register_globals: CGI.pm allows importing parameters into the namespace you say. Documentation has dire warnings against importing into main. In Perl you'd have $Args::user_name, not $user_name (which could override something important and is obviously a braindead idea)
Also, unlike PHP, Perl doesn't set such things system-wide, the script does. This way you can't really write a script that requires a specific configuration of the interpreter.
Error reporting: Perl is sane about error reporting, and has taint checks that make the interpreter outright refuse to do something insecure, like opening a filename passed in a parameter unless verified.
Inconsistencies: Perl also falls to the (5 == "5 SELECT...") trap, but emits a warning if you do that. Strings are compared with "eq" and not ==. You can get this wrong, but it's hard to miss.
Input checking: In Perl it's easy. The language was made to parse text, and the DBI API makes a large amount of it unnecessary.
Obviously, Perl has its failings as well. For example, it's very common to store large amounts of data in hash trees ($self->{settings}{rows_per_page}) which has the problem of that as they're not variables, declaration of hash elements can't be forced. But overall it's a much less braindead language than PHP and just as easy to write in.
Now really. Of course I wouldn't like being without internet access for several days, for the simple reason that a large part of my life is related to it somehow. With no internet I'd lose contact with many people, would find it much harder to find documentation for some of the work I do, etc.
But isn't every specialist that way? I bet that my father would also feel uncomfortable if he couldn't play the viola for a few days. For me, the main theme in my life is internet and computers. For others it's a musical instrument, drawing, playing soccer, etc. Everybody feels uncomfortable when they're unable to do their favourite activity for a while.
Even for "normal" people with no obsession with anything in particular it still works that way. When somebody's car breaks they're often grumpy while it's being fixed, as all of a sudden their freedom of movement got drastically reduced.
There probably are people with serious problems, but I think most of the people don't have any addiction of any sort, they simply became dependent on it, like many people depend on their car or telephone. For them it just became an indispensable tool.
Did you even read the page you linked? At the bottom of it:
Careful investigation of the Hindenburg disaster verified the opinion of the engineers on the Hindenburg and proved that it was the flammable aluminum powder filled paint varnish that coated the infamous airship, not the hydrogen that started the fateful fire.
The Hindenburg repeated the famous experiment of Ben Franklin regarding collection of electric charge on an object in the sky. Ben Franklin flew a kite in a storm to learn about lightening. The captain of the Hindenburg provided the 800' long, 236 ton, aluminum-powder varnish covered airship as a much larger electric charge collector. As the Hindenburg was grounded by dropping landing lines, the experiment was complete and electrical discharge in the Hindenburg's skin started the fire. The Hindenburg would have burned and crashed if it had been filled with helium or simply held in the air by some other force.
Besides, I never got this argument. So hydrogen burns, big deal. So does gasoline, which has been involved in plenty accidents, and for some reason that doesn't stop anybody from using it.
Mind, I also thing the hydrogen economy is bunk, but that's just a really lousy argument against it.
It's really neat how this week Joel says that "simplicity is overrated", while a couple weeks he was writing on how there are too many options in the shutdown menu, and how the average user shouldn't have to give a damn about the difference between shutdown, suspend and hibernate.
Of course, it's a complex problem. Take said shutdown screen. Apparently there are now laptops that will first suspend to RAM, then transition to hibernate. On the surface that's nice and simple. But if you think of it, that means the laptop is using the hard disk - a delicate and sensitive component that doesn't like in the slightest being thrown into a car's seat while it's spinning. Now while it's stopped it can deal with that very well. This is the sort of the thing that ADDS complexity: With such a mechanism I now have to consider whether the computer is writing or going to write to disk now, and whether my handling of it is safe or not, while previously choosing the wrong option from the menu would only result in a few extra seconds of wasted time.
Space isn't supposed to be allocated efficiently. If 1.2.3.4 goes to the US, 1.2.3.5 goes to Spain, and 1.2.3.6 is in Japan that makes routing a huge pain.
This is the problem IPv6 is supposed to solve. With so much address space you can just assign a range to a country which is much, much larger than all of IPv4 and forget about having huge routing tables.
You being in a privileged position doesn't stop you from being a jerk, and if it gets to the point that it's the kids trying to get you to come to dinner and not the other way, then it's pretty obvious you're doing something wrong.
This is a bit different if you sell an actual product though. For google, the cost of delivering their own ad, and delivering somebody else's ad is effectively the same, and there are no intermediaries.
Now, you make periperhals. Let's say you make a keyboard that costs $5 to produce, which you sell to a store for $10 and which the user gets for $20. Also, if the $10 price is: $5 production + $3 profit + $2 transport costs, you could sell it to your own employees for $8 and earn exactly the same amount of money as before, while charging much below what it costs in a shop.
Well, that depends. You can set the ToS bits in the IP header. What actually happens depends on the router. If you have one application set to "Maximize bandwidth" while the other one is set to "normal service", AND the router looks at that and actually does what you asked for, you can get it to work that way.
Or you can use a Linux box and set up traffic shaping, in which case you can divide bandwidth in any way you want. HTB makes what you say easy to do. Say: 20% for server A, 50% for server B, 30% for server C, servers A and B can use the full pipe if nothing else wants it, and C is always limited to 30%.
It's best done with CompactFlash. CF actually has an IDE interface, and all that you need to use it as a hard disk is an adapter that simply provides a connector of the right shape. No drivers or anything else needed. The only problem is that at least on my card there's no DMA, so data transfer is slow. On the other hand, seek latency is awesome.
I've heard some rumors that newer CF can do DMA, but haven't seen it myself.
Now pretty much every mail server supports running all the checks you want before accepting delivery.
This is really the best way to do it, IMO. If you reject it, it doesn't vanish into nothingness, and the sender notices it wasn't delivered. It also works system-wide, which means that most junk doesn't get delivered to a mailbox at all.
Uhh, what the heck is that nonsense? I see no actual discussion of anything there.
This is the "security expert" that never heard of SYN Cookies before, started the whole mess about raw sockets in XP, and ran (or maybe still runs, haven't checked) a port scanner's supposed to scan the ports of the one going to the website, but can be tricked into scanning somebody else.
Well, it's expensive. Are you going to waste a box that can run Vista on that? A box that can run shorewall and traffic shaping is a P100 with 64MB RAM, which can be found for free.
You have two options: 1. The Vista box shapes traffic for itself and nothing else. This isn't terribly effective as to have a good effect you need to shape all of the traffic, giving different hosts different priority.
2. You have the Vista box as a firewall for the network. In this case it's expensive, can be broken into, and if it is, you have a major mess because all your traffic will be going through it.
An old P100 with 64MB RAM running shorewall is practically invulnerable. No ports need to be open, excepting for SSH from the internal network, or not even that. You can run it from CompactFlash and have it with no moving parts at all. It'll quietly sit there for years shoveling packets back and forth with zero problems. It doesn't accept connections, it has no open ports of public services -- it's impossible to break into barring a kernel bug in the TCP stack.
That's nice, but it doesn't match the current situation.
For example, while the "hibernate after a while" idea is nice, it requires extra hardware to be optimal. My guess is that it relies on hard disks with Flash, as suddenly spinning up the hard disk while the laptop is being transported isn't necessarily a great idea.
Initially it will suspend to RAM, then go into a mode like Hibernate, and after a little while longer, it will almost entirely shut down -- but not quite
This makes no sense at all. Hibernate is a complete poweroff mode, with RAM flushed to disk and all hardware being turned off. It uses zero battery power.
It will also be able to do things like checking your e-mail and displaying new messages on a secondary, external LCD screen without powering on the whole machine
This doesn't make much sense either. If the machine is suspended, then why would it check the mail? It can check when it comes back up. The point of any sort of suspend is that you're not actually using it. Checking mail means maintaining an ethernet or worse, WiFi connection. Not exactly power efficient.
This sounds like "monitor style suspend" for laptops. CTRs for example have multiple suspend modes, which take progressively longer to come back from (black screen, coil off, everything off) and can over time switch to a lower power mode.
But on the laptop you still have suspend, shutdown and lock. All you've managed to do is to merge various suspend modes into one. It's nice, but that big of an improvement.
The problem is that the reality and physical constraints don't give a damn about user friendliness. Example:
Sleep: Suspend to RAM. Can be nearly instant (few seconds), but requires battery power, so can't be done if it ran out, or if you plan keeping it like that for a week
Hibernate: Takes longer, but doesn't require battery power. Hibernate when the lid is closed would be likely to result in hard disk damage, as it's far from instant.
Shutdown: Even longer than hibernate. Loss of state, so can't be done automatically.
Lock: Might be possible to combine with "sleep", but runs into the problem of that you might want to have something actually running (downloads, say) while the computer isn't accessible.
Yes, it'd be great if you could just close the lid and be done with it, but unfortunately we don't have nuclear power stations in our laptops.
Sheesh. If they are going to use a cartoon character, they could have at least used Gadget Hackwrench instead, who made neat things that are at least plausible;-)
Baldness is not a hair style Being single is not my wife Being a virgin is not a style of having sex Being a civilian is not a type of military service Being fully functional is not a type of disability etc, etc.
Slashdot Mirror
So you do it in multiple transactions then. Transaction 1 inserts the order data, transaction 2 processes the payment, transaction 3 updates statistics, with each saving a note somewhere of how far it got.
This way you have both things: consistency, and the possibility to have a partially complete (but cut off at a well determined point) operations.
That's easy, in my application I just log all of the requests headers and POST data. That's step 1, and will always succeed unless the database is down, as it's nice and simple.
Step 2 is processing it, in one transaction. If it fails, I can retry the operation.
Why? In a well designed database, things don't just vanish. What happens is that it returns an error to the user, who knows it wasn't saved at all, instead of being in some half-saved state the user may not be able to recover from. Then the user can retry saving it, knowing that unless the database says it's good, nothing gets written, and so there won't be 20 half-written records in the database due to the previous attempts.
But this isn't really related to the discussion at hand.
At least in my case, the database enforces integrity. The business layer is there, but: It doesn't have to remain being the only one (eg, I might want to migrate to a more modern system at some point), and it's pretty thin. My business layer basically provides a friendly interface. If the database says "foreign key violation" the business layer would translate that "That user doesn't exist".
None of this applies when somebody logs in with psql/enterprise manager/whatever and updates something in the database by hand. You can have all the OO and libraries you want, but it doesn't help if the new application doesn't use it. Yesterday we had code in VB6, today we have it in C#. Application is completely different. Guaranteeing that all the VB code will be exactly translated to C# is very, very hard.
On the other hand, the database remains being the same, and all the constraints it has don't care about which language, methodology or whatever is being used. VB, C#, Perl, PHP, are all automatically held to the same constraints.
And what's the problem with that? Use stored procedures and triggers then. Seriously, in a database of any size, forget about any attempts at compatibility with other databases. It only works on very, very trivial applications.
Just take postgres and mysql. PostgreSQL loves big transactions. The overhead for a transaction is high, but it's perfectly happy with large, long running transactions, and the more the better. PostgreSQL will be slow if you have a transaction per statement.
On the other hand, databases like mySQL want tiny transactions because the locks are really problematic. Leave a transaction uncommitted, and quickly things will grind to a halt. On the other hand, on postgresql the worst problem will be the lack of vacuum, which will gradually slow things down, but doesn't cause immediate problems.
If you make it for mySQL, without a redesign it'll suck on postgres and viceversa. If you try to make it for both, it'll be suboptimal on both.
You don't need to pay in Second Life to have furniture, there's plenty of it that's free. Now, if you want custom furniture and no artistic ability you can pay somebody to make it for you. Or you can buy something commercial, which is generally better made. But there's quite a lot of decent free stuff, if you can find it among the pile of various free crap.
OSS won't do anything to change that situation, really.
The one thing you HAVE to pay for is land, but land happens to translate to server resources, so open source or not it has to be paid for anyway.
This is probably due to two things:
1. MySQL's locking is VASTLY inferior to MVCC
2. Many of MySQL's users are complete morons
Locking: MVCC allows really good concurrency, to the point where SELECT * FROM table is a perfectly good backup strategy. This kills row locking databases like mysql because this results in locking the whole table, as rows are overwritten in place, and you can't allow them changing under you while reading the table.
2. MANY MySQL users have no idea of what a decent database should be like, and to boot use it in completely braindead ways. Many of those applications are coded with no regard for the underlying DB (locking issues) and general DB practices (normalization, not requesting more than you need).
For example, somebody else here posted about an application that does a "SELECT * FROM table" then only uses the 5 first rows. Let's compare what happens:
MySQL: Whole table locked while reading, absolutely lousy concurrency as no concurrency is possible on that table.
PostgreSQL: Not very good performance due to reading more than necessary, but no concurrency problems at all.
My guess is that the test you mention had something of the sort. MySQL got bogged down with locks and ground to a halt, while postgres continued chugging along just fine.
Well, I sure hope you never work on anything serious.
The database's function is to provide a RELIABLE storage for your data. Part of the whole reliability thing is making sure crap can't get in, because once it's there everything goes to heck.
For instance, let's take a shopping cart. Can an order be for a negative quantity? If your app doesn't work that way (it could, using a negative amount for returns for example), and you still allow it in the DB, then all your reporting goes to heck, as SELECT SUM... now returns the wrong thing.
A proper database is set up in such a way that every piece of data in it makese sense. This means for instance not having things like orders hanging around without in the void without being linked to some client. This is something easily ensured by foreign keys. Otherwise you have an utter mess - the total of the orders in the database doesn't match the sum of the orders of all clients!
If you put your checks in the database, you have a guarantee that when somebody else codes another frontend to it (say, you had a website and now are making a special version for PDAs), if the application does the wrong thing, the database simply won't let it happen. This may cost a bit of speed, but I assure you that peace, your sanity and your ASS (if you have a boss and he's got any sense, he's not going to like it at ALL if it turns out that reports don't match reality, and that reality can't be even easily extracted) is far, far more valuable.
Which is one of the problems. Why the heck is stuff like that in an
In Perl, you do things like: This way you don't need to worry whether it's enabled or not enabled in some
That's exactly how it should be. Now, why does it seem that most PHP software doesn't use it?
I have flexibility without issues like that. I use Perl.
Let's look at the issues:
magic_quotes: Problem that doesn't exist in Perl. The way you do things is:
my $sth = $dbh->prepare('SELECT foo FROM bar WHERE id = ?');
$sth->execute($id);
No manual quoting needed, no SQL injection issues. Perfect security. Notice the '' quoting, it prevents variables in strings from working.
register_globals: CGI.pm allows importing parameters into the namespace you say. Documentation has dire warnings against importing into main. In Perl you'd have $Args::user_name, not $user_name (which could override something important and is obviously a braindead idea)
Also, unlike PHP, Perl doesn't set such things system-wide, the script does. This way you can't really write a script that requires a specific configuration of the interpreter.
Error reporting: Perl is sane about error reporting, and has taint checks that make the interpreter outright refuse to do something insecure, like opening a filename passed in a parameter unless verified.
Inconsistencies: Perl also falls to the (5 == "5 SELECT...") trap, but emits a warning if you do that. Strings are compared with "eq" and not ==. You can get this wrong, but it's hard to miss.
Input checking: In Perl it's easy. The language was made to parse text, and the DBI API makes a large amount of it unnecessary.
Obviously, Perl has its failings as well. For example, it's very common to store large amounts of data in hash trees ($self->{settings}{rows_per_page}) which has the problem of that as they're not variables, declaration of hash elements can't be forced. But overall it's a much less braindead language than PHP and just as easy to write in.
Now really. Of course I wouldn't like being without internet access for several days, for the simple reason that a large part of my life is related to it somehow. With no internet I'd lose contact with many people, would find it much harder to find documentation for some of the work I do, etc.
But isn't every specialist that way? I bet that my father would also feel uncomfortable if he couldn't play the viola for a few days. For me, the main theme in my life is internet and computers. For others it's a musical instrument, drawing, playing soccer, etc. Everybody feels uncomfortable when they're unable to do their favourite activity for a while.
Even for "normal" people with no obsession with anything in particular it still works that way. When somebody's car breaks they're often grumpy while it's being fixed, as all of a sudden their freedom of movement got drastically reduced.
There probably are people with serious problems, but I think most of the people don't have any addiction of any sort, they simply became dependent on it, like many people depend on their car or telephone. For them it just became an indispensable tool.
Thank you, I will bookmark your post to give a link to it the next time somebody asks why I won't touch PHP with a 10 foot pole.
You know, modern systems have this feature called "logs", and often you can determine what went wrong by looking there.
For instance, if after to a break-in you notice somebody tried to ssh in 500 times unsuccessfully, perhaps the 501th one worked.
In the PHP case, it's very likely the apache logs would have something interesting.
Besides, I never got this argument. So hydrogen burns, big deal. So does gasoline, which has been involved in plenty accidents, and for some reason that doesn't stop anybody from using it.
Mind, I also thing the hydrogen economy is bunk, but that's just a really lousy argument against it.
It's really neat how this week Joel says that "simplicity is overrated", while a couple weeks he was writing on how there are too many options in the shutdown menu, and how the average user shouldn't have to give a damn about the difference between shutdown, suspend and hibernate.
Of course, it's a complex problem. Take said shutdown screen. Apparently there are now laptops that will first suspend to RAM, then transition to hibernate. On the surface that's nice and simple. But if you think of it, that means the laptop is using the hard disk - a delicate and sensitive component that doesn't like in the slightest being thrown into a car's seat while it's spinning. Now while it's stopped it can deal with that very well. This is the sort of the thing that ADDS complexity: With such a mechanism I now have to consider whether the computer is writing or going to write to disk now, and whether my handling of it is safe or not, while previously choosing the wrong option from the menu would only result in a few extra seconds of wasted time.
Space isn't supposed to be allocated efficiently. If 1.2.3.4 goes to the US, 1.2.3.5 goes to Spain, and 1.2.3.6 is in Japan that makes routing a huge pain.
This is the problem IPv6 is supposed to solve. With so much address space you can just assign a range to a country which is much, much larger than all of IPv4 and forget about having huge routing tables.
Parents can be wrong as well, you know.
You being in a privileged position doesn't stop you from being a jerk, and if it gets to the point that it's the kids trying to get you to come to dinner and not the other way, then it's pretty obvious you're doing something wrong.
This is a bit different if you sell an actual product though. For google, the cost of delivering their own ad, and delivering somebody else's ad is effectively the same, and there are no intermediaries.
Now, you make periperhals. Let's say you make a keyboard that costs $5 to produce, which you sell to a store for $10 and which the user gets for $20. Also, if the $10 price is: $5 production + $3 profit + $2 transport costs, you could sell it to your own employees for $8 and earn exactly the same amount of money as before, while charging much below what it costs in a shop.
Well, that depends. You can set the ToS bits in the IP header. What actually happens depends on the router. If you have one application set to "Maximize bandwidth" while the other one is set to "normal service", AND the router looks at that and actually does what you asked for, you can get it to work that way.
Or you can use a Linux box and set up traffic shaping, in which case you can divide bandwidth in any way you want. HTB makes what you say easy to do. Say: 20% for server A, 50% for server B, 30% for server C, servers A and B can use the full pipe if nothing else wants it, and C is always limited to 30%.
It's best done with CompactFlash. CF actually has an IDE interface, and all that you need to use it as a hard disk is an adapter that simply provides a connector of the right shape. No drivers or anything else needed. The only problem is that at least on my card there's no DMA, so data transfer is slow. On the other hand, seek latency is awesome.
I've heard some rumors that newer CF can do DMA, but haven't seen it myself.
Now pretty much every mail server supports running all the checks you want before accepting delivery.
This is really the best way to do it, IMO. If you reject it, it doesn't vanish into nothingness, and the sender notices it wasn't delivered. It also works system-wide, which means that most junk doesn't get delivered to a mailbox at all.
Uhh, what the heck is that nonsense? I see no actual discussion of anything there.
This is the "security expert" that never heard of SYN Cookies before, started the whole mess about raw sockets in XP, and ran (or maybe still runs, haven't checked) a port scanner's supposed to scan the ports of the one going to the website, but can be tricked into scanning somebody else.
Well, it's expensive. Are you going to waste a box that can run Vista on that? A box that can run shorewall and traffic shaping is a P100 with 64MB RAM, which can be found for free.
You have two options:
1. The Vista box shapes traffic for itself and nothing else. This isn't terribly effective as to have a good effect you need to shape all of the traffic, giving different hosts different priority.
2. You have the Vista box as a firewall for the network. In this case it's expensive, can be broken into, and if it is, you have a major mess because all your traffic will be going through it.
An old P100 with 64MB RAM running shorewall is practically invulnerable. No ports need to be open, excepting for SSH from the internal network, or not even that. You can run it from CompactFlash and have it with no moving parts at all. It'll quietly sit there for years shoveling packets back and forth with zero problems. It doesn't accept connections, it has no open ports of public services -- it's impossible to break into barring a kernel bug in the TCP stack.
For example, while the "hibernate after a while" idea is nice, it requires extra hardware to be optimal. My guess is that it relies on hard disks with Flash, as suddenly spinning up the hard disk while the laptop is being transported isn't necessarily a great idea.
This makes no sense at all. Hibernate is a complete poweroff mode, with RAM flushed to disk and all hardware being turned off. It uses zero battery power.
This doesn't make much sense either. If the machine is suspended, then why would it check the mail? It can check when it comes back up. The point of any sort of suspend is that you're not actually using it. Checking mail means maintaining an ethernet or worse, WiFi connection. Not exactly power efficient.
This sounds like "monitor style suspend" for laptops. CTRs for example have multiple suspend modes, which take progressively longer to come back from (black screen, coil off, everything off) and can over time switch to a lower power mode.
But on the laptop you still have suspend, shutdown and lock. All you've managed to do is to merge various suspend modes into one. It's nice, but that big of an improvement.
The problem is that the reality and physical constraints don't give a damn about user friendliness. Example:
Sleep: Suspend to RAM. Can be nearly instant (few seconds), but requires battery power, so can't be done if it ran out, or if you plan keeping it like that for a week
Hibernate: Takes longer, but doesn't require battery power. Hibernate when the lid is closed would be likely to result in hard disk damage, as it's far from instant.
Shutdown: Even longer than hibernate. Loss of state, so can't be done automatically.
Lock: Might be possible to combine with "sleep", but runs into the problem of that you might want to have something actually running (downloads, say) while the computer isn't accessible.
Yes, it'd be great if you could just close the lid and be done with it, but unfortunately we don't have nuclear power stations in our laptops.
Sheesh. If they are going to use a cartoon character, they could have at least used Gadget Hackwrench instead, who made neat things that are at least plausible ;-)
Ok, then how would you describe a lack of belief?
We have plenty labels like that. Example:
Baldness is not a hair style
Being single is not my wife
Being a virgin is not a style of having sex
Being a civilian is not a type of military service
Being fully functional is not a type of disability
etc, etc.