Android needs some sort of remote wipe software to make it even remotely feasible for most businesses. For example, the government requires remote wipe, and some sort of encryption. Until Android has a solution for these two, the VPN-less capability is moot.
The Google Apps Device Policy app supports password policies and remote wipe, and Ice Cream Sandwich supports full-device encryption (I turned it on for my own ICS phone, took about an hour to encrypt the 16GB internal storage partition plus two or three reboots).
Ethically loaded? How? I don't see how the brain would be suffering? Or are they worried about skynet?
Here in meatspace, putting a human in a sensory deprivation tank is torture and one of the more surefire ways to drive a person insane. The brain isn't wired to believe in null sensory data. If a region of the brain stops receiving stimulation, it frantically strengthens its connections to other regions, tapping randomly into its neighbors and interpreting their arbitrary stimulation as sense data (compare the hallucinations of sensory deprivation to phantom limb syndrome and somatosensory remapping in amputees, e.g. touching an amputee's face triggering sensation on the amputee's phantom fingers because the face and fingers are next to each other in the sensory map of the postcentral gyrus). If this frantic effort fails and the brain regions can't find a source of stimulus, they start to die outright, nerve by nerve, because nerves are wired to commit suicide if they don't fire regularly.
But even a sensory deprivation tank still provides senses of sound, proprioception, temperature, gravity. If we were to create an accurate nerve-by-nerve simulation of an entire vertebrate brain and then provide it with no sensory input.... Well, at best the result would be phantom body syndrome. At worst, it could go well beyond torture and become the greatest suffering ever inflicted on a single sentient being. And we don't understand the brain well enough to know which pieces of sensory data must be provided to maintain sanity and prevent existence from being torture.
And that's not even getting into the legal and moral issues. Let's say we can put a sane mind on a chip by cloning the synaptic structure of a recently deceased human and feeding it all the appropriate sensory inputs. Is it a person? Is it a citizen? Can it consent to a contract? Is it a minor until the hardware turns 18? May I enslave it? Is it ethical to feed it false sensory data culled from a virtual reality simulation, i.e. trap it in The Matrix? If I turn it off and erase it at the end of my scientific study, have I murdered it? If yes, am I legally obligated to keep it powered until the hardware fails? Am I morally obligated to transfer the synapse data to new hardware before the old hardware fails, making the uploaded human immortal? Alternatively, am I morally prohibited from doing that for more than N years, for some value of N? If I'm transferring the mind to new hardware, and my mistake causes a power surge that erases its synapses, am I protected by existing Good Samaritan laws, or have I committed involuntary manslaughter? As it's a simulated human mind, complete with all human appetites, am I obligated to provide it with pornography and the means to masturbate itself to orgasm? Do I have to obtain consent from the human whose deceased mind will be used to create the chip? Am I obligated to pick an atheist, or more to the point a subject who doesn't believe in souls? How well informed does the consenting subject have to be before dying? Does the family have to consent as well, or are we content with provoking another HeLa controversy for the greater good? And so on...
The wear and tear on the body is such that even if you can increase the lifespan to a theoretical 150 years you wouldnt be very healthy for the last 90 or so years. You also need something that adresses the wear on the body. Our hearts arent made for 150 years of use and we build up various plaques and toxins in our bodies as time goes by. Even if we all lived under controlled and ideal circumstances the last seven decades would be pretty much seven decades of being eighty.
Actually, there's some research that strongly suggests that there's only a finite amount of aging going on. What's happening in aging might not be "the body's self repair process falls behind entropy", as commonly thought. Instead, aging would be "the same tradeoffs which favor reproductive success in youth exact a cost later in life"; after some finite time, you've paid those costs in full and aging stops, leaving only a constant risk of disability and death per year instead of the ever-growing one postulated by the "falling behind on entropy" model. In this view, there are still some specific things that actually do wear out with age because they aren't constantly replaced (tooth decay and cornea clouding / cataracts are the obvious ones), but general health doesn't suffer the same fate.
See New Scientist's The end of ageing: Why life begins at 90 (behind a paywall, sadly), which references a demographic study where annual mortality rates became constant above age 93 (Greenwood and Irwin, Human Biology, 1939), a study confirming the same pattern in fruit fly populations (Carey and Curtsinger, Science vol. 258 p. 457 and p. 461, 1992), and an exploration of a mathematical model of mutation which concluded that a mortality plateau is inevitable, not a mere special case (Rose and Mueller; PNAS vol. 93 pp. 15249-15253, 1996). (Of note: Rose is the author of the New Scientist article, with all the confirmation bias that implies.)
Also, the research into aging suggests there are only a handful systemic problems that actually cause it (accumulation of crosslinked proteins; declining telomerase production causing cells to stop dividing; etc.), and if those systemic problems were addressed we could largely arrest the aging process. Aubrey de Gray's TED talk is pretty much mandatory viewing on that front.
It's worth keeping in mind that if metabolism and entropy inevitably led to cell death after 100 years, then human beings as a species would have already died out: sperm and egg cells are metabolically active cells that contain DNA that's millions of years old, and there's no time machine that allows a pristine copy of the germline DNA to be copied forward from conception to adulthood without at least a childhood's worth of accumulated error. Likewise for our mitochondria, pseudo-cells that they are, with their own mtDNA separate from the DNA of the nucleus, exposed to the entropic ravages of the Krebs cycle firsthand without a nuclear membrane to protect it; our bodies pass these pseudo-cells on from mother to child unchanged, without even giving their mtDNA a de-methylation/re-methylation spring cleaning like mammalian nuclear DNA receives. But they thrive in the germ cell line, generation after generation, even as they suffer and decline in the somatic cell lines. There must be a difference in upkeep, some cost that evolution is willing to pay for the germline but unwilling for the somatic lines, that allows the germline mitochondria to remain healthy and "young" for millions of years.
I realize that IPv4 is going to be with us for quite some time, but is this going to be worth the effort? It requires a bit of jiggery-pokery to repoint your DNS, the kind of thing that appeals to the Slashdot crowd but which your grandma will never, ever pull off. ISPs could help, but will they do so before IPv6 makes it irrelevant?
It's described in IPv4 terms, but extending it to work with IPv6 addresses should be simple enough. The trickiest part will be finding the golden CIDR mask to replace IPv4/24. Giving up/64 is too much, since it identifies most ISP customers uniquely, and/48 has similar issues. Probably something near/32 or/40 would be appropriate, although you could probably do a lot with as little as/20.
Other than that, the described technique is still fully relevant because IPv6 doesn't change the game in any other way: DNS still works the same way, HTTP still works the same way, and websites are still slow for the same reasons, so you have the same incentives for regional caching and the same choices in how to do it.
Does anyone else see this as a giant security hole? As in, various schemes like this have been tried since the days of ActiveX, and the only reason ActiveX has the worst reputation is because it's the only one that gained widespread use?
The point of NaCl is that it's a virtual machine bytecode language, and you can statically verify (without running the code) that the bytecode conforms to the spec. However, for performance reasons, the bytecode language and the virtual machine architecture just happen to line up with the native machine code and native architecture. NaCl provides only a subset of the full instruction set, though, and this prevents arbitrary pointer arithmetic or self-modifying code that could break outside the sandbox. NaCl authors actually need to recompile their code to x86 NaCl or ARM NaCl as a distinct GCC compiler target, instead of plain old x86 or ARM, because the NaCl targets are easily distinguishable from the native ones when you examine the machine code bytes. (The most important feature: all jumps are aligned and no ops cross an alignment boundary, so there's only one possible machine code interpretation for each byte of NaCl code.)
Needless to say, this is a vastly different model compared to ActiveX, which was "we'll trust any old native code to make arbitrary system calls, just so long as there's an RSA signature attached". NaCl ditches the central trusted authority model that Microsoft preferred, and instead goes with the Java/JavaScript/Lua/LISP model of "you can only perform side effects that the interpreter chooses to expose to your code". As with the interpreted languages your NaCl code is Turing-complete, so you can waste CPU and RAM until the cows come home, but you can't actually touch the filesystem, create GUI elements, or modify the address space of other processes unless Chrome decides to permit it. The only difference is that you don't run at some fraction of native code speed, but exactly at native code speed, and you can statically optimize as much or as little as you like, or write in any language you want (so long as someone's written a NaCl target for your language's compiler).
There will probably be a few bugs in the static verification logic that allow not-quite-NaCl code to slip through, but this is no worse than the sandboxing problems we already face from Javascript in the browser. With JavaScript, this has even included double free bugs that allowed overwriting arbitrary memory with native code and executing it. The risks with NaCl are no different.
The bright side is that the people who innovated to make the patents are being compensated for their efforts. This is how patents motivate people to innovate. Would you prefer if Google could use other people's innovations without compensating them?
If anything, patents in the software industry cause innovation NOT by rewarding the company that holds the patent so that they will feel inclined to invent more, but by encouraging companies to patent the lowest-hanging fruit and forcing everyone else to invent workarounds as the patent owner lords over the market by charging exorbitant prices. Think of gzip, PNG, Vorbis, Tarkin, and to a lesser extent VP3/Theora and VP8/WebM, which were all developed in response to the patents on LZW and MPEG 1 through 4 because the licensing terms were greater than the market would bear.
Patents give their owners monopoly power, which ipso facto means that the licensing fees charged by the owner will never be at the free market price created by the intersection of supply and demand. Even the MPEG-LA consortium, which actually goes to the effort of trying to invent a "fair" price, doesn't have enough information to actually determine what the fair price would actually be in the absence of a monopoly, e.g. what the MPEG algorithms would sell for if they were a contractually-protected trade secret bought and sold on the open market (the scenario that patents were created to prevent).
Just to nit-pick, you mean "the direction of movement". Velocity also implies the magnitude as well as the direction, and I don't see why we need to bring magnitude into the argument.
No, I meant what I said. The noun phrase "<vector X> in the opposite direction of <vector Y>" makes sense for any vectors X and Y, even though it doesn't define a relationship between their magnitudes or otherwise mention them.
In physics, "deceleration" is just an informal shorthand way of saying "acceleration in the opposite direction of something", where the vector "something" is often "velocity" by default but can be anything else depending on context. Saying "Pioneer is decelerating" is not quite right, then: the Pioneer craft are traveling on hyperbolic paths that slingshot away from the Sun on a curve, not zipping away in straight lines, so an acceleration toward the Sun would not point in the opposite direction from the velocity. It would slow them down since the velocity-acceleration angle is obtuse, but not as much as an actual 180 degree acceleration would. (Perhaps the acceleration is Sun-ward instead of backward because the Pioneer craft aligned their spins to keep their radio dishes pointed toward Earth, and asymmetry makes them emit more RTG heat on the opposite side from the dishes? Pure speculation on my part.)
Granted, this is a little less ridiculous than some of his past claims — machine translation has improved a lot in the O(decade) since Babelfish — but translation algorithms are still context-blind for the foreseeable future because no one's yet found a computationally feasible shortcut for the "every Bayesian probability is dependent on every other Bayesian probability" case that natural language seems to teeter in the direction of. Moore's law isn't going to fix it, either, because it's not a polynomial-time problem that can be fixed by just throwing faster clocks or more cores at the problem. We've gotten as far as we have by using dumber, polynomial-time algorithms and just throwing supertankers of training data at the problem, but in the end it's no more contextual than Dissociated Press.
Incidentally, it's clear that natural language translation is not actually as difficult as computing the maximum likelihood of a fully cross-connected Bayes network (i.e. superpolynomial-time), or else the human brain itself would be stumped. But we don't know enough about which shortcuts are useful for convincing human brains versus which shortcuts result in "the vodka is good but the meat is rotten" translations. That means we're stuck theorizing from our armchairs, throwing algorithmic crap at the wall and seeing what sticks, or maybe poking at brains with pointy sticks and fMRIs. On this matter, date predictions are worthless. The breakthrough could come tomorrow or hundreds of years from now, and Kurzweil is no better equipped to predict the date than my cat is.
One interesting element of these findings is that the achievements that are highly correlated – or part of the same clique – do not necessarily have any obvious connection. For example, an achievement dealing with a character’s prowess in unarmed combat is highly correlated to the achievement badge associated with world travel – even though there is no clear link between the two badges to the outside observer.
Really, no clear link? Did they even ask one player? These are both low-hanging fruit for the solo completionist. In particular, I suspect that north of 90% of players with the 400 unarmed weapon skill achievement will have World Explorer, although the relationship will be lower in the reverse direction — the former is a bit more of a time investment, and much more boring and tedious (Blizzard removed weapon skills for a reason), whereas World Explorer is something that can be knocked out by an hour-a-day casual player in two weeks with no problem. Since World Explorer can easily be teamed up with book collecting, critter/love-ing, the zone and continent quest completions, and Loremaster, I suspect those all form a single clique of solo completionist achievements, with some sub-cliques that are a bit more accessible to the casual player.
Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source? Should we be pushing to see firmware source too? Instead should it not matter about seeing driver source? I'd love to hear your perspectives.
Device A has an open source driver, proprietary guts, and a firmware blob loaded by the driver on boot.
Device B has an open source driver, proprietary guts, and a firmware blob hidden in an immutable ROM on the device that you don't know about.
For some reason, Debian scorns Device A and praises Device B, even if the firmware blob for Device A allows unlimited redistribution. For the most part I like Debian, but that policy is just silly: Device A is the one that has the greater potential for end-user hackability.
Wait, nevermind. I seem to be confused about something, Wikipedia says the transcendentals are uncountable.
In another universe, perhaps they are...
For the rest of us, Taylor series are the best oculus I can think of into the known transcendentals (Pi, e, sin(a/b), etc.). However, most transcendentals will remain obscure by virtue of being irrelevant.
Even in this universe, there are uncountably many uncomputable transcendentals. The canonical example of an uncomputable real is Chaitin's constant, which is the probability that a randomly chosen computer program (in some specified language) will halt. We can figure out the first few digits, but beyond that it's seemingly impossible to calculate. If you had a way to iteratively generate the digits in Chaitin's constant, you could solve the halting problem, and vice versa.
My great-grandparent post was under the seemingly mistaken impression that "transcendental" referred to a distinct subset of the reals, something like "the reals with a well-defined Taylor series that are not algebraic", but instead (per Wikipedia) it appears to be "the reals that are not algebraic", which is a vastly larger set.
Wait, nevermind. I seem to be confused about something, Wikipedia says the transcendentals are uncountable. There's probably an argument for why Turing Machines can't be used to uniquely identify arbitrary transcendentals, e.g. there aren't enough Turing Machines to go around (Cantor argument), or you can't prove that a given Turing Machine identifies the transcendental you're seeking (Halting problem), or something.
I'm still fairly convinced that pi is a computable transcendental, and probably likewise for most of the transcendentals that we've given names to, but I now suspect that the majority of the transcendentals don't fall in that category. Oops.
The rational numbers are infinite, the irrational numbers are infinite, add them together and you have the real numbers, which is a "larger" infinite set than the rational numbers (and probably the irrationals, though I can't say for sure since I've never attempted that proof).
Quite right. There are two types of infinite cardinality: countable and uncountable. Countable encompasses the set of rational numbers, and calculable irrationals such as roots and all polynomial combinations of the those for which there is an isomorphic map onto the set of integers. Then there's the greater set, the uncountably infinite, e.g. the transcendental numbers and their ilk.
I doubt the cardinality of real numbers would be greater than irrationals themselves, since most numbers are transcendental. It'd be like taking a teaspoon of water out of the ocean and wondering if it's still the ocean.
To be pedantic, the transcendentals are also countably infinite. The integers, rationals, algebraic irrationals, transcendentals, and quite a few others all fall under the heading of "computable numbers", i.e. numbers whose exact solution can be arrived at by a Turing machine given infinite time and tape. Even though it sounds like a ridiculously large set, the set of computable numbers is countable: for any Universal Turing Machine you like, each computable number maps to the natural number that encodes the initial tape for the UTM such that the UTM simulates any one of the TMs that can generate the computable number in question.
For instance, even though pi is a transcendental and has no algebraic representation, there are well-known algorithms that iteratively generate as many digits of pi as you like. The infinite series of pi digits can thus be replaced with a (finite) computer program implementing one of these algorithms, and any finite series of pi digits can be replaced by the same algorithm plus the number of digits to stop at. A finite approximation of pi is merely cached output from the computer program, and therefore {program U finite approximation} adds no new information beyond {program} to help you distinguish pi from the other real numbers, meaning you can uniquely identify pi with just the computer program and no further information.
if you live in the USA, isn't it a bit of a problem that your chosen media codec solution involves deliberate lawbreaking?
It is -- so I call it civil disobedience.
Notwithstanding your comment about how you already have a patent license through other means, "civil disobedience" isn't the same as "doing it and not getting caught". In the original sense, "civil disobedience" means breaking the law in public, daring the police to arrest you / civil lawsuits to fly, and using the obvious injustice of the response to inflame the public against the bad law. DeCSS in your.signature is civil disobedience, downloading a gray-market codec from a non-US APT repository is merely getting away with it.
FWIW, I highly recommend setting your brightness to the minimum the OS will let you. In my experience, the Nexus One screen is useless in any amount of daylight, no matter how high it cranks up the screen's light levels, so you might as well not waste that energy and find a nice shady spot instead. My "Battery use" screen consistently shows that the display sucks down the vast majority of my power usage, even if I've only had the screen on for 30 minutes throughout the day, and I still get through the day with 40-60% of my battery remaining. In a pinch, I can go 36 hours without charging, especially if I minimize screen activity.
Also, get Watts, and try to correlate the slope of the graph with what you were doing at that time. I found it quite helpful.
"Relatively short drive"? If you live in Berne, Multimap is giving me over 100 miles each way to get to a likely town outside Swizerland. Man, you've got to really want that game!
Beyond the other comment about 100 miles versus 100 years, I also feel compelled to point out that Switzerland is very well connected with its neighbors via a very reasonably-priced passenger rail system. (And with schedules that are extremely... Swiss... to boot.)
It still blows my puny American mind that it's possible to ride a train and arrive in another country, and moreover to do so as a day trip.
Actually, I'm fairly sure you miscounted. When I looked over that list, I only counted 8.
Star Trek: The Motion Picture (Star Trek 1)
Star Trek II: The Wrath of Khan (Star Trek 2)
Star Trek III: The Search for Spock (Star Trek 3)
Star Trek IV: The Voyage Home (Star Trek 4) Star Trek V: The Final Frontier FNORD (Star Trek 5)
Star Trek VI: The Undiscovered Country (Star Trek 6)
Star Trek: Generations (Star Trek 7)
Star Trek: First Contact (Star Trek 8) Star Trek: Insurrection FNORD (Star Trek 9) Star Trek: Nemesis FNORD (Star Trek 10)
Star Trek (2009 - Star Trek 11)
See? There's a mysterious gap between 4 and 6 that I've never been able to figure out, but you can't seriously mean that the new movie gets a +2 added to its sequel number just because it's a reboot.
Now if you'll excuse me, I have a sudden urge to go shopping.
Android devices can mount loopback file systems, overcoming FAT's lack of unix permissions. They did it to install Debian on the G1's SD card.
Yes, and as I said, this is exactly what I keep hearing about as the long-term plan. The problem as I understand it is that it will require significant developer time to write an implementation. The easy part is automatically generating, mounting, and unmounting the encrypted loopbacks as needed. The hard part is changing Dalvik, the GUI, etc. so that they all do something sensible when the SD card is yanked out.
(The naïve solution of "SIGSTOP the missing apps until the SD card is reinserted" could well leave the phone effectively hosed if the app was running in the foreground. There are plenty of full-screen apps that hide the notification panel, and apps can capture a surprisingly large set of keypresses — and games, the most likely candidates for installing to an SD card, are also the most likely candidates for capturing keystrokes and going full-screen. Most users won't care that adb shell still works fine.)
Disclaimer: I work at Google, but not on Android and definitely not as a spokesman for Android, and I would be quite shocked if any of this were news outside the company. I'm fairly sure the bulk of this discussion exists in the public Android bug tracking system, as I remember being pointed there when we all got our shiny ADP1s a year ago and the same question came up. At any rate, the problem space is well known since it afflicts non-Android Linux (esp. Knoppix and other removable-media distros, which solve the problem by copying the entire system image to a RAMdisk).
Is it really that hard to create a directory for each app and to modify the file API to prevent apps from reading/writing outside of their directory?
Why do major surgery on Linux, creating a fork that no one else would touch with a ten foot pole (open source or not), when Linux already implements everything necessary? (Namely per-process UIDs and per-file permissions.)
What exactly they're trying to protect against or even if it actually helps, I do not know.
The SD card is FAT-formatted because the phone presents it over USB as a block device, so that PCs and Macs can pretend it's a camera or other media device. But the use of FAT means that the card lacks Unix file permissions, in particular the owner/group info that stops one app from stomping on another app's data. (The device is mounted noexec, to prevent temptation/abuse.) I've seen talk of using Linux's encrypted loopback abilities at some future point, but it's been on the wishlist since the G1 came out so I wouldn't hold my breath.
[...] As for the GPS. That’s not the worst problem. The worst problem is, that without a data connection, GPS is not working and useless. It just tries to find satellites. According to Nokia, it takes up to 40 minutes to get the first fix, then it’s fast. 40 minutes?? A TomTom does it in under two seconds! Like pretty much every GPS device (including phones) out there. [...]
That is either physically impossible or sheer dumb luck, depending on your device.
Some explanation of GPS is in order. For a GPS receiver to work, the GPS network must send it three pieces of data: the almanac data, the ephemeris data, and the current time (to atomic accuracy). Some receivers cheat and can get by without the almanac, at the cost of slow satellite locks and inaccurate position fixes until the almanac is available.
Among other things, the almanac tells the receiver a general, fuzzy idea of where all the satellites are located, and also gives the receiver a chance to measure the amount of ionospheric distortion (the single biggest cause of GPS position errors). The fuzzy satellite positions are valid for about 6 months, but the network only transmits one full copy per 12.5 minutes. You physically can't download it faster than that via the GPS network: GPS transmits in a repeating loop at a mere 50 bits per second, slower than an ancient 300-baud modem. Worse, the ~4KB almanac is only part of the GPS data, so the download rate is even slower than that. Oh, and to add insult to injury, GPS has no error correction, so if a section is corrupted you have to wait another 12.5 minutes for a retransmit.
With the almanac in hand, the receiver next needs the ephemeris data, which provides satellite orbital parameters in detail far beyond what the almanac specifies. This is absolutely mandatory for obtaining a fix. Once downloaded, it's good for about 4 hours, but the data is specific to each individual satellite. One satellite's ephemeris takes 12 seconds to transmit from start to end, but they can be downloaded in parallel. (As with the almanac, there is no error correction. If the receiver misses part or all of an ephemeris, it has to wait 30 seconds for the next retransmission.)
The clock data is similar to the ephemeris, except that it takes only 6 seconds to transmit. It's on the same 30-second retransmit loop as the ephemeris.
With all three pieces of background information at hand, a 60-bit signal every 6 seconds keeps the clock data up-to-date. This is what the receiver is paying attention to once it has a "lock" on a satellite. 3 locked satellites gives a latitude, longitude fix by making some educated guesses. 4 locked satellites gives a far better latitude, longitude fix and adds altitude as well.
In summary, if your TomTom truly has zero almanac data and zero ephemeris data (i.e. it's a fair "first fix" fight), the time to first fix must necessarily lie in the range from 12 seconds to 30 seconds... if the TomTom can download ungarbled and pristine ephemerides from 3 or more satellites simultaneously, without a single bit error among any of them. This also assumes that the TomTom is cheating by foregoing the almanac, trying to get a fix from ephemeris only and not correcting for the ionosphere.
The only possible way you can get the claimed 2-second fix is if the TomTom (a) already has a current almanac (or is deliberately foregoing one), (b) already has current ephemerides for multiple still-visible satellites, (c) already has very fresh clock data for those same satellites, and (d) gets lucky and catches 3 or more of those still-visible satellites with known data that all just happen to be transmitting their respective 60-bit subframe headers (1.2 seconds minimum, 6 seconds maximum) within the same 2-second window. As I recall, the TomTom backs up the almanac, ephemerides, and clock data to fl
Slashdot Mirror
Android needs some sort of remote wipe software to make it even remotely feasible for most businesses. For example, the government requires remote wipe, and some sort of encryption. Until Android has a solution for these two, the VPN-less capability is moot.
The Google Apps Device Policy app supports password policies and remote wipe, and Ice Cream Sandwich supports full-device encryption (I turned it on for my own ICS phone, took about an hour to encrypt the 16GB internal storage partition plus two or three reboots).
Ethically loaded? How? I don't see how the brain would be suffering? Or are they worried about skynet?
Here in meatspace, putting a human in a sensory deprivation tank is torture and one of the more surefire ways to drive a person insane. The brain isn't wired to believe in null sensory data. If a region of the brain stops receiving stimulation, it frantically strengthens its connections to other regions, tapping randomly into its neighbors and interpreting their arbitrary stimulation as sense data (compare the hallucinations of sensory deprivation to phantom limb syndrome and somatosensory remapping in amputees, e.g. touching an amputee's face triggering sensation on the amputee's phantom fingers because the face and fingers are next to each other in the sensory map of the postcentral gyrus). If this frantic effort fails and the brain regions can't find a source of stimulus, they start to die outright, nerve by nerve, because nerves are wired to commit suicide if they don't fire regularly.
But even a sensory deprivation tank still provides senses of sound, proprioception, temperature, gravity. If we were to create an accurate nerve-by-nerve simulation of an entire vertebrate brain and then provide it with no sensory input.... Well, at best the result would be phantom body syndrome. At worst, it could go well beyond torture and become the greatest suffering ever inflicted on a single sentient being. And we don't understand the brain well enough to know which pieces of sensory data must be provided to maintain sanity and prevent existence from being torture.
And that's not even getting into the legal and moral issues. Let's say we can put a sane mind on a chip by cloning the synaptic structure of a recently deceased human and feeding it all the appropriate sensory inputs. Is it a person? Is it a citizen? Can it consent to a contract? Is it a minor until the hardware turns 18? May I enslave it? Is it ethical to feed it false sensory data culled from a virtual reality simulation, i.e. trap it in The Matrix? If I turn it off and erase it at the end of my scientific study, have I murdered it? If yes, am I legally obligated to keep it powered until the hardware fails? Am I morally obligated to transfer the synapse data to new hardware before the old hardware fails, making the uploaded human immortal? Alternatively, am I morally prohibited from doing that for more than N years, for some value of N? If I'm transferring the mind to new hardware, and my mistake causes a power surge that erases its synapses, am I protected by existing Good Samaritan laws, or have I committed involuntary manslaughter? As it's a simulated human mind, complete with all human appetites, am I obligated to provide it with pornography and the means to masturbate itself to orgasm? Do I have to obtain consent from the human whose deceased mind will be used to create the chip? Am I obligated to pick an atheist, or more to the point a subject who doesn't believe in souls? How well informed does the consenting subject have to be before dying? Does the family have to consent as well, or are we content with provoking another HeLa controversy for the greater good? And so on...
The wear and tear on the body is such that even if you can increase the lifespan to a theoretical 150 years you wouldnt be very healthy for the last 90 or so years. You also need something that adresses the wear on the body. Our hearts arent made for 150 years of use and we build up various plaques and toxins in our bodies as time goes by. Even if we all lived under controlled and ideal circumstances the last seven decades would be pretty much seven decades of being eighty.
Actually, there's some research that strongly suggests that there's only a finite amount of aging going on. What's happening in aging might not be "the body's self repair process falls behind entropy", as commonly thought. Instead, aging would be "the same tradeoffs which favor reproductive success in youth exact a cost later in life"; after some finite time, you've paid those costs in full and aging stops, leaving only a constant risk of disability and death per year instead of the ever-growing one postulated by the "falling behind on entropy" model. In this view, there are still some specific things that actually do wear out with age because they aren't constantly replaced (tooth decay and cornea clouding / cataracts are the obvious ones), but general health doesn't suffer the same fate.
See New Scientist's The end of ageing: Why life begins at 90 (behind a paywall, sadly), which references a demographic study where annual mortality rates became constant above age 93 (Greenwood and Irwin, Human Biology, 1939), a study confirming the same pattern in fruit fly populations (Carey and Curtsinger, Science vol. 258 p. 457 and p. 461, 1992), and an exploration of a mathematical model of mutation which concluded that a mortality plateau is inevitable, not a mere special case (Rose and Mueller; PNAS vol. 93 pp. 15249-15253, 1996). (Of note: Rose is the author of the New Scientist article, with all the confirmation bias that implies.)
Also, the research into aging suggests there are only a handful systemic problems that actually cause it (accumulation of crosslinked proteins; declining telomerase production causing cells to stop dividing; etc.), and if those systemic problems were addressed we could largely arrest the aging process. Aubrey de Gray's TED talk is pretty much mandatory viewing on that front.
It's worth keeping in mind that if metabolism and entropy inevitably led to cell death after 100 years, then human beings as a species would have already died out: sperm and egg cells are metabolically active cells that contain DNA that's millions of years old, and there's no time machine that allows a pristine copy of the germline DNA to be copied forward from conception to adulthood without at least a childhood's worth of accumulated error. Likewise for our mitochondria, pseudo-cells that they are, with their own mtDNA separate from the DNA of the nucleus, exposed to the entropic ravages of the Krebs cycle firsthand without a nuclear membrane to protect it; our bodies pass these pseudo-cells on from mother to child unchanged, without even giving their mtDNA a de-methylation/re-methylation spring cleaning like mammalian nuclear DNA receives. But they thrive in the germ cell line, generation after generation, even as they suffer and decline in the somatic cell lines. There must be a difference in upkeep, some cost that evolution is willing to pay for the germline but unwilling for the somatic lines, that allows the germline mitochondria to remain healthy and "young" for millions of years.
psychopaths used more conjunctions such as “because “ or “since,”
Sounds like another attempt to label left-brain people as psychopaths.
Uh... the old "left brain is logical, right brain is creative" stuff is out the window. Please refer to Dr. Ramachandran's work on anosognosia in stroke victims.
I realize that IPv4 is going to be with us for quite some time, but is this going to be worth the effort? It requires a bit of jiggery-pokery to repoint your DNS, the kind of thing that appeals to the Slashdot crowd but which your grandma will never, ever pull off. ISPs could help, but will they do so before IPv6 makes it irrelevant?
It's described in IPv4 terms, but extending it to work with IPv6 addresses should be simple enough. The trickiest part will be finding the golden CIDR mask to replace IPv4 /24. Giving up /64 is too much, since it identifies most ISP customers uniquely, and /48 has similar issues. Probably something near /32 or /40 would be appropriate, although you could probably do a lot with as little as /20.
Other than that, the described technique is still fully relevant because IPv6 doesn't change the game in any other way: DNS still works the same way, HTTP still works the same way, and websites are still slow for the same reasons, so you have the same incentives for regional caching and the same choices in how to do it.
Does anyone else see this as a giant security hole? As in, various schemes like this have been tried since the days of ActiveX, and the only reason ActiveX has the worst reputation is because it's the only one that gained widespread use?
The point of NaCl is that it's a virtual machine bytecode language, and you can statically verify (without running the code) that the bytecode conforms to the spec. However, for performance reasons, the bytecode language and the virtual machine architecture just happen to line up with the native machine code and native architecture. NaCl provides only a subset of the full instruction set, though, and this prevents arbitrary pointer arithmetic or self-modifying code that could break outside the sandbox. NaCl authors actually need to recompile their code to x86 NaCl or ARM NaCl as a distinct GCC compiler target, instead of plain old x86 or ARM, because the NaCl targets are easily distinguishable from the native ones when you examine the machine code bytes. (The most important feature: all jumps are aligned and no ops cross an alignment boundary, so there's only one possible machine code interpretation for each byte of NaCl code.)
Needless to say, this is a vastly different model compared to ActiveX, which was "we'll trust any old native code to make arbitrary system calls, just so long as there's an RSA signature attached". NaCl ditches the central trusted authority model that Microsoft preferred, and instead goes with the Java/JavaScript/Lua/LISP model of "you can only perform side effects that the interpreter chooses to expose to your code". As with the interpreted languages your NaCl code is Turing-complete, so you can waste CPU and RAM until the cows come home, but you can't actually touch the filesystem, create GUI elements, or modify the address space of other processes unless Chrome decides to permit it. The only difference is that you don't run at some fraction of native code speed, but exactly at native code speed, and you can statically optimize as much or as little as you like, or write in any language you want (so long as someone's written a NaCl target for your language's compiler).
There will probably be a few bugs in the static verification logic that allow not-quite-NaCl code to slip through, but this is no worse than the sandboxing problems we already face from Javascript in the browser. With JavaScript, this has even included double free bugs that allowed overwriting arbitrary memory with native code and executing it. The risks with NaCl are no different.
The bright side is that the people who innovated to make the patents are being compensated for their efforts. This is how patents motivate people to innovate. Would you prefer if Google could use other people's innovations without compensating them?
If anything, patents in the software industry cause innovation NOT by rewarding the company that holds the patent so that they will feel inclined to invent more, but by encouraging companies to patent the lowest-hanging fruit and forcing everyone else to invent workarounds as the patent owner lords over the market by charging exorbitant prices. Think of gzip, PNG, Vorbis, Tarkin, and to a lesser extent VP3/Theora and VP8/WebM, which were all developed in response to the patents on LZW and MPEG 1 through 4 because the licensing terms were greater than the market would bear.
Patents give their owners monopoly power, which ipso facto means that the licensing fees charged by the owner will never be at the free market price created by the intersection of supply and demand. Even the MPEG-LA consortium, which actually goes to the effort of trying to invent a "fair" price, doesn't have enough information to actually determine what the fair price would actually be in the absence of a monopoly, e.g. what the MPEG algorithms would sell for if they were a contractually-protected trade secret bought and sold on the open market (the scenario that patents were created to prevent).
I hope so. Dark matter is the ugliest kludge to the standard model ever.
I think you have it confused with dark energy. Dark matter is tame and well-behaved in comparison.
It's worse than the Plus upgrade for Windows 98.
... I think even dark energy makes more sense than THAT.
where the vector "something" is often "velocity"
Just to nit-pick, you mean "the direction of movement". Velocity also implies the magnitude as well as the direction, and I don't see why we need to bring magnitude into the argument.
No, I meant what I said. The noun phrase "<vector X> in the opposite direction of <vector Y>" makes sense for any vectors X and Y, even though it doesn't define a relationship between their magnitudes or otherwise mention them.
In physics, "deceleration" is just an informal shorthand way of saying "acceleration in the opposite direction of something", where the vector "something" is often "velocity" by default but can be anything else depending on context. Saying "Pioneer is decelerating" is not quite right, then: the Pioneer craft are traveling on hyperbolic paths that slingshot away from the Sun on a curve, not zipping away in straight lines, so an acceleration toward the Sun would not point in the opposite direction from the velocity. It would slow them down since the velocity-acceleration angle is obtuse, but not as much as an actual 180 degree acceleration would. (Perhaps the acceleration is Sun-ward instead of backward because the Pioneer craft aligned their spins to keep their radio dishes pointed toward Earth, and asymmetry makes them emit more RTG heat on the opposite side from the dishes? Pure speculation on my part.)
Can we start marking Kurzweil articles as dupes?
Granted, this is a little less ridiculous than some of his past claims — machine translation has improved a lot in the O(decade) since Babelfish — but translation algorithms are still context-blind for the foreseeable future because no one's yet found a computationally feasible shortcut for the "every Bayesian probability is dependent on every other Bayesian probability" case that natural language seems to teeter in the direction of. Moore's law isn't going to fix it, either, because it's not a polynomial-time problem that can be fixed by just throwing faster clocks or more cores at the problem. We've gotten as far as we have by using dumber, polynomial-time algorithms and just throwing supertankers of training data at the problem, but in the end it's no more contextual than Dissociated Press.
Incidentally, it's clear that natural language translation is not actually as difficult as computing the maximum likelihood of a fully cross-connected Bayes network (i.e. superpolynomial-time), or else the human brain itself would be stumped. But we don't know enough about which shortcuts are useful for convincing human brains versus which shortcuts result in "the vodka is good but the meat is rotten" translations. That means we're stuck theorizing from our armchairs, throwing algorithmic crap at the wall and seeing what sticks, or maybe poking at brains with pointy sticks and fMRIs. On this matter, date predictions are worthless. The breakthrough could come tomorrow or hundreds of years from now, and Kurzweil is no better equipped to predict the date than my cat is.
Really, no clear link? Did they even ask one player? These are both low-hanging fruit for the solo completionist. In particular, I suspect that north of 90% of players with the 400 unarmed weapon skill achievement will have World Explorer, although the relationship will be lower in the reverse direction — the former is a bit more of a time investment, and much more boring and tedious (Blizzard removed weapon skills for a reason), whereas World Explorer is something that can be knocked out by an hour-a-day casual player in two weeks with no problem. Since World Explorer can easily be teamed up with book collecting, critter /love-ing, the zone and continent quest completions, and Loremaster, I suspect those all form a single clique of solo completionist achievements, with some sub-cliques that are a bit more accessible to the casual player.
Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source? Should we be pushing to see firmware source too? Instead should it not matter about seeing driver source? I'd love to hear your perspectives.
Device A has an open source driver, proprietary guts, and a firmware blob loaded by the driver on boot.
Device B has an open source driver, proprietary guts, and a firmware blob hidden in an immutable ROM on the device that you don't know about.
For some reason, Debian scorns Device A and praises Device B, even if the firmware blob for Device A allows unlimited redistribution. For the most part I like Debian, but that policy is just silly: Device A is the one that has the greater potential for end-user hackability.
Wait, nevermind. I seem to be confused about something, Wikipedia says the transcendentals are uncountable.
In another universe, perhaps they are ...
For the rest of us, Taylor series are the best oculus I can think of into the known transcendentals (Pi, e, sin(a/b), etc.). However, most transcendentals will remain obscure by virtue of being irrelevant.
Even in this universe, there are uncountably many uncomputable transcendentals. The canonical example of an uncomputable real is Chaitin's constant, which is the probability that a randomly chosen computer program (in some specified language) will halt. We can figure out the first few digits, but beyond that it's seemingly impossible to calculate. If you had a way to iteratively generate the digits in Chaitin's constant, you could solve the halting problem, and vice versa.
My great-grandparent post was under the seemingly mistaken impression that "transcendental" referred to a distinct subset of the reals, something like "the reals with a well-defined Taylor series that are not algebraic", but instead (per Wikipedia) it appears to be "the reals that are not algebraic", which is a vastly larger set.
Wait, nevermind. I seem to be confused about something, Wikipedia says the transcendentals are uncountable. There's probably an argument for why Turing Machines can't be used to uniquely identify arbitrary transcendentals, e.g. there aren't enough Turing Machines to go around (Cantor argument), or you can't prove that a given Turing Machine identifies the transcendental you're seeking (Halting problem), or something.
I'm still fairly convinced that pi is a computable transcendental, and probably likewise for most of the transcendentals that we've given names to, but I now suspect that the majority of the transcendentals don't fall in that category. Oops.
The rational numbers are infinite, the irrational numbers are infinite, add them together and you have the real numbers, which is a "larger" infinite set than the rational numbers (and probably the irrationals, though I can't say for sure since I've never attempted that proof).
Quite right. There are two types of infinite cardinality: countable and uncountable. Countable encompasses the set of rational numbers, and calculable irrationals such as roots and all polynomial combinations of the those for which there is an isomorphic map onto the set of integers. Then there's the greater set, the uncountably infinite, e.g. the transcendental numbers and their ilk.
I doubt the cardinality of real numbers would be greater than irrationals themselves, since most numbers are transcendental. It'd be like taking a teaspoon of water out of the ocean and wondering if it's still the ocean.
To be pedantic, the transcendentals are also countably infinite. The integers, rationals, algebraic irrationals, transcendentals, and quite a few others all fall under the heading of "computable numbers", i.e. numbers whose exact solution can be arrived at by a Turing machine given infinite time and tape. Even though it sounds like a ridiculously large set, the set of computable numbers is countable: for any Universal Turing Machine you like, each computable number maps to the natural number that encodes the initial tape for the UTM such that the UTM simulates any one of the TMs that can generate the computable number in question.
For instance, even though pi is a transcendental and has no algebraic representation, there are well-known algorithms that iteratively generate as many digits of pi as you like. The infinite series of pi digits can thus be replaced with a (finite) computer program implementing one of these algorithms, and any finite series of pi digits can be replaced by the same algorithm plus the number of digits to stop at. A finite approximation of pi is merely cached output from the computer program, and therefore {program U finite approximation} adds no new information beyond {program} to help you distinguish pi from the other real numbers, meaning you can uniquely identify pi with just the computer program and no further information.
if you live in the USA, isn't it a bit of a problem that your chosen media codec solution involves deliberate lawbreaking?
It is -- so I call it civil disobedience.
Notwithstanding your comment about how you already have a patent license through other means, "civil disobedience" isn't the same as "doing it and not getting caught". In the original sense, "civil disobedience" means breaking the law in public, daring the police to arrest you / civil lawsuits to fly, and using the obvious injustice of the response to inflame the public against the bad law. DeCSS in your .signature is civil disobedience, downloading a gray-market codec from a non-US APT repository is merely getting away with it.
...This is on automatic brightness...
FWIW, I highly recommend setting your brightness to the minimum the OS will let you. In my experience, the Nexus One screen is useless in any amount of daylight, no matter how high it cranks up the screen's light levels, so you might as well not waste that energy and find a nice shady spot instead. My "Battery use" screen consistently shows that the display sucks down the vast majority of my power usage, even if I've only had the screen on for 30 minutes throughout the day, and I still get through the day with 40-60% of my battery remaining. In a pinch, I can go 36 hours without charging, especially if I minimize screen activity.
Also, get Watts, and try to correlate the slope of the graph with what you were doing at that time. I found it quite helpful.
"Relatively short drive"? If you live in Berne, Multimap is giving me over 100 miles each way to get to a likely town outside Swizerland. Man, you've got to really want that game!
Beyond the other comment about 100 miles versus 100 years, I also feel compelled to point out that Switzerland is very well connected with its neighbors via a very reasonably-priced passenger rail system. (And with schedules that are extremely... Swiss... to boot.)
It still blows my puny American mind that it's possible to ride a train and arrive in another country, and moreover to do so as a day trip.
Actually, I'm fairly sure you miscounted. When I looked over that list, I only counted 8.
Star Trek: The Motion Picture (Star Trek 1)
Star Trek II: The Wrath of Khan (Star Trek 2)
Star Trek III: The Search for Spock (Star Trek 3)
Star Trek IV: The Voyage Home (Star Trek 4)
Star Trek V: The Final Frontier FNORD (Star Trek 5)
Star Trek VI: The Undiscovered Country (Star Trek 6)
Star Trek: Generations (Star Trek 7)
Star Trek: First Contact (Star Trek 8)
Star Trek: Insurrection FNORD (Star Trek 9)
Star Trek: Nemesis FNORD (Star Trek 10)
Star Trek (2009 - Star Trek 11)
See? There's a mysterious gap between 4 and 6 that I've never been able to figure out, but you can't seriously mean that the new movie gets a +2 added to its sequel number just because it's a reboot.
Now if you'll excuse me, I have a sudden urge to go shopping.
Android devices can mount loopback file systems, overcoming FAT's lack of unix permissions. They did it to install Debian on the G1's SD card.
Yes, and as I said, this is exactly what I keep hearing about as the long-term plan. The problem as I understand it is that it will require significant developer time to write an implementation. The easy part is automatically generating, mounting, and unmounting the encrypted loopbacks as needed. The hard part is changing Dalvik, the GUI, etc. so that they all do something sensible when the SD card is yanked out.
(The naïve solution of "SIGSTOP the missing apps until the SD card is reinserted" could well leave the phone effectively hosed if the app was running in the foreground. There are plenty of full-screen apps that hide the notification panel, and apps can capture a surprisingly large set of keypresses — and games, the most likely candidates for installing to an SD card, are also the most likely candidates for capturing keystrokes and going full-screen. Most users won't care that adb shell still works fine.)
Disclaimer: I work at Google, but not on Android and definitely not as a spokesman for Android, and I would be quite shocked if any of this were news outside the company. I'm fairly sure the bulk of this discussion exists in the public Android bug tracking system, as I remember being pointed there when we all got our shiny ADP1s a year ago and the same question came up. At any rate, the problem space is well known since it afflicts non-Android Linux (esp. Knoppix and other removable-media distros, which solve the problem by copying the entire system image to a RAMdisk).
Is it really that hard to create a directory for each app and to modify the file API to prevent apps from reading/writing outside of their directory?
Why do major surgery on Linux, creating a fork that no one else would touch with a ten foot pole (open source or not), when Linux already implements everything necessary? (Namely per-process UIDs and per-file permissions.)
My understanding is that it's a security measure.
What exactly they're trying to protect against or even if it actually helps, I do not know.
The SD card is FAT-formatted because the phone presents it over USB as a block device, so that PCs and Macs can pretend it's a camera or other media device. But the use of FAT means that the card lacks Unix file permissions, in particular the owner/group info that stops one app from stomping on another app's data. (The device is mounted noexec, to prevent temptation/abuse.) I've seen talk of using Linux's encrypted loopback abilities at some future point, but it's been on the wishlist since the G1 came out so I wouldn't hold my breath.
[...] As for the GPS. That’s not the worst problem. The worst problem is, that without a data connection, GPS is not working and useless. It just tries to find satellites. According to Nokia, it takes up to 40 minutes to get the first fix, then it’s fast. 40 minutes?? A TomTom does it in under two seconds! Like pretty much every GPS device (including phones) out there. [...]
That is either physically impossible or sheer dumb luck, depending on your device.
Some explanation of GPS is in order. For a GPS receiver to work, the GPS network must send it three pieces of data: the almanac data, the ephemeris data, and the current time (to atomic accuracy). Some receivers cheat and can get by without the almanac, at the cost of slow satellite locks and inaccurate position fixes until the almanac is available.
Among other things, the almanac tells the receiver a general, fuzzy idea of where all the satellites are located, and also gives the receiver a chance to measure the amount of ionospheric distortion (the single biggest cause of GPS position errors). The fuzzy satellite positions are valid for about 6 months, but the network only transmits one full copy per 12.5 minutes. You physically can't download it faster than that via the GPS network: GPS transmits in a repeating loop at a mere 50 bits per second, slower than an ancient 300-baud modem. Worse, the ~4KB almanac is only part of the GPS data, so the download rate is even slower than that. Oh, and to add insult to injury, GPS has no error correction, so if a section is corrupted you have to wait another 12.5 minutes for a retransmit.
With the almanac in hand, the receiver next needs the ephemeris data, which provides satellite orbital parameters in detail far beyond what the almanac specifies. This is absolutely mandatory for obtaining a fix. Once downloaded, it's good for about 4 hours, but the data is specific to each individual satellite. One satellite's ephemeris takes 12 seconds to transmit from start to end, but they can be downloaded in parallel. (As with the almanac, there is no error correction. If the receiver misses part or all of an ephemeris, it has to wait 30 seconds for the next retransmission.)
The clock data is similar to the ephemeris, except that it takes only 6 seconds to transmit. It's on the same 30-second retransmit loop as the ephemeris.
With all three pieces of background information at hand, a 60-bit signal every 6 seconds keeps the clock data up-to-date. This is what the receiver is paying attention to once it has a "lock" on a satellite. 3 locked satellites gives a latitude, longitude fix by making some educated guesses. 4 locked satellites gives a far better latitude, longitude fix and adds altitude as well.
In summary, if your TomTom truly has zero almanac data and zero ephemeris data (i.e. it's a fair "first fix" fight), the time to first fix must necessarily lie in the range from 12 seconds to 30 seconds... if the TomTom can download ungarbled and pristine ephemerides from 3 or more satellites simultaneously, without a single bit error among any of them. This also assumes that the TomTom is cheating by foregoing the almanac, trying to get a fix from ephemeris only and not correcting for the ionosphere.
The only possible way you can get the claimed 2-second fix is if the TomTom (a) already has a current almanac (or is deliberately foregoing one), (b) already has current ephemerides for multiple still-visible satellites, (c) already has very fresh clock data for those same satellites, and (d) gets lucky and catches 3 or more of those still-visible satellites with known data that all just happen to be transmitting their respective 60-bit subframe headers (1.2 seconds minimum, 6 seconds maximum) within the same 2-second window. As I recall, the TomTom backs up the almanac, ephemerides, and clock data to fl