Untrue. Modern Java (since 1.6, if not earlier) has nearly native performance on most platforms.
Android's "Java" problems are specific to DalvikVM inferior heap management strategy. Java 1.5 and newer does a VERY good job of dealing with mountains of short-lived objects that get promiscuously created, then discarded almost immediately. DalvikVM falls flat on its face, and ends up stalling to do garbage-collection.
Part of the blame lies with Android's strong (if not overwhelming) architectural preference for destroying and restarting activities, vs suspending them to swap. The truth is, Android handles long-lived processes VERY poorly... partly, because its preference for kill-and-relaunch has allowed them to sidestep the larger issue of managing resources with long-lived processes for several years now. That's the REAL reason why Gingerbread began actively killing even well-behaved background services that were running for "too long". Metaphorically, they were like a little old lady with a nice, neat house right smack in the middle of an urban block some developer wanted to bulldoze and redevelop with a skyscraper.
Sun had to grapple with the problem directly and solve it properly. When you have something like a web server written in Java that needs to be able to run for months without restarting, you MUST be able to hunt down insidious resource leaks, and keep them under control in the long term without being too disruptive at any moment in time. In contrast, Dalvik just ignores them until it runs out of space, then halts everything while it does garbage collection and moves things around.
This is actually one of the problems people who've experimented with adding support for swapfiles to Android have encountered. In order to make Android swap instead of kill, you have to modify its default behavior. The problem is, when you allow your Activities to live for hours or days instead of minutes, problems due to resource leaks that wouldn't get bad enough to notice start to become visible. As a practical matter, an Android phone with swapfiles forcibly enabled has to be rebooted at least once or twice a day, or the phone will start hanging to do garbage collection more and more often (defeating the point of having the swapfile in the first place).
There are basically four things that make Android laggy. The good news is that most of them can be overcome by user-modified firmware. The bad news is that manufacturers and Google are unlikely to ever fix them directly, because it would increase the manufacturing cost of phones by a few cents.
ONE: KILL-VS-SWAP
Android's normal behaviour is to aggressively kill activities and suspended background tasks, then respawn them from scratch when brought back into the foreground or reactivated. The LINUX (and Windows) norm is to simply quit giving them CPU cycles, stash their state into swap space on the hard drive, and resurrect them later.
One reason why this is done is because Android devices, while not necessarily STARVING for flash, don't have it in quite the abundance that a normal computer has hard drive space. There are also concerns about prematurely wearing out flash. The problem is that flash rewrite life estimates are based upon general use of the entire block of memory... but a swap partition gets created in a specific chunk of flash, and that one tiny chunk gets relentlessly hammered. If your erase-rewrite activity gets spread across the whole flash, it would usually take months of active efforts to be destructive before you really caused damage. However, if you create a 256mb swap partition and hammer it relentlessly, you can permanently damage it in a weekend. For this reason, few at XDA will advocate ever using internal flash for swap.
That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.
Making matters worse, the users in the best position to experiment with swap enhancements are Nexus owners. Unfortunately, Google has this near-religious aversion to microSD, and I don't think any Nexus device since the original Nexus One has shipped with a microSD slot. All that said, if you have a rooted and reflashed Android phone with class 6-10 microSD that has a swap partition and a custom ROM that uses it, you MIGHT see a big reduction in lag if you frequently run apps that have "expensive" startup costs (ie, apps that always begin by trying to make a http request to somewhere, or generate cryptographically-secure random numbers, etc).
TWO: DISDAIN FOR 2D GPU ACCELERATION
Historically, Android hasn't done a good job of putting 2D acceleration to good use ICS was a step forward, but you can't help but feel like the GPU support is more symbolic, half-assed, and buried under 400 abstraction layers that fritter away most of its potential. At least, for simple and straightforward "scroll and/or pan the viewport across a large virtual bitmap" type operations.
Compounding the problem is Android's architectural bias towards generating content on the fly, instead of generating humongous virtual bitmaps and keeping them available for instant viewport rendering.
THREE: ANDROID'S MEMORY-MANAGEMENT SUCKS
Building upon 2, and being completely blunt... Dalvik's memory-management totally fucking sucks compared to Java's. ESPECIALLY the way it handles short-lived objects that get repeatedly created in large numbers, and discarded almost immediately.
I dare anyone to disagree. Half the Android API bends over backwards to tiptoe around Android's shitty heap-management by trying to avoid creating and discarding objects for use as short-lived containers.
No, don't give me crap about mobile devices having limited resources compared to desktop computers. That's bullshit, and everyone knows it. Java mostly solved the worst of its memory-management problems around 1.5. Compare the specs of a high-end laptop circa ~2002 with the specs of a Galaxy S3, and arguments about Android devices being "severely resource limited" just kind of fall on the ground and thrash aroun
It's unfortunate, but lots of Americans get hung up on the name of China's governing political party, take it at face value, and blindly read cold-war Soviet memes into it that are about as relevant to modern China and accurately descriptive as "Leave it to Beaver" was to life in 1960s America.
Why would they fake something like that? Remember, if you're building a brand new building from the ground up, and you aren't terribly hung up on maintaining official certifications, single-mode fiber is cheaper per foot than Home Depot-quality cat6 cable (copper is shockingly expensive now). Fiber doesn't really get expensive (in new construction) until you actually go to TERMINATE it... and that's an expense you can defer until the day you really *have* to.
As for the great firewall and duopoly, both are strikes against its usefulness... but on the other hand, I think it's safe to say that the fiber will probably be around longer than the politics and duopoly will. At least when a more competitive business environment arrives in China, they'll have the fiber in place and ready to go. We'll probably still have... AT&T and Verizon, both trying their hardest to abandon more wired infrastructure than the other, while using their lawyers and lobbyists to ensure that their abandoned right of ways remain that way forever.
Re: cable and sat don't have the bandwidth for it
on
The Trouble With 4K TV
·
· Score: 1
^^^ By the way, just in case anybody thinks I'm smoking crack when I say a broadcast-quality camera with "NTSC" resolution could capture text readable on a studio monitor that a nominally-1080i60 camera would turn into a blurry unreadable mess, there IS actually a sound engineering explanation... the bandwidth of clean 640/704x480/525 video with deep, saturated colors, and 8-bit luminance that allows pure white next to pure black on alternating pixels is approximately 16MHz. For comparison, the bandwidth necessary to display ATSC-resolution 1080i60 with 4:1:1 color (ie, each scanline conveys 1920 luminance pixels, with red and blue difference signals spread out across a 2x2 block) is roughly 38Mhz -- slightly more than double the bandwidth needed for NTSC/VGA resolution.
So... in theory... 1080i60 might be conveying twice the detail of in-studio NTSC-resolution RGB video, but it doesn't take a rocket scientist to see how butchering and cutting corners at the 1080i60 end could leave you with a cheap HD camera that actually captures less hard detail than a super-premium camera capturing uncompromised NTSC-resolution high-bandwidth interlaced video. Obviously, even the most pristine NTSC broadcast video is going to look like complete shit compared to the worst and most compromised 1080i60 (assuming it's not dropping frames/fields or stuttering).
> Can anyone remind me as to why gambling is illegal?
To ensure a never-ending supply of new daytraders to supply Wall Street's liquidity needs?
Re: cable and sat don't have the bandwidth for it
on
The Trouble With 4K TV
·
· Score: 1
They do it, and it's a genuine improvement over bob/weave artifacts. They just don't put it as bluntly as I did.
People have short memories. We've gotten SO used to video processors that turn 1080i60 into de-facto 1080p30 while deinterlacing, and 720p60 content that was really shot on 720p30 or 1080p30 cameras, that we've mostly forgotten what real 60fps video is even supposed to LOOK like.
None of the processors derive or interpolate more than a single frame. 240hz synthesizes 48fps from 24fps, and shows each frame 5 times. Some processors might try to synth 120 fields out of 60, but most just silently emulate a CRT to turn 1080i60 into good-looking 1080p60, and turn 720p30 (30fps ccd, encoded as 60fps by camera) into single-interpolated 720p60.
Don't believe me? Check out the prices of a camcorder that outputs real honest-to-god 1280x720 24-48 bit RGB video at 60fps. Why are they so much more than cameras that output h.264-encoded "720p60"? Because you can't fool mother nature, and you can't fudge image sensor or video processor specs with such a camera. If you literally want a real 60fps HD video source, you're going to pay *dearly* for it, even today. Lots of cameras fudge and fake 720p60, but few output a 60fps stream of real, honest-to-god high-quality 1280x720 JPEG-like images. Many have a "real" luma horizontal resolution of 640 or 960. Some have 720 or 1080-line sensors, but only have the internal bus bandwidth to read half of them in any 1/60-sec interval. Compressed video has enabled the industry to sell products with specs that are SO MISLEADING, in almost any other industry they'd be considered *fraud*.
If you want the ugly truth, read the datasheets of the image sensors & codec ASICs... and check out the blogs of guys trying to build open-source HD hardware... they've seen the unvarnished real specs of real-world hd chips & sensors... and the specs aren't pretty. Most started out trying to build things like a real 720p60 or 1080p60 camera, and discovered along the way that the components in consumer gear can't even *dream* of doing half the things they're marketed as being capable of. That's why most prosumer-grade "1080p" camcorders can't shoot readable text that even a broadcast-quality NTSC camera could show readably on studio monitors 20 years ago.
Look at it this way... the TV/satellite/cable industry has compressed 720p60 and 1080i60 to a degree that makes lots of us want to just cry. With a little luck, even criminally-compressed 4k TV will have the detail we SHOULD be getting NOW from 19.2mbps 720p60, but aren't.
Tip: for anybody who has older TVs still in use, try using them with the s-video output of a HD box instead of using them with a normal SD box. Instead of blocky, ugly, overcompressed SD video, you can enjoy downsampled HD video that's basically DVD quality. It's a neat trick I learned back in the days of Voom that spoiled me permanently, even after Voom itself went bye-bye.
Re: cable and sat don't have the bandwidth for it
on
The Trouble With 4K TV
·
· Score: 1
> Well when 1080p was first standardized (which is where 4k is right now) they didn't have the bandwidth for that either.
Actually, that's not *quite* true. 19.2mbps has plenty of bandwidth to do true 1080p60 -- you just can't do the compression in realtime, and you need more ram so you can use variable bitrate, longer GOPs, and more B-frames. In fact, Microsoft released a ton of demos around 2004 to prove that it's totally possible to do 1080p60 at DVD bitrates (~8mbps... HALF of what ATSC allows) using their VC-1 codec. Admittedly, MPEG-2 is nowhere close to VC-1 when it comes to compression ratio, but if you increase your bitrate budget to 18-19.2mbps, even MPEG-2 1080p60 is do-able.
Re: cable and sat don't have the bandwidth for it
on
The Trouble With 4K TV
·
· Score: 1
> Show me an interlaced digital display. Seriously. Show me one.
Actually, that's precisely what 120hz and 240hz TVs *do*. They use the higher framerate to simulate the way scanlines faded on a real CRT. Among other things, but that's the big thing you get from 120hz or 240hz -- you can watch 1080i60 video without it being completely ugly and ruined by bob/weave artifacts.
I have a 2008 SportTrac with Ford's first-generation (AFAIK) SYNC. It's kind of nice, but OMG it gets paternalistic and annoying sometimes. They've been talking about releasing a SDK for Sync since... late 2008. I'll believe they're ever going to allow thirdparty apps when I personally see it.
Now, if you'll excuse me, I'm going to go back to using my nice, rooted Android phone with a native app I'm working on that fools SYNC into thinking the fake bluetooth media player it's spoofing isn't actually a custom interface for Sync'ified Android apps that recognize track up/down and 'ok' as command buttons their own right -- completely bypassing SYNC and its annoying restrictions, and using it as little more than a handy embedded bluetooth audio + control interface for my phone.
> is that so? Just how did the country function before 1940?
J.P. Morgan personally bankrolled it... and enjoyed almost inconceivable power & influence over US policy as a direct result. Few individuals in history have ever personally had the power to effectively (if temporarily) bankrupt the US Federal Government on a whim or grudge. JP Morgan was one of them.
> The US dollar is now worth roughly 2% of what it was 80 years ago
Name one major currency that's held substantially more value over the same period. There isn't one. Swiss Franc? Nope. British Pound? L0L. Japanese Yen? You must be joking. Soviet Ruble? Poof. Literally, up in smoke.
Not even GOLD has the same purchasing power it did 80 years ago -- the supply is basically finite with respect to the number of Au atoms within 10,000 miles of the Earth's core, but the percentage of it in circulation since the dawn of human history is relatively low, new gold continues to be mined, and the annual rate of increase is higher than ever (with the possible exception of Spain's first few years of looting the Inca empire, and that was more a matter of bringing gold into circulation within the European money system than increasing the amount of gold per se).
> People who hold the debt of the US are being cheated.
And yet, the world's wealthiest investors continue to purchase record amounts despite an interest rate approaching zero. Compared to the historic volatility of other currencies, US debt is a valuable investment, if only because US Treasury Notes are cheaper and less-risky than physically acquiring paper money and storing it in a vault somewhere. US debt is valuable, because it eventually translates into spendable US Dollars, which are the most liquid currency on Earth.
The US Dollar's value doesn't come from anything that "backs" it, and the availability of US-made goods is almost a secondary consideration. The fact is, if you have a suitcase full of US Dollars, you can spend them on just about anything -- big or small, legal or illegal -- anywhere on Earth. You can use them to buy electronic goods, and you can stuff them into G-strings in an Asian titty bar, and the recipient can turn around and use them to pay the rent, regardless of what the local currency might actually be. Other currencies come close, but no currency has ever been more universally liquid in more places for more things.
> You would think that a packet specifying X seconds of simulated silence could be packed into a few bits, > so maybe two bytes should suffice.
You're confusing media-encoding with telephony. Media encoding occurs in non-realtime, so you can analyze a big chunk of data and plan ahead for both silence and bursts. Telephony is realtime. The more you delay the audio for analysis, the more annoying it becomes to the people having the conversation. With realtime telephony, you don't HAVE "X seconds" to buffer and delay transmission so you can analyze a chunk of audio that long.
The supreme irony of video compression is that you can compress pristine HD video down to 320x480 60 field/second VHS-quality with 4:0:0 chroma subsampling and end up with an average bitrate that's barely more than what you'd need for uncompressed (or maybe realtime-compressed, with max. 1ms added latency) audiophile-quality surround sound. Why? Surround sound SEVERELY limits what you can throw away in realtime (it uses phase relationships to encode side/rear/sub channels, which are one of the first things codecs like GSM's throw away and dispense with), and if you're compressing pristine noise-free video using DVD-noncompliant (but usually works anyway) outrageously long GOPs, B-frames, multipass variable-bitrate encoding, and aggressive huffman compression, you can pack the video down to almost nothing -- especially if you're willing to accept a little blockiness.
Shhhh. You're forgetting that the people who really dig IPv6 get TOTALLY bent out of shape about home routers in any form.
IMHO, the nearly-religious hatred its advocates have towards NAT and routers is one of the biggest things holding IPv6 back. If they'd just humor people who want to set up an internal network with private IPv6 addresses and NAT it through their router somehow instead of trying to beat them into submission and force them to abandon their shameful backwards ways, we'd be a lot closer to having IPv6 in widespread deployment today.
The problem is, they're absolutely HELLBENT on abolishing the handy devices we mostly abuse as ghetto-fabulous firewalls. From the way they talk about routers, you'd think they cost thousands of dollars and make the internet unusable, instead of being something that most people either get for free or pay less than $50 for... maybe $150-250 if they're high-end users who want one that's hackable and can be flashed with custom firmware.
The same trick routers do to allow a dozen devices to share one public IPv4 address could transparently map public IPv6 addresses to devices who identify themselves by internal 192.168.x.x or 10.x.x.x addresses. Better, in fact, because every IPv6 address mapped to an internal IPv4 address by the user's router could enjoy the equivalent of "DMZ" mode port forwarding. Give the same user a public IPv4 address (or at least a fixed range of ports from one, a-la RFC 6346), and every IPv4-only device sitting behind his router can be made fully-accessible to the outside world via both IPv4 and IPv6.
For IPv6-native devices, it's even better. They can have their public IPv6 address, but let the router assign them a phantom 192.168.x.x address, and DMZ-forward all of its ports to their IPv6 address. Create an additional router forwarding rule forwarding port xxxx of the public IPv4 address to port yyyy of the phantom 192.168.x.x address that can be chained with the rule forwarding all of 192.168.x.x's traffic to the device's IPv6 address, and you have an IPv6 device that can be easily reached by IPv4 devices on the other side of the router, too, just like NAT'ed IPv4 devices can be. The bonus is that if IPv6 is talking to IPv6, they can drop the act and communicate directly.
The people who hate routers forget that they're a wonderful way to allow end users to embrace IPv6 at THEIR OWN pace, in ways under THEIR DIRECT control, instead of dictated by their ISP or someone else's timetable -- usually, in ways that will break expensive legacy hardware that will never work natively under IPv6.
Routers aren't going away. If anything, 10-20 years from now, we'll have legacy devices connected to the rest of the LAN through a $10 POE-powered adapter from China that sits inline between the device and the rest of the network, and acts like a single-port DMZ-forwarding NAT router dedicated to just one device. A box that lets your IPv4-only device be a:b:c:d:e:f:g:h to the rest of the world, while thinking of itself as 192.168.1.1 and never knowing the difference.
The problem's root is the blind faith Eclipse has in its own metadata and virtual filesystem, and its determination to blindly go by it even when it contradicts the real-world filesystem's state. Apparently, Google blames Eclipse, the Eclipse team blames Google, it's probably at least partly the fault of both, and nobody has any idea how to fix the underlying problem.
A related problem is when Eclipse/ADT corrupts the library info, and Jarfiles you added to the classpath suddenly get ignored. The only way to fix it is to add some unrelated jarfile to the build path (to force Eclipse to regenerate the metadata) & remove it again after cleaning & building.
As for version control, I believe at least one known cause project-corruption ~2 years ago was due to a bug in one of the Subversion connectors (or maybe it was EGit)... basically, it was auto-adding a metadata file to the repo & confusing Eclipse by corrupting it with metadata from a different workspace on another computer.
Yep. To load a game, at the *bare* minimum, you had to hop over at least one trivial speedbump that somehow managed to stump lots of supposedly "normal" kids:
load "*",8,1
God knows, it took my brother almost TWO YEARS to finally get the hang of it. He now owns a Mac. Surprise, surprise...;-)
Fast forward ~10 years to 1993... and try explaining the concept of an IRQ, a cascaded IRQ, and reconciling conflicts between a piece of shit internal modem that only supported IRQ 2, 3, and 4 & a malfunctioning soundcard camped out on IRQ 9... to that same tech-challenged brother (hint, for anyone who didn't instantly get the punchline... the modem was set to IRQ 2)
Today's kids are no dumber than the kids we went to school with. The difference is, 25 years ago, today's clueless kids wouldn't have owned a computer at all, and if WE were 13 again, we'd spend summer vacation building Arduino LED cubes (or if we were in college, we'd be building circuits with FPGAs).
Kids who are like we were still exist, they're just lost amidst the background noise of stupid kids with toys they think work by magic.
> Why? Since when do app developers typically need to "modify, adapt, redistribute, decompile, > reverse engineer, disassemble, or create derivative works of the SDK"?
To fix annoying bugs that have been around for eternity, and Google seems to have no interest in fixing? Like, you know, the nice one that occasionally induces Eclipse to transpose the cursor and semicolon at the end of a line of code, so you'll type semicolon, hit return, then end up swearing violently because the goddamn IDE (acting at the behest of ADT, since Android Isn't Java(tm), and as far as Eclipse is concerned, it's dealing with a C++ preprocessor) decided to enter the semicolon, then reposition the cursor to be RIGHT BEFORE IT immediately afterward.
Or the way, once or twice a year, Eclipse just goes senile and forgets how to build Android projects, and the only way to fix it is to create a brand new project and reimport everything into it by hand?
Or those times when Eclipse refuses to compile an Android file because it thinks there's a bug that isn't there, and the squiggly-line bug won't go away unless you select the source code, cut it into the clipboard, save the emptied-out file, paste the source back into the file, and save it again?
These are all bugs that have plagued ADT since the beginning, spawned hundreds of entries over at StackOverflow... and whose developer cries have largely fallen upon deaf ears over in Mountain View, for reasons nobody can really discern or explain.
1/25th might be more "in the spirit" of the metric system, but it wouldn't have been any real improvement over 1/25.4th. The whole point of 1/24 is that 24 can be neatly and cleanly divided by 2, 3, 4, 6, 8, and 12. In contrast, 25 can be cleanly divided by... er... 5. Probably better than 25.4, but not really enough to have been worth the lobbying effort.
Ultimately, the metric system and Java both share the same fundamental design flaw -- they both do pedantic, annoying things for the sake of blind consistency with some abstract rule that was conceived mostly in a vacuum devoid of real-world considerations. 2 liters and 1/2 liter are handy sizes commonly seen in stores. 1 liter bottles of anything are unloved orphans -- too big for one serving, but not big enough for the leftovers to even be worth saving. Unsigned 8-bit values are the foundation of modern computing. Java uses signed bytes just to be consistent with int and long, and any attempt to deal directly with 8-bit values in Java ends up being ungodly painful and tedious as a result.
If Shuttleworth wants to make a REAL difference in the future of mobile Linux, he needs to come up with a way to allow loadable kernel modules built for older kernels to keep working with newer ones. God knows, Google's never going to do it. It's an old, tired story by now in Android-land... every new version of Android needs a new kernel, every new kernel catastrophically breaks every loadable kernel module that came before it, and most manufacturers are in no hurry whatsoever to release newer kernel modules for existing phones... assuming they ever do. It's a problem that bites Android over and over again, year after painful year, and it's going to hurt Ubuntu even WORSE because it will initially be forced to live with Android's crumbs and hardware cast-offs.
For God's fsck'ing sake, a couple of years ago, people were using NDISwrapper to run binary wifi drivers intended for WINDOWS NT under Linux. Is it REALLY that impossible to allow end users to wrap binary kernel modules for things like the camera, GPS, 4G modem, or whatever in some kind of thin thunking layer so they can at least limp along when the next kernel comes out, even if the manufacturer is an asshole and takes months (or eternity) to release newer drivers? If we can thunk binaries built for A TOTALLY DIFFERENT OPERATING SYSTEM into working, is it REALLY that hard to pull a similar trick with binaries that were built for Linux in the first place?
It's a nice idea, but the Chinese hardware market is kind of weird compared to the rest of the world.
In America, companies like Qualcomm release chips whose precise capabilities and documentation are kept under lock and key, and it's nearly impossible for anybody outside of a small, handpicked group of companies to actually get their hands on a chip that wasn't harvested from a device... but customers deemed worthy by the chipmaker pretty much get to know whatever they want to learn about.
In China, the companies who make the ASICs needed to build phones and tablets will pretty much sell them to anyone (or at least sell them to distributors, who can sell them to anyone with the chipmaker's full blessing). They'll also make the chips' public documentation freely-available to anyone and everyone. The catch is, there isn't much actual information IN that public documentation. The expectation is that you, as the owner of a small factory, will buy their chips, assemble them into a device following one of their reference designs, download the necessary firmware binaries, burn them more or less verbatim onto the devices, and get started on the chipmaker's next-generation design a couple of months later.
In other words, China is a relatively easy place for small (compared to Samsung, Sony, and Motorola) companies to manufacture sophisticated electronic devices with minimal ceremony, but it's a very HARD place to take those devices to the next level, and make them anything besides bland, generic, commodity knock-off copies of the chipmaker's reference design. That's why Chinese companies work so hard to make their devices LOOK GOOD, with attractive cases and packaging... it's one of the few things within their direct ability to control.
Put another way, if Shuttleworth wants totally open phones, he's going to have to get really, REALLY friendly with companies like Rockchip. Otherwise, he's going to have to settle for Ubuntu running on phones that are no more open than most Android phones are today (ie, not necessarily locked down per se, but often are more de-facto black boxes than even Windows Mobile phones used to be back when XDA got started).
Chinese phones might not be intentionally locked down, but most Chinese Android hardware has no meaningful chip-level documentation to speak of. Some Chinese Android devices don't even have fully-implemented ADB support.
Many of them are built around chips that are epoxied-over blobs on the circuit board with no real markings (in English, Chinese, or any other language), and most of THOSE chips have no lifecycle to speak of... the ASIC manufacturer churns out 10-100 million of them, makes changes, churns out 10-100 million of the modified chip, makes changes, churns out 10-100 million of the modified modified chip, and the cycle repeats itself. Go google the misery some Americans trying to document the workings of Rockchip-based Android tablets have gone through.
Put another way, the biggest problem with the Chinese chips is that by the time anybody starts to figure out how they work and release documentation, they've already been obsolete for one or two generations. And sometimes, if someone in the supply chain gets a good deal on a few pallets of old chips, they might randomly show up in a new phone... but by the time anyone figures it out, those phones will be gone, replaced by a different model that looks identical in photos, but is built around totally different hardware. It's just like everything else that gets sold in China... it's easy to buy something that's pretty, cheap, and probably works, but it's VERY hard to buy a consumer item with specific specs and parts that are guaranteed to be some specific model, let alone stepping. Even if you buy one, crack it open, examine it with a microscope, and confirm that it has what you want, there's at least 50-50 odds that the one in the box in the pile next to it came from a different pallet, and is likely to differ in meaningful ways from what you're hoping it is. And more often than not, "cracking it open" is literal rather than figurative... these are devices aren't meant to be kept more than a few months, let alone repaired or serviced.
Now, having said that... there are perfectly good, well-built products from China too. Unfortunately, most of them have the same closed specs and restrictions that their American and European counterparts do. Pick your poison -- a phone guaranteed to have a specific model and stepping of a specific Qualcomm chipset whose datasheets are a closely-guarded trade secret, or a nominally-open phone with no documentation to speak of that will be moot, obsolete, and quite possibly broken & nonworking by the time anyone figures out how to hack it.
UbuntuPhone is technically a parasite on Android (because it depends on Android's make-believe-open hardware to make it past the gatekeepers doing their best to control American mobile networks), but it's likely to end up as a symbiotic relationship. My guess is that if Ubuntu Phone is viable 5 years from now, it'll basically be a native-code framework that wraps Android. Your 'launcher' app will be native "Ubuntu", but you'll have at least one instance of DalvikVM spawned and running in the background on one or more cores, and 97% of the apps running on an "Ubuntu" phone will be Android anyway.
It might even be a good thing for both Google AND Canonical. Google still gets politely ignored by Qualcomm (mostly because Qualcomm owns enough IP to make it nearly impossible to build a CDMA phone that can legally be sold in the US without using their chips, so Google's threats to take Motorola's business elsewhere ring hollow), but Canonical has one strength that Google has kind of been teetering a bit at lately... it still has a dominant CEO who's a kind of a loose cannon. Google hasn't been pwn3d by Wall Street, but they're big enough now that they have to at least go through the motions of pretending they care what institutional investors want. Shuttleworth can still openly say and do things that would get Google hauled in front of the SEC, FTC, and/or Congress for corporate blasphemy.
What I want to know is why BBC American can't just leave their shows at 50fps, and deliver content as 1080i50 and 720p50? Modern HDTVs, even American ones, can display 1080i50 and 720p50 just fine over HDMI. IMHO, 50-60hz temporal rate conversion is pointless when the TVs can deal with the native framerate anyway. It's like the fetish web designers had around 1996 of pre-converting images into ugly dithered web-safe colors, instead of just letting the browser deal with it when necessary. Leave 50 as 50 and 60 as 60, and let the TV sort it out the way God and Engineers intended.
^^^ Exactly. Capacitive is ok for blunt selections, but are pure agony for precise selection. Personally, I used to solve both problems by slightly shaping my right index finger into a subtle, blunt point so it worked nicely as an adhoc stylus.
OK, I'll be honest... I'm a hardcore Graffiti user, and the official version for Android seems to be getting worse and worse by the year... partly due to apps that try to do Ajax lookups after each stroke, partly due to over-aggressive CPU governors that treat the appearance of a soft input area as an excuse to drop the speed down to 200mhz, and partly because it has no way to disable foreign accented letters & it's over-eager to recognize carriage returns. It pisses me off that a slow 16mhz Dragonball could achieve 99.9% accuracy, but my 1.5ghz quadcore s3 can't tell the fscking difference between 'm' and 'e' (written as backwards '3'), or between 'o' and 'g' (written as letterside-6). Actually, it almost feels like they recently re-weighted it towards Graffiti-2, because its worst recognition seems to be with the true single-stroke variants... which, of course, are the ones I use. Sigh.
I swear, I'm going to gut an old Palm III and transplant the Dragonball & Graffiti-pad to a hacked-up case and interface it to my Android phone via USB-OTG or bluetooth. Or make my own homebrew input method consisting of a M68k emulator running original assembly-language Graffiti ripped from a Palm III rom. I generally love my Galaxy S3, but its Graffiti error rate is TERRIBLE compared to older versions on my older phones. My creaky old HeroC overclocked to 711mhz has butter-smooth and accurate Graffiti... my S3 has me swearing in frustration trying to type the exact same text, and my old Photon & Epic4g aren't much better. I almost think multitouch capacitive controllers are partly to blame, because Graffiti's ability to work seems to be inversely related to touchscreen sophistication...:-(
Slashdot Mirror
Untrue. Modern Java (since 1.6, if not earlier) has nearly native performance on most platforms.
Android's "Java" problems are specific to DalvikVM inferior heap management strategy. Java 1.5 and newer does a VERY good job of dealing with mountains of short-lived objects that get promiscuously created, then discarded almost immediately. DalvikVM falls flat on its face, and ends up stalling to do garbage-collection.
Part of the blame lies with Android's strong (if not overwhelming) architectural preference for destroying and restarting activities, vs suspending them to swap. The truth is, Android handles long-lived processes VERY poorly... partly, because its preference for kill-and-relaunch has allowed them to sidestep the larger issue of managing resources with long-lived processes for several years now. That's the REAL reason why Gingerbread began actively killing even well-behaved background services that were running for "too long". Metaphorically, they were like a little old lady with a nice, neat house right smack in the middle of an urban block some developer wanted to bulldoze and redevelop with a skyscraper.
Sun had to grapple with the problem directly and solve it properly. When you have something like a web server written in Java that needs to be able to run for months without restarting, you MUST be able to hunt down insidious resource leaks, and keep them under control in the long term without being too disruptive at any moment in time. In contrast, Dalvik just ignores them until it runs out of space, then halts everything while it does garbage collection and moves things around.
This is actually one of the problems people who've experimented with adding support for swapfiles to Android have encountered. In order to make Android swap instead of kill, you have to modify its default behavior. The problem is, when you allow your Activities to live for hours or days instead of minutes, problems due to resource leaks that wouldn't get bad enough to notice start to become visible. As a practical matter, an Android phone with swapfiles forcibly enabled has to be rebooted at least once or twice a day, or the phone will start hanging to do garbage collection more and more often (defeating the point of having the swapfile in the first place).
There are basically four things that make Android laggy. The good news is that most of them can be overcome by user-modified firmware. The bad news is that manufacturers and Google are unlikely to ever fix them directly, because it would increase the manufacturing cost of phones by a few cents.
ONE: KILL-VS-SWAP
Android's normal behaviour is to aggressively kill activities and suspended background tasks, then respawn them from scratch when brought back into the foreground or reactivated. The LINUX (and Windows) norm is to simply quit giving them CPU cycles, stash their state into swap space on the hard drive, and resurrect them later.
One reason why this is done is because Android devices, while not necessarily STARVING for flash, don't have it in quite the abundance that a normal computer has hard drive space. There are also concerns about prematurely wearing out flash. The problem is that flash rewrite life estimates are based upon general use of the entire block of memory... but a swap partition gets created in a specific chunk of flash, and that one tiny chunk gets relentlessly hammered. If your erase-rewrite activity gets spread across the whole flash, it would usually take months of active efforts to be destructive before you really caused damage. However, if you create a 256mb swap partition and hammer it relentlessly, you can permanently damage it in a weekend. For this reason, few at XDA will advocate ever using internal flash for swap.
That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.
Making matters worse, the users in the best position to experiment with swap enhancements are Nexus owners. Unfortunately, Google has this near-religious aversion to microSD, and I don't think any Nexus device since the original Nexus One has shipped with a microSD slot. All that said, if you have a rooted and reflashed Android phone with class 6-10 microSD that has a swap partition and a custom ROM that uses it, you MIGHT see a big reduction in lag if you frequently run apps that have "expensive" startup costs (ie, apps that always begin by trying to make a http request to somewhere, or generate cryptographically-secure random numbers, etc).
TWO: DISDAIN FOR 2D GPU ACCELERATION
Historically, Android hasn't done a good job of putting 2D acceleration to good use ICS was a step forward, but you can't help but feel like the GPU support is more symbolic, half-assed, and buried under 400 abstraction layers that fritter away most of its potential. At least, for simple and straightforward "scroll and/or pan the viewport across a large virtual bitmap" type operations.
Compounding the problem is Android's architectural bias towards generating content on the fly, instead of generating humongous virtual bitmaps and keeping them available for instant viewport rendering.
THREE: ANDROID'S MEMORY-MANAGEMENT SUCKS
Building upon 2, and being completely blunt... Dalvik's memory-management totally fucking sucks compared to Java's. ESPECIALLY the way it handles short-lived objects that get repeatedly created in large numbers, and discarded almost immediately.
I dare anyone to disagree. Half the Android API bends over backwards to tiptoe around Android's shitty heap-management by trying to avoid creating and discarding objects for use as short-lived containers.
No, don't give me crap about mobile devices having limited resources compared to desktop computers. That's bullshit, and everyone knows it. Java mostly solved the worst of its memory-management problems around 1.5. Compare the specs of a high-end laptop circa ~2002 with the specs of a Galaxy S3, and arguments about Android devices being "severely resource limited" just kind of fall on the ground and thrash aroun
It's unfortunate, but lots of Americans get hung up on the name of China's governing political party, take it at face value, and blindly read cold-war Soviet memes into it that are about as relevant to modern China and accurately descriptive as "Leave it to Beaver" was to life in 1960s America.
Why would they fake something like that? Remember, if you're building a brand new building from the ground up, and you aren't terribly hung up on maintaining official certifications, single-mode fiber is cheaper per foot than Home Depot-quality cat6 cable (copper is shockingly expensive now). Fiber doesn't really get expensive (in new construction) until you actually go to TERMINATE it... and that's an expense you can defer until the day you really *have* to.
As for the great firewall and duopoly, both are strikes against its usefulness... but on the other hand, I think it's safe to say that the fiber will probably be around longer than the politics and duopoly will. At least when a more competitive business environment arrives in China, they'll have the fiber in place and ready to go. We'll probably still have... AT&T and Verizon, both trying their hardest to abandon more wired infrastructure than the other, while using their lawyers and lobbyists to ensure that their abandoned right of ways remain that way forever.
^^^ By the way, just in case anybody thinks I'm smoking crack when I say a broadcast-quality camera with "NTSC" resolution could capture text readable on a studio monitor that a nominally-1080i60 camera would turn into a blurry unreadable mess, there IS actually a sound engineering explanation... the bandwidth of clean 640/704x480/525 video with deep, saturated colors, and 8-bit luminance that allows pure white next to pure black on alternating pixels is approximately 16MHz. For comparison, the bandwidth necessary to display ATSC-resolution 1080i60 with 4:1:1 color (ie, each scanline conveys 1920 luminance pixels, with red and blue difference signals spread out across a 2x2 block) is roughly 38Mhz -- slightly more than double the bandwidth needed for NTSC/VGA resolution.
So... in theory... 1080i60 might be conveying twice the detail of in-studio NTSC-resolution RGB video, but it doesn't take a rocket scientist to see how butchering and cutting corners at the 1080i60 end could leave you with a cheap HD camera that actually captures less hard detail than a super-premium camera capturing uncompromised NTSC-resolution high-bandwidth interlaced video. Obviously, even the most pristine NTSC broadcast video is going to look like complete shit compared to the worst and most compromised 1080i60 (assuming it's not dropping frames/fields or stuttering).
> Can anyone remind me as to why gambling is illegal?
To ensure a never-ending supply of new daytraders to supply Wall Street's liquidity needs?
They do it, and it's a genuine improvement over bob/weave artifacts. They just don't put it as bluntly as I did.
People have short memories. We've gotten SO used to video processors that turn 1080i60 into de-facto 1080p30 while deinterlacing, and 720p60 content that was really shot on 720p30 or 1080p30 cameras, that we've mostly forgotten what real 60fps video is even supposed to LOOK like.
None of the processors derive or interpolate more than a single frame. 240hz synthesizes 48fps from 24fps, and shows each frame 5 times. Some processors might try to synth 120 fields out of 60, but most just silently emulate a CRT to turn 1080i60 into good-looking 1080p60, and turn 720p30 (30fps ccd, encoded as 60fps by camera) into single-interpolated 720p60.
Don't believe me? Check out the prices of a camcorder that outputs real honest-to-god 1280x720 24-48 bit RGB video at 60fps. Why are they so much more than cameras that output h.264-encoded "720p60"? Because you can't fool mother nature, and you can't fudge image sensor or video processor specs with such a camera. If you literally want a real 60fps HD video source, you're going to pay *dearly* for it, even today. Lots of cameras fudge and fake 720p60, but few output a 60fps stream of real, honest-to-god high-quality 1280x720 JPEG-like images. Many have a "real" luma horizontal resolution of 640 or 960. Some have 720 or 1080-line sensors, but only have the internal bus bandwidth to read half of them in any 1/60-sec interval. Compressed video has enabled the industry to sell products with specs that are SO MISLEADING, in almost any other industry they'd be considered *fraud*.
If you want the ugly truth, read the datasheets of the image sensors & codec ASICs... and check out the blogs of guys trying to build open-source HD hardware... they've seen the unvarnished real specs of real-world hd chips & sensors... and the specs aren't pretty. Most started out trying to build things like a real 720p60 or 1080p60 camera, and discovered along the way that the components in consumer gear can't even *dream* of doing half the things they're marketed as being capable of. That's why most prosumer-grade "1080p" camcorders can't shoot readable text that even a broadcast-quality NTSC camera could show readably on studio monitors 20 years ago.
Look at it this way... the TV/satellite/cable industry has compressed 720p60 and 1080i60 to a degree that makes lots of us want to just cry. With a little luck, even criminally-compressed 4k TV will have the detail we SHOULD be getting NOW from 19.2mbps 720p60, but aren't.
Tip: for anybody who has older TVs still in use, try using them with the s-video output of a HD box instead of using them with a normal SD box. Instead of blocky, ugly, overcompressed SD video, you can enjoy downsampled HD video that's basically DVD quality. It's a neat trick I learned back in the days of Voom that spoiled me permanently, even after Voom itself went bye-bye.
> Well when 1080p was first standardized (which is where 4k is right now) they didn't have the bandwidth for that either.
Actually, that's not *quite* true. 19.2mbps has plenty of bandwidth to do true 1080p60 -- you just can't do the compression in realtime, and you need more ram so you can use variable bitrate, longer GOPs, and more B-frames. In fact, Microsoft released a ton of demos around 2004 to prove that it's totally possible to do 1080p60 at DVD bitrates (~8mbps... HALF of what ATSC allows) using their VC-1 codec. Admittedly, MPEG-2 is nowhere close to VC-1 when it comes to compression ratio, but if you increase your bitrate budget to 18-19.2mbps, even MPEG-2 1080p60 is do-able.
> Show me an interlaced digital display. Seriously. Show me one.
Actually, that's precisely what 120hz and 240hz TVs *do*. They use the higher framerate to simulate the way scanlines faded on a real CRT. Among other things, but that's the big thing you get from 120hz or 240hz -- you can watch 1080i60 video without it being completely ugly and ruined by bob/weave artifacts.
I have a 2008 SportTrac with Ford's first-generation (AFAIK) SYNC. It's kind of nice, but OMG it gets paternalistic and annoying sometimes. They've been talking about releasing a SDK for Sync since... late 2008. I'll believe they're ever going to allow thirdparty apps when I personally see it.
Now, if you'll excuse me, I'm going to go back to using my nice, rooted Android phone with a native app I'm working on that fools SYNC into thinking the fake bluetooth media player it's spoofing isn't actually a custom interface for Sync'ified Android apps that recognize track up/down and 'ok' as command buttons their own right -- completely bypassing SYNC and its annoying restrictions, and using it as little more than a handy embedded bluetooth audio + control interface for my phone.
> is that so? Just how did the country function before 1940?
J.P. Morgan personally bankrolled it... and enjoyed almost inconceivable power & influence over US policy as a direct result. Few individuals in history have ever personally had the power to effectively (if temporarily) bankrupt the US Federal Government on a whim or grudge. JP Morgan was one of them.
> The US dollar is now worth roughly 2% of what it was 80 years ago
Name one major currency that's held substantially more value over the same period. There isn't one. Swiss Franc? Nope. British Pound? L0L. Japanese Yen? You must be joking. Soviet Ruble? Poof. Literally, up in smoke.
Not even GOLD has the same purchasing power it did 80 years ago -- the supply is basically finite with respect to the number of Au atoms within 10,000 miles of the Earth's core, but the percentage of it in circulation since the dawn of human history is relatively low, new gold continues to be mined, and the annual rate of increase is higher than ever (with the possible exception of Spain's first few years of looting the Inca empire, and that was more a matter of bringing gold into circulation within the European money system than increasing the amount of gold per se).
> People who hold the debt of the US are being cheated.
And yet, the world's wealthiest investors continue to purchase record amounts despite an interest rate approaching zero. Compared to the historic volatility of other currencies, US debt is a valuable investment, if only because US Treasury Notes are cheaper and less-risky than physically acquiring paper money and storing it in a vault somewhere. US debt is valuable, because it eventually translates into spendable US Dollars, which are the most liquid currency on Earth.
The US Dollar's value doesn't come from anything that "backs" it, and the availability of US-made goods is almost a secondary consideration. The fact is, if you have a suitcase full of US Dollars, you can spend them on just about anything -- big or small, legal or illegal -- anywhere on Earth. You can use them to buy electronic goods, and you can stuff them into G-strings in an Asian titty bar, and the recipient can turn around and use them to pay the rent, regardless of what the local currency might actually be. Other currencies come close, but no currency has ever been more universally liquid in more places for more things.
> You would think that a packet specifying X seconds of simulated silence could be packed into a few bits,
> so maybe two bytes should suffice.
You're confusing media-encoding with telephony. Media encoding occurs in non-realtime, so you can analyze a big chunk of data and plan ahead for both silence and bursts. Telephony is realtime. The more you delay the audio for analysis, the more annoying it becomes to the people having the conversation. With realtime telephony, you don't HAVE "X seconds" to buffer and delay transmission so you can analyze a chunk of audio that long.
The supreme irony of video compression is that you can compress pristine HD video down to 320x480 60 field/second VHS-quality with 4:0:0 chroma subsampling and end up with an average bitrate that's barely more than what you'd need for uncompressed (or maybe realtime-compressed, with max. 1ms added latency) audiophile-quality surround sound. Why? Surround sound SEVERELY limits what you can throw away in realtime (it uses phase relationships to encode side/rear/sub channels, which are one of the first things codecs like GSM's throw away and dispense with), and if you're compressing pristine noise-free video using DVD-noncompliant (but usually works anyway) outrageously long GOPs, B-frames, multipass variable-bitrate encoding, and aggressive huffman compression, you can pack the video down to almost nothing -- especially if you're willing to accept a little blockiness.
Shhhh. You're forgetting that the people who really dig IPv6 get TOTALLY bent out of shape about home routers in any form.
IMHO, the nearly-religious hatred its advocates have towards NAT and routers is one of the biggest things holding IPv6 back. If they'd just humor people who want to set up an internal network with private IPv6 addresses and NAT it through their router somehow instead of trying to beat them into submission and force them to abandon their shameful backwards ways, we'd be a lot closer to having IPv6 in widespread deployment today.
The problem is, they're absolutely HELLBENT on abolishing the handy devices we mostly abuse as ghetto-fabulous firewalls. From the way they talk about routers, you'd think they cost thousands of dollars and make the internet unusable, instead of being something that most people either get for free or pay less than $50 for... maybe $150-250 if they're high-end users who want one that's hackable and can be flashed with custom firmware.
The same trick routers do to allow a dozen devices to share one public IPv4 address could transparently map public IPv6 addresses to devices who identify themselves by internal 192.168.x.x or 10.x.x.x addresses. Better, in fact, because every IPv6 address mapped to an internal IPv4 address by the user's router could enjoy the equivalent of "DMZ" mode port forwarding. Give the same user a public IPv4 address (or at least a fixed range of ports from one, a-la RFC 6346), and every IPv4-only device sitting behind his router can be made fully-accessible to the outside world via both IPv4 and IPv6.
For IPv6-native devices, it's even better. They can have their public IPv6 address, but let the router assign them a phantom 192.168.x.x address, and DMZ-forward all of its ports to their IPv6 address. Create an additional router forwarding rule forwarding port xxxx of the public IPv4 address to port yyyy of the phantom 192.168.x.x address that can be chained with the rule forwarding all of 192.168.x.x's traffic to the device's IPv6 address, and you have an IPv6 device that can be easily reached by IPv4 devices on the other side of the router, too, just like NAT'ed IPv4 devices can be. The bonus is that if IPv6 is talking to IPv6, they can drop the act and communicate directly.
The people who hate routers forget that they're a wonderful way to allow end users to embrace IPv6 at THEIR OWN pace, in ways under THEIR DIRECT control, instead of dictated by their ISP or someone else's timetable -- usually, in ways that will break expensive legacy hardware that will never work natively under IPv6.
Routers aren't going away. If anything, 10-20 years from now, we'll have legacy devices connected to the rest of the LAN through a $10 POE-powered adapter from China that sits inline between the device and the rest of the network, and acts like a single-port DMZ-forwarding NAT router dedicated to just one device. A box that lets your IPv4-only device be a:b:c:d:e:f:g:h to the rest of the world, while thinking of itself as 192.168.1.1 and never knowing the difference.
The problem's root is the blind faith Eclipse has in its own metadata and virtual filesystem, and its determination to blindly go by it even when it contradicts the real-world filesystem's state. Apparently, Google blames Eclipse, the Eclipse team blames Google, it's probably at least partly the fault of both, and nobody has any idea how to fix the underlying problem.
A related problem is when Eclipse/ADT corrupts the library info, and Jarfiles you added to the classpath suddenly get ignored. The only way to fix it is to add some unrelated jarfile to the build path (to force Eclipse to regenerate the metadata) & remove it again after cleaning & building.
As for version control, I believe at least one known cause project-corruption ~2 years ago was due to a bug in one of the Subversion connectors (or maybe it was EGit)... basically, it was auto-adding a metadata file to the repo & confusing Eclipse by corrupting it with metadata from a different workspace on another computer.
Yep. To load a game, at the *bare* minimum, you had to hop over at least one trivial speedbump that somehow managed to stump lots of supposedly "normal" kids:
load "*",8,1
God knows, it took my brother almost TWO YEARS to finally get the hang of it. He now owns a Mac. Surprise, surprise... ;-)
Fast forward ~10 years to 1993... and try explaining the concept of an IRQ, a cascaded IRQ, and reconciling conflicts between a piece of shit internal modem that only supported IRQ 2, 3, and 4 & a malfunctioning soundcard camped out on IRQ 9... to that same tech-challenged brother (hint, for anyone who didn't instantly get the punchline... the modem was set to IRQ 2)
Today's kids are no dumber than the kids we went to school with. The difference is, 25 years ago, today's clueless kids wouldn't have owned a computer at all, and if WE were 13 again, we'd spend summer vacation building Arduino LED cubes (or if we were in college, we'd be building circuits with FPGAs).
Kids who are like we were still exist, they're just lost amidst the background noise of stupid kids with toys they think work by magic.
> Why? Since when do app developers typically need to "modify, adapt, redistribute, decompile,
> reverse engineer, disassemble, or create derivative works of the SDK"?
To fix annoying bugs that have been around for eternity, and Google seems to have no interest in fixing? Like, you know, the nice one that occasionally induces Eclipse to transpose the cursor and semicolon at the end of a line of code, so you'll type semicolon, hit return, then end up swearing violently because the goddamn IDE (acting at the behest of ADT, since Android Isn't Java(tm), and as far as Eclipse is concerned, it's dealing with a C++ preprocessor) decided to enter the semicolon, then reposition the cursor to be RIGHT BEFORE IT immediately afterward.
Or the way, once or twice a year, Eclipse just goes senile and forgets how to build Android projects, and the only way to fix it is to create a brand new project and reimport everything into it by hand?
Or those times when Eclipse refuses to compile an Android file because it thinks there's a bug that isn't there, and the squiggly-line bug won't go away unless you select the source code, cut it into the clipboard, save the emptied-out file, paste the source back into the file, and save it again?
These are all bugs that have plagued ADT since the beginning, spawned hundreds of entries over at StackOverflow... and whose developer cries have largely fallen upon deaf ears over in Mountain View, for reasons nobody can really discern or explain.
1/25th might be more "in the spirit" of the metric system, but it wouldn't have been any real improvement over 1/25.4th. The whole point of 1/24 is that 24 can be neatly and cleanly divided by 2, 3, 4, 6, 8, and 12. In contrast, 25 can be cleanly divided by... er... 5. Probably better than 25.4, but not really enough to have been worth the lobbying effort.
Ultimately, the metric system and Java both share the same fundamental design flaw -- they both do pedantic, annoying things for the sake of blind consistency with some abstract rule that was conceived mostly in a vacuum devoid of real-world considerations. 2 liters and 1/2 liter are handy sizes commonly seen in stores. 1 liter bottles of anything are unloved orphans -- too big for one serving, but not big enough for the leftovers to even be worth saving. Unsigned 8-bit values are the foundation of modern computing. Java uses signed bytes just to be consistent with int and long, and any attempt to deal directly with 8-bit values in Java ends up being ungodly painful and tedious as a result.
If Shuttleworth wants to make a REAL difference in the future of mobile Linux, he needs to come up with a way to allow loadable kernel modules built for older kernels to keep working with newer ones. God knows, Google's never going to do it. It's an old, tired story by now in Android-land... every new version of Android needs a new kernel, every new kernel catastrophically breaks every loadable kernel module that came before it, and most manufacturers are in no hurry whatsoever to release newer kernel modules for existing phones... assuming they ever do. It's a problem that bites Android over and over again, year after painful year, and it's going to hurt Ubuntu even WORSE because it will initially be forced to live with Android's crumbs and hardware cast-offs.
For God's fsck'ing sake, a couple of years ago, people were using NDISwrapper to run binary wifi drivers intended for WINDOWS NT under Linux. Is it REALLY that impossible to allow end users to wrap binary kernel modules for things like the camera, GPS, 4G modem, or whatever in some kind of thin thunking layer so they can at least limp along when the next kernel comes out, even if the manufacturer is an asshole and takes months (or eternity) to release newer drivers? If we can thunk binaries built for A TOTALLY DIFFERENT OPERATING SYSTEM into working, is it REALLY that hard to pull a similar trick with binaries that were built for Linux in the first place?
It's a nice idea, but the Chinese hardware market is kind of weird compared to the rest of the world.
In America, companies like Qualcomm release chips whose precise capabilities and documentation are kept under lock and key, and it's nearly impossible for anybody outside of a small, handpicked group of companies to actually get their hands on a chip that wasn't harvested from a device... but customers deemed worthy by the chipmaker pretty much get to know whatever they want to learn about.
In China, the companies who make the ASICs needed to build phones and tablets will pretty much sell them to anyone (or at least sell them to distributors, who can sell them to anyone with the chipmaker's full blessing). They'll also make the chips' public documentation freely-available to anyone and everyone. The catch is, there isn't much actual information IN that public documentation. The expectation is that you, as the owner of a small factory, will buy their chips, assemble them into a device following one of their reference designs, download the necessary firmware binaries, burn them more or less verbatim onto the devices, and get started on the chipmaker's next-generation design a couple of months later.
In other words, China is a relatively easy place for small (compared to Samsung, Sony, and Motorola) companies to manufacture sophisticated electronic devices with minimal ceremony, but it's a very HARD place to take those devices to the next level, and make them anything besides bland, generic, commodity knock-off copies of the chipmaker's reference design. That's why Chinese companies work so hard to make their devices LOOK GOOD, with attractive cases and packaging... it's one of the few things within their direct ability to control.
Put another way, if Shuttleworth wants totally open phones, he's going to have to get really, REALLY friendly with companies like Rockchip. Otherwise, he's going to have to settle for Ubuntu running on phones that are no more open than most Android phones are today (ie, not necessarily locked down per se, but often are more de-facto black boxes than even Windows Mobile phones used to be back when XDA got started).
Chinese phones might not be intentionally locked down, but most Chinese Android hardware has no meaningful chip-level documentation to speak of. Some Chinese Android devices don't even have fully-implemented ADB support.
Many of them are built around chips that are epoxied-over blobs on the circuit board with no real markings (in English, Chinese, or any other language), and most of THOSE chips have no lifecycle to speak of... the ASIC manufacturer churns out 10-100 million of them, makes changes, churns out 10-100 million of the modified chip, makes changes, churns out 10-100 million of the modified modified chip, and the cycle repeats itself. Go google the misery some Americans trying to document the workings of Rockchip-based Android tablets have gone through.
Put another way, the biggest problem with the Chinese chips is that by the time anybody starts to figure out how they work and release documentation, they've already been obsolete for one or two generations. And sometimes, if someone in the supply chain gets a good deal on a few pallets of old chips, they might randomly show up in a new phone... but by the time anyone figures it out, those phones will be gone, replaced by a different model that looks identical in photos, but is built around totally different hardware. It's just like everything else that gets sold in China... it's easy to buy something that's pretty, cheap, and probably works, but it's VERY hard to buy a consumer item with specific specs and parts that are guaranteed to be some specific model, let alone stepping. Even if you buy one, crack it open, examine it with a microscope, and confirm that it has what you want, there's at least 50-50 odds that the one in the box in the pile next to it came from a different pallet, and is likely to differ in meaningful ways from what you're hoping it is. And more often than not, "cracking it open" is literal rather than figurative... these are devices aren't meant to be kept more than a few months, let alone repaired or serviced.
Now, having said that... there are perfectly good, well-built products from China too. Unfortunately, most of them have the same closed specs and restrictions that their American and European counterparts do. Pick your poison -- a phone guaranteed to have a specific model and stepping of a specific Qualcomm chipset whose datasheets are a closely-guarded trade secret, or a nominally-open phone with no documentation to speak of that will be moot, obsolete, and quite possibly broken & nonworking by the time anyone figures out how to hack it.
UbuntuPhone is technically a parasite on Android (because it depends on Android's make-believe-open hardware to make it past the gatekeepers doing their best to control American mobile networks), but it's likely to end up as a symbiotic relationship. My guess is that if Ubuntu Phone is viable 5 years from now, it'll basically be a native-code framework that wraps Android. Your 'launcher' app will be native "Ubuntu", but you'll have at least one instance of DalvikVM spawned and running in the background on one or more cores, and 97% of the apps running on an "Ubuntu" phone will be Android anyway.
It might even be a good thing for both Google AND Canonical. Google still gets politely ignored by Qualcomm (mostly because Qualcomm owns enough IP to make it nearly impossible to build a CDMA phone that can legally be sold in the US without using their chips, so Google's threats to take Motorola's business elsewhere ring hollow), but Canonical has one strength that Google has kind of been teetering a bit at lately... it still has a dominant CEO who's a kind of a loose cannon. Google hasn't been pwn3d by Wall Street, but they're big enough now that they have to at least go through the motions of pretending they care what institutional investors want. Shuttleworth can still openly say and do things that would get Google hauled in front of the SEC, FTC, and/or Congress for corporate blasphemy.
What I want to know is why BBC American can't just leave their shows at 50fps, and deliver content as 1080i50 and 720p50? Modern HDTVs, even American ones, can display 1080i50 and 720p50 just fine over HDMI. IMHO, 50-60hz temporal rate conversion is pointless when the TVs can deal with the native framerate anyway. It's like the fetish web designers had around 1996 of pre-converting images into ugly dithered web-safe colors, instead of just letting the browser deal with it when necessary. Leave 50 as 50 and 60 as 60, and let the TV sort it out the way God and Engineers intended.
^^^ Exactly. Capacitive is ok for blunt selections, but are pure agony for precise selection. Personally, I used to solve both problems by slightly shaping my right index finger into a subtle, blunt point so it worked nicely as an adhoc stylus.
OK, I'll be honest... I'm a hardcore Graffiti user, and the official version for Android seems to be getting worse and worse by the year... partly due to apps that try to do Ajax lookups after each stroke, partly due to over-aggressive CPU governors that treat the appearance of a soft input area as an excuse to drop the speed down to 200mhz, and partly because it has no way to disable foreign accented letters & it's over-eager to recognize carriage returns. It pisses me off that a slow 16mhz Dragonball could achieve 99.9% accuracy, but my 1.5ghz quadcore s3 can't tell the fscking difference between 'm' and 'e' (written as backwards '3'), or between 'o' and 'g' (written as letterside-6). Actually, it almost feels like they recently re-weighted it towards Graffiti-2, because its worst recognition seems to be with the true single-stroke variants... which, of course, are the ones I use. Sigh.
I swear, I'm going to gut an old Palm III and transplant the Dragonball & Graffiti-pad to a hacked-up case and interface it to my Android phone via USB-OTG or bluetooth. Or make my own homebrew input method consisting of a M68k emulator running original assembly-language Graffiti ripped from a Palm III rom. I generally love my Galaxy S3, but its Graffiti error rate is TERRIBLE compared to older versions on my older phones. My creaky old HeroC overclocked to 711mhz has butter-smooth and accurate Graffiti... my S3 has me swearing in frustration trying to type the exact same text, and my old Photon & Epic4g aren't much better. I almost think multitouch capacitive controllers are partly to blame, because Graffiti's ability to work seems to be inversely related to touchscreen sophistication... :-(