I have actually signed up for this site at least 5 times now. I remember the logins for 3 of them but not the password and the email accounts they were linked to no longer exist (2 at yahoo that I didn't log in to for several years and when I went back they didn't let me in, and one at eudora.com).
There are very many ways to differentiate them (I would hypothesize an infinite number of different ways), most of them are just not efficient.
The trouble I have is understanding why we need so many. A transport protocol is a mechanism for ensuring the delivery of data from one point to another. Surely it would be far simpler to optimize a network (or write faster software for routers/switches) if there were only a few standard protocols (granted there are only a few in wide use and most network hardware is designed for that fact).
If you can get a bunch of people to prefer using a particular piece of software on any hardware, and at the same time you make that software better on specific hardware (say a premium line of samsung phones), you are likely to get some people to buy said hardware.
It would be in Samsung's best interest to get Cyanogen to work (in a basic sense; perhaps require rooting and not to be actually optimized for given hardware) on as many phones as possible.
Everyone would have the capability and simply decide to not use it. Many governments currently do.
Today that functionality is nuclear weapons. Tomorrow it might be orbital kinetic bombardment. Or an engineered virus. Or an atmospheric toxin. Or satellite based microwave emission system. Or another radiation system.
There are too many ways to destroy entire populations of humans to defend against them all. One thing we are really good at is killing each other.
The power source is irrelevant and inconsequential (it would be a side affect of creating the kinetic energy dispersal system, consider siphoning the energy off the evaporation process of a black hole as an example energy source that would be available)
this would need: 1. AI built in to it 2. lasers than can instantly cut through just about anything 3. personal jet engines / rockets and the stability software necessary for flight (ignoring acrobatics) 4. palm based energy blasters 5. kinetic energy dispersal system (whatever it is that makes Stark's insides not flatten when he comes to a stop like that; this is by far the most important aspect)
I doubt we can get an AI powerful enough before 2050 even with the singularity.
The lasers might be possible if we can come up with a powerful enough power source and miniaturization processes (they are basically industrial cutting lasers with a couple of orders of magnitude more power).
If the propulsion system ever happens, it will be someone's fantasy as we would have already come up with far better transportation systems (due to having a solution to #5). The AI would be necessary for adjusting the system to maintain stability.
The palm blasters are an interesting concept. It might be possible to emit a waveform with enough power to break molecular bonds and enough direction to be useful and not to leave behind harmful radiation. However the effect would be more like a lightning bolt than any energy weapon depicted in the movies. The AI would be necessary for the targeting estimates. The kinetic dispersal system would also be necessary for dealing with the recoil of the system.
To say whether or not such a kinetic dispersal system is possible would require a deeper understanding of physics than what we currently have. Newtonian mechanics would prohibit it, but perhaps there is a way to construct something akin to a mass effect field (warp field, spacetime relocation mechanism, etc.), thus reducing the mass of the suit and contents to the point where the momentum is negligible. Such a construct would permit things like FTL travel (useful for time travel only as other uses would be covered by non-euclidean environments), non-euclidean environments (and the nearly incomprehensible energy sources and advancements available with them), and the warping of space-time to exhibit effects like teleportation (teleportation would be the act of moving in a non-euclidean environment; we wouldn't have a need for travel by motorized propulsion systems as we could simply ignore the space between points A and B).
In short, to create the Iron Man suit, we would necessarily already be at least a type III civilization on the Kardashev scale and the concept of why we might make the suit wouldn't make sense. For weapons, lasers, bullets, rockets and blasters are quite useless compared to simply relocating the spacetime in which the opponent occupies. The concept of serious machine assisted locomotion would be equally laughable, devices that would exist would only be for our amusement.
My favorite language is JavaScript, followed by Perl then Python.
C# is nice, but dealing with tons of really poorly designed libraries drags it down. It is amazing what crappy developers can do to make working on a program not fun. Ruby, PHP and Java also have this problem but I don't like those languages in the first place (Perl and Python probably do too but it is relatively easy to avoid bad libraries there due to superior packaging facilities, and I have yet to attempt to use a js library where I didn't have clean source code).
My preferred language order would be something like (out of languages I have ever written something that a non-developer used in): js > Perl = Python > C# = Haskell > C++ > C > Objective-C > Ruby > PHP > Java > VB.NET > VB6
On the contrary, I have found it quite difficult to take a given C or C++ program which depended on a significant number of external libraries and port it from one platform to another.
For example, the effort maintained in the libraries for Firefox is far from trivial.
If I wrote a C# application which didn't use significant external libraries (IE, only use libraries either defined in the standard or which only use functionality from the standard), I could port it just as easily as a similar C++ app.
The core problem is that the line of what is a documented standard and what is not is very blurred from a.NET developer's perspective.
On top of this, many of the libraries have bugs which prevent your code from working even if the library dif have all the classes you were using. For example you might have a class which inherits from the library class and overrides a method. In.NET this class may compile fine, and in Mono it complains about the method not being virtual, so the resulting code doesn't function properly.
btw, the only thing I am using in.NET 4 are the new expression types (ex: StatementExpression). However my code is all ASP.NET.
That was the same thing I thought too. My second play-through identified that the whole game was like that though. It took me to hell to acquire the taste for where the monsters were going to spawn, the ideas were there right from the beginning.
1: Current online storage 2: online backups (live, hourly, daily, whatever...): a backup drive ready to take the place of the online storage at any time 3: offline backups
every month: 2 becomes 3 1 becomes 2 either 3 becomes 1 or new drive becomes 1
Because the editors are still in their heads comparing them to HDDs. It will be a few more years before the wow factor of just how fast these things are winds down and reviewers become able to compare them against each other and not the spinning media.
You obviously haven't had the pleasure of seeing your compile times drop 10x (or you aren't doing work on something big enough to notice).
The projects I work on take about 12 minutes to compile on a 7200 rpm drive; 8 on a 10k and 1 on my intel SSD. Visual Studio itself shows noticeable performance gains as well. These improvements are enough to translate to extra features in a release cycle.
Take notice that Atwood says they are worth it even with the failure rates he is experiencing. Also consider that he may not be the norm when it comes to failure rates.
I purchased my X-25M G2 the day it became available on newegg (mid 2009 sometime). Several of my friends also have various drives(all still running with no indications of problems): X-25M G2 160GB Vertex 2 120GB another Vertex 2 120GB several others that I don't know the names of offhand. All were purchased immediately when they first came to market.
The point is personal experiences are not indicative of statistical means.
I'm sorry, but the rapid release cycle does make a lot of sense. Firefox as a whole is relatively speaking not very buggy. It certainly is less so than IE or Safari (at least I don't hit any noticeable Firefox bugs on a daily basis but Safari regularly crashes [windows] and IE dev tools have so many problems that they are nearly impossible to use).
New features/enhancements/fixes used to be implemented on trunk, with a "bake" time needed to make sure that they didn't degrade the product. Now they are done in their own branches and tested in isolation from each other then merged into trunk (now called mozilla-central) when it is felt that they are ready. This lets the end user (you) get to see new features faster than you would have before, without worrying about bugs from other things which needed to be included before, but had nothing to do with the feature which is finished.
I think the good points of this new development schedule outweigh the bad, and the bad points that have been discovered so far can all be minimized with a bit of effort. Good: 1. Faster features to end users. 2. Less bugs introduced due to being able to decide not to include features right up until the moment something is actually released. Indifferent: 1. Firefox is just as difficult to manage for a domain's worth of users as it was before this change; the only difference is that it is likely to be major version number increases instead of minor version number increases whenever a new release comes out. However as you pointed out, nobody cares what the difference is. Bad: 1. Addons need to be managed more by their respective authors to keep them up to date with the latest version of firefox. Last time I checked AMO didn't accept setting the maxver property to a version greater than the current major release. Something might need to be changed here.
Yeah and the same CFL uses 1/4 of that to give the same light. And lasts about 5 times longer.
Under near-ideal conditions.
In our old place, we were changing every bulb in the house every other month, regardless of what kind of bulb they were. When we first moved in and noticed that half the lights in the place were burnt out (they were all incandescent at the time), we went out and bought CFLs for $3 per bulb at Walmart (the GE energy smart line I think they were, sold in the plastic two packs with the green labels). Within the next month we had replaced the rest of the lights in the apartment, and 2 of the CFLs we had bought initially (one in the bathroom and one in the living room). Two weeks after that the bathroom light went out again (and again 3 weeks after that). After 4 months we had replaced every single bulb, and about half of those had been replaced twice or more. Most I switched back to incandescents because they worked out to be $0.25 a piece and the lighting part of our electric bill didn't remotely compare with the heating part (welcome to winter: Bozeman, MT in a house with poorly sealed single pane windows).
When our refrigerator blew we had a repairman come by and he informed us that the lighting in our house wasn't surge protected (along with about half of the outlets) because there was poor regulation in the area until about 10 years ago, so any houses built before then were built to very widely varying degrees of freedom and safety. I then watched him pull the refrigerator away from the wall and saw that the it was plugged into a 3-2 outlet changer (the ones you screw into the middle screw on the outlet, this one was screwed in) which then went into the wall outlet. He unscrewed it and plugged it into another (two prong) outlet in the kitchen and it turned back on, so he went and looked at what was wrong with the outlet (one of the wires was barely connected). I then watched as he replaced the two pronged outlet with a 3 pronged outlet. As there was only 2 wires in the socket, I asked him how it was grounded. He replied that it wasn't as he pulled out a sharpie and colored a circle around the ground prong, but he had a 3 pronged outlet with him and it was obviously no different than plugging the refrigerator into an adapter into a non-grounded two pronged outlet.
I'd say we spent at least $3 a month on lightbulbs while we lived there. Several of the bulbs we never replaced again when they died. When we looked for a new apartment to move into I brought along my surge protector which has a 3 pronged plug and a couple of lights on it to let me know that A: power is constant without significant spikes or drops and B: the outlet is grounded. The first 10 places we looked at failed both conditions. 4 didn't have any 3 pronged outlets. In 4 that did, the outlets weren't grounded at all. In the others, the first light wouldn't stay on for more than a few seconds. Every one of those places had at least one light bulb out and almost none of the bulbs anywhere were CFLs. On several of the 3 pronged outlets I noticed a black marking around the ground.
The 11th place we looked at passed my very simple test, and since we moved in (8 months ago now) I have replaced 2 bulbs with CFLs (GE smart line), 4 that are on a dimmer and 2 that are outside with new incandescents, bought 2 incandescents and 3 CFLs (GE reveal line) for lamps and have 2 bulbs out which I haven't replaced since moving in (one in a bathroom and one in a hallway). Both outdoor lights are out and one on the dimmer is out (all 3 were new incandescents), but overall I am replacing them at less than 1/4th the rate which I was at the old place (9 blocks away, same electric grid, underground cabling). I am quite happy with the CFLs overall so far and enjoy the color from the reveal line more than the others.
I don't quite understand why 13 bulbs have gone out in the past 8 months, but 10 of them could have been pretty old I guess (leaving only 3 to go out within 6 months of replacing the
What HMAC does provide is a method which accepts both a message (the password) and a key (the salt) and an algorithm which supplies a single hash.
It is at least as strong as SHA(password+salt), and you don't have to worry about if you implemented it right. Ie is correct password salting like this: function hash(password,salt) { return SHA(password+salt); } or this: function hash(password,salt) {
(salt1,salt2)=split_salt_somehow(salt);
return SHA(SHA(password+salt1)+salt2); }
(hint, the latter is better and is what is done internally inside HMAC)
With HMAC, an organization doesn't need to be concerned about the proper implementation of a password hash: function hash(password,salt) { return HMAC(password,salt); }
MS is a part of the consortium. While yes they would still have to pay for 264, it is cheaper for them to do so on a per-browser installation basis (they are already paying on a per unit basis for windows, so supporting it in Chrome in windows costs them nothing extra). Since Google will not be supporting it with their own implementation, they wouldn't be liable for any of the costs.
If Google/Mozilla were to include H.264 then they would have to pay the consortium the fee of 1 cent per download (or 5 million, whichever is cheaper)*. Mozilla simply cannot afford this, and Google has no incentive for it.
Remember that Google's goal with Chrome is to make browsers better so that Google can provide an experience in their services which users will readily accept and interact with advertizing. Supporting 264 would do nothing toward that goal which WebM cannot do at least as well (without funding MS or Apple).
Chrome, Mozilla and Opera also have to deal with supporting more than just one platform. Not only would they need an H.264 implementation, but they would need one optimized for each platform they support. This extra implementation cost also adds up. In contrast, MS relies on their system codecs library and Apple relies on Quicktime for support of 264. Neither of these are readily available for Linux, let alone the PS3, Wii, Android phones, Nokia phones, etc.
* I haven't read the actual requirements for implementing H.264, I've only read about them on various websites and this is the general idea I get of the cost for implementers.
I bet this will not affect Amazon (or B&N or Sony or...) at all.
The problem as Apple sees it is that there is starting to be apps that you can download free from the store which say things like "Call of the Wild book here." When you run these apps you get presented with a list of books you can buy, directly from the scum that is selling them. Since the kindle app isn't marketed as "hey, look at me, I have this fancy book you want to read and you can get me free," but rather "with me you can read any of the books you can already read on any other platform which supports kindle books" (and thus isn't advertizing within the app store or in the app itself any particular book), this restriction wouldn't apply.
Now, Apple wouldn't mind at all if Amazon interpreted this as applying to them and complied, however unlikely that is.
Really, Amazon's 3 choices here are: 1. Do nothing (believing Apple will not touch the Kindle app). 2. Do nothing (let Apple catch bad press for removing the Kindle app). Consider coming back to the Apple store after being removed. 3. Change now (under the impression that Apple would remove their app and that it would affect profits more than a 43% price increase)
It seems to me that this is a no-brainer to Amazon. Do nothing now, and at worst you get blocked for a few days while having a large opportunity to give Apple bad PR (think of it now, a kindle vs ipad commercial during the superbowl which looks just like the mac vs pc ones apple used to run).
Google is pouring money into Google Docs. Both directly and indirectly. Google funds the Docs apps by paying the developers. It also started Chrome to speed up javascript execution and page rendering (so that, among other reasons, Docs can have more computationally expensive functionality). Further it sponsors development of Firefox and Webkit. This is done to foster competition so that MS makes IE better (which helps Docs and everything else Google does). It also is spending a lot of money toward html5 (which will reduce implementation costs for Google).
The trouble of it is that MS is also pouring money into Office. A question is if Oracle is going to make OpenOffice significantly better (I'm betting not; oracle just wants to wring out the money that is there right now while spending as little as possible, when OO becomes unprofitable it will be shelved away and forgotten).
Every single thing Google does is designed to increase the profit stream of the advertizing. Most of the obvious places are already highly optimized (see ex. placement of sponsored links in search) and so many of the current Google services are done for long term benefits (Google Docs + sophisticated AI = better targeted ads to the people using Docs; faster javascript may mean some of the computation necessary to feed data to the AI can be done in browser, reducing server costs for Google). It doesn't matter much how long it takes Google to get a Docs package that is good (and it certainly doesn't need to happen until the AI is equally good enough). It may never wind up better than Office (it only needs to be good enough to catch a significant enough number of eyeballs to turn a profit; it will continuously need to improve from here because Office will do the same, but it never needs to get better than Office in terms of functionality).
Honestly while thus far the nightlies as a whole have been pleasant (aside from a few bugs), I would have to say panorama seems very useless at the moment.
IMO the good parts of the update: 1. faster (though for me it wasn't exactly slow before) 2. swapping open in new tab and open in new window in the context menu 3. better ui for remembering passwords, requesting things like location data, site identity,... 4. better ui for tabs window and bookmarks window
The bad parts: 1. swapping open in new tab and open in new window in the context menu (until I got used to the change) 2. moving all the status stuff into the url bar (added back with status-4-evar; something that shouldn't be necessary; though perhaps I find the need for this due to to needing it as a developer) 3. The orange button (completely unnecessary as alt shows the menu) 4. panorama still has too many bugs for me to consider trusting it 5. strong dislike of the combined refresh/stop/go button in the url bar 6. after loading a page, the star doesn't appear for bookmarking until after I click in the url bar
Slashdot Mirror
me too :(
I have actually signed up for this site at least 5 times now. I remember the logins for 3 of them but not the password and the email accounts they were linked to no longer exist (2 at yahoo that I didn't log in to for several years and when I went back they didn't let me in, and one at eudora.com).
There are very many ways to differentiate them (I would hypothesize an infinite number of different ways), most of them are just not efficient.
The trouble I have is understanding why we need so many. A transport protocol is a mechanism for ensuring the delivery of data from one point to another. Surely it would be far simpler to optimize a network (or write faster software for routers/switches) if there were only a few standard protocols (granted there are only a few in wide use and most network hardware is designed for that fact).
Try looking at the bigger picture.
If you can get a bunch of people to prefer using a particular piece of software on any hardware, and at the same time you make that software better on specific hardware (say a premium line of samsung phones), you are likely to get some people to buy said hardware.
It would be in Samsung's best interest to get Cyanogen to work (in a basic sense; perhaps require rooting and not to be actually optimized for given hardware) on as many phones as possible.
Take for example this one:
http://singularityhub.com/2011/08/14/dutch-plantlab-revolutionizes-farming-no-sunlight-no-windows-less-water-better-food/
In a hundred years that one is going to be taken for granted.
Just scanning that site for other examples that I have seen elsewhere as well:
http://singularityhub.com/2011/07/09/in-medical-first-doctors-implant-lab-grown-synthetic-trachea-into-patient/
http://singularityhub.com/2011/08/08/square-transforms-your-phone-into-a-credit-card-machine-now-handling-4-milllion-a-day/
http://singularityhub.com/2011/07/26/anybots-ramps-up-to-bring-telepresence-robot-revolution/
Ideas haven't gotten smaller, they have gotten diluted due to the sheer number of them.
It wouldn't be a single agency.
Everyone would have the capability and simply decide to not use it. Many governments currently do.
Today that functionality is nuclear weapons. Tomorrow it might be orbital kinetic bombardment. Or an engineered virus. Or an atmospheric toxin. Or satellite based microwave emission system. Or another radiation system.
There are too many ways to destroy entire populations of humans to defend against them all. One thing we are really good at is killing each other.
The power source is irrelevant and inconsequential (it would be a side affect of creating the kinetic energy dispersal system, consider siphoning the energy off the evaporation process of a black hole as an example energy source that would be available)
this would need:
1. AI built in to it
2. lasers than can instantly cut through just about anything
3. personal jet engines / rockets and the stability software necessary for flight (ignoring acrobatics)
4. palm based energy blasters
5. kinetic energy dispersal system (whatever it is that makes Stark's insides not flatten when he comes to a stop like that; this is by far the most important aspect)
I doubt we can get an AI powerful enough before 2050 even with the singularity.
The lasers might be possible if we can come up with a powerful enough power source and miniaturization processes (they are basically industrial cutting lasers with a couple of orders of magnitude more power).
If the propulsion system ever happens, it will be someone's fantasy as we would have already come up with far better transportation systems (due to having a solution to #5). The AI would be necessary for adjusting the system to maintain stability.
The palm blasters are an interesting concept. It might be possible to emit a waveform with enough power to break molecular bonds and enough direction to be useful and not to leave behind harmful radiation. However the effect would be more like a lightning bolt than any energy weapon depicted in the movies. The AI would be necessary for the targeting estimates. The kinetic dispersal system would also be necessary for dealing with the recoil of the system.
To say whether or not such a kinetic dispersal system is possible would require a deeper understanding of physics than what we currently have. Newtonian mechanics would prohibit it, but perhaps there is a way to construct something akin to a mass effect field (warp field, spacetime relocation mechanism, etc.), thus reducing the mass of the suit and contents to the point where the momentum is negligible. Such a construct would permit things like FTL travel (useful for time travel only as other uses would be covered by non-euclidean environments), non-euclidean environments (and the nearly incomprehensible energy sources and advancements available with them), and the warping of space-time to exhibit effects like teleportation (teleportation would be the act of moving in a non-euclidean environment; we wouldn't have a need for travel by motorized propulsion systems as we could simply ignore the space between points A and B).
In short, to create the Iron Man suit, we would necessarily already be at least a type III civilization on the Kardashev scale and the concept of why we might make the suit wouldn't make sense. For weapons, lasers, bullets, rockets and blasters are quite useless compared to simply relocating the spacetime in which the opponent occupies. The concept of serious machine assisted locomotion would be equally laughable, devices that would exist would only be for our amusement.
as an aside:
My favorite language is JavaScript, followed by Perl then Python.
C# is nice, but dealing with tons of really poorly designed libraries drags it down. It is amazing what crappy developers can do to make working on a program not fun.
Ruby, PHP and Java also have this problem but I don't like those languages in the first place (Perl and Python probably do too but it is relatively easy to avoid bad libraries there due to superior packaging facilities, and I have yet to attempt to use a js library where I didn't have clean source code).
My preferred language order would be something like (out of languages I have ever written something that a non-developer used in):
js > Perl = Python > C# = Haskell > C++ > C > Objective-C > Ruby > PHP > Java > VB.NET > VB6
On the contrary, I have found it quite difficult to take a given C or C++ program which depended on a significant number of external libraries and port it from one platform to another.
For example, the effort maintained in the libraries for Firefox is far from trivial.
If I wrote a C# application which didn't use significant external libraries (IE, only use libraries either defined in the standard or which only use functionality from the standard), I could port it just as easily as a similar C++ app.
The core problem is that the line of what is a documented standard and what is not is very blurred from a .NET developer's perspective.
On top of this, many of the libraries have bugs which prevent your code from working even if the library dif have all the classes you were using. For example you might have a class which inherits from the library class and overrides a method. In .NET this class may compile fine, and in Mono it complains about the method not being virtual, so the resulting code doesn't function properly.
btw, the only thing I am using in .NET 4 are the new expression types (ex: StatementExpression). However my code is all ASP.NET.
That was the same thing I thought too. My second play-through identified that the whole game was like that though. It took me to hell to acquire the taste for where the monsters were going to spawn, the ideas were there right from the beginning.
1: Current online storage
2: online backups (live, hourly, daily, whatever...): a backup drive ready to take the place of the online storage at any time
3: offline backups
every month:
2 becomes 3
1 becomes 2
either 3 becomes 1 or new drive becomes 1
Because the editors are still in their heads comparing them to HDDs. It will be a few more years before the wow factor of just how fast these things are winds down and reviewers become able to compare them against each other and not the spinning media.
You obviously haven't had the pleasure of seeing your compile times drop 10x (or you aren't doing work on something big enough to notice).
The projects I work on take about 12 minutes to compile on a 7200 rpm drive; 8 on a 10k and 1 on my intel SSD. Visual Studio itself shows noticeable performance gains as well. These improvements are enough to translate to extra features in a release cycle.
Take notice that Atwood says they are worth it even with the failure rates he is experiencing. Also consider that he may not be the norm when it comes to failure rates.
I purchased my X-25M G2 the day it became available on newegg (mid 2009 sometime). Several of my friends also have various drives(all still running with no indications of problems):
X-25M G2 160GB
Vertex 2 120GB
another Vertex 2 120GB
several others that I don't know the names of offhand. All were purchased immediately when they first came to market.
The point is personal experiences are not indicative of statistical means.
I'm sorry, but the rapid release cycle does make a lot of sense. Firefox as a whole is relatively speaking not very buggy. It certainly is less so than IE or Safari (at least I don't hit any noticeable Firefox bugs on a daily basis but Safari regularly crashes [windows] and IE dev tools have so many problems that they are nearly impossible to use).
New features/enhancements/fixes used to be implemented on trunk, with a "bake" time needed to make sure that they didn't degrade the product. Now they are done in their own branches and tested in isolation from each other then merged into trunk (now called mozilla-central) when it is felt that they are ready. This lets the end user (you) get to see new features faster than you would have before, without worrying about bugs from other things which needed to be included before, but had nothing to do with the feature which is finished.
I think the good points of this new development schedule outweigh the bad, and the bad points that have been discovered so far can all be minimized with a bit of effort. Good:
1. Faster features to end users.
2. Less bugs introduced due to being able to decide not to include features right up until the moment something is actually released.
Indifferent:
1. Firefox is just as difficult to manage for a domain's worth of users as it was before this change; the only difference is that it is likely to be major version number increases instead of minor version number increases whenever a new release comes out. However as you pointed out, nobody cares what the difference is.
Bad:
1. Addons need to be managed more by their respective authors to keep them up to date with the latest version of firefox. Last time I checked AMO didn't accept setting the maxver property to a version greater than the current major release. Something might need to be changed here.
Not to mention the awful frog man and annoying kid.
Horrible terrible program.
That is still better than everything else.
Chrooted into a jail that they can do almost nothing from (perhaps get version numbers from a few tools).
Yeah and the same CFL uses 1/4 of that to give the same light. And lasts about 5 times longer.
Under near-ideal conditions.
In our old place, we were changing every bulb in the house every other month, regardless of what kind of bulb they were. When we first moved in and noticed that half the lights in the place were burnt out (they were all incandescent at the time), we went out and bought CFLs for $3 per bulb at Walmart (the GE energy smart line I think they were, sold in the plastic two packs with the green labels). Within the next month we had replaced the rest of the lights in the apartment, and 2 of the CFLs we had bought initially (one in the bathroom and one in the living room). Two weeks after that the bathroom light went out again (and again 3 weeks after that). After 4 months we had replaced every single bulb, and about half of those had been replaced twice or more. Most I switched back to incandescents because they worked out to be $0.25 a piece and the lighting part of our electric bill didn't remotely compare with the heating part (welcome to winter: Bozeman, MT in a house with poorly sealed single pane windows).
When our refrigerator blew we had a repairman come by and he informed us that the lighting in our house wasn't surge protected (along with about half of the outlets) because there was poor regulation in the area until about 10 years ago, so any houses built before then were built to very widely varying degrees of freedom and safety. I then watched him pull the refrigerator away from the wall and saw that the it was plugged into a 3-2 outlet changer (the ones you screw into the middle screw on the outlet, this one was screwed in) which then went into the wall outlet. He unscrewed it and plugged it into another (two prong) outlet in the kitchen and it turned back on, so he went and looked at what was wrong with the outlet (one of the wires was barely connected). I then watched as he replaced the two pronged outlet with a 3 pronged outlet. As there was only 2 wires in the socket, I asked him how it was grounded. He replied that it wasn't as he pulled out a sharpie and colored a circle around the ground prong, but he had a 3 pronged outlet with him and it was obviously no different than plugging the refrigerator into an adapter into a non-grounded two pronged outlet.
I'd say we spent at least $3 a month on lightbulbs while we lived there. Several of the bulbs we never replaced again when they died. When we looked for a new apartment to move into I brought along my surge protector which has a 3 pronged plug and a couple of lights on it to let me know that A: power is constant without significant spikes or drops and B: the outlet is grounded. The first 10 places we looked at failed both conditions. 4 didn't have any 3 pronged outlets. In 4 that did, the outlets weren't grounded at all. In the others, the first light wouldn't stay on for more than a few seconds. Every one of those places had at least one light bulb out and almost none of the bulbs anywhere were CFLs. On several of the 3 pronged outlets I noticed a black marking around the ground.
The 11th place we looked at passed my very simple test, and since we moved in (8 months ago now) I have replaced 2 bulbs with CFLs (GE smart line), 4 that are on a dimmer and 2 that are outside with new incandescents, bought 2 incandescents and 3 CFLs (GE reveal line) for lamps and have 2 bulbs out which I haven't replaced since moving in (one in a bathroom and one in a hallway). Both outdoor lights are out and one on the dimmer is out (all 3 were new incandescents), but overall I am replacing them at less than 1/4th the rate which I was at the old place (9 blocks away, same electric grid, underground cabling). I am quite happy with the CFLs overall so far and enjoy the color from the reveal line more than the others.
I don't quite understand why 13 bulbs have gone out in the past 8 months, but 10 of them could have been pretty old I guess (leaving only 3 to go out within 6 months of replacing the
What HMAC does provide is a method which accepts both a message (the password) and a key (the salt) and an algorithm which supplies a single hash.
It is at least as strong as SHA(password+salt), and you don't have to worry about if you implemented it right. Ie is correct password salting like this:
function hash(password,salt) { return SHA(password+salt); }
or this:
function hash(password,salt) {
(salt1,salt2)=split_salt_somehow(salt);
return SHA(SHA(password+salt1)+salt2);
}
(hint, the latter is better and is what is done internally inside HMAC)
With HMAC, an organization doesn't need to be concerned about the proper implementation of a password hash:
function hash(password,salt) { return HMAC(password,salt); }
Or a GUID...
We use the string representation of a guid (32 chars: 256 bits). Granted that half of those bits are 0, it is still an extra 128 bits.
At this size, the storage space necessary for a good rainbow table is essentially impossible (estimated size of the universe, etc.).
MS is a part of the consortium. While yes they would still have to pay for 264, it is cheaper for them to do so on a per-browser installation basis (they are already paying on a per unit basis for windows, so supporting it in Chrome in windows costs them nothing extra). Since Google will not be supporting it with their own implementation, they wouldn't be liable for any of the costs.
If Google/Mozilla were to include H.264 then they would have to pay the consortium the fee of 1 cent per download (or 5 million, whichever is cheaper)*. Mozilla simply cannot afford this, and Google has no incentive for it.
Remember that Google's goal with Chrome is to make browsers better so that Google can provide an experience in their services which users will readily accept and interact with advertizing. Supporting 264 would do nothing toward that goal which WebM cannot do at least as well (without funding MS or Apple).
Chrome, Mozilla and Opera also have to deal with supporting more than just one platform. Not only would they need an H.264 implementation, but they would need one optimized for each platform they support. This extra implementation cost also adds up. In contrast, MS relies on their system codecs library and Apple relies on Quicktime for support of 264. Neither of these are readily available for Linux, let alone the PS3, Wii, Android phones, Nokia phones, etc.
* I haven't read the actual requirements for implementing H.264, I've only read about them on various websites and this is the general idea I get of the cost for implementers.
I bet this will not affect Amazon (or B&N or Sony or ...) at all.
The problem as Apple sees it is that there is starting to be apps that you can download free from the store which say things like "Call of the Wild book here." When you run these apps you get presented with a list of books you can buy, directly from the scum that is selling them. Since the kindle app isn't marketed as "hey, look at me, I have this fancy book you want to read and you can get me free," but rather "with me you can read any of the books you can already read on any other platform which supports kindle books" (and thus isn't advertizing within the app store or in the app itself any particular book), this restriction wouldn't apply.
Now, Apple wouldn't mind at all if Amazon interpreted this as applying to them and complied, however unlikely that is.
Really, Amazon's 3 choices here are:
1. Do nothing (believing Apple will not touch the Kindle app).
2. Do nothing (let Apple catch bad press for removing the Kindle app). Consider coming back to the Apple store after being removed.
3. Change now (under the impression that Apple would remove their app and that it would affect profits more than a 43% price increase)
It seems to me that this is a no-brainer to Amazon. Do nothing now, and at worst you get blocked for a few days while having a large opportunity to give Apple bad PR (think of it now, a kindle vs ipad commercial during the superbowl which looks just like the mac vs pc ones apple used to run).
Google is pouring money into Google Docs. Both directly and indirectly. Google funds the Docs apps by paying the developers. It also started Chrome to speed up javascript execution and page rendering (so that, among other reasons, Docs can have more computationally expensive functionality). Further it sponsors development of Firefox and Webkit. This is done to foster competition so that MS makes IE better (which helps Docs and everything else Google does). It also is spending a lot of money toward html5 (which will reduce implementation costs for Google).
The trouble of it is that MS is also pouring money into Office. A question is if Oracle is going to make OpenOffice significantly better (I'm betting not; oracle just wants to wring out the money that is there right now while spending as little as possible, when OO becomes unprofitable it will be shelved away and forgotten).
Every single thing Google does is designed to increase the profit stream of the advertizing. Most of the obvious places are already highly optimized (see ex. placement of sponsored links in search) and so many of the current Google services are done for long term benefits (Google Docs + sophisticated AI = better targeted ads to the people using Docs; faster javascript may mean some of the computation necessary to feed data to the AI can be done in browser, reducing server costs for Google). It doesn't matter much how long it takes Google to get a Docs package that is good (and it certainly doesn't need to happen until the AI is equally good enough). It may never wind up better than Office (it only needs to be good enough to catch a significant enough number of eyeballs to turn a profit; it will continuously need to improve from here because Office will do the same, but it never needs to get better than Office in terms of functionality).
Honestly while thus far the nightlies as a whole have been pleasant (aside from a few bugs), I would have to say panorama seems very useless at the moment.
IMO the good parts of the update: ...
1. faster (though for me it wasn't exactly slow before)
2. swapping open in new tab and open in new window in the context menu
3. better ui for remembering passwords, requesting things like location data, site identity,
4. better ui for tabs window and bookmarks window
The bad parts:
1. swapping open in new tab and open in new window in the context menu (until I got used to the change)
2. moving all the status stuff into the url bar (added back with status-4-evar; something that shouldn't be necessary; though perhaps I find the need for this due to to needing it as a developer)
3. The orange button (completely unnecessary as alt shows the menu)
4. panorama still has too many bugs for me to consider trusting it
5. strong dislike of the combined refresh/stop/go button in the url bar
6. after loading a page, the star doesn't appear for bookmarking until after I click in the url bar