This is basic stuff to anyone who actually maintains a build, but Slashdot hasn't been a forum mostly populated by engineers for a number of years, now.
This appears to be due to link-time optimization blowing up the resident memory size of the linker, taking it past 3GB (which is already a non-standard hack the 32 bit build has had to do). Firefox is large, yes, but this has nothing to do with the final binary - which appears to be about 100MB total including all libraries in the Aurora builds.
I used to routinely run out of 32 bit address space compiling executables for a 64MB embedded ARM platform. This was due to symbol bloat, not executable size (which was 8MB). I also ran out of space compiling for a DSP with 288KB of RAM and 1MB flash, but that was mostly piss poor tools (Tasking). In fact, doesn't Chrome and even the Android sources already require building on a 64 bit host?
Theora really can't even compete with MPEG-1 on either video quality at a given bitrate, or performance. It was very specifically designeed for extremely low quality, extremely low resolution, extremely low bitrate streaming video, over a decade ago...
This isn't true. There's plenty of results out there which say Theora is, while not the best, a good codec. To quote Wikipedia:
More recently however, Xiph developers have compared the 1.1 Theora encoder to YouTube's H.264 and H.263+ encoders, in response to concerns raised in 2009 about Theora's inferior performance by Chris DiBona, a Google employee. They found the results from Theora to be nearly the same as YouTube's H.264 output, and much better than the H.263+ output.
There are plenty of people proclaiming that because it doesn't come out top, it's useless. Theora is far from useless: the results in any scenario that H.264 (even main profile) would be used, are still usable if you select Theora instead. They just aren't as pretty, because it's just not designed to the same constraints as H.264.
Becoming the HDTV standard would be an unrealistic goal. You attribute Theora not becoming the dominant standard due to Xiph's mishandling of the codec. The more obvious reason is politics: the MPEG group exists specifically to create audio/video standards which can be licensed. Broadcasters and content providers generally only use MPEG standards, and they just love licensing.
I'm interested to know what your theory is that Xiph could drive HDTV standards and have handled this better than a small company could?
The solution is obvious: allow installation of your own root certificate. This is supposed to be for security, not vendor lock-in. Without this option, I simply don't believe their intent.
FTP? Smtp? Distributed file shares? SQL server mirrors? NNTP? Ntp? I could probably list a dozen more.
Yes, that's a list of common internet protocols. I do not know of any example of anyone actually using geolocated DNS to CDN them. Do you have a concrete example?
And here we have the real reason why this is being promoted:
3. And IMO most importantly, this removes the server selection choice from being under the sole control of the CDN provider. If this stuff is logic'd through the main HTTP page of the website, the CDN must expose its server selection strategy to the client, which is likely proprietary business knowledge.
It breaks DNS. It certainly breaks my local DNS installation, for starters. It also means that *everyone* must use this DNS hack because service will be degraded unless you do.
Messing with DNS is doing it the Wrong Way. All of these CDN services are based on HTTP. When you're using them, that's an HTTP server you're talking to. It's perfectly capable of geolocating you by IP, and it can either hand you back links to a local CDN, or redirect you to another server.
Why the hell must we mess with DNS to do this? This is a solution which only works if you use Google DNS, OpenDNS, or sometimes if you use your local ISP's DNS. What if you're just running bind for you local net vs the root servers? Bzzt. Doesn't work.
The most insane thing about this is it's Google we're talking about here. They damn well know how to implement this entirely in their servers without resorting to DNS hacks. Why are they promoting this net-neutrality breaking, layering violating botch? We need less people to use this, not more.
NaCl is not so much about executing C/C++ code as it is about executing native compiled binaries. This has issues:
If I compile my C++ code for x86, I can run it on x86 browsers (well, specifically only Chrome on x86).
Ok now I have a cell phone, which is ARM. Guess I have to compile for ARM.
Now I have to compile everything for both x86 and ARM.
Ok now some other architecture is popular, but it won't run x86 or ARM.
It's incredible Google is even pushing this. It's so anti-portable and in concept anti-web.
There is a "portable" version of this, called "Portable Native Client". This means, of course, that NaCl is actually "Non-Portable Native Client" and that should itself be a clue. The "portable" version uses LLVM bitcode and a virtual machine. So more than a decade later, we've basically reinvented Java virtual machine applets minus the gigantic runtime (and language of your choice).
The only people who could possibly benefit from NaCl are Google. There's no general case use for this, and pushing it as standard into Chrome is a nasty move. Mozilla also reject the idea of NaCl. I believe Opera rejects it too (lacking a link). So, why is this being pushed?
This is all very irrelevant. The point is, it is technically not "Linux", it does not match what people would define as "Linux" (pre-Android) and it in no way is "Linux" other than just the kernel and some public-facing Google engineers who call it such. I didn't bring politics into this.
The same is true of Ubuntu and the Multiverse. You can CHOOSE to run pay software, the same as Android. I can run a commercial server daemon on pure, fully open Linux. Does that cease to be Linux? No.
It's a matter of what's meant by "Linux". Everyone used to mean "GNU/Linux" when they said simply "Linux". Android isn't GNU/Linux. There's no GNU in it - they stripped out what they could and rewrote from scratch what they couldn't. It's Apache/BSD/Linux.
So no, Android is not "Linux" by the definition of what everyone - before Android came along - would call Linux.
He didn't call it a linux desktop; he called it "the linux desktop dream come true"
It's not "Linux" as most people know it. There's a reason Richard Stallman was always bothered by people referring to the OS underlying Debian, Red Hat, Ubuntu and the countless other distributions as "Linux"; it ignores the fact that the vast majority of what makes it tick is the GNU userland.
Android does not have a GNU userland. In fact, they rewrote nearly all of it precisely to avoid it.
Android is an Apache/Linux desktop. It's only vaguely related to what everyone used to refer to as "Linux" or properly GNU/Linux.
Any contract lawyer would read over it and tell you what the holes are for a few hundred bucks. It's no big deal.
Since when is a few hundred bucks no big deal? For that matter, since when was it acceptable that a contract can only be understood by hiring a lawyer for a few hundred bucks? You're saying it yourself: the wording in the contract is so strangely constructed, that only a lawyer could understand it.
There's no reason NOT to go to a lawyer if you're considering signing something like this. It happens every day.
Well, apart from the several hundred bucks. If that happens every day, that's $50-100k a year, I guess. Good for the lawyers, bad for employees. The thing is, 364 days of the year you get a contract with normal termination clauses, but 1 of them has a dick clause. Do we pay a lawyer tax to insure ourselves against this, or do we assume that the courts will see it for what it is?
It just so happens that this guy decided to cut corners, got burned, and then whined about it publicly.
I fail to see how not spending a large sum on lawyers is cutting corners. People often don't use lawyers. it happens every day.
So, I guess you spend several hundred bucks on a lawyer every time you get a new job or receive stock or options?
It seems a large number of people here think that it is, though. Idiocy, or trolls. Do people really have so little sympathy? Contracts are intended to be a fair, bindings agreement between two parties. There are countless examples of unfair or weasel worded contracts failing in court, but apparently that would be news to some. What about loan sharks? What if someone snuck in a paragraph of mind bending legalize which amounted to "we can kill you"?
Oh, of course, they should have read the contract, and in case it was too confusing, they should have hired a really expensive lawyer to read it for them.
Bullshit. While I have diminished sympathy for Lee for not double and triple checking his termination clause, I do not have none. I also suspect, as pointed out in another comment here, that Skype should be liable for a lot of taxes by effectively buying back his options for nothing rather than their grant price. This probably still represents a net win for Skype, but at least then it's not "free" for them to exercise this clause.
In any case, it's still a particularly nasty thing for Skype to have done. Options generally have a "30 day" clause so you're not screwed in case of termination. This is supposed to add potential value to the options: you don't constantly run the risk of losing them all at the whim of the company. Skype effectively has a termination clause which takes away all your options any time they want. The difference is huge: I currently work on the assumption that my options are "safe" and I don't have to worry about them vs termination. My employer has written their options clauses to effectively say "we cannot be a dick - we are bound to allow you a grace period". Skype didn't. Their employees must treat options as directly bound to their employment, and if they're working under an "at will" contract, they can be gone in an instant. Skype took away a vast amount of value in their options due to the buy-back clause.
So yeah, OpenID is only as good as its providers, and it's been demonstrated to me that they can be pretty damn insecure, ergo, I'm avoiding using OpenID for now. Using it for everything makes the OpenID provider I picked a single point of failure. I hate having to use seperate accounts for everything but at least when something bad happens, it doesn't usually affect anything else.
I just think this is like stopping driving just because one manufacturer made an unsafe car. You may be prematurely missing out - and making other people miss out - on what's potentially a good solution to password proliferation.
Some time ago myOpenID.com lost all (or some portion) of their registered accounts (afaik this was due to Amazon's cloud trouble). Which was annoying because I used it for my stackexchange login. As it turns out, I could just recreate my login with the same name and voila I could use it to access my stackexchange account. That means if someone had created an account with my name before I did they'd have full access to my SE account.
These are problems with myOpenID not OpenID. You're mixing protocol and provider.
I never realised how potentially broken things could get with OpenID and I'm being a bit weary about ever using OpenID again, even though I suppose I should've been more careful about what OpenID provider I picked.
You even say it yourself: you should've been more careful picking an OpenID provider. In any case, what did you lose? Nothing. What could you potentially have lost? A login on StackExchange. Many people would love to only have that problem.
This article from the Ottawa Citizen [ottawacitizen.com] sums it up nicely. The Playbook is sleek and well designed. It supports Flash and QNX is the best mobile operating system available. The PB's smaller size makes it more portable and therefore more useful. It fits in my jacket pocket or my wife's purse. It is much lighter than carrying a laptop. Wifi is all I need at home or in a hotel room. The bridge to my Blackberry works well when wifi is not available.
And yet... if you asked a potential customer whether they'd buy this or an iPad 2, they're more likely to buy an iPad 2. This is what all the other companies haven't figured out yet: the age of winning on specs and back-of-the-box check marks is over. This just isn't a well executed product. You either understand this, or you scratch your head wondering why you can't sell, blaming some phantom "halo effect" or other nonsense.
Interestingly, each and every iPhone user is doing the same "crime" committed by Google,, but unintentionally (and no, this does not seem to collect packets).
No, Google's "crime" was logging actual packet contents transmitted on open networks. This is just a list of network IDs.
Blu-ray is *not*/clearly/ superior - most people honestly can't tell the difference. Even on my 42in HDTV, I can't tell the difference between Blu-Ray and DVD unless I pause to see the jaggies.
Seriously? You must have an eye medical condition or a bad prescription not to see the difference between Blu-Ray and DVD. Or you're watching footage which was originally shot in 480 or 576 line. The difference is absolutely clear for any reasonable length of side-by-side comparison viewing.
There was some study (done in Holland?) where they told people a picture was HD, then randomly showed them SD or HD; they couldn't tell the difference.
You may be referring to an over-the-air SD vs HD comparison, where over use of compression almost destroys any advantage to the increased resolution. Also, if you simply sit someone down, show them one random clip of SD or HD and ask which it was, it's a bit like asking someone "was that a light or dark shade of gray?" Or sitting them down, feeding them low quality or high quality chicken and asking which they ate. The study isn't concluding that SD vs HD isn't noticeable. It's concluding about how the eye isn't good at making a quality judgement without context. The same is true for many things: food quality, air quality, car acceleration, and so on. But you wouldn't argue that people should just settle for low quality food, air, and shitty cars. You can't apply the study conclusions to your argument.
There's plenty to good reasons why Blu-Ray doesn't have strong uptake, but not being clearly superior to DVD isn't one of them, because it clearly is superior.
Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.
Funny, I find any flavor of C immensely easier to develop responsive applications due to pointers and the lack of garbage collection. I get the impression I don't want to see your C code.
Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf [llvm.org] concerning that effort.
The LLVM version is the ONLY version which should exist. It's funny that the LLVM version is called Portable Native Client because that infers that the x86/arm version is the Non-Portable Native Client. Damn right.
So what happens if I'm not x86-32, x86-64 or arm? What if I'm MIPS, running on a set-top box? What about Itanium? What about one of the lesser known architectures out there? Do I add support to NaCl, then ask every web developer in the world to recompile?
That's NOT how the web is supposed to work. This is an abomination of a web tech - it simply should not be promoted. Portable NaCl, fine, because architecture support means adding LLVM support, and doesn't require a recompile.
It's not like I have to recompile my HTML every time someone invents a new CPU.
The strategy they are referring to is a feature Motorola pioneered called 'e-fuse', the ability for the phone's CPU to stop working if it detects unauthorized software running.
Oh not this bullshit again. This was first published by an ill-informed "hacker" a while back and regurgitated by every blog in the world with no fact checking.
Here's what an e-fuse is: a write-once programmable bit.
Here's what they're typically used for: unique IDs (serial number), RAM repair (mark bad rows etc), feature selection, keys, miscellaneous factory config things.
Here's what you find with e-fuses in them: almost every CPU in the world, probably all of the SoCs used by Motorola's competitors, probably every SoC in every cell phone.
Here's what they're not used for: bricking devices.
Motorola has even stated very clearly that they never intend to completely brick a device if it detects an unauthorized ROM. It'll just need restoring. The SoCs Motorola uses are in no way pioneering e-fuses. Someone just read a gigantic amount of conspiracy into the tiniest of press release. This is OLD technology. Can this lie please go away?
Slightly less flippantly: Netwinder, empeg car, various prototype boards, various MP3 players. Just irks me that apparently this stuff is news to people.
Indeed - I've been using Debian on ARM devices for at least 12 years. I'm always amused when someone new comes along and assumes a big distro running on ARM is a new thing.
Slashdot Mirror
This is basic stuff to anyone who actually maintains a build, but Slashdot hasn't been a forum mostly populated by engineers for a number of years, now.
This appears to be due to link-time optimization blowing up the resident memory size of the linker, taking it past 3GB (which is already a non-standard hack the 32 bit build has had to do). Firefox is large, yes, but this has nothing to do with the final binary - which appears to be about 100MB total including all libraries in the Aurora builds.
I used to routinely run out of 32 bit address space compiling executables for a 64MB embedded ARM platform. This was due to symbol bloat, not executable size (which was 8MB). I also ran out of space compiling for a DSP with 288KB of RAM and 1MB flash, but that was mostly piss poor tools (Tasking). In fact, doesn't Chrome and even the Android sources already require building on a 64 bit host?
I don't have to explain:
Theora really can't even compete with MPEG-1 on either video quality at a given bitrate, or performance. It was very specifically designeed for extremely low quality, extremely low resolution, extremely low bitrate streaming video, over a decade ago...
This isn't true. There's plenty of results out there which say Theora is, while not the best, a good codec. To quote Wikipedia: More recently however, Xiph developers have compared the 1.1 Theora encoder to YouTube's H.264 and H.263+ encoders, in response to concerns raised in 2009 about Theora's inferior performance by Chris DiBona, a Google employee. They found the results from Theora to be nearly the same as YouTube's H.264 output, and much better than the H.263+ output.
There are plenty of people proclaiming that because it doesn't come out top, it's useless. Theora is far from useless: the results in any scenario that H.264 (even main profile) would be used, are still usable if you select Theora instead. They just aren't as pretty, because it's just not designed to the same constraints as H.264.
Becoming the HDTV standard would be an unrealistic goal. You attribute Theora not becoming the dominant standard due to Xiph's mishandling of the codec. The more obvious reason is politics: the MPEG group exists specifically to create audio/video standards which can be licensed. Broadcasters and content providers generally only use MPEG standards, and they just love licensing.
I'm interested to know what your theory is that Xiph could drive HDTV standards and have handled this better than a small company could?
The solution is obvious: allow installation of your own root certificate. This is supposed to be for security, not vendor lock-in. Without this option, I simply don't believe their intent.
Yes: Gmail (IMAP and SMTP), Google Chat (XMPP), etc. Try it out...do the DNS lookups yourself from different places.
So, it's only Google doing it?
FTP? Smtp? Distributed file shares? SQL server mirrors? NNTP? Ntp? I could probably list a dozen more.
Yes, that's a list of common internet protocols. I do not know of any example of anyone actually using geolocated DNS to CDN them. Do you have a concrete example?
Because it works, and there is more out there than just HTTP. This same approach will work for any protocol that uses DNS to resolve domain names.
Except that this is only used for HTTP. I do not know of any non-HTTP examples.
And here we have the real reason why this is being promoted:
3. And IMO most importantly, this removes the server selection choice from being under the sole control of the CDN provider. If this stuff is logic'd through the main HTTP page of the website, the CDN must expose its server selection strategy to the client, which is likely proprietary business knowledge.
It breaks DNS. It certainly breaks my local DNS installation, for starters. It also means that *everyone* must use this DNS hack because service will be degraded unless you do.
Messing with DNS is doing it the Wrong Way. All of these CDN services are based on HTTP. When you're using them, that's an HTTP server you're talking to. It's perfectly capable of geolocating you by IP, and it can either hand you back links to a local CDN, or redirect you to another server.
Why the hell must we mess with DNS to do this? This is a solution which only works if you use Google DNS, OpenDNS, or sometimes if you use your local ISP's DNS. What if you're just running bind for you local net vs the root servers? Bzzt. Doesn't work.
The most insane thing about this is it's Google we're talking about here. They damn well know how to implement this entirely in their servers without resorting to DNS hacks. Why are they promoting this net-neutrality breaking, layering violating botch? We need less people to use this, not more.
NaCl is not so much about executing C/C++ code as it is about executing native compiled binaries. This has issues:
It's incredible Google is even pushing this. It's so anti-portable and in concept anti-web.
There is a "portable" version of this, called "Portable Native Client". This means, of course, that NaCl is actually "Non-Portable Native Client" and that should itself be a clue. The "portable" version uses LLVM bitcode and a virtual machine. So more than a decade later, we've basically reinvented Java virtual machine applets minus the gigantic runtime (and language of your choice).
The only people who could possibly benefit from NaCl are Google. There's no general case use for this, and pushing it as standard into Chrome is a nasty move. Mozilla also reject the idea of NaCl. I believe Opera rejects it too (lacking a link). So, why is this being pushed?
This is all very irrelevant. The point is, it is technically not "Linux", it does not match what people would define as "Linux" (pre-Android) and it in no way is "Linux" other than just the kernel and some public-facing Google engineers who call it such. I didn't bring politics into this.
The same is true of Ubuntu and the Multiverse. You can CHOOSE to run pay software, the same as Android. I can run a commercial server daemon on pure, fully open Linux. Does that cease to be Linux? No.
It's a matter of what's meant by "Linux". Everyone used to mean "GNU/Linux" when they said simply "Linux". Android isn't GNU/Linux. There's no GNU in it - they stripped out what they could and rewrote from scratch what they couldn't. It's Apache/BSD/Linux.
So no, Android is not "Linux" by the definition of what everyone - before Android came along - would call Linux.
He didn't call it a linux desktop; he called it "the linux desktop dream come true"
It's not "Linux" as most people know it. There's a reason Richard Stallman was always bothered by people referring to the OS underlying Debian, Red Hat, Ubuntu and the countless other distributions as "Linux"; it ignores the fact that the vast majority of what makes it tick is the GNU userland.
Android does not have a GNU userland. In fact, they rewrote nearly all of it precisely to avoid it.
Android is an Apache/Linux desktop. It's only vaguely related to what everyone used to refer to as "Linux" or properly GNU/Linux.
Any contract lawyer would read over it and tell you what the holes are for a few hundred bucks. It's no big deal.
Since when is a few hundred bucks no big deal? For that matter, since when was it acceptable that a contract can only be understood by hiring a lawyer for a few hundred bucks? You're saying it yourself: the wording in the contract is so strangely constructed, that only a lawyer could understand it.
There's no reason NOT to go to a lawyer if you're considering signing something like this. It happens every day.
Well, apart from the several hundred bucks. If that happens every day, that's $50-100k a year, I guess. Good for the lawyers, bad for employees. The thing is, 364 days of the year you get a contract with normal termination clauses, but 1 of them has a dick clause. Do we pay a lawyer tax to insure ourselves against this, or do we assume that the courts will see it for what it is?
It just so happens that this guy decided to cut corners, got burned, and then whined about it publicly.
I fail to see how not spending a large sum on lawyers is cutting corners. People often don't use lawyers. it happens every day.
So, I guess you spend several hundred bucks on a lawyer every time you get a new job or receive stock or options?
It seems a large number of people here think that it is, though. Idiocy, or trolls. Do people really have so little sympathy? Contracts are intended to be a fair, bindings agreement between two parties. There are countless examples of unfair or weasel worded contracts failing in court, but apparently that would be news to some. What about loan sharks? What if someone snuck in a paragraph of mind bending legalize which amounted to "we can kill you"?
Oh, of course, they should have read the contract, and in case it was too confusing, they should have hired a really expensive lawyer to read it for them.
Bullshit. While I have diminished sympathy for Lee for not double and triple checking his termination clause, I do not have none. I also suspect, as pointed out in another comment here, that Skype should be liable for a lot of taxes by effectively buying back his options for nothing rather than their grant price. This probably still represents a net win for Skype, but at least then it's not "free" for them to exercise this clause.
In any case, it's still a particularly nasty thing for Skype to have done. Options generally have a "30 day" clause so you're not screwed in case of termination. This is supposed to add potential value to the options: you don't constantly run the risk of losing them all at the whim of the company. Skype effectively has a termination clause which takes away all your options any time they want. The difference is huge: I currently work on the assumption that my options are "safe" and I don't have to worry about them vs termination. My employer has written their options clauses to effectively say "we cannot be a dick - we are bound to allow you a grace period". Skype didn't. Their employees must treat options as directly bound to their employment, and if they're working under an "at will" contract, they can be gone in an instant. Skype took away a vast amount of value in their options due to the buy-back clause.
So yeah, OpenID is only as good as its providers, and it's been demonstrated to me that they can be pretty damn insecure, ergo, I'm avoiding using OpenID for now. Using it for everything makes the OpenID provider I picked a single point of failure. I hate having to use seperate accounts for everything but at least when something bad happens, it doesn't usually affect anything else.
I just think this is like stopping driving just because one manufacturer made an unsafe car. You may be prematurely missing out - and making other people miss out - on what's potentially a good solution to password proliferation.
Some time ago myOpenID.com lost all (or some portion) of their registered accounts (afaik this was due to Amazon's cloud trouble). Which was annoying because I used it for my stackexchange login. As it turns out, I could just recreate my login with the same name and voila I could use it to access my stackexchange account. That means if someone had created an account with my name before I did they'd have full access to my SE account.
These are problems with myOpenID not OpenID. You're mixing protocol and provider.
I never realised how potentially broken things could get with OpenID and I'm being a bit weary about ever using OpenID again, even though I suppose I should've been more careful about what OpenID provider I picked.
You even say it yourself: you should've been more careful picking an OpenID provider. In any case, what did you lose? Nothing. What could you potentially have lost? A login on StackExchange. Many people would love to only have that problem.
A good programmer would try to use as few resources as possible.
No, a good programmer recognizes premature optimization.
This article from the Ottawa Citizen [ottawacitizen.com] sums it up nicely. The Playbook is sleek and well designed. It supports Flash and QNX is the best mobile operating system available. The PB's smaller size makes it more portable and therefore more useful. It fits in my jacket pocket or my wife's purse. It is much lighter than carrying a laptop. Wifi is all I need at home or in a hotel room. The bridge to my Blackberry works well when wifi is not available.
And yet... if you asked a potential customer whether they'd buy this or an iPad 2, they're more likely to buy an iPad 2. This is what all the other companies haven't figured out yet: the age of winning on specs and back-of-the-box check marks is over. This just isn't a well executed product. You either understand this, or you scratch your head wondering why you can't sell, blaming some phantom "halo effect" or other nonsense.
Interestingly, each and every iPhone user is doing the same "crime" committed by Google,, but unintentionally (and no, this does not seem to collect packets).
No, Google's "crime" was logging actual packet contents transmitted on open networks. This is just a list of network IDs.
Blu-ray is *not* /clearly/ superior - most people honestly can't tell the difference. Even on my 42in HDTV, I can't tell the difference between Blu-Ray and DVD unless I pause to see the jaggies.
Seriously? You must have an eye medical condition or a bad prescription not to see the difference between Blu-Ray and DVD. Or you're watching footage which was originally shot in 480 or 576 line. The difference is absolutely clear for any reasonable length of side-by-side comparison viewing.
There was some study (done in Holland?) where they told people a picture was HD, then randomly showed them SD or HD; they couldn't tell the difference.
You may be referring to an over-the-air SD vs HD comparison, where over use of compression almost destroys any advantage to the increased resolution. Also, if you simply sit someone down, show them one random clip of SD or HD and ask which it was, it's a bit like asking someone "was that a light or dark shade of gray?" Or sitting them down, feeding them low quality or high quality chicken and asking which they ate. The study isn't concluding that SD vs HD isn't noticeable. It's concluding about how the eye isn't good at making a quality judgement without context. The same is true for many things: food quality, air quality, car acceleration, and so on. But you wouldn't argue that people should just settle for low quality food, air, and shitty cars. You can't apply the study conclusions to your argument.
There's plenty to good reasons why Blu-Ray doesn't have strong uptake, but not being clearly superior to DVD isn't one of them, because it clearly is superior.
Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.
Funny, I find any flavor of C immensely easier to develop responsive applications due to pointers and the lack of garbage collection. I get the impression I don't want to see your C code.
Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf [llvm.org] concerning that effort.
The LLVM version is the ONLY version which should exist. It's funny that the LLVM version is called Portable Native Client because that infers that the x86/arm version is the Non-Portable Native Client. Damn right.
So what happens if I'm not x86-32, x86-64 or arm? What if I'm MIPS, running on a set-top box? What about Itanium? What about one of the lesser known architectures out there? Do I add support to NaCl, then ask every web developer in the world to recompile?
That's NOT how the web is supposed to work. This is an abomination of a web tech - it simply should not be promoted. Portable NaCl, fine, because architecture support means adding LLVM support, and doesn't require a recompile.
It's not like I have to recompile my HTML every time someone invents a new CPU.
The strategy they are referring to is a feature Motorola pioneered called 'e-fuse', the ability for the phone's CPU to stop working if it detects unauthorized software running.
Oh not this bullshit again. This was first published by an ill-informed "hacker" a while back and regurgitated by every blog in the world with no fact checking.
Motorola has even stated very clearly that they never intend to completely brick a device if it detects an unauthorized ROM. It'll just need restoring. The SoCs Motorola uses are in no way pioneering e-fuses. Someone just read a gigantic amount of conspiracy into the tiniest of press release. This is OLD technology. Can this lie please go away?
If you don't mind could you please share more about your setup and what your user experience is compared to any other x86 systems you have? Thanks
This might help
Slightly less flippantly: Netwinder, empeg car, various prototype boards, various MP3 players. Just irks me that apparently this stuff is news to people.
Eh. Debian has fully supported ARM for years.
Indeed - I've been using Debian on ARM devices for at least 12 years. I'm always amused when someone new comes along and assumes a big distro running on ARM is a new thing.