That particular use is quite uncommon, but it's increasingly common to stick a recovery root partition in flash (or even in a kernel-embedded RAM disk on a recovery USB drive or similar) so that if you screw up some core configuration you can boot the core system and recover everything else. Keeping it small and self-contained has several advantages. If it's being loaded to RAM on recovery boot, you don't want it to be large and you do want to be able to write the recovery images quickly. If it's in flash (or even a separate FS on the main storage pool) then you don't want it to be too big.
It matters less for big users, who will fix a machine by simply reimaging it and have redundant everything, but if's very useful for a small company that only has a few servers. It's also useful if you're building an appliance and want to be able to have two root partitions that you switch between for atomic updates (boot one, update the other, reboot on the other, always have one bootable root).
The only thing ARM ships that might speed up Dalvik is Thumb-2EE (a.k.a. Jazelle RCT), which neither Dalvik nor ART actually use. No idea what your/proc/cpuinfo is talking about.
Actually, C is used in these cases specifically because it is cross-platform, not for 'platform-specific optimisations'. The core of most of the popular apps on iOS and Android is the same, with a thin layer of platform-specific code, which is Java on Android or Objective-C on iOS. For games, the amount of Java code is typically tiny - create an OpenGL context and pass it to the native code, which is identical on both mobile platforms. This is a big part of the reason why there are so few apps for Windows Phone compared to the other platforms: by forcing WP apps to be entirely managed code, they make it hard to port apps.
Medical and military sounds like mostly Windows shops, with maybe a bit of Linux thrown in. Qt apps on OS X tend to be garbage - you can spot them within a few seconds of launch, because they look vaguely like OS X but don't behave at all like it (e.g. modal dialog boxes, incorrect shortcut keys for text field navigation, preferences that need buttons hitting to take effect, and so on).
The JVM is a clean bytecode virtual machine, which can be implemented in hardware and reasonably compiled to native machine code.
Only one of those is really true. You can implement a stack-based ISA in hardware, but there's a reason that most of the companies that tried it went out of business in the '80s: stack-based ISAs are really hard to get any ILP from and so once pipelining became common they started to be noticeably slower and were completely killed by superscalar register-based architectures.
Wow, that's a pretty old article. ARM9 was introduced in 1997 and pretty much dead for a good 5 or so years. The Jazelle extensions (no, they're not called 'Java extensions', they're called Jazelle DBX) added a decoder alongside the ARM decoder that would execute simple Java instructions natively and trap to the JVM for more complex ones. They were pretty nice for their target (i.e. machines with 2MB or so of RAM) but were surpassed quite a while ago by JIT compilers, for several reasons:
The JVM is stack-based, so it's hard to get any ILP out of a superscalar core and it's even hard to identify hazard-free pairs for a simple in-order pipelined core, so you don't end up packing the pipeline very well.
The javac output is not very well optimised, because it's intended to be consumed by something else that will optimise and doing the optimisation in the front end can hide opportunities later.
Run-time optimisations (trace-based adaptive recompilation) techniques improved a lot
Once ARM devices wanting to run Java had 32-64MB of RAM, you could get better performance with an optimising JIT compiler than with Jazelle and it died. More recent chips have Jazelle RCT (also known as Thumb-2EE) which has some extra instructions for fast bounds checking and so on, but even that isn't used much.
"You're missing the point. You buy stuff like that occasionally and on specific occasions. "
Half the time is occaisonally. Got it.
Are you really that dense? You may be buying gifts for one of your friends half of the time, but you're not buying gifts for one specific friend half of the time. Recommending things that one friend likes when you're shopping for things for a different friend may coincidentally be useful, but probably isn't unless you have a very homogeneous set of friends.
You're missing the point. You buy stuff like that occasionally and on specific occasions. If I have, say, 10 friends for whom I buy birthday presents, and buy 20 things for myself, from Amazon each year, then if you want to recommend things to me then there is absolutely no point in recommending things that one of my friends likes, because there's a very small chance that this will be the time when I'll be buying something for that person. The same applies to seasonal goods, but those patterns are easier to spot because they apply to everyone.
The problem is, if half of the stuff that you buy on Amazon is intended for gifts, then it's very difficult for the algorithm to determine the difference between a pattern with 50% of inputs being false positives, and a completely different pattern. It's quite easy to train a machine learning algorithm to discover that, given these 100 things that you've bought for either yourself or your friends, either you or one of your friends would like something from this other set of items. It's much harder for it to then determine that, at this instant, you're shopping for yourself or a specific friend and that it should narrow the search down to things that person will be interested in.
The point that the grandparent is trying to make is that you don't need to prevent cancer, you need to prevent cancerous cells from having a serious adverse effect on the organism. There are a number of benign growths that have cancer-like properties that people can live with and that don't spread over the body. Being able to differentiate the benign versions from the malignant and kill off the malignant cells would not require eradicating the cancer mechanism, but would (from the perspective of humans outside of the medical profession) count as curing cancer.
I wonder if this will change, given all of the reports about web advertising being a bubble. Advertisers are starting to notice that, for most of them, the ROI is tiny and that's eventually going to trickle up the supply chain. If Microsoft were smart, they'd sell off their ad business while it's still at an overinflated price and then work to kill the market.
The self-destructing cookies plugin for Firefox has the cookie management policy that I want. Sites can leave whatever cookies they want, but they are silently removed when I navigate away from the page (there's also an undo feature, so if I realise after navigating away that I actually wanted the site to store something persistent, I can retrieve it). It also does the same for HTML5 local storage and will aggressively delete tracking cookies from ad networks. It needed basically no configuration other than to whitelist a few sites as I go.
I'd love to see Microsoft and Apple integrate this kind of functionality into IE and Safari. I doubt Google would do the same for Chrome, as they rely too heavily on aggressive tracking for making money. I don't really understand why Apple and Microsoft don't aggressively push privacy features in their browsers: they'd get good PR and hurt one of their competitors at the same time...
Don't get me wrong, DuckDuckGo sounds good. Sounds like they certainly don't actively track you. But I don't see them bragging that they "keep no data to hand over in the first place"
They don't use tracking cookies (their preferences cookies are not identifying, they're just a string of your options, if you've set them), so the most data that they can have for identifying you is the IP address. They've been SSL by default (redirecting from http to https and defaulting to https in search results where available, for example on Wikipedia) for a long time, so you don't suddenly jump into an unencrypted connection as soon as you leave.
One word: Zoning. If you've played SimCity, you have a good idea of the structure of a lot of US cities. For some reason, they decided that places where people live, places where people shop, and places where people work should all be separate and so you need to drive to get between them. In most of the rest of the world, cities formed where villages grew until they were overlapping, so contain a mixture of homes, shops, offices, and so on. In the UK, it's hard to live in a city (or town) and be more than 5 minutes walk from a grocery store and usually a load of other small shops. A big supermarket may be a bit further away, but most deliver so you don't usually need to physically visit them.
Clang has some builtins that allow you to get the carry bit, so you can cheaply write code that branches on carry. We (mostly CERT, I helped a bit) had a proposal for inclusion in C11 that would have added qualifiers on integers explicitly defining their overflow behaviour as trapping or wrapping, along with a model that let this be implemented cheaply (e.g. allowing a set of side-effect-free code to propagate temporary results and only trap if one of them along the way overflowed). Sadly, it didn't make it into the standard.
If you can't call native code, you probably don't have a working JVM. The Oracle JDK and OpenJDK each include around a million lines of C in their standard libraries. That doesn't mean that you won't find it easier to write secure code in Java, it just means that you probably don't have much less C code in your TCB for a Java program than you do for a C one.
Walled gardens like AOL and CompuServe failed because they had to compete with everyone else. In the early '90s, there was a lot of content that was exclusive to AOL or CompuServe. There were a load of small BBS that had their own unique content. And then there was the Internet. Anyone could put something on the Internet and when web browsers started to be easy to install anyone could put up a web page. Individuals would put things up on their ISPs' web space or somewhere like Geocities, big companies would buy their own servers. Small individual ISPs started to spring up, because the cost of entry was low: a rack of modems, a leased line, and a load of phone lines and you could be an ISP. Local ISPs competed by differentiating themselves in various ways (free email, free web space, static IPs, whatever).
Meanwhile, AOL and CompuServe (OSPs - Online Service Providers) were trying to sell access but also be responsible for all of the content. The parallel with Facebook isn't quite there, because they're only selling the content. The problem is that, while there is some content on Facebook, anyone who can access Facebook can also access the whole of the web. They need to somehow justify putting content on Facebook (where only Facebook users can see it) rather than just putting it on a web site. Their argument for this is that they can collect lots of data about potential customers if you do, but it's not clear that this is a good long-term alternative.
That was more true a year ago than it is now. Modern smartphones and data plans mean that email is becoming as easy as SMS for a lot of people who would previously only check it when they actively went to their computer. This is also true of the older generation, who previously might have turned on the computer once every day or two for email, but now increasingly have tablets that can do email, thanks to companies like Amazon selling appliances that are mainly there for videos and ebooks..
The useful gadget to sell would be something cheap (under $50) that has a small array of microphones and listens to a predefined set of tones, then produces calibration data telling your audio source what it needs to do to compensate for the poor acoustics and speaker placement in the owner's living room.
*sends Morse "telegrams" with ham licence and homebrew radio costing about $25 one-off in junk parts*
If you think Morse sent over a Ham radio connection is equivalent to a telegram, then you're missing the point. It's only equivalent if someone prints it off at the far end and couriers it to the recipient.
Can you imagine the number of dit-dah combinations you'd need to memorize for a minimum of 2000 or so kanji?
You'd probably use a short sequence for each of the brushstrokes and compose Kanji like from them. There's an input method (Cangee? Something like that) that works like this with a QWERTY keyboard. From 26 brush strokes, it can compose any Kanji and is apparently the fastest way of entering Kanji on a computer, although it takes a while to learn.
Slashdot Mirror
That particular use is quite uncommon, but it's increasingly common to stick a recovery root partition in flash (or even in a kernel-embedded RAM disk on a recovery USB drive or similar) so that if you screw up some core configuration you can boot the core system and recover everything else. Keeping it small and self-contained has several advantages. If it's being loaded to RAM on recovery boot, you don't want it to be large and you do want to be able to write the recovery images quickly. If it's in flash (or even a separate FS on the main storage pool) then you don't want it to be too big.
It matters less for big users, who will fix a machine by simply reimaging it and have redundant everything, but if's very useful for a small company that only has a few servers. It's also useful if you're building an appliance and want to be able to have two root partitions that you switch between for atomic updates (boot one, update the other, reboot on the other, always have one bootable root).
The only thing ARM ships that might speed up Dalvik is Thumb-2EE (a.k.a. Jazelle RCT), which neither Dalvik nor ART actually use. No idea what your /proc/cpuinfo is talking about.
Actually, C is used in these cases specifically because it is cross-platform, not for 'platform-specific optimisations'. The core of most of the popular apps on iOS and Android is the same, with a thin layer of platform-specific code, which is Java on Android or Objective-C on iOS. For games, the amount of Java code is typically tiny - create an OpenGL context and pass it to the native code, which is identical on both mobile platforms. This is a big part of the reason why there are so few apps for Windows Phone compared to the other platforms: by forcing WP apps to be entirely managed code, they make it hard to port apps.
You can not program 1B android devices in ANSI C.
Yes you can and most of the most-downloaded apps in Google Play use a significant amount of C (often everything except a basic launcher).
Medical and military sounds like mostly Windows shops, with maybe a bit of Linux thrown in. Qt apps on OS X tend to be garbage - you can spot them within a few seconds of launch, because they look vaguely like OS X but don't behave at all like it (e.g. modal dialog boxes, incorrect shortcut keys for text field navigation, preferences that need buttons hitting to take effect, and so on).
The JVM is a clean bytecode virtual machine, which can be implemented in hardware and reasonably compiled to native machine code.
Only one of those is really true. You can implement a stack-based ISA in hardware, but there's a reason that most of the companies that tried it went out of business in the '80s: stack-based ISAs are really hard to get any ILP from and so once pipelining became common they started to be noticeably slower and were completely killed by superscalar register-based architectures.
Once ARM devices wanting to run Java had 32-64MB of RAM, you could get better performance with an optimising JIT compiler than with Jazelle and it died. More recent chips have Jazelle RCT (also known as Thumb-2EE) which has some extra instructions for fast bounds checking and so on, but even that isn't used much.
Half the time is occaisonally. Got it.
Are you really that dense? You may be buying gifts for one of your friends half of the time, but you're not buying gifts for one specific friend half of the time. Recommending things that one friend likes when you're shopping for things for a different friend may coincidentally be useful, but probably isn't unless you have a very homogeneous set of friends.
You're missing the point. You buy stuff like that occasionally and on specific occasions. If I have, say, 10 friends for whom I buy birthday presents, and buy 20 things for myself, from Amazon each year, then if you want to recommend things to me then there is absolutely no point in recommending things that one of my friends likes, because there's a very small chance that this will be the time when I'll be buying something for that person. The same applies to seasonal goods, but those patterns are easier to spot because they apply to everyone.
The problem is, if half of the stuff that you buy on Amazon is intended for gifts, then it's very difficult for the algorithm to determine the difference between a pattern with 50% of inputs being false positives, and a completely different pattern. It's quite easy to train a machine learning algorithm to discover that, given these 100 things that you've bought for either yourself or your friends, either you or one of your friends would like something from this other set of items. It's much harder for it to then determine that, at this instant, you're shopping for yourself or a specific friend and that it should narrow the search down to things that person will be interested in.
The point that the grandparent is trying to make is that you don't need to prevent cancer, you need to prevent cancerous cells from having a serious adverse effect on the organism. There are a number of benign growths that have cancer-like properties that people can live with and that don't spread over the body. Being able to differentiate the benign versions from the malignant and kill off the malignant cells would not require eradicating the cancer mechanism, but would (from the perspective of humans outside of the medical profession) count as curing cancer.
I wonder if this will change, given all of the reports about web advertising being a bubble. Advertisers are starting to notice that, for most of them, the ROI is tiny and that's eventually going to trickle up the supply chain. If Microsoft were smart, they'd sell off their ad business while it's still at an overinflated price and then work to kill the market.
DuckDuckGo also does not appear to offer to act as your Web proxy like Startpage will do.
No, because if they did then they'd be able to track all of your browsing. They don't wish to do this...
The self-destructing cookies plugin for Firefox has the cookie management policy that I want. Sites can leave whatever cookies they want, but they are silently removed when I navigate away from the page (there's also an undo feature, so if I realise after navigating away that I actually wanted the site to store something persistent, I can retrieve it). It also does the same for HTML5 local storage and will aggressively delete tracking cookies from ad networks. It needed basically no configuration other than to whitelist a few sites as I go.
I'd love to see Microsoft and Apple integrate this kind of functionality into IE and Safari. I doubt Google would do the same for Chrome, as they rely too heavily on aggressive tracking for making money. I don't really understand why Apple and Microsoft don't aggressively push privacy features in their browsers: they'd get good PR and hurt one of their competitors at the same time...
Don't get me wrong, DuckDuckGo sounds good. Sounds like they certainly don't actively track you. But I don't see them bragging that they "keep no data to hand over in the first place"
They don't use tracking cookies (their preferences cookies are not identifying, they're just a string of your options, if you've set them), so the most data that they can have for identifying you is the IP address. They've been SSL by default (redirecting from http to https and defaulting to https in search results where available, for example on Wikipedia) for a long time, so you don't suddenly jump into an unencrypted connection as soon as you leave.
One word: Zoning. If you've played SimCity, you have a good idea of the structure of a lot of US cities. For some reason, they decided that places where people live, places where people shop, and places where people work should all be separate and so you need to drive to get between them. In most of the rest of the world, cities formed where villages grew until they were overlapping, so contain a mixture of homes, shops, offices, and so on. In the UK, it's hard to live in a city (or town) and be more than 5 minutes walk from a grocery store and usually a load of other small shops. A big supermarket may be a bit further away, but most deliver so you don't usually need to physically visit them.
We proposed it to WG14, not WG21. It's pretty trivial to add wrapping and trapping integer templates in C++.
Clang has some builtins that allow you to get the carry bit, so you can cheaply write code that branches on carry. We (mostly CERT, I helped a bit) had a proposal for inclusion in C11 that would have added qualifiers on integers explicitly defining their overflow behaviour as trapping or wrapping, along with a model that let this be implemented cheaply (e.g. allowing a set of side-effect-free code to propagate temporary results and only trap if one of them along the way overflowed). Sadly, it didn't make it into the standard.
Integer overflow has absolutely nothing to do with security
Integer overflow has been in the top five causes of CVEs for several years running. Buffer overflows, sadly, are still at the top.
If you can't call native code, you probably don't have a working JVM. The Oracle JDK and OpenJDK each include around a million lines of C in their standard libraries. That doesn't mean that you won't find it easier to write secure code in Java, it just means that you probably don't have much less C code in your TCB for a Java program than you do for a C one.
Walled gardens like AOL and CompuServe failed because they had to compete with everyone else. In the early '90s, there was a lot of content that was exclusive to AOL or CompuServe. There were a load of small BBS that had their own unique content. And then there was the Internet. Anyone could put something on the Internet and when web browsers started to be easy to install anyone could put up a web page. Individuals would put things up on their ISPs' web space or somewhere like Geocities, big companies would buy their own servers. Small individual ISPs started to spring up, because the cost of entry was low: a rack of modems, a leased line, and a load of phone lines and you could be an ISP. Local ISPs competed by differentiating themselves in various ways (free email, free web space, static IPs, whatever).
Meanwhile, AOL and CompuServe (OSPs - Online Service Providers) were trying to sell access but also be responsible for all of the content. The parallel with Facebook isn't quite there, because they're only selling the content. The problem is that, while there is some content on Facebook, anyone who can access Facebook can also access the whole of the web. They need to somehow justify putting content on Facebook (where only Facebook users can see it) rather than just putting it on a web site. Their argument for this is that they can collect lots of data about potential customers if you do, but it's not clear that this is a good long-term alternative.
That was more true a year ago than it is now. Modern smartphones and data plans mean that email is becoming as easy as SMS for a lot of people who would previously only check it when they actively went to their computer. This is also true of the older generation, who previously might have turned on the computer once every day or two for email, but now increasingly have tablets that can do email, thanks to companies like Amazon selling appliances that are mainly there for videos and ebooks..
The useful gadget to sell would be something cheap (under $50) that has a small array of microphones and listens to a predefined set of tones, then produces calibration data telling your audio source what it needs to do to compensate for the poor acoustics and speaker placement in the owner's living room.
*sends Morse "telegrams" with ham licence and homebrew radio costing about $25 one-off in junk parts*
If you think Morse sent over a Ham radio connection is equivalent to a telegram, then you're missing the point. It's only equivalent if someone prints it off at the far end and couriers it to the recipient.
Can you imagine the number of dit-dah combinations you'd need to memorize for a minimum of 2000 or so kanji?
You'd probably use a short sequence for each of the brushstrokes and compose Kanji like from them. There's an input method (Cangee? Something like that) that works like this with a QWERTY keyboard. From 26 brush strokes, it can compose any Kanji and is apparently the fastest way of entering Kanji on a computer, although it takes a while to learn.