There's an increasing amount of good open source software on Android that can replace the Google crap. I'm now using:
OSMAnd, which is actually the reason that I'm still using Android. Best mobile maps app (Nokia's Here is better for driving, but not for walking): offline vector maps that are small enough that you can fit a few entire countries on the phone, offline routing, and so on. The version on the Play store is not as good. I used to use the free version on Play, but actually donated $10 to them after discovering the F-Droid version.
Standalone Calendar is a fork of the AOSP calendar (now replaced by the Google Calendar app on most devices). The UI is not great, but I've not found any mobile calendar app that is. I mostly just use the Calendar Widget on my home screen to look at upcoming events and DAVDroid to sync with my CalDAV / CardDAV server (which also syncs with my laptop).
Open Camera is definitely a geek's calendar app: far more configurable settings than the stock one, but the UI isn't quite as polished.
KQSMS provides a nicer interface to SMS. For backups, SMS Backup+ will sync SMS with an IMAP server.
AnySoftKeyboard provides a configurable set of keyboard layouts and, unlike the Google version, doesn't appear to be spyware.
Firefox on Android is actually pretty nice, and the addition of the Self Destructing Cookies addon makes it a lot nicer than any other Android browser I've tried (cookies are automatically deleted when you navigate away from a page, tracking cookies are deleted periodically while on the page. There's an undo button if you realised that you actually wanted them for one site, and and you can then whitelist just those ones).
I'd love to have a company adopt some of these, polish the UI a bit, and provide an Android phone that ships with them by default, instead of the Google stuff.
I meant cached on the plane, rather than on your device. If they're sticking a few hundred TBs of video on each plane, and you let them know which flight you'll be on, then they can make sure that things on your to-watch list are available.
It's not just that they're complex. The code for decoding them is also not usually with security in mind. Remember that libjpeg was written in an era when a 486 was a high-end machine and all three sites on the web that contained images were pretty trustworthy. It needed to be able to decode and display the image in a limited amount of RAM, on a slow CPU, without the user complaining about the time it took (and it didn't - it was slow, and we complained). Modern CPUs are fast enough that even an interpreted JavaScript PNG or JPEG decoder is fast enough, but video decoding (unless offloaded to an accelerator) is still pretty CPU-intensive, so now video decoders are written with performance as the overriding goal and security a distant second. Doing proper bounds checks costs cycles (and, worse, often breaks autovectorisation), so gets overlooked.
Even without that, it's a good scam. You ask people for money to guarantee something that will happen to some of them anyway. Imagine that the odds are 5%. You get 100 people to pay you the $250. 5 of them are lucky, so you keep $1,250. You refund the other $23,750 (after earning interest on it for a year, say $475 at a conservative 2% interest rate). Now you've made $1,725, for doing precisely nothing.
CPU speed hasn't improved much since the 3 GHz wall
Clock speeds haven't improved much, but instructions per clock (as well as work per instruction) has increased quite a lot. Compare benchmarks of a 3GHz P4 and a 3GHz turbo-bosted i7 on a single-threaded workload and you'll see a huge difference, and that's ignoring that core counts have been going up.
PC monitor resolutions have flattened out with the economies of scale of 1366x768 and 1920x1080 panels
The 4K display on my desk, which cost about £200, on my desk says otherwise, as does the 15" 2880x1800 panel in my laptop and the 10" 1920x1080 in my oldish tablet (the manufacturer's newer model has a higher resolution).
And the form factor for a PC with a preinstalled multi-window OS hasn't changed much because adult human hands haven't changed much
My current laptop is about half the thickness and a lot lighter than the one that I bought from the same manufacturer, with the same market segment about 6 years ago.
It takes light a whole 30 microseconds to travel 9km. Even the total round trip is not going to make much difference to latency. If your jitter is less than 60 microseconds, you're probably doing HFT, not web browsing...
United has started to roll out something like this (they keep telling me about it, while apologising for the fact that it isn't yet in the planes that I happen to be in at the time), where you can stream the video content to your laptop / tablet / phone, rather than watch on the crappy screen on the back of the seat. It's not terrible well thought through, because they don't provide a little slot on the back of the seat to hold the tablet for you, so you have to balance it on the tray table, which they then put food on. I don't know how much they pay for the in-flight entertainment now, but I bet Netflix could undercut them (especially if they provided a limited catalogue to everyone and a less limited catalogue to their customers. One interesting option would be for Netflix customers to indicate their flight number and select things to be cached before boarding, while the plane is at the gate).
Well that just goes contrary to my understanding of what the main CPU is supposed to do, crunch data, and as much of it efficiently as possible in the smallest package available
Why? Especially in a desktop package, space isn't a constraint. Die area is cheap, heat dissipation is expensive. Your choices are either add some rarely-used coprocessors in the available space, or don't use the space. The cost is the same in both cases.
Specialized hardware that's rarely used (relatively speaking) should resides outside of it via PCIe bus assuming latency and bandwidth considerations are met
Latency is one big issue. Another is power. Off-chip communication is slow and very power intensive. The ARM GPUs, for example, compute a hash of each tile before writing it off to the frame buffer, and if the hash is the same as the last time then they don't write it. That extra computation, which only saves a fraction of the total writes is still a net win for power.
I find it slightly ironic that you use SIMD as a counter example. SIMD is precisely the kind of thing that I'm talking about: something that's a big win for some workloads and can be powered off most of the time.
Since the end of Dennard scaling, the transistor budget for new chips has kept increasing, but the powered transistor budget has not (or, at least, at a much lower rate). More L1 or L2 that needs to be powered all of the time is not easily affordable, but something that only runs when most of the rest of the chip is powered down is basically free (especially something as small as a DSP for voice). Expect to see a lot more of this kind of thing: features that give a big speedup or power saving when in use, but are not in use most of the time, are increasingly attractive additions to modern CPUs.
The problem is that it's very hard to detect, if it is true. Modern pseudo-random number generators use a block cypher and can provide output that will meet all statistical tests that you throw at it, but can be easy to compromise if you know the key. If you were the NSA, then you'd want to have some bits in the key known / predictable, but the rest provided by random electrical fluctuation so that anyone else brute-forcing the key would have to search the entire space, but you'd only have to search a much smaller space. For this reason, it's best not to trust hardware random number generators entirely. Using them as an entropy source for Fortuna is fine though (as long as they're not the only entropy source).
The 'new' part is that you can shut down the main CPU entirely and just have a very low-power DSP (and microphone) running. Is put new in quotes, because a number of ARM SoCs have shipped with this feature for a year or two.
No, the message is 'don't trust a large centralised third-part system for communication, it's not operating for your benefit and you will end up losing out in the end'. It's something that people in western countries could do well to learn.
For the sake of argument do you think the government should tell you that you MUST install a home security system, have dead bolts on every exterior door, require exterior doors be steel or solid wood, limit the side of windows to no more than 1" by 1" or require bars? If you violate any of these rules on your structure fine or punish you?
Nope, but that's a flawed analogy. A better analogy would be, if you offer a service that involves storing stuff for other people, being liable for any loss or damage of their property due to negligence. If you run a hotel and your customers are robbed because you use cheap locks that mean that anyone can get into the rooms, then you should be liable. The government doesn't need to force you to enact specific procedures, it just has to prevent you from having any liability shield in the case of gross incompetence.
It's not even a good description of what was happening. Positive clinical trials were published, but if a company had invested in a drug then it would often do a dozen clinical trials. Of these, a few (due to normal statistical variation) would show that there was some correlation with whatever they were looking for, and those are the ones that they'd publish. It's similar to the stock market scam, where you create a dozen funds, trade them at random, and then cherry-pick the one that had done a lot better than the market, claim that it's due to your brilliance and then ask for investors (charging a hefty administration fee to each one).
Right. Start with things like randomising the list of fonts that you claim is installed (or only advertise the web fonts set on every Firefox install). Don't allow JavaScript to enumerate plugins, unless on trusted sites. Don't allow JavaScript to tell whether a link has been coloured as followed (including when rendering via a canvas!).
Incorporate the self-destructing cookies plugin by default: cookies are automatically deleted when you leave a page, unless you explicitly opt in to keeping them (the plugin also has a nice undo mode, where the cookies are not actually deleted, they're just not made available to the web site, so you can later decide that you did want to keep them if something on the site stops working). That plugin is the reason that I use Firefox on Android. Make it more of a selling point.
Unless Firefox is using a different API to other browsers that use this service, they do *not* send the URL to Google, they send a hash. If there is a match with the blacklist, then Google returns the URL. This means that Google is only aware of the URL that you're accessing if they are in the blacklist. I turn it off too, because it's a bit more information leaking than I'm comfortable with, but it's not the same as sending every URL to Google.
I especially like the boot environment upgrade process. The only thing you need to be aware of is not installing new software on your system after the ZFS clone. Otherwise the upgrade process affects you not at all until you're good and ready to boot into it, and at that point if anything goes wrong, you just roll it back and wait for next time.
We currently have a GSoC student working on improving BE support in the ZFS loader. For 11.0, we'll planning on using pkg for the base system (which should make it possible to move between -RELEASE, -STABLE and -CURRENT branches a bit more easily and mean that -STABLE gets wider testing - we've benefitted quite a bit from PC-BSD shipping some experimental stuff). Nexenta has a nice model for apt-clone that inspired the PC-BSD stuff - we'll likely use something similar, so pkg will do a snapshot and then the upgrade, making it trivial to roll back.
I have a hard time believing this. The SMP support in Linux is far more mature than the BSDs.
The fact that you'd make such sweeping generalisations implies that you don't know what you're talking about. The BSDs, in SMP support in particular, are far from homogeneous. FreeBSD began to move away from a giant lock around the entire kernel in 5.0 (2003), about the same time as Linux. Lots of work has gone on in various subsystems to introduce fine-grained locking. Linux tends to apply RCU in a lot of places (some where it's sensible, some where it isn't), which FreeBSD can't because of the patent issues, but benchmarks have shown that RCU scalability is decidedly nonlinear in a lot of places. FreeBSD has been used for a lot of network stack scalability in the last few years. I don't know exactly how Linux compares, but you may recall a job ad at Facebook that was posted a few months ago aiming to hire people to get the Linux network stack up to the same standard within 5 years...
The Linux community has a whole has some ADD notion that tools are disposable and to replace them with the latest greatest tool. This is just a sign that no one put any thought into the original tool.
(FreeBSD developer, so beware that there may be some bias here:) In my observation, there's a tendency for Linux developers to identify a problem and immediately implement and ship a solution. In the FreeBSD community, there's more of a tendency to identify the problem, step back and try to find a more general solution, then implement that. This means that Linux often has the solution right now, whereas FreeBSD often lags a bit, but when the FreeBSD solution exists it's a lot more pleasant to work with (compare kqueue vs epoll + timerfd + eventfd +..., for example).
Both approaches have upsides and downsides. I generally prefer the end result of the FreeBSD approach, but it still sucks when you're in the window (often a couple of years long) where Linux has a bad solution and FreeBSD has no solution at all.
I can't remember if I committed it in the end, but I had code in libcxxrt that did printed a stack trace for uncaught exceptions. It's not very hard. The Itanium EH ABI (i.e. the one that everyone except MS uses) is a two-phase unwinder. First it walks the stack to find where the handler is, then it walks it again actually doing the unwinding. If you don't find a landing pad, then the throw function fails and you can then walk the stack again to get a call stack. You could equally keep track of the function addresses during the initial unwind and wrap them up in the exception object, though you'd probably have to do this in the generic unwinder, as the C++ personality function is only called for C++ stack frames (you can throw C++ exceptions through, C, Objective-C, Ada, Fortran, and so on).
Objective-C's NSException class does a stack walk when it's instantiated (before it's thrown) and records the stack trace for debugging. It's fairly trivial (half a dozen lines of code) to make an exception class in C++ that does the same. The main reason that it's not done by default is that the stack walking is expensive. It's also expensive in Java, but a JITing JVM can optimise based on where the exception lands whether it will ever have its stack trace used (if nothing either rethrows the exception or reads the trace, don't bother computing it).
Java was not designed for low battery power devices with hard real-time constraints
You might want to look at the origin of Java. It grew from the Green Project, which aimed to build a system for battery-powered devices with about 1MB of RAM that needed interactive UIs and to control other devices.
Slashdot Mirror
I'd love to have a company adopt some of these, polish the UI a bit, and provide an Android phone that ships with them by default, instead of the Google stuff.
With the wheel on the front, I initially thought that the picture was of an iPod.
I meant cached on the plane, rather than on your device. If they're sticking a few hundred TBs of video on each plane, and you let them know which flight you'll be on, then they can make sure that things on your to-watch list are available.
It's not just that they're complex. The code for decoding them is also not usually with security in mind. Remember that libjpeg was written in an era when a 486 was a high-end machine and all three sites on the web that contained images were pretty trustworthy. It needed to be able to decode and display the image in a limited amount of RAM, on a slow CPU, without the user complaining about the time it took (and it didn't - it was slow, and we complained). Modern CPUs are fast enough that even an interpreted JavaScript PNG or JPEG decoder is fast enough, but video decoding (unless offloaded to an accelerator) is still pretty CPU-intensive, so now video decoders are written with performance as the overriding goal and security a distant second. Doing proper bounds checks costs cycles (and, worse, often breaks autovectorisation), so gets overlooked.
Even without that, it's a good scam. You ask people for money to guarantee something that will happen to some of them anyway. Imagine that the odds are 5%. You get 100 people to pay you the $250. 5 of them are lucky, so you keep $1,250. You refund the other $23,750 (after earning interest on it for a year, say $475 at a conservative 2% interest rate). Now you've made $1,725, for doing precisely nothing.
CPU speed hasn't improved much since the 3 GHz wall
Clock speeds haven't improved much, but instructions per clock (as well as work per instruction) has increased quite a lot. Compare benchmarks of a 3GHz P4 and a 3GHz turbo-bosted i7 on a single-threaded workload and you'll see a huge difference, and that's ignoring that core counts have been going up.
PC monitor resolutions have flattened out with the economies of scale of 1366x768 and 1920x1080 panels
The 4K display on my desk, which cost about £200, on my desk says otherwise, as does the 15" 2880x1800 panel in my laptop and the 10" 1920x1080 in my oldish tablet (the manufacturer's newer model has a higher resolution).
And the form factor for a PC with a preinstalled multi-window OS hasn't changed much because adult human hands haven't changed much
My current laptop is about half the thickness and a lot lighter than the one that I bought from the same manufacturer, with the same market segment about 6 years ago.
It takes light a whole 30 microseconds to travel 9km. Even the total round trip is not going to make much difference to latency. If your jitter is less than 60 microseconds, you're probably doing HFT, not web browsing...
United has started to roll out something like this (they keep telling me about it, while apologising for the fact that it isn't yet in the planes that I happen to be in at the time), where you can stream the video content to your laptop / tablet / phone, rather than watch on the crappy screen on the back of the seat. It's not terrible well thought through, because they don't provide a little slot on the back of the seat to hold the tablet for you, so you have to balance it on the tray table, which they then put food on. I don't know how much they pay for the in-flight entertainment now, but I bet Netflix could undercut them (especially if they provided a limited catalogue to everyone and a less limited catalogue to their customers. One interesting option would be for Netflix customers to indicate their flight number and select things to be cached before boarding, while the plane is at the gate).
Well that just goes contrary to my understanding of what the main CPU is supposed to do, crunch data, and as much of it efficiently as possible in the smallest package available
Why? Especially in a desktop package, space isn't a constraint. Die area is cheap, heat dissipation is expensive. Your choices are either add some rarely-used coprocessors in the available space, or don't use the space. The cost is the same in both cases.
Specialized hardware that's rarely used (relatively speaking) should resides outside of it via PCIe bus assuming latency and bandwidth considerations are met
Latency is one big issue. Another is power. Off-chip communication is slow and very power intensive. The ARM GPUs, for example, compute a hash of each tile before writing it off to the frame buffer, and if the hash is the same as the last time then they don't write it. That extra computation, which only saves a fraction of the total writes is still a net win for power.
I find it slightly ironic that you use SIMD as a counter example. SIMD is precisely the kind of thing that I'm talking about: something that's a big win for some workloads and can be powered off most of the time.
Since the end of Dennard scaling, the transistor budget for new chips has kept increasing, but the powered transistor budget has not (or, at least, at a much lower rate). More L1 or L2 that needs to be powered all of the time is not easily affordable, but something that only runs when most of the rest of the chip is powered down is basically free (especially something as small as a DSP for voice). Expect to see a lot more of this kind of thing: features that give a big speedup or power saving when in use, but are not in use most of the time, are increasingly attractive additions to modern CPUs.
It's a mobile processor. It will be in laptops, if not in tablets. Power saving in laptops is still important.
The problem is that it's very hard to detect, if it is true. Modern pseudo-random number generators use a block cypher and can provide output that will meet all statistical tests that you throw at it, but can be easy to compromise if you know the key. If you were the NSA, then you'd want to have some bits in the key known / predictable, but the rest provided by random electrical fluctuation so that anyone else brute-forcing the key would have to search the entire space, but you'd only have to search a much smaller space. For this reason, it's best not to trust hardware random number generators entirely. Using them as an entropy source for Fortuna is fine though (as long as they're not the only entropy source).
The 'new' part is that you can shut down the main CPU entirely and just have a very low-power DSP (and microphone) running. Is put new in quotes, because a number of ARM SoCs have shipped with this feature for a year or two.
I remember a friend showing me the Mac built-in speech command stuff back around 1997. It wasn't a great demo: it seemed to interpret everything that he said as 'shut down the computer'. A few years later, this userfriendly comic showed a good reason why voice command is a bad idea.
No, the message is 'don't trust a large centralised third-part system for communication, it's not operating for your benefit and you will end up losing out in the end'. It's something that people in western countries could do well to learn.
For the sake of argument do you think the government should tell you that you MUST install a home security system, have dead bolts on every exterior door, require exterior doors be steel or solid wood, limit the side of windows to no more than 1" by 1" or require bars? If you violate any of these rules on your structure fine or punish you?
Nope, but that's a flawed analogy. A better analogy would be, if you offer a service that involves storing stuff for other people, being liable for any loss or damage of their property due to negligence. If you run a hotel and your customers are robbed because you use cheap locks that mean that anyone can get into the rooms, then you should be liable. The government doesn't need to force you to enact specific procedures, it just has to prevent you from having any liability shield in the case of gross incompetence.
If you actually want an answer, I suggest that you go and read the Coq papers. You might learn something.
It's not even a good description of what was happening. Positive clinical trials were published, but if a company had invested in a drug then it would often do a dozen clinical trials. Of these, a few (due to normal statistical variation) would show that there was some correlation with whatever they were looking for, and those are the ones that they'd publish. It's similar to the stock market scam, where you create a dozen funds, trade them at random, and then cherry-pick the one that had done a lot better than the market, claim that it's due to your brilliance and then ask for investors (charging a hefty administration fee to each one).
Right. Start with things like randomising the list of fonts that you claim is installed (or only advertise the web fonts set on every Firefox install). Don't allow JavaScript to enumerate plugins, unless on trusted sites. Don't allow JavaScript to tell whether a link has been coloured as followed (including when rendering via a canvas!).
Incorporate the self-destructing cookies plugin by default: cookies are automatically deleted when you leave a page, unless you explicitly opt in to keeping them (the plugin also has a nice undo mode, where the cookies are not actually deleted, they're just not made available to the web site, so you can later decide that you did want to keep them if something on the site stops working). That plugin is the reason that I use Firefox on Android. Make it more of a selling point.
Unless Firefox is using a different API to other browsers that use this service, they do *not* send the URL to Google, they send a hash. If there is a match with the blacklist, then Google returns the URL. This means that Google is only aware of the URL that you're accessing if they are in the blacklist. I turn it off too, because it's a bit more information leaking than I'm comfortable with, but it's not the same as sending every URL to Google.
I especially like the boot environment upgrade process. The only thing you need to be aware of is not installing new software on your system after the ZFS clone. Otherwise the upgrade process affects you not at all until you're good and ready to boot into it, and at that point if anything goes wrong, you just roll it back and wait for next time.
We currently have a GSoC student working on improving BE support in the ZFS loader. For 11.0, we'll planning on using pkg for the base system (which should make it possible to move between -RELEASE, -STABLE and -CURRENT branches a bit more easily and mean that -STABLE gets wider testing - we've benefitted quite a bit from PC-BSD shipping some experimental stuff). Nexenta has a nice model for apt-clone that inspired the PC-BSD stuff - we'll likely use something similar, so pkg will do a snapshot and then the upgrade, making it trivial to roll back.
I have a hard time believing this. The SMP support in Linux is far more mature than the BSDs.
The fact that you'd make such sweeping generalisations implies that you don't know what you're talking about. The BSDs, in SMP support in particular, are far from homogeneous. FreeBSD began to move away from a giant lock around the entire kernel in 5.0 (2003), about the same time as Linux. Lots of work has gone on in various subsystems to introduce fine-grained locking. Linux tends to apply RCU in a lot of places (some where it's sensible, some where it isn't), which FreeBSD can't because of the patent issues, but benchmarks have shown that RCU scalability is decidedly nonlinear in a lot of places. FreeBSD has been used for a lot of network stack scalability in the last few years. I don't know exactly how Linux compares, but you may recall a job ad at Facebook that was posted a few months ago aiming to hire people to get the Linux network stack up to the same standard within 5 years...
The Linux community has a whole has some ADD notion that tools are disposable and to replace them with the latest greatest tool. This is just a sign that no one put any thought into the original tool.
(FreeBSD developer, so beware that there may be some bias here:) In my observation, there's a tendency for Linux developers to identify a problem and immediately implement and ship a solution. In the FreeBSD community, there's more of a tendency to identify the problem, step back and try to find a more general solution, then implement that. This means that Linux often has the solution right now, whereas FreeBSD often lags a bit, but when the FreeBSD solution exists it's a lot more pleasant to work with (compare kqueue vs epoll + timerfd + eventfd + ..., for example).
Both approaches have upsides and downsides. I generally prefer the end result of the FreeBSD approach, but it still sucks when you're in the window (often a couple of years long) where Linux has a bad solution and FreeBSD has no solution at all.
Objective-C's NSException class does a stack walk when it's instantiated (before it's thrown) and records the stack trace for debugging. It's fairly trivial (half a dozen lines of code) to make an exception class in C++ that does the same. The main reason that it's not done by default is that the stack walking is expensive. It's also expensive in Java, but a JITing JVM can optimise based on where the exception lands whether it will ever have its stack trace used (if nothing either rethrows the exception or reads the trace, don't bother computing it).
Java was not designed for low battery power devices with hard real-time constraints
You might want to look at the origin of Java. It grew from the Green Project, which aimed to build a system for battery-powered devices with about 1MB of RAM that needed interactive UIs and to control other devices.