Or, just get IPv6 to work. It's a panaceum for all NAT-related problems -- it fixes them by just removing the damn thing and restoring IP to work the way it was designed.
I already have an IPv6 network - have done for years. But you don't actually expect a clueless MSN user who wants to send you a file to have IPv6 do you? Also, if you want to do SIP you have the problem that one of the more major VoIP projects, Asterisk, has no support for IPv6 at all.
Hell, every transitioned user is a step towards getting rid of IPv4, and that's a noble deed.
I agree, however, IPv6 has one major roadblock which will stop it's adoption in the near future: There are no consumer grade DSL routers in existence that do IPv6. This basically means it's impossible to do native IPv6 or 6-to-4 in most setups (the router is the only thing with a global scope IPv4 address)*.
(* You can of course get one of the Linksys routers, flash it with WhiteRussian and set that up to do IPv6 either natively or 6-to-4, but that's beyond most users. I'm quite disappointed that despite Cisco's stance on IPv6, none of their Linksys DSL routers seem to support it with the official firmware.)
That said, there is apparantly some interesting IPv6 stuff in Vista, so maybe that'll push things in the right direction.
Having supported a lot of moron users I can say that yes, email attachments are often a very Bad Thing. But mainly in the "when you have a hammer everything looks like a nail" sense. In some cases attachments are a good way of sending someone a file, but the clueless get too used to doing it that way and don't think of the consequences.
An example I saw a few years ago (which is a whole catalogue of cockups):
An estate agent did email-shots to prospective house buyers on a weekly basis. This mail shot consisted of an attached Word document containing descriptions and photos of properties. The photos were taken with something like a 2MP camera and they let Word "scale" them (read: the photos were imported in full resolution and then resized so they were still stored in the document at 2MP!). They would then mail-shot this (very large) document to around 500 email addresses. To make things worse, each week they took the last week's document and modified it, and Word in it's infinite wisdom keeps metadata about changes so the document got bigger each week.
By the time I got called in to fix their mail server (which had fallen over under the strain) I discovered several tens of gigabytes of mails queued for sending, many of them weeks old because it was now taking over a week to send the weekly mailings over their ADSL. And of course, almost all the mails were eventually getting bounced by the recipients' mail servers anyway because they were so big.
What they should've done is paid someone to set up a web site for them with a proper SQL backend to present the data they were mailing out. Clearly the users here were terminally clueless, but the point is that the software they were using made it far too easy to make each and every one of these mistakes.
So in summary, yes in some cases email attachments are useful, but I worry that they are frequently over-used because people get too comfortable using that feature for everything. Oh, and I don't believe most people have much legitimate need for sending executables over email so they should probably be automagically rejected.
when you download an executable from the Web, it gets an Internet zone identifier attached that says the file came from the Internet zone. Running the file shows a warning dialog with the application name and the publisher before it will let the file run. I don't know what else Windows can do here.
Some thoughts spring to mind:
1. Make it impossible to run the file directly from the browser - you force the user to (hopefully) think a little more if executable files have to be saved somewhere and then executed in a separate operation. 2. Make executables and datafiles look so obviously different that you can't miss it.
Admittedly this only goes part way to mitigating the problem, and the lines between executables and data files are getting worryingly blurred. Anyone else remember the days when people would worry that they had got a virus through an email and any techie who knew anything could tell them that no, that's impossible... how times have changed.
You are suggesting that not being able to transfer files via GAIM is a feature and not a bug?
It is neither.
A feature is something that was designed into a project for a particular end-user reason
A bug is functionality that is not working as intended
Clearly this is neither - the support wasn't left unimplemented specifically to help the end-user (it was probably more a case of "we don't have time and don't consider it important enough to bother with"), now is it a bug since the functionality was never intended to exist.
GAIM is obviously a load of complete rubbish because it doesn't support this functionality.
Many people don't actually want that functionality. For such people there is nothing "rubbish" about the functionality being lacking.
Downloading executable code off the web is one thing, but how many people actually need to send it over IM? Refusing to accept executable files that are being sent to you would probably be a good start (at least by default - you could stick an option to allow it in the preferences if you want so people with a legitimate need can turn it on).
you can't do anything with that except send instant messages - that's not what IM was invented for.
In other news, FTP (file transfer protocol) can't do anything but transfer files! *shock*
From what i read it will never support the direct connect. I don't get it and I'm no C programmer but I think its annoying.
Direct client-to-client connections is fraught with firewall/NAT traversal problems. That said, Jingle and SIP support both require client-to-client RTP connections (NAT discovery is done through STUN), so it's possible direct file transfer will be implemented then.
internal systems should ideally be going through proxies and a firewall to prevent random applications (such as viruses) from setting up their own connections.
The "security" provided by proxies is for the most part only perceived security - it's not exactly rocket science for malware to pull the proxy settings from other software such as your web browser and just connect that way.
they could probably even use layer 7 filtering and block unauthorized applications even if they did have all the correct passwords/tokens and port numbers.
To a firewall device, an HTTP POST on port 80 looks much the same as any other HTTP POST, even if it happens to be caused by some malware posting confidential data. (Even worse, if it uses HTTPS then all you get to know is that there's some SSL traffic on port 443 - you can't tell what is in that traffic). The only way you get to know this traffic isn't from the web browser is by running a personal firewall on the workstation itself so it can see which process owns the socket. Malware has a habit of disabling stuff like personal firewalls.
Normally, you'd have a private intranet that cannot access the outside world at all for sensitive data.
That very much depends what the job involves. It's getting increasingly difficult to work without web access in many jobs. For example, my ex-employer went nuts on security and blocked web access to all but a few "authorised" sites. If you needed access to a site that wasn't on the whitelist you had to request for it to be added. It basically just made it too hard to get to the sites that we legitimately needed to get to for our jobs. Our jobs wouldn't allow us to have a nice neat list of sites we needed to access regularly, we basically needed to be able to google for solutions to problems and follow the links to random sites. Not long after this "security" policy was implemented over 50% of us quit our jobs - this wasn't the only factor in us leaving but it certainly didn't help and it greatly reduced productivity.
There is no excuse for keeping data like that on a high-risk machine that may well be portscanned and attacked every few minutes anyway.
I think you're making bad assumptions here - A machine isn't going to be portscanned and attacked every few minutes if it's sat behind a firewall. The problem was caused by the user *downloading* a trojan and executing it, not by a remote machine attacking the network. There's very little a firewall can do to guard against trojans.
If it was encrypted to any reasonable standard, there wouldn't have been any fuss made.
It has to be plain text in the database's user-interface. Maybe the trojan was doing keylogging while the employee was doing data entry.
I would very much like to see a requirement that ALL sensitive and personal data that is even potentially exposed to the Internet be encrypted using strong algorithms and strong keys, and that unnecessary risks with other peoples personal data be strongly penalized.
The keys have to be stored somewhere (unless you expect an employee to enter a 2048 bit key from memory:) - once the workstation (complete with it's keys) has been compromised then it's game over. This is very much the "problem" that DRM faces - the data has to be decrypted before it's usable, which means you have to trust the end-user's system to give up neither the key nor the cleartext to any untrusted software or hardware.
If course, there is absolutely no excuse to not fix security holes in a timely fasion once they are discovered.
Eliminated the head and primary lieutenants of Al Qaeda in Iraq
Ok, explain what the hell gives the US the right to ignore the UN and invade a sovereign state and blow up a shit load of it's people (a lot of civilians were killed by the war as well you know)? If Iraq had decided to invade the US in order to remove the warmongering and corrupt government then I'm sure you'd complain that they had no right to do that (ignoring the fact, for the minute, that Iraq had no WMDs so wouldn't be in a position to win that war).
Improved health, human services, infrastructure, and education
That hasn't happened yet - Iraq is still an almighty mess - some may argue that it is less stable now than before the war.
The US's idea that democracy and capitalism are 100% good things is terribly flawed - the US should learn to stay the hell out of everyone else's business.
And I'm afraid I've lost count of how many different excuses have been used to justify the war.
France has recently tested a nuclear weapon, but has never used one against an enemy. Nor has Britain, Russia, China, India, or Pakistan.
Hang on, you're saying that the US is more trustworthy than the likes of France because the US is the only country to have used nukes in anger - on civilians no less. Talk about backwards logic...
Personally, I can't really think of any scenario where Iranians, Arabs in general, or the world as a whole would be better off if Iran had nukes. They might be better off if the U.S. butted out of the Middle East, but the two things aren't necessarily related.
Don't get me wrong - I don't think Iran should have nukes. My point was that neither should the US. If the US is so keen on other people not having nuclear weapons, it should be setting an example and getting rid of it's own.
IMHO no single nation should be trusted with weapons of mass destruction - control of WMDs should be with a group of nations, such as the UN - no one nation should be able to ignore the rest of the world and start firing off nuclear weapons at people. The Iraq war is a perfect example of this - the US ignored the UN and started a war on it's own - noone should be allowed to do the same with WMDs.
The difference between Iran wanting to build a new nuclear weapon and the US wanting to build a new nuclear weapon is vastly significant in my opinion. I think it's light years away from a, "do what we say, not what we do" situation. The US *currently* possess a nuclear weapons capability, and it has for over half a century, while Iran -- we hope -- doesn't yet have the means to produce a destructive nuclear device.
Why does that make it any more right for the US (the only country with a historical record of dropping nuclear weapons on civilians) to develop nuclear weapons? If the US wants other countries to avoid building nukes it should damned well be setting an example by *decomissioning* it's stockpile rather than building new weapons to go on it, whether or not those new weapons are better than the ones they are replacing.
The US has got to be about the most hypocritical nation on the planet at the moment, and Bush is probably a much bigger threat to world peace than Iran and Iraq put together. "Bombs are bad - if you build a bomb we'll bomb you because we're the only people who should be allowed to have bombs".
Only time can tell if the new Windows cluster system will be decent.
Decent or not, I think it will be as difficult for MS to break into the high performance market as it is for Linux to break into the desktop market. Lets look at desktops:
1. All the relevent people know how to use and administer Windows 2. Theres a big, well established library of software for Windows (yes, there are usually equivalents under Linux but they aren't well known established industry tools as far as most users are concerned).
Now look at high performance clusters: 1. Cluster admins know how to admin Unix-type OSes 2. Software writers will write for the systems that are currently available (Unix-type systems) 3. Computing facilities will install systems for the software that needs to be run (as mentioned above, this will be built to run on current systems)
Experience tells me that quality of the offering isn't as important as inertia. The current solution has to get pretty bad before people start changing to a new system en-masse.
Forcing competition would mean requiring the telcos to give new parties their phone wiring or appropriating the telcos networks and making them a public resource that all telcos must pay equally to access. That sort of government is called socialism and those sort of measures violate the free market that is found in the US.
I don't see the difference between regulating the pricing and regulating the service (which would be required if you want to force the telcos into providing uncontended bandwidth).
Contended connections are a bad thing that the consumer who forced to deal with.
The fact remains that the *vast majority* of customers don't need an uncontended connection and frankly wouldn't notice the difference. My 8Mbps connection lets me download at close to 8Mbps most of the time when I want to - this is because my ISP does bandwidth management to throttle the connections of those who use a disproportionate amount of the bandwidth. The only people who are significantly impacted by the contention are those who use a large amount of bandwidth for long periods of time.
And yes, if it was a choice between an uncontended connection or a reduction in my £20/month charge then I'd take the price reduction every time *because I don't need an uncontended connection*.
Almost one forth of the US population participates in filesharing, that is a substantial enough to warrant attention whether they are the 'majority' or not.
In that case there is a market for uncontended connections (which would presumably be charged at a higher price - that is how the free market works afterall). The fact that the bandwidth providers aren't already providing the service seems to show that they believe the profit doesn't outweigh the cost. You seem to be promoting the free market in one sentence and then condemning it in the next.
But also VOIP, games, and other real time traffic are all hurt by contended connections.
No, they aren't. If your ISP does queuing prioritisation of real time traffic (which is what I was originally promoting) then there is no impact.
If you really are in the UK then you would do well to take look at the US since the UK is moving more and more toward a US style of businesses daily.
The UK has the 1968 Trade Descriptions Act and the Advertising Standards Association. If an ISP were to fail to mention somewhere that the connection is contended then they would get slapped down pretty quickly. There is pretty-much no chance of this law being recinded.
When your web-based-datastore gets 50,000 inserts per second, hovers between 15 and 20 billion rows and endures a sustained query rate of 43,000 queries per hour, tell me which part of it you want to coded in PHP.
Whilest the query rate has a bearing on the design of the front-end system, the total number of rows in the database shouldn't since that should be handled by a high performance database backend and the frontend shouldn't know or care. You then have to weigh up which is more important: the language you're using vs. the amount of hardware. Web servers can often be clustered so you can just throw hardware at the problem if writing it in PHP is deemed necessary.
The problem is more important for workstation apps though, where you really don't have the option of throwing more hardware at the problem.
However, the idea of using java for applications (not applets) is crazy IMHO: You already know what architecture the app is going to run on when you package it (practically all java applications seem to have native installers), so you may as well just use a portable glue layer and compile for each architecture natively. The whole thing becomes even more crazy when you see FOSS applications in java, since there's no reason to avoid distributing the source which could be compiled natively anyway.
Actually since most foreign content is found on US servers as well, you get a speedy link to almost all of the web.
Complete rubbish - most non-US content is hosted outside the US.
To be frank, I couldn't care less if they charge $5 a kilobyte for bandwidth outside the US.
Unless you are only ever accessing US content you would care since that cost would be passed on to you.
Not if the ISP has properly throttled my link and given me exactly the amount of bandwidth they have sold me and done the same for you.
My ISP does give me exactly the amount of bandwidth they sold me - they sold me a 2Mbps (soon to be 8Mbps) contended DSL and I get 2Mbps *contended* bandwidth. If your ISP sold you your connection as an uncontended connection then you have cause to complain, otherwise you're getting exactly what you were sold.
Corporations charge you as much as you are willing to pay, period. What I do has nothing to do with what they charge you. They do NOT merely pass along expenses, that is just an excuse for what they charge you.
This is only true in a market with no effective competition. Here in the UK the ISP market has a lot of active competition and the profit margins are very tight. If this is not the case with the US market then *that* is the problem and can be solved by introducing more competition - that would result in reduced costs for the end user, which is good for the majority of customers. Your "solution" is to force the ISP to keep the same high prices but spend their excess profit on things only a minority of customers actually want.
the United States, the nation we are talking about.
Like it or not, net neutrality affects the whole world - not just your small corner of it.
I am claiming that you and I should EACH get a bottle since you and I EACH paid for an entire bottle and that the culprit is the store that sold ten bottles when they only had two bottles in stock.
No, you didn't pay for a whole bottle - you paid for a *contended* bottle since that's how it was advertised. If you didn't want to contend for the bottle you should've gone somewhere selling uncontended ones. If it *wasn't* advertised as contended then you have cause for complaint, but I suspect that wasn't the case (if it really wasn't sold as contended, sue them for fraudulent marketting).
I don't need to prioritize anybody elses traffic, only my own.
You clearly don't understand what it means when the ISP sells you a "contended internet connection" - that means that you don't have exclusive access to the bandwidth. If the ISP doesn't do QoS then that means my BitTorrent traffic can wipe out your VoIP connection.
Because it is not just *I* who can use my connection in an uncontended way. It is you, me, and everyone else.
But I don't want an uncontended connection - I'm quite happy with a contended connection that has ISP-side QoS. I shift about 18GB per month over my 2Mbps DSL. If it was uncontended and you're running bittorrent 24/7 it would probably saturate it most of the time - that's about 610GB down + 76GB up == 686GB total. So why the hell would I want to subsidise your 686GB per month when the costs associated with your bandwidth vastly outweigh the costs associated with mine? If you want an uncontended connection, go buy one (it'll cost you a lot more than a contended connection) but don't force it on the rest of us who frankly just don't want to shift that much data.
Management through regulation instead of leaving power in the hands of the individual opposes one of the cores ideals of society.
I don't care what your ideals are - mine certainly don't involve me being forced to subsidise other people's downloading habits. Look at it this way: should everyone be required to buy a certain amount of alcohol each day even if they don't want it, just so the alcoholics don't have to pay more than anyone else? What you're suggesting is no different.
It should be much simpler than that. If I am paying for a 1.5Mb/s, I should receive 1.5Mb/s, regardless of what protocols I use, encrypted or not. Latency is a little tricker, but in the end there's a limit to latency for a packet if you have to stay within X Mb/s. Saying that I have X Mb/s but only if I use them for unecrypted browsing and uncencrypted e-mail is just absurd.
The point of QoS queuing isn't to restrict the bandwidth on low priority traffic, it is simply to stop it impacting high priority traffic. So the ISP shouldn't be saying "you only get 1Mbps on bittorrent traffic but you can do 2Mbps on HTTP" - the amount of bandwidth you get should be purely dependent on network load, not some arbitrary limit.
The only ways to keep the network usable for all people is either to do QoS priority queuing or to give everyone an uncontended connection. The latter is cost-prohibitive and the former happens to work. The people who put the most load on the networks are the bittorrent users so it seem fair that they should have their usage made a lower priority or be required to pay the costs associated with shifting that quantity of data around - charging *all* customers more just so the bittorrent users can get higher performance seems unfair to me.
(Note: I use bittorrent myself. But I don't leave it sitting there sucking up my bandwidth all day downloading gigs and gigs).
if I want to use encryption, then I am using the Internet for "business" needs (which is somewhat true)
Completely untrue - am I considered a "business user" because I want to access my personal bank account online? or because I want to order a CD from Amazon? Or because I don't want some random person to see my root password when I'm logging into my machine?
IMHO most traffic *should* use encryption. I'm a big fan of the idea of ad-hoc ESP in preference to protocols with built in encryption - you publish shared keys in DNS and have the hosts automagically establish the ESP association when any traffic passes between them. This does cause the aforementioned problems with fingerprinting the protocols for QoS purposes though and it's very hard to reconcile the two.
That is NOT improvement. If I want QoS then it is for ME to implement that over the pipe I have purchased. I purchased a pipe of x speed up and x speed down and I have every right to saturate that pipe entirely both ways with whatever traffic I desire.
I don't even know where to begin... 1. How the hell are you going to implement QoS when you don't have access to the ISP's routers? 2. I think you'll find the connection you bought was advertised as *contended* that means that the bandwidth is shared with other users. So you do not have any right to saturate your connection at the exclusion of the other users who are sharing the bandwidth. *analogy alert*: this is no different to you driving down the road - you are sharing it with other users and do not have the right to use it at the exclusion of those users.
QoS is like firewalling and port blocking, something that should be left in the hands of the end user to use as they see fit.
I'm in two minds about this - I think that all users should have the *option* of having an unfirewalled connection, but the fact remains that most users are just too clueless to run their own firewalls. I also thing that ISPs should do active monitoring for compromised machines and automatically block the whole net connection for those that are attacking other systems.
Before anyone chimes in with the cost of bandwidth issues. I know bandwidth is expensive for smaller ISPs. But it isn't expensive for the telcos, in fact they pull numbers out of a hat.
Telcos can provide relatively cheap bandwidth within *some sections* of their *own networks*. Long distance backhauls often can't provide masses of cheap bandwidth, and as soon as you start connecting between service providers then that does get expensive.
A significant point is - why should *I* pay extra for my internet connection so that *you* can use yours in an uncontended way? If you want an uncontended connection to a tier-1 provider then feel free to get one - it'll cost you a few tens of thousands of pounds a month.
And this will have no negative impact on other users because my pipe will be dedicated to me.
You're measuring a 1:1 contention ratio from where to where? Saying "my internet connection is uncontended" is meaningless unless you specify the end point you're measuring the contention to - the internet is a network with millions of nodes. Routes to some of these nodes may well be undersubscribed, others will be oversubscribed. If you think you'll ever get access to *every* node on the network over a connection that isn't oversubscribed then you're living in cloud cookoo land - this doesn't even happen on moderately sized LANs, let alone a WAN.
Fundamentally, then, it's not my fault if _your_ connection (RTP) degrades because I'm using _my_ connection (BitTorrent), it's _our_ ISPs.
Pretty much - the ISP should be responsible for shaping the traffic so your bittorrent traffic doesn't kill my RTP traffic. However, lot of bittorrent users whinge and whinge that the ISP is shaping their traffic and doesn't allow them to max out their £15/month conntection 24/7 - they just don't understand the economics of running an ISP.
Hell, I'd pay $70 a month for DSL if it meant they didn't have to oversell bandwidth, but all that would happen is some Executive would get a new car.
I think if you want a non-contended connection right up to the tier-1 networks you'll be paying a whole hell of a lot more than $70. I'm sorry, but uncontended connections are just not economic for most people - this isn't the ISPs being evil and intentionally making sure there's less bandwidth available, it's simply that almost noone can afford to pay for (nor needs) uncontended access so why should the ISPs even bother trying to offer the service?
But, and here's the question I've been struggling with over the last few days, what happens when the connection is encrypted? HTTPS or SSH or SSL or TLS? What can you route on? Source and dest IP only, I would think. Maybe that will be the lowest on the pole - "if your connection is encrypted, it gets the lowest service, since we can't tell what is going over that connection."
This is indeed one of the problems of protocol fingerprinting - about the only thing you can tell is that it's an SSL session, or a TLS session, etc. Although you can make a guess that an SSL session on port 443/tcp is probably HTTPS that doesn't stop someone doing some other SSL based protocol on that port.
SSH is a little easier - if it's an interactive session then the packet sizes will be reasonably small. If the packet sizes are large then it's probably SCP or some other high-bandwidth protocol and should probably be considered a bulk transfer anyway.
Things get worse with protocols like ESP - you get no access to things like port numbers and very limited access to protocol attributes.
Encryption and obfuscation is a big problem - some people think that it's a good idea to work around their ISP's traffic shaping by encrypting or obfuscating traffic. These people do not understand the economies of running a shared network and make things bad for everyone (themselves included). It's not possible to provide uncontended connectivity to each end user at a sensible price. As soon as you start contending for the bandwidth you have to do some prioritisation to prevent high bandiwdth protocols ruining the quality of service for everyone else. People who work around the ISP's traffic shaping end up causing the ISP to either buy more upstream bandwidth (which they have to pass on as a cost to their customers) or invest in more rigorous fingerprinting systems, whcih again result in higher charges.
Maybe that's the next step in the bill - "in order to enforce this bill, we must require that all communications be unencrypted." Kind of a scary thought, no?
I think that's very unlikely - it would mean the death of internet banking, shopping, etc. There's no way the banks would accept liability for confidential data being sent unencrypted.
Do you think that backbone routers will make that distinction?
That's not what I meant - I meant when talking about QoS traffic shaping it's important to make a distinction between the types - protocol classification is good, toll classification is bad - just telling everyone that QoS is a bad thing and should be banned is a terrible idea because ISPs who are *improving* the service by using protocol classification will be unfairly labelled as evil.
I think it's important to differentiate between protocol based prioritisation and toll based prioritisation.
The ISP I use does traffic prioritisation based on protocol. This is a Good Thing and should be encouraged - it means that RTP traffic, for example, gets higher priority than BitTorrent. This is great since RTP gets pretty unusable more than a few hundred milliseconds of latency jitter, but BitTorrent won't care. (Yes, I'm aware that many people complain that they want to be able to shift enough BitTorrent traffic over their 15ukp DSL connection to destroy the usability of everyone else's connections).
On the other hand, I'm paying for the internet connection so prioritising traffic based on whether the remote party are paying protection money to my ISP is a very Bad Thing - I already paid for the connection, the remote party already paid for theirs, why the hell should my ISP be demanding more cash from them and penalising me if they don't pay?
Of course, protocol based QoS is fraught with problems because you can't trust the end user to set the ToS flags correctly so you have to identify the protocol by fingerprinting instead. It's not an easy problem to solve, but it's very worthwhile.
99.999% availability for ANY of the above services would be a disaster
This all depends when the downtime occurs. Are you measuring total downtime or unplanned downtime?
Your toilet?
Do you actually need to use the toilet 24/7/365? If it's down for 5 minutes can't you just hold it? And if you think about it, there is essentially "planned downtime" on your toilet while you're waiting for it to refill the tank after flushing it.... big list of other things that wouldn't be a major problem with having a few minutes a day downtime...
Your internet connection?
I think you will struggle to find a residential ISP that guarantees your internet connection won't be down for 20 hours...
I generally don't bother to update the kernel unless there is a significant security hole. Most kernel security problems are local user exploits. Whilest theoretically they might be exploitable remotely when coupled with another security hole in a service, the chances seem pretty unlikely. And as for general kernel bug fixes (not security related), if it ain't broke don't fix it.
One example: our (commercial, expensive) database is stopped everyday at 3am and stays one full hour down for backup
Sounds crazy to me. A transaction based database, such as a properly written Postgres system, can safely be backed up while live, since the transactions prevent data becoming inconsistent during the backup.
Compatibility and ease of integrating into existing systems I'd assume.
Compatability really doesn't count since it requires specific support in Vista, so they could've implemented it to use a completely separate flash device rather than one that's built into a drive.
I'm taking the "ease of integration" thing with a large pinch of salt too - if this is primarily for notebooks then you can more or less discount upgrades (how many people really upgrade the drive in their notebook?). So this will be installed by the notebook manufacturer - i.e. there's no real reason for putting it in the drive rather than on the motherboard. And it seems like it might be more sensible to hang the flash chips off the north bridge directly rather than on an ATA bus since it would probably improve read speeds.
Slashdot Mirror
Or, just get IPv6 to work. It's a panaceum for all NAT-related problems -- it fixes them by just removing the damn thing and restoring IP to work the way it was designed.
I already have an IPv6 network - have done for years. But you don't actually expect a clueless MSN user who wants to send you a file to have IPv6 do you? Also, if you want to do SIP you have the problem that one of the more major VoIP projects, Asterisk, has no support for IPv6 at all.
Hell, every transitioned user is a step towards getting rid of IPv4, and that's a noble deed.
I agree, however, IPv6 has one major roadblock which will stop it's adoption in the near future: There are no consumer grade DSL routers in existence that do IPv6. This basically means it's impossible to do native IPv6 or 6-to-4 in most setups (the router is the only thing with a global scope IPv4 address)*.
(* You can of course get one of the Linksys routers, flash it with WhiteRussian and set that up to do IPv6 either natively or 6-to-4, but that's beyond most users. I'm quite disappointed that despite Cisco's stance on IPv6, none of their Linksys DSL routers seem to support it with the official firmware.)
That said, there is apparantly some interesting IPv6 stuff in Vista, so maybe that'll push things in the right direction.
if the bot replied "it's a virus lol j/k, just click on it", i'm sure some people would STILL download it.
The cover would be blown with the "lol" and "j/k" anyway since I have no 12 year olds on my buddy list... (not that I use MSN anyway)
Do you also rail against email attachments?
Having supported a lot of moron users I can say that yes, email attachments are often a very Bad Thing. But mainly in the "when you have a hammer everything looks like a nail" sense. In some cases attachments are a good way of sending someone a file, but the clueless get too used to doing it that way and don't think of the consequences.
An example I saw a few years ago (which is a whole catalogue of cockups):
An estate agent did email-shots to prospective house buyers on a weekly basis. This mail shot consisted of an attached Word document containing descriptions and photos of properties. The photos were taken with something like a 2MP camera and they let Word "scale" them (read: the photos were imported in full resolution and then resized so they were still stored in the document at 2MP!). They would then mail-shot this (very large) document to around 500 email addresses. To make things worse, each week they took the last week's document and modified it, and Word in it's infinite wisdom keeps metadata about changes so the document got bigger each week.
By the time I got called in to fix their mail server (which had fallen over under the strain) I discovered several tens of gigabytes of mails queued for sending, many of them weeks old because it was now taking over a week to send the weekly mailings over their ADSL. And of course, almost all the mails were eventually getting bounced by the recipients' mail servers anyway because they were so big.
What they should've done is paid someone to set up a web site for them with a proper SQL backend to present the data they were mailing out. Clearly the users here were terminally clueless, but the point is that the software they were using made it far too easy to make each and every one of these mistakes.
So in summary, yes in some cases email attachments are useful, but I worry that they are frequently over-used because people get too comfortable using that feature for everything. Oh, and I don't believe most people have much legitimate need for sending executables over email so they should probably be automagically rejected.
when you download an executable from the Web, it gets an Internet zone identifier attached that says the file came from the Internet zone. Running the file shows a warning dialog with the application name and the publisher before it will let the file run. I don't know what else Windows can do here.
Some thoughts spring to mind:
1. Make it impossible to run the file directly from the browser - you force the user to (hopefully) think a little more if executable files have to be saved somewhere and then executed in a separate operation.
2. Make executables and datafiles look so obviously different that you can't miss it.
Admittedly this only goes part way to mitigating the problem, and the lines between executables and data files are getting worryingly blurred. Anyone else remember the days when people would worry that they had got a virus through an email and any techie who knew anything could tell them that no, that's impossible... how times have changed.
It is neither.
Clearly this is neither - the support wasn't left unimplemented specifically to help the end-user (it was probably more a case of "we don't have time and don't consider it important enough to bother with"), now is it a bug since the functionality was never intended to exist.
It is simply unimplemented functionality.
GAIM is obviously a load of complete rubbish because it doesn't support this functionality.
Many people don't actually want that functionality. For such people there is nothing "rubbish" about the functionality being lacking.
Downloading executable code off the web is one thing, but how many people actually need to send it over IM? Refusing to accept executable files that are being sent to you would probably be a good start (at least by default - you could stick an option to allow it in the preferences if you want so people with a legitimate need can turn it on).
you can't do anything with that except send instant messages - that's not what IM was invented for.
In other news, FTP (file transfer protocol) can't do anything but transfer files! *shock*
From what i read it will never support the direct connect. I don't get it and I'm no C programmer but I think its annoying.
Direct client-to-client connections is fraught with firewall/NAT traversal problems. That said, Jingle and SIP support both require client-to-client RTP connections (NAT discovery is done through STUN), so it's possible direct file transfer will be implemented then.
internal systems should ideally be going through proxies and a firewall to prevent random applications (such as viruses) from setting up their own connections.
:) - once the workstation (complete with it's keys) has been compromised then it's game over. This is very much the "problem" that DRM faces - the data has to be decrypted before it's usable, which means you have to trust the end-user's system to give up neither the key nor the cleartext to any untrusted software or hardware.
The "security" provided by proxies is for the most part only perceived security - it's not exactly rocket science for malware to pull the proxy settings from other software such as your web browser and just connect that way.
they could probably even use layer 7 filtering and block unauthorized applications even if they did have all the correct passwords/tokens and port numbers.
To a firewall device, an HTTP POST on port 80 looks much the same as any other HTTP POST, even if it happens to be caused by some malware posting confidential data. (Even worse, if it uses HTTPS then all you get to know is that there's some SSL traffic on port 443 - you can't tell what is in that traffic). The only way you get to know this traffic isn't from the web browser is by running a personal firewall on the workstation itself so it can see which process owns the socket. Malware has a habit of disabling stuff like personal firewalls.
Normally, you'd have a private intranet that cannot access the outside world at all for sensitive data.
That very much depends what the job involves. It's getting increasingly difficult to work without web access in many jobs. For example, my ex-employer went nuts on security and blocked web access to all but a few "authorised" sites. If you needed access to a site that wasn't on the whitelist you had to request for it to be added. It basically just made it too hard to get to the sites that we legitimately needed to get to for our jobs. Our jobs wouldn't allow us to have a nice neat list of sites we needed to access regularly, we basically needed to be able to google for solutions to problems and follow the links to random sites. Not long after this "security" policy was implemented over 50% of us quit our jobs - this wasn't the only factor in us leaving but it certainly didn't help and it greatly reduced productivity.
There is no excuse for keeping data like that on a high-risk machine that may well be portscanned and attacked every few minutes anyway.
I think you're making bad assumptions here - A machine isn't going to be portscanned and attacked every few minutes if it's sat behind a firewall. The problem was caused by the user *downloading* a trojan and executing it, not by a remote machine attacking the network. There's very little a firewall can do to guard against trojans.
If it was encrypted to any reasonable standard, there wouldn't have been any fuss made.
It has to be plain text in the database's user-interface. Maybe the trojan was doing keylogging while the employee was doing data entry.
I would very much like to see a requirement that ALL sensitive and personal data that is even potentially exposed to the Internet be encrypted using strong algorithms and strong keys, and that unnecessary risks with other peoples personal data be strongly penalized.
The keys have to be stored somewhere (unless you expect an employee to enter a 2048 bit key from memory
If course, there is absolutely no excuse to not fix security holes in a timely fasion once they are discovered.
Deposed a brutal dictator
Eliminated his murderous offspring
Eliminated the head and primary lieutenants of Al Qaeda in Iraq
Ok, explain what the hell gives the US the right to ignore the UN and invade a sovereign state and blow up a shit load of it's people (a lot of civilians were killed by the war as well you know)? If Iraq had decided to invade the US in order to remove the warmongering and corrupt government then I'm sure you'd complain that they had no right to do that (ignoring the fact, for the minute, that Iraq had no WMDs so wouldn't be in a position to win that war).
Improved health, human services, infrastructure, and education
That hasn't happened yet - Iraq is still an almighty mess - some may argue that it is less stable now than before the war.
The US's idea that democracy and capitalism are 100% good things is terribly flawed - the US should learn to stay the hell out of everyone else's business.
And I'm afraid I've lost count of how many different excuses have been used to justify the war.
France has recently tested a nuclear weapon, but has never used one against an enemy. Nor has Britain, Russia, China, India, or Pakistan.
Hang on, you're saying that the US is more trustworthy than the likes of France because the US is the only country to have used nukes in anger - on civilians no less. Talk about backwards logic...
Personally, I can't really think of any scenario where Iranians, Arabs in general, or the world as a whole would be better off if Iran had nukes. They might be better off if the U.S. butted out of the Middle East, but the two things aren't necessarily related.
Don't get me wrong - I don't think Iran should have nukes. My point was that neither should the US. If the US is so keen on other people not having nuclear weapons, it should be setting an example and getting rid of it's own.
IMHO no single nation should be trusted with weapons of mass destruction - control of WMDs should be with a group of nations, such as the UN - no one nation should be able to ignore the rest of the world and start firing off nuclear weapons at people. The Iraq war is a perfect example of this - the US ignored the UN and started a war on it's own - noone should be allowed to do the same with WMDs.
The difference between Iran wanting to build a new nuclear weapon and the US wanting to build a new nuclear weapon is vastly significant in my opinion. I think it's light years away from a, "do what we say, not what we do" situation. The US *currently* possess a nuclear weapons capability, and it has for over half a century, while Iran -- we hope -- doesn't yet have the means to produce a destructive nuclear device.
Why does that make it any more right for the US (the only country with a historical record of dropping nuclear weapons on civilians) to develop nuclear weapons? If the US wants other countries to avoid building nukes it should damned well be setting an example by *decomissioning* it's stockpile rather than building new weapons to go on it, whether or not those new weapons are better than the ones they are replacing.
The US has got to be about the most hypocritical nation on the planet at the moment, and Bush is probably a much bigger threat to world peace than Iran and Iraq put together. "Bombs are bad - if you build a bomb we'll bomb you because we're the only people who should be allowed to have bombs".
Only time can tell if the new Windows cluster system will be decent.
Decent or not, I think it will be as difficult for MS to break into the high performance market as it is for Linux to break into the desktop market. Lets look at desktops:
1. All the relevent people know how to use and administer Windows
2. Theres a big, well established library of software for Windows (yes, there are usually equivalents under Linux but they aren't well known established industry tools as far as most users are concerned).
Now look at high performance clusters:
1. Cluster admins know how to admin Unix-type OSes
2. Software writers will write for the systems that are currently available (Unix-type systems)
3. Computing facilities will install systems for the software that needs to be run (as mentioned above, this will be built to run on current systems)
Experience tells me that quality of the offering isn't as important as inertia. The current solution has to get pretty bad before people start changing to a new system en-masse.
Forcing competition would mean requiring the telcos to give new parties their phone wiring or appropriating the telcos networks and making them a public resource that all telcos must pay equally to access. That sort of government is called socialism and those sort of measures violate the free market that is found in the US.
I don't see the difference between regulating the pricing and regulating the service (which would be required if you want to force the telcos into providing uncontended bandwidth).
Contended connections are a bad thing that the consumer who forced to deal with.
The fact remains that the *vast majority* of customers don't need an uncontended connection and frankly wouldn't notice the difference. My 8Mbps connection lets me download at close to 8Mbps most of the time when I want to - this is because my ISP does bandwidth management to throttle the connections of those who use a disproportionate amount of the bandwidth. The only people who are significantly impacted by the contention are those who use a large amount of bandwidth for long periods of time.
And yes, if it was a choice between an uncontended connection or a reduction in my £20/month charge then I'd take the price reduction every time *because I don't need an uncontended connection*.
Almost one forth of the US population participates in filesharing, that is a substantial enough to warrant attention whether they are the 'majority' or not.
In that case there is a market for uncontended connections (which would presumably be charged at a higher price - that is how the free market works afterall). The fact that the bandwidth providers aren't already providing the service seems to show that they believe the profit doesn't outweigh the cost. You seem to be promoting the free market in one sentence and then condemning it in the next.
But also VOIP, games, and other real time traffic are all hurt by contended connections.
No, they aren't. If your ISP does queuing prioritisation of real time traffic (which is what I was originally promoting) then there is no impact.
If you really are in the UK then you would do well to take look at the US since the UK is moving more and more toward a US style of businesses daily.
The UK has the 1968 Trade Descriptions Act and the Advertising Standards Association. If an ISP were to fail to mention somewhere that the connection is contended then they would get slapped down pretty quickly. There is pretty-much no chance of this law being recinded.
When your web-based-datastore gets 50,000 inserts per second, hovers between 15 and 20 billion rows and endures a sustained query rate of 43,000 queries per hour, tell me which part of it you want to coded in PHP.
Whilest the query rate has a bearing on the design of the front-end system, the total number of rows in the database shouldn't since that should be handled by a high performance database backend and the frontend shouldn't know or care. You then have to weigh up which is more important: the language you're using vs. the amount of hardware. Web servers can often be clustered so you can just throw hardware at the problem if writing it in PHP is deemed necessary.
The problem is more important for workstation apps though, where you really don't have the option of throwing more hardware at the problem.
However, the idea of using java for applications (not applets) is crazy IMHO: You already know what architecture the app is going to run on when you package it (practically all java applications seem to have native installers), so you may as well just use a portable glue layer and compile for each architecture natively. The whole thing becomes even more crazy when you see FOSS applications in java, since there's no reason to avoid distributing the source which could be compiled natively anyway.
Actually since most foreign content is found on US servers as well, you get a speedy link to almost all of the web.
Complete rubbish - most non-US content is hosted outside the US.
To be frank, I couldn't care less if they charge $5 a kilobyte for bandwidth outside the US.
Unless you are only ever accessing US content you would care since that cost would be passed on to you.
Not if the ISP has properly throttled my link and given me exactly the amount of bandwidth they have sold me and done the same for you.
My ISP does give me exactly the amount of bandwidth they sold me - they sold me a 2Mbps (soon to be 8Mbps) contended DSL and I get 2Mbps *contended* bandwidth. If your ISP sold you your connection as an uncontended connection then you have cause to complain, otherwise you're getting exactly what you were sold.
Corporations charge you as much as you are willing to pay, period. What I do has nothing to do with what they charge you. They do NOT merely pass along expenses, that is just an excuse for what they charge you.
This is only true in a market with no effective competition. Here in the UK the ISP market has a lot of active competition and the profit margins are very tight. If this is not the case with the US market then *that* is the problem and can be solved by introducing more competition - that would result in reduced costs for the end user, which is good for the majority of customers. Your "solution" is to force the ISP to keep the same high prices but spend their excess profit on things only a minority of customers actually want.
the United States, the nation we are talking about.
Like it or not, net neutrality affects the whole world - not just your small corner of it.
I am claiming that you and I should EACH get a bottle since you and I EACH paid for an entire bottle and that the culprit is the store that sold ten bottles when they only had two bottles in stock.
No, you didn't pay for a whole bottle - you paid for a *contended* bottle since that's how it was advertised. If you didn't want to contend for the bottle you should've gone somewhere selling uncontended ones. If it *wasn't* advertised as contended then you have cause for complaint, but I suspect that wasn't the case (if it really wasn't sold as contended, sue them for fraudulent marketting).
I don't need to prioritize anybody elses traffic, only my own.
You clearly don't understand what it means when the ISP sells you a "contended internet connection" - that means that you don't have exclusive access to the bandwidth. If the ISP doesn't do QoS then that means my BitTorrent traffic can wipe out your VoIP connection.
Because it is not just *I* who can use my connection in an uncontended way. It is you, me, and everyone else.
But I don't want an uncontended connection - I'm quite happy with a contended connection that has ISP-side QoS. I shift about 18GB per month over my 2Mbps DSL. If it was uncontended and you're running bittorrent 24/7 it would probably saturate it most of the time - that's about 610GB down + 76GB up == 686GB total. So why the hell would I want to subsidise your 686GB per month when the costs associated with your bandwidth vastly outweigh the costs associated with mine? If you want an uncontended connection, go buy one (it'll cost you a lot more than a contended connection) but don't force it on the rest of us who frankly just don't want to shift that much data.
Management through regulation instead of leaving power in the hands of the individual opposes one of the cores ideals of society.
I don't care what your ideals are - mine certainly don't involve me being forced to subsidise other people's downloading habits.
Look at it this way: should everyone be required to buy a certain amount of alcohol each day even if they don't want it, just so the alcoholics don't have to pay more than anyone else? What you're suggesting is no different.
It should be much simpler than that. If I am paying for a 1.5Mb/s, I should receive 1.5Mb/s, regardless of what protocols I use, encrypted or not. Latency is a little tricker, but in the end there's a limit to latency for a packet if you have to stay within X Mb/s. Saying that I have X Mb/s but only if I use them for unecrypted browsing and uncencrypted e-mail is just absurd.
The point of QoS queuing isn't to restrict the bandwidth on low priority traffic, it is simply to stop it impacting high priority traffic. So the ISP shouldn't be saying "you only get 1Mbps on bittorrent traffic but you can do 2Mbps on HTTP" - the amount of bandwidth you get should be purely dependent on network load, not some arbitrary limit.
The only ways to keep the network usable for all people is either to do QoS priority queuing or to give everyone an uncontended connection. The latter is cost-prohibitive and the former happens to work. The people who put the most load on the networks are the bittorrent users so it seem fair that they should have their usage made a lower priority or be required to pay the costs associated with shifting that quantity of data around - charging *all* customers more just so the bittorrent users can get higher performance seems unfair to me.
(Note: I use bittorrent myself. But I don't leave it sitting there sucking up my bandwidth all day downloading gigs and gigs).
if I want to use encryption, then I am using the Internet for "business" needs (which is somewhat true)
Completely untrue - am I considered a "business user" because I want to access my personal bank account online? or because I want to order a CD from Amazon? Or because I don't want some random person to see my root password when I'm logging into my machine?
IMHO most traffic *should* use encryption. I'm a big fan of the idea of ad-hoc ESP in preference to protocols with built in encryption - you publish shared keys in DNS and have the hosts automagically establish the ESP association when any traffic passes between them. This does cause the aforementioned problems with fingerprinting the protocols for QoS purposes though and it's very hard to reconcile the two.
That is NOT improvement. If I want QoS then it is for ME to implement that over the pipe I have purchased. I purchased a pipe of x speed up and x speed down and I have every right to saturate that pipe entirely both ways with whatever traffic I desire.
I don't even know where to begin...
1. How the hell are you going to implement QoS when you don't have access to the ISP's routers?
2. I think you'll find the connection you bought was advertised as *contended* that means that the bandwidth is shared with other users. So you do not have any right to saturate your connection at the exclusion of the other users who are sharing the bandwidth. *analogy alert*: this is no different to you driving down the road - you are sharing it with other users and do not have the right to use it at the exclusion of those users.
QoS is like firewalling and port blocking, something that should be left in the hands of the end user to use as they see fit.
I'm in two minds about this - I think that all users should have the *option* of having an unfirewalled connection, but the fact remains that most users are just too clueless to run their own firewalls. I also thing that ISPs should do active monitoring for compromised machines and automatically block the whole net connection for those that are attacking other systems.
Before anyone chimes in with the cost of bandwidth issues. I know bandwidth is expensive for smaller ISPs. But it isn't expensive for the telcos, in fact they pull numbers out of a hat.
Telcos can provide relatively cheap bandwidth within *some sections* of their *own networks*. Long distance backhauls often can't provide masses of cheap bandwidth, and as soon as you start connecting between service providers then that does get expensive.
A significant point is - why should *I* pay extra for my internet connection so that *you* can use yours in an uncontended way? If you want an uncontended connection to a tier-1 provider then feel free to get one - it'll cost you a few tens of thousands of pounds a month.
And this will have no negative impact on other users because my pipe will be dedicated to me.
You're measuring a 1:1 contention ratio from where to where? Saying "my internet connection is uncontended" is meaningless unless you specify the end point you're measuring the contention to - the internet is a network with millions of nodes. Routes to some of these nodes may well be undersubscribed, others will be oversubscribed. If you think you'll ever get access to *every* node on the network over a connection that isn't oversubscribed then you're living in cloud cookoo land - this doesn't even happen on moderately sized LANs, let alone a WAN.
Fundamentally, then, it's not my fault if _your_ connection (RTP) degrades because I'm using _my_ connection (BitTorrent), it's _our_ ISPs.
Pretty much - the ISP should be responsible for shaping the traffic so your bittorrent traffic doesn't kill my RTP traffic. However, lot of bittorrent users whinge and whinge that the ISP is shaping their traffic and doesn't allow them to max out their £15/month conntection 24/7 - they just don't understand the economics of running an ISP.
Hell, I'd pay $70 a month for DSL if it meant they didn't have to oversell bandwidth, but all that would happen is some Executive would get a new car.
I think if you want a non-contended connection right up to the tier-1 networks you'll be paying a whole hell of a lot more than $70. I'm sorry, but uncontended connections are just not economic for most people - this isn't the ISPs being evil and intentionally making sure there's less bandwidth available, it's simply that almost noone can afford to pay for (nor needs) uncontended access so why should the ISPs even bother trying to offer the service?
But, and here's the question I've been struggling with over the last few days, what happens when the connection is encrypted? HTTPS or SSH or SSL or TLS? What can you route on? Source and dest IP only, I would think. Maybe that will be the lowest on the pole - "if your connection is encrypted, it gets the lowest service, since we can't tell what is going over that connection."
This is indeed one of the problems of protocol fingerprinting - about the only thing you can tell is that it's an SSL session, or a TLS session, etc. Although you can make a guess that an SSL session on port 443/tcp is probably HTTPS that doesn't stop someone doing some other SSL based protocol on that port.
SSH is a little easier - if it's an interactive session then the packet sizes will be reasonably small. If the packet sizes are large then it's probably SCP or some other high-bandwidth protocol and should probably be considered a bulk transfer anyway.
Things get worse with protocols like ESP - you get no access to things like port numbers and very limited access to protocol attributes.
Encryption and obfuscation is a big problem - some people think that it's a good idea to work around their ISP's traffic shaping by encrypting or obfuscating traffic. These people do not understand the economies of running a shared network and make things bad for everyone (themselves included). It's not possible to provide uncontended connectivity to each end user at a sensible price. As soon as you start contending for the bandwidth you have to do some prioritisation to prevent high bandiwdth protocols ruining the quality of service for everyone else. People who work around the ISP's traffic shaping end up causing the ISP to either buy more upstream bandwidth (which they have to pass on as a cost to their customers) or invest in more rigorous fingerprinting systems, whcih again result in higher charges.
Maybe that's the next step in the bill - "in order to enforce this bill, we must require that all communications be unencrypted." Kind of a scary thought, no?
I think that's very unlikely - it would mean the death of internet banking, shopping, etc. There's no way the banks would accept liability for confidential data being sent unencrypted.
Do you think that backbone routers will make that distinction?
That's not what I meant - I meant when talking about QoS traffic shaping it's important to make a distinction between the types - protocol classification is good, toll classification is bad - just telling everyone that QoS is a bad thing and should be banned is a terrible idea because ISPs who are *improving* the service by using protocol classification will be unfairly labelled as evil.
At that point it will be subject to QOS.
I think it's important to differentiate between protocol based prioritisation and toll based prioritisation.
The ISP I use does traffic prioritisation based on protocol. This is a Good Thing and should be encouraged - it means that RTP traffic, for example, gets higher priority than BitTorrent. This is great since RTP gets pretty unusable more than a few hundred milliseconds of latency jitter, but BitTorrent won't care. (Yes, I'm aware that many people complain that they want to be able to shift enough BitTorrent traffic over their 15ukp DSL connection to destroy the usability of everyone else's connections).
On the other hand, I'm paying for the internet connection so prioritising traffic based on whether the remote party are paying protection money to my ISP is a very Bad Thing - I already paid for the connection, the remote party already paid for theirs, why the hell should my ISP be demanding more cash from them and penalising me if they don't pay?
Of course, protocol based QoS is fraught with problems because you can't trust the end user to set the ToS flags correctly so you have to identify the protocol by fingerprinting instead. It's not an easy problem to solve, but it's very worthwhile.
99.999% availability for ANY of the above services would be a disaster
... big list of other things that wouldn't be a major problem with having a few minutes a day downtime ...
This all depends when the downtime occurs. Are you measuring total downtime or unplanned downtime?
Your toilet?
Do you actually need to use the toilet 24/7/365? If it's down for 5 minutes can't you just hold it? And if you think about it, there is essentially "planned downtime" on your toilet while you're waiting for it to refill the tank after flushing it.
Your internet connection?
I think you will struggle to find a residential ISP that guarantees your internet connection won't be down for 20 hours...
Or don't you update your kernel?
I generally don't bother to update the kernel unless there is a significant security hole. Most kernel security problems are local user exploits. Whilest theoretically they might be exploitable remotely when coupled with another security hole in a service, the chances seem pretty unlikely. And as for general kernel bug fixes (not security related), if it ain't broke don't fix it.
One example: our (commercial, expensive) database is stopped everyday at 3am and stays one full hour down for backup
Sounds crazy to me. A transaction based database, such as a properly written Postgres system, can safely be backed up while live, since the transactions prevent data becoming inconsistent during the backup.
Compatibility and ease of integrating into existing systems I'd assume.
Compatability really doesn't count since it requires specific support in Vista, so they could've implemented it to use a completely separate flash device rather than one that's built into a drive.
I'm taking the "ease of integration" thing with a large pinch of salt too - if this is primarily for notebooks then you can more or less discount upgrades (how many people really upgrade the drive in their notebook?). So this will be installed by the notebook manufacturer - i.e. there's no real reason for putting it in the drive rather than on the motherboard. And it seems like it might be more sensible to hang the flash chips off the north bridge directly rather than on an ATA bus since it would probably improve read speeds.