I've dealt with both Verizon and AT&T. My experience with Verizon was that I dumped them because they wouldn't sell replacement phones without changing my grandfathered night rate to start at 9:00. Still, although they were personified evil as a company, I never found them to be utterly incompetent.
And AT&T... it's hard to get results from them, but that's mostly because they keep telling you to call a different number eighteen times before you get the right division. That's not incompetence. That's being entirely too large to function properly. There's a difference.
If we limit it to things the government would do, yeah, they probably could standardize on something with a dozen other states and save a lot of money. If they go into it alone, it's just a money pit, though. If you have to run a custom app just for you, I'd expect it to be much cheaper to maintain systems in-house than to contract it out to a for-profit company to maintain them for you.
That said, I can think of a lot of apps that can't realistically work via the cloud---not because of the number of records, but because of the size of each individual record and the performance requirements for accessing those records.
Examples of apps that cannot realistically exist in the cloud:
video editing--the bandwidth requirements are too great, and each user would need the equivalent of several full blown CPUs all at once for the majority of the time (minimal idle time), so there is no advantage to cloud hosting over having those CPUs locally.
audio editing--in addition to all the problems of video editing, audio work tends to have a live recording component. There's no possibility of using a remote computer to apply real-time effects to the audio that is being recorded. The latency alone makes this difficult even if the cloud is really a server in the next room. So at minimum, you must have enough local CPU to handle all channel effects for any channels with record activated, plus any busses that those channels dump into, plus any master effects. In short, you have to have a beefy system locally, so why bother with the cloud at all? Oh, and a packet getting dropped would spell disaster, making it decidedly not fault tolerant.
photo editing--the bandwidth requirements are far too great for any serious editing (not talking about the fairly lightweight editors out there now), and the CPU requirements would at best allow maybe a 4:1 ratio between users and hardware, which doesn't save enough to cover the extra cost of rack-mount servers and faster networking even within your own building, much less the R&D costs or the cost of contracting it out to a third party to maintain at a profit. This ratio won't likely improve much because as computers get faster, people take advantage of that to do more complex effects and work with larger, higher-resolution images. And if you are just using Canvas on your local machine or similar, then there's no advantage to the cloud.
Just to be pedantic, you'd have to move it into a colder room or it won't be distinguishable from the background emissions of everything else. The only things that could possibly be distinguishable would be things that produce their own heat, whether electrically or chemically.
Piss them off anyway. GoDaddy is a bunch of leaches on the face of the Internet. Although I've never used GoDaddy for providing domain names (I'm very picky about who I trust with something that important), I tried using them for hosting and SSL certs recently. My GoDaddy experience was so bad that I actually wrote my first Slashdot journal entry about it. The gory details are chronicled here.
Godaddy is absolutely the most inept company I have ever dealt with; they make Fry's employees look knowledgeable, caring, and competent. They make Brooklyn camera shops seem above board. They sell services, then back out of the deal, screw up the refund afterwards, oversell their shared hosting servers, don't monitor what people do with them (allowing a few customers to cause multi-minute site outages), don't respond to customer complaints other than suggesting ways for you to pay them more money, require you to do things that defy the laws of physics in order for them to pay attention to your complaints... basically, they have single-handedly changed what the "S" stands for in ISP. They are to ISPs what the BOFH is to a proper IT manager.
I think it would be absolutely AWESOME if ICANN revoked their registrar status. It's not Chapter 7, but it would be a good start.
Agreed. You have to move to SATA-based SSDs for flash to be a speed win. USB just doesn't cut it for serious storage, both in terms of CPU overhead and in terms of maximum throughput. Of course, if you're moving stuff back and forth between two machines, the alternative is probably a USB external drive that has all the same performance problems. FireWire is much better in both respects. And, of course, eSATA is better still, but is relatively rare.
It's the first 256 GB USB flash stick, not the first 256GB flash drive. There are half a dozen 256GB flash-based SSDs out there that attach via SATA. The only thing that makes this even slightly relevant is the form factor.
Browser detection is almost always the wrong way to do things anyway. Test for existence of specific JavaScript properties/methods on objects to find out if they exist. You can generally check for IE-specific behavior just by testing for the presence or absence of JavaScript properties/methods.
if (document.getElementsByClassName) {
elts = document.getElementsByClassName("resulttablerow");
} else { /* IE and old browser version */
}
By doing this, you won't have to do a browser check at all and your page will "just work" for any browser that implements either the standards-compliant behavior, the IE behavior, or both. You can do the same thing for CSS properties by trying to add the property, then going and trying to read it back for verification. If it isn't there when you go back and check for it, the browser doesn't support the CSS property.
I'm not familiar with Opera's behavior, but in my experience, roughly 99.5% of CSS and JavaScript that works with FireFox also works with Safari and vice versa (as long as you don't try to use bleeding edge HTML5 or CSS3 features). Any browser check that only tests for FireFox is almost always just guaranteed to make a bunch of users mad for no reason.
That's more luck than anything else, though. There are tons of non-catastrophic possible ways to die in a fatal space accident--an unlucky micrometeorite/space junk impact while on a spacewalk, tearing your suit severely while on a spacewalk, sudden airlock failure (glass breakage, for example) before you get your helmet secured, accidental electrocution, on-board fire causing death from smoke inhalation while some people are wearing spacesuits or have some other oxygen supply, docking failures between the shuttle or a Soyuz capsule and ISS, damaged drogue chute leading to a harder than normal landing of a capsule, a landing gear failure on the shuttle, etc. I'm actually kind of surprised that there haven't been any accidental deaths in space yet that didn't involve the craft blowing up....
There were also several refueling disasters on the ground, apparently, plus two losses of all hands during reentry (one failed parachute, one depressurization). So yeah, there are quite a few qualifications in that sentence that are pretty critical. It's like saying that no one has ever died in the cab of a combine on an Interstate highway while traveling above 90 MPH.
Sadly, although that post was crude, it is not entirely off topic. My first thought when I read the headline was, "Now your 14-year-old daughter's 19-year-old boyfriend can feel like he's really there when she sends him a video of her stripping and...." Maybe I just have too little faith in humanity....
That would be speeding up the rotation. Also, if we pushed it the other way, we could make it exactly 52 weeks, which would be slightly more fun, IMHO. Of course, the right number of days is 336. 48 weeks, four weeks per month, and everything just divides out neatly. We would also need to move the moon a little closer so the synodic period would match up (29.5 days is just too far from 28).
The post I was replying to was complaining about just that sort of integration. If you want to upgrade Konqueror, upgrading it necessitates replacing the KTHML engine. Thus, it would be nontrivial to try to run multiple versions of such a browser. So yes, the same problem does exist in Linux. The only real difference is that there are four or five competing engines, any one of which can break a truckload of apps if you upgrade it in an incompatible way....
Also, it's not just help files, though that is the most common use. You could write an entire app in a browser, using native code for local file access. You could write an app that provides searching of eBooks from hundreds of sites and uses a web view to display the actual eBooks. You could write an iPhone app that provides a nice user interface with native app functionality of all sorts (taking photos, for example), but uses a UIWebView to render some content from your mobile website. And so on.
To a large degree, it's for the same reason that Safari can't be fully removed from Mac OS X. The browser contains almost no code, and all the actual engine parts are used by hundreds of other applications, tools, etc. from both the OS vendor and third parties. Although you can remove the browser app, you really aren't removing anything but the barest outer skin of the browser; probably a solid 99% of it will still be there. To a lesser degree, this is also true for Linux. Delete Firefox, install Chrome, and I'd imagine you'll find at least a few apps that break badly (unable to display help, etc.).
I'll use Mac OS X for my examples because I'm more familiar with it. In Mac OS X, the WebKit framework is used by Mail, Preview, etc. for rendering HTML. This is important for several reasons:
RAM use. The WebKit framework is a bit over 7MB on disk. There's exactly one copy of most of that in RAM, and the pages are shared among all the applications that link against WebKit. The alternative would be including a separate copy of this library for each app, which would mean that each app would have its own copy of that 7 MB. More RAM use = slower.
Security. If every app that needed browser functionality had to include its own copy of the browser core code, each of those apps would have to be updated every time there's a security fix or other major bug fix....
Stability. If every app that needed browser functionality had to include its own copy of the browser core code, each app would probably end up with its own slightly diverged version of the code with its own set of bugs, leading to a maintenance nightmare, reduced stability, inconsistent behavior between apps, etc.
Similarly, the JavaScriptCore framework is used by other apps for running JavaScript code as an application scripting language, the PubSub framework is used by other apps for subscribing to RSS feeds, and so on.
As for why having multiple such engines is less than useful, there are three main reasons that immediately spring to mind:
Application developers (open source notwithstanding) are generally wary about depending on having another application installed. And the ones who aren't wary about that are the same developers who keep reinstalling that five-year-old copy of Acrobat Reader every time you install their software, so being wary is a good thing.
The various engine vendors will never be able to agree on a single, standardized API. That means that you have to code to a particular engine. If it isn't there, you're hosed. See point 1.
In the worst case, you can end up with several competing HTML rendering engines, none of which work adequately as an embedded browser....
In short, the reasons for including a single standard browser core as part of the OS should be both obvious and compelling even if you have no interest in actually using it as your main web browser.
But just to address the original point, if every day were extended by approximately one minute (about 59.18 seconds, actually), that would be enough. Except for the need to buy new watches, nobody is going to notice an extra minute per day and say "Oh, wow, the days are longer." And that's all it would take to make a 365-day cycle line up with the seasons instead of a 365.25-day cycle. Just a minute a day will feed a hungry child... no, wait... wrong commercial.
Different person. This apparently happened to a bunch of people. This story is about somebody in New Hampshire; the one you linked to is about somebody in Texas.
I'd imagine that the code that authorized the transaction (checking it against the credit limit) worked, but the code that actually applied the transaction to the account didn't.
That's correct. The GP's power figures are low by a factor of more than 1,000. The actual worldwide power production in 2007 was about 19,852 TWh. I've seen sources that suggest the 2008 numbers were 30% greater, which would put it just shy of 26,000 TWh.
You'd have to capture as much energy as six continuous hurricanes for an entire year to cover the world's power needs.
Everything is relative, though. If you slow the rotation of the earth, each day will be longer, and you will thus necessarily have fewer days in a year (the time it takes Earth to move around the sun once) because each day will be a slightly greater percentage of that time. The only way decreasing the earth's rotation would not change the number of days in a year would be if you did so in a way that also changed the planet's orbital period to compensate.
Slashdot Mirror
I've dealt with both Verizon and AT&T. My experience with Verizon was that I dumped them because they wouldn't sell replacement phones without changing my grandfathered night rate to start at 9:00. Still, although they were personified evil as a company, I never found them to be utterly incompetent.
And AT&T... it's hard to get results from them, but that's mostly because they keep telling you to call a different number eighteen times before you get the right division. That's not incompetence. That's being entirely too large to function properly. There's a difference.
There are plenty of good programmers. Like the guy who wrote Hello, World. Completely safe.
The plusses are silent.
If we limit it to things the government would do, yeah, they probably could standardize on something with a dozen other states and save a lot of money. If they go into it alone, it's just a money pit, though. If you have to run a custom app just for you, I'd expect it to be much cheaper to maintain systems in-house than to contract it out to a for-profit company to maintain them for you.
That said, I can think of a lot of apps that can't realistically work via the cloud---not because of the number of records, but because of the size of each individual record and the performance requirements for accessing those records.
Examples of apps that cannot realistically exist in the cloud:
I'm sure there are plenty of others.
Just to be pedantic, you'd have to move it into a colder room or it won't be distinguishable from the background emissions of everything else. The only things that could possibly be distinguishable would be things that produce their own heat, whether electrically or chemically.
Piss them off anyway. GoDaddy is a bunch of leaches on the face of the Internet. Although I've never used GoDaddy for providing domain names (I'm very picky about who I trust with something that important), I tried using them for hosting and SSL certs recently. My GoDaddy experience was so bad that I actually wrote my first Slashdot journal entry about it. The gory details are chronicled here.
Godaddy is absolutely the most inept company I have ever dealt with; they make Fry's employees look knowledgeable, caring, and competent. They make Brooklyn camera shops seem above board. They sell services, then back out of the deal, screw up the refund afterwards, oversell their shared hosting servers, don't monitor what people do with them (allowing a few customers to cause multi-minute site outages), don't respond to customer complaints other than suggesting ways for you to pay them more money, require you to do things that defy the laws of physics in order for them to pay attention to your complaints... basically, they have single-handedly changed what the "S" stands for in ISP. They are to ISPs what the BOFH is to a proper IT manager.
I think it would be absolutely AWESOME if ICANN revoked their registrar status. It's not Chapter 7, but it would be a good start.
Multiple personalities, both of them newbies.
Agreed. You have to move to SATA-based SSDs for flash to be a speed win. USB just doesn't cut it for serious storage, both in terms of CPU overhead and in terms of maximum throughput. Of course, if you're moving stuff back and forth between two machines, the alternative is probably a USB external drive that has all the same performance problems. FireWire is much better in both respects. And, of course, eSATA is better still, but is relatively rare.
It's the first 256 GB USB flash stick, not the first 256GB flash drive. There are half a dozen 256GB flash-based SSDs out there that attach via SATA. The only thing that makes this even slightly relevant is the form factor.
Browser detection is almost always the wrong way to do things anyway. Test for existence of specific JavaScript properties/methods on objects to find out if they exist. You can generally check for IE-specific behavior just by testing for the presence or absence of JavaScript properties/methods.
if (document.getElementsByClassName) {
/* IE and old browser version */
elts = document.getElementsByClassName("resulttablerow");
} else {
}
By doing this, you won't have to do a browser check at all and your page will "just work" for any browser that implements either the standards-compliant behavior, the IE behavior, or both. You can do the same thing for CSS properties by trying to add the property, then going and trying to read it back for verification. If it isn't there when you go back and check for it, the browser doesn't support the CSS property.
I'm not familiar with Opera's behavior, but in my experience, roughly 99.5% of CSS and JavaScript that works with FireFox also works with Safari and vice versa (as long as you don't try to use bleeding edge HTML5 or CSS3 features). Any browser check that only tests for FireFox is almost always just guaranteed to make a bunch of users mad for no reason.
That's more luck than anything else, though. There are tons of non-catastrophic possible ways to die in a fatal space accident--an unlucky micrometeorite/space junk impact while on a spacewalk, tearing your suit severely while on a spacewalk, sudden airlock failure (glass breakage, for example) before you get your helmet secured, accidental electrocution, on-board fire causing death from smoke inhalation while some people are wearing spacesuits or have some other oxygen supply, docking failures between the shuttle or a Soyuz capsule and ISS, damaged drogue chute leading to a harder than normal landing of a capsule, a landing gear failure on the shuttle, etc. I'm actually kind of surprised that there haven't been any accidental deaths in space yet that didn't involve the craft blowing up....
There were also several refueling disasters on the ground, apparently, plus two losses of all hands during reentry (one failed parachute, one depressurization). So yeah, there are quite a few qualifications in that sentence that are pretty critical. It's like saying that no one has ever died in the cab of a combine on an Interstate highway while traveling above 90 MPH.
Sadly, although that post was crude, it is not entirely off topic. My first thought when I read the headline was, "Now your 14-year-old daughter's 19-year-old boyfriend can feel like he's really there when she sends him a video of her stripping and...." Maybe I just have too little faith in humanity....
Maybe I'm confused, but I thought the atheists defined it as an empty string, while the agnostics leave it in an undefined state.
Obligatory Futurama reference: "Death by snoo snoo."
That would be speeding up the rotation. Also, if we pushed it the other way, we could make it exactly 52 weeks, which would be slightly more fun, IMHO. Of course, the right number of days is 336. 48 weeks, four weeks per month, and everything just divides out neatly. We would also need to move the moon a little closer so the synodic period would match up (29.5 days is just too far from 28).
The post I was replying to was complaining about just that sort of integration. If you want to upgrade Konqueror, upgrading it necessitates replacing the KTHML engine. Thus, it would be nontrivial to try to run multiple versions of such a browser. So yes, the same problem does exist in Linux. The only real difference is that there are four or five competing engines, any one of which can break a truckload of apps if you upgrade it in an incompatible way....
Also, it's not just help files, though that is the most common use. You could write an entire app in a browser, using native code for local file access. You could write an app that provides searching of eBooks from hundreds of sites and uses a web view to display the actual eBooks. You could write an iPhone app that provides a nice user interface with native app functionality of all sorts (taking photos, for example), but uses a UIWebView to render some content from your mobile website. And so on.
Potatoe, potato.
To a large degree, it's for the same reason that Safari can't be fully removed from Mac OS X. The browser contains almost no code, and all the actual engine parts are used by hundreds of other applications, tools, etc. from both the OS vendor and third parties. Although you can remove the browser app, you really aren't removing anything but the barest outer skin of the browser; probably a solid 99% of it will still be there. To a lesser degree, this is also true for Linux. Delete Firefox, install Chrome, and I'd imagine you'll find at least a few apps that break badly (unable to display help, etc.).
I'll use Mac OS X for my examples because I'm more familiar with it. In Mac OS X, the WebKit framework is used by Mail, Preview, etc. for rendering HTML. This is important for several reasons:
Similarly, the JavaScriptCore framework is used by other apps for running JavaScript code as an application scripting language, the PubSub framework is used by other apps for subscribing to RSS feeds, and so on.
As for why having multiple such engines is less than useful, there are three main reasons that immediately spring to mind:
In short, the reasons for including a single standard browser core as part of the OS should be both obvious and compelling even if you have no interest in actually using it as your main web browser.
:-)
But just to address the original point, if every day were extended by approximately one minute (about 59.18 seconds, actually), that would be enough. Except for the need to buy new watches, nobody is going to notice an extra minute per day and say "Oh, wow, the days are longer." And that's all it would take to make a 365-day cycle line up with the seasons instead of a 365.25-day cycle. Just a minute a day will feed a hungry child... no, wait... wrong commercial.
Different person. This apparently happened to a bunch of people. This story is about somebody in New Hampshire; the one you linked to is about somebody in Texas.
I'd imagine that the code that authorized the transaction (checking it against the credit limit) worked, but the code that actually applied the transaction to the account didn't.
If we set up a colony on Mercury, people would go poof.
That's correct. The GP's power figures are low by a factor of more than 1,000. The actual worldwide power production in 2007 was about 19,852 TWh. I've seen sources that suggest the 2008 numbers were 30% greater, which would put it just shy of 26,000 TWh.
You'd have to capture as much energy as six continuous hurricanes for an entire year to cover the world's power needs.
Everything is relative, though. If you slow the rotation of the earth, each day will be longer, and you will thus necessarily have fewer days in a year (the time it takes Earth to move around the sun once) because each day will be a slightly greater percentage of that time. The only way decreasing the earth's rotation would not change the number of days in a year would be if you did so in a way that also changed the planet's orbital period to compensate.