Comment Re:Fail (Score 5, Insightful) 452
I love the awesome bar. It's made my browsing faster and more efficient.
I love the awesome bar. It's made my browsing faster and more efficient.
I imagine if you're a gamer that DOESN'T drink, then you're not going to a bar to watch StarCraft anyway. The kind of person that is interested in both StarCraft, and watching it in a bar will most likely drink.
This would be awesome for validating SSH keys. You could flash up an image instead of:
RSA key fingerprint is e2:1b:ec:de:3e:72:1a:9a:4e:82:a0:5f:8f:d3:01:af.
And it would be a much better indicator if the key had changed.
Did you read the link that was posted in the article? Mozilla clearly states that they are no going to responsible for implementing DRM, but that it's certainly feasible for a third party (i.e. Hulu) to implement something on top of the base the Mozilla provides. I think this is a "best of both worlds" attempt at DRM. Mozilla doesn't see value in DRM, but third parties might, if so they can implement their own.
Finally someone on
I work for an ISP and if we tried to institute any limits as to what you can connect to our network our customers would go crazy. This would be like your ISP saying, "You pay $80 a month for unlimited DSL service, but don't connect your PS3. PS3 uses a lot of bandwidth and brings down the network for everyone else." Sure we'd love it if all our users did nothing but text email all day and didn't use any bandwidth, but that's not real world. If T-Mobile has a problem with some app sending too much bandwidth, or too many packets they need to add some intelligent filtering to prevent that. Or add some logic to selectively disconnect phones that are inadvertently causing a DOS, instead of an outright ban.
Occasionally we'll have a rogue user who'll get a malware infection and send out a TON of packets and cause havoc. We just shut down that port until we can contact that customer and have them clean things up. We certainly don't (and wouldn't want to) limit what we allow customers to connect to the ethernet jack on the other end of our pipe.
Just to be cool and reply to my own post... I get 24653.0ms with a FF4 night on Windows XP and 38106.4ms with FF4 nightly on Linux on the *SAME* hardware.
I'm guessing this is in response to the recent criticism of both the Sunspider and V8 benchmarks as not testing realistic workloads. I'd be very curious to see an "acid" test of javascript that's developed with input from all the browser vendors and the community. It looks like maybe Microsoft of all people is moving in this direction with their JSMeter app? In all fairness this is kraken version 1.0, it could change drastically with more feedback from the community.
Also, did anyone verify the numbers in the original post? On my x86_64 linux box I get 28631.6ms with Chrome and 38106.4ms with FF4 nightly. It seems to me that Linux really gets the shaft in JS performance. It significant underperforms the Windows version on the same hardware.
Apple doesn't like Flash because it's proprietary Adobe technology and not an open platform? Hello pot meet kettle!
If I were Mozilla I wouldn't worry about Google pulling the plug on their deal. Google has more to lose than Mozilla does if the default searches go to another provider. I'm sure Microsoft would LOVE to throw some dollars at Mozilla if it meant billions of searches coming their way.
Mozilla's revenue isn't from Google it's from internet searches. There are other players that just Google doing searching now.
Get hold of portable property. -- Charles Dickens, "Great Expectations"