You can use a (mini) bluetooth keyboard with it. Not out of the box, but it's not overly complex to set up either. I even saw an app for this appear in the Ovi store a couple of days ago.
Objective C vs Java might have something to do with it. In Objective C the programmer has to take care of more low-level stuff so the potential for errors is larger. Also the compiler will catch fewer problems.
Making it explicit is a very important difference with Java, where every reference can be null. In Rust you can check the formal interface to see whether you can pass a null argument, while in Java you have to check the informal JavaDoc and hope the author documented whether the argument is allowed to be null. Also the Rust compiler will check both the caller (type error if you potentially pass null where it is not allowed) and the callee (pointer must be unpacked explicitly), while in Java the check is only done at run time.
(Just tried it.) You're right, insmod complains of insufficient permissions. It is uid 0 though, but apparently Aegis is blocking certain actions at the kernel level...
Indeed enabling developer mode gets you a non-root terminal or SSH login. You can get real root on N9 through "devel-su" though, so while it's one more step it's still easy enough.
For that price I could get an iPad 2 (or equivalent Android tablet)
I doubt that: currently the iPad 2 is about twice as expensive as the quoted euro prices and equivalent Android tablets aren't significantly cheaper. Tablet prices might drop a bit in the next half year, but not so dramatically.
3G enabled is pointless for modern games if there's a a 20mb cap. It becomes something to only download tiny games on, which don't need a dedicated device.
You can download the games over WiFi and play them online over 3G. Probably the 3G is too slow to download big games anyway even if there wasn't a cap.
No backwards compatability (can't play PS1/PS2 games).
PS1 games could be emulated. Of course, it is very likely Sony will want you to buy the game again instead of letting you put a disk image of your PS1 game on a flash card.
I probably won't be buying one either: for simple games a smartphone will do just fine and for more complex games I prefer a bigger screen.
First, here is the actual PDF instead of some web-based PDF viewer surrounded by dubious ads.
The most damning statement from the report (in my opinion) didn't make the summary: "The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN."
I have worked at company that generated encryption keys and they did so on a PC in a locked rack in a locked room with no network connection; such an approach would have prevented this attack.
This fragment from the timeline is also interesting:
19-Jun-2011 Incident detected by DigiNotar by daily audit procedure 02-Jul-2011 First attempt creating a rogue certificate 10-Jul-2011 The first succeeded rogue certificate (*.Google.com)
So an incident was detected three weeks before the first rogue cert was issued.
I'm somewhere between beginner and experienced myself. Most of the time retaining and releasing is an automatism, but there are tricky cases, such as discarding an object on an observer notification from that same object, that still require being careful. Also, every once in a while I do still make mistakes such as forgetting to unregister a delegate before it's deallocated and it can take a while before I notice that I'm looking at bogus data in the debugger. In Java I spent less time debugging because there are less mistakes you can make and if you do make a mistake, the error report you get is at a higher level and therefore easier to interpret. You don't have to wonder whether you're looking at a real object of type X or just a bunch of random bytes pointed to by an X-pointer.
Java's reflection can do things similar to performSelector, but its syntax is very verbose, so in practice you'll end up declaring explicit interfaces for everything that you would handle with an implicit interface in Objective C. This is the main drawback of Java in my opinion: in order to get the "no unpleasant surprises" benefit you have to spell everything out for the compiler. In my ideal language the compiler would detect the implicit interfaces you are using and make a fuss if you pass something that doesn't fulfill the required interface ("argument of type X is not guaranteed to provide method M").
The original poster claimed that Objective C is as easy as Java without requiring a VM, so I think that makes the comparison meaningful in this context. It might be possible to get most of the benefits from languages like Java by having a smarter compiler instead of a VM, but I haven't seen it happen yet.
In Objective C you have to manually retain and release, unlike for example Python where the refcounting is done by the language itself (Python has mark-and-sweep too, but you can disable it at runtime and break reference cycles manually). Recently automatic reference counting support was added to Clang, if that is transparent enough to the user I think it would be valid to call that a form of garbage collection, but I haven't been in a situation where I could use it yet.
I've never used Vala, but Objective C is certainly not as easy as Java. Especially if you target iOS, where you don't have garbage collection. The main difference is that bugs are much easier to spot in Java: much is checked at compile time and if something goes wrong at run time you get a stack trace that is at least semi-informative. In Objective C, a lot of problems only show up at run time and then you might get useless stack traces, especially if the top of the stack is in a library of which you don't have the source code (again, iOS). Even calling a non-existing method is a run time error; for a direct call you do get a warning from the compiler, but if you call via @selector, one ":" too many or too little only is the difference between running fine and a crash.
I do think (hope?) you're right in theory, but Objective C vs Java is not a valid example in my opinion.
It's made by Logilab, who also made pylint, a static code checker for Python. The logilab.org site runs on CubicWeb, so they are eating their own dog food.
I'd seriously doubt that a government funded project for voting polls would have such _easy_ to compromise security features.
Diebold employees said their ATMs are more secure than their voting machines because the customer is willing to pay for security. It seems the government wants cheap machines even if that means less secure.
you will find that statistical anomalies will be verified, things like 1 machine (or 1 vote counter) has an unusual candidate count compared to counts done by adjacent machines.
But how can you verify if there is no paper trail or if the paper trail cannot be trusted either?
Also how exactly would a single machine be able to falsify votes on any meaningful scale undetected? there would be huge statistical anomalies
Attacks might not be limited to a single machine. There are thousands of identical machines, so compromising for example 100 machines is not 100 times as hard as compromising a single one. If the attacker can modify the code before it is deployed on the machines, all machines of a certain type would be compromised. If the attacker can modify the machines after installation but before transport, for example by breaking into or otherwise having access to a storage facility, large numbers could be compromised. If the machines have WiFi enabled (this has been reported), a single attack might be able to compromise multiple machines very quickly.
then there is also the challenge of accessing the machines, (as difficult as accessing a balled box really).
The main problem is that it's very hard to detect whether a machine has been compromised. If you have a ballot box that for example already contains votes before the election begins, it's easy to spot. If a voting machine has been compromised, it will look exactly the same as one that has not.
Also, voting machines are much more complex equipment than a ballot box, so there are far more opportunities to exploit (much larger attack surface). For example, the voting software itself is audited, but what about the OS, the drivers, the compilers, the hardware?
there are ways of doing this right to be more secure than paper voting, as well as cheaper in the long term (paper voting requires people counting...)
I do believe secure voting machines could be built. However, insecure voting machines have been built and are being used in elections and I'm surprised few people have a problem with that.
to get away with it completely unscathed, the political party would have to have control over all the regional media (to give people the impression they are winning), access to the machine that takes the votes, access to the server who counts the votes, tackle the paper trail that's designed to prevent exactly this kind of abuse etc. etc. etc.
Vote results rarely turn out exactly as predicted; only if the differences are really large it will be seen as a sign of fraud. If a new party would win an election out of the blue, it would be very suspicious. Because of gerrymandering and winner-takes-all systems, the overall winner between the two established parties can be decided by a relatively small amount of votes. The local media headlines won't say "fraud!" if a party that was predicted to get 48% of the votes gets 53% on election day.
If the machine that takes the votes is compromised, it will report the wrong count to the central server, so the central server does not have to be compromised for the fraud to work. A paper trail would help against tampering with the machine that takes the votes, but a lot of the machines either have no paper trail or have one that could be compromised just as easy as the electronic count.
Auditing is useful, but you have to be sure that the software that was audited is also the software that is used on election day (there have been reports of this not being the case) and that the software is secure against exploitation after the voting machine's installation (some voting machine software is of very low quality, so likely to be prone to exploits).
I think in theory it is possible to design a hybrid system that has a proper paper trail for safety and an electronic count to get the results quickly on election night. But today's practice of electronic voting has such low security standards that it's better to vote using paper only.
SDL is actually pretty modular. You can tell SDL_Init() which subsystems you want to use. For example, you could use SDL for video and input, use libao for audio and use pthreads for threading.
For most games, SDL is good enough. If you're going to be pushing thousands of custom events per seconds through the queue, it should be optimized. If you're just going to process button presses, SDL's event queue implementation is not going to be the bottleneck. And if you're targeting a device with only 1 CPU core, you're probably better off running the entire game on the main thread rather than doing lots of fancy multi-threading.
May I suggest the Dingoo A320? It's cheap, it's powerful enough for 2D games, it can run Linux and it is actually available. Or if you want something more powerful but also more expensive, the Caanoo.
The nD looks nice on paper, but if you've followed the Pandora story you'll know it's far from easy to get a device produced, especially if you've never done such a thing before. Also the $10 price point does not sound very realistic to me.
Even though I do think copyright itself is a good idea, I often find myself on the "pirate side" of the debate because the content industry is abusing copyright:
- copyright extensions have very little to do with promoting the creation of new content, which is what copyright is supposed to be for
- calculated damages from piracy are often highly unrealistic (both "piracy is costing the industry X billion per year" press releases and damages in lawsuits)
- unnecessary restrictions in content use (unskippable commercials, blocking of format shifting) are enforced via copyright
- bad legislation (three strikes, privacy invasion) is being lobbied for by the industry
- if I had to choose between abandoning copyright and living in a police state, I'd choose the former (*1)
- the industry should put more effort into making the content accessible for a reasonable fee (*2)
*1: I don't think those are the only two options but it's important to realize that copyright enforcement at all costs would lead us to a very undesirable society.
*2: There is progress being made here. Nowadays I can buy most music as files without DRM for acceptable prices, although I would like to see more competition (why does Amazon sell songs in fewer EU countries than Apple?). DVD boxes of TV series are now priced at levels where you can consider buying them even if you're going to watch them just once or twice. Streaming video is still hopeless though, nothing like Hulu here yet. Things like football (soccer) matches are available for paid live streaming now, but at 6 euros a match I'm not going to order it unless I want to see that match really bad. Since ad-supported matches on TV can be profitable, then either my semi-attention for ~15 minutes of ads is worth 6 euros or the streaming price is not based costs.
Many articles about copyright are about copyright abuses. I could post every time that while I am against copyright abuse I do think copyright in general should be respected, but like Greyfox said, I don't have the energy for it.
This kind of shite would NEVER be accepted in a mature x86 based project.
Many of the problems that embedded Linux projects have come from packages that are mature on x86 but not on embedded architectures. One reason is that x86 is not strict about memory alignment, but on for example PPC or MIPS (I don't know about ARM) you get hit by a SIGBUS if you break alignment rules. But the main issue is that cross compilation is broken on many packages.
Some try to run the compiled binaries as part of the build process. Some detect cross compilation and then use different implementations of some routines, which are often broken because they are not re-tested as the code around them changes. Some detect cross compilation and then preemptively disable features that they fear might be broken, so you'll end up with a working application lacking a feature you want.
The article was about the kernel, but in my opinion the user space is in even worse shape than the kernel.
The NanoNote has a USB device controller, but no USB host controller. So you can connect it to a PC and run ethernet over USB, but you cannot connect other devices directly to the NanoNote.
Slashdot Mirror
There is always some risk in preorders, but I think this one is relatively safe:
Or what about Slightly Annoyed Rodents?
You can use a (mini) bluetooth keyboard with it. Not out of the box, but it's not overly complex to set up either. I even saw an app for this appear in the Ovi store a couple of days ago.
0.75 percent point. The relative difference is quite large.
Objective C vs Java might have something to do with it. In Objective C the programmer has to take care of more low-level stuff so the potential for errors is larger. Also the compiler will catch fewer problems.
Making it explicit is a very important difference with Java, where every reference can be null. In Rust you can check the formal interface to see whether you can pass a null argument, while in Java you have to check the informal JavaDoc and hope the author documented whether the argument is allowed to be null. Also the Rust compiler will check both the caller (type error if you potentially pass null where it is not allowed) and the callee (pointer must be unpacked explicitly), while in Java the check is only done at run time.
(Just tried it.) You're right, insmod complains of insufficient permissions. It is uid 0 though, but apparently Aegis is blocking certain actions at the kernel level...
Indeed enabling developer mode gets you a non-root terminal or SSH login. You can get real root on N9 through "devel-su" though, so while it's one more step it's still easy enough.
1 in 17, actually.
For that price I could get an iPad 2 (or equivalent Android tablet)
I doubt that: currently the iPad 2 is about twice as expensive as the quoted euro prices and equivalent Android tablets aren't significantly cheaper. Tablet prices might drop a bit in the next half year, but not so dramatically.
3G enabled is pointless for modern games if there's a a 20mb cap. It becomes something to only download tiny games on, which don't need a dedicated device.
You can download the games over WiFi and play them online over 3G. Probably the 3G is too slow to download big games anyway even if there wasn't a cap.
No backwards compatability (can't play PS1/PS2 games).
PS1 games could be emulated. Of course, it is very likely Sony will want you to buy the game again instead of letting you put a disk image of your PS1 game on a flash card.
I probably won't be buying one either: for simple games a smartphone will do just fine and for more complex games I prefer a bigger screen.
First, here is the actual PDF instead of some web-based PDF viewer surrounded by dubious ads.
The most damning statement from the report (in my opinion) didn't make the summary: "The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN."
I have worked at company that generated encryption keys and they did so on a PC in a locked rack in a locked room with no network connection; such an approach would have prevented this attack.
This fragment from the timeline is also interesting:
19-Jun-2011 Incident detected by DigiNotar by daily audit procedure
02-Jul-2011 First attempt creating a rogue certificate
10-Jul-2011 The first succeeded rogue certificate (*.Google.com)
So an incident was detected three weeks before the first rogue cert was issued.
I'm somewhere between beginner and experienced myself. Most of the time retaining and releasing is an automatism, but there are tricky cases, such as discarding an object on an observer notification from that same object, that still require being careful. Also, every once in a while I do still make mistakes such as forgetting to unregister a delegate before it's deallocated and it can take a while before I notice that I'm looking at bogus data in the debugger. In Java I spent less time debugging because there are less mistakes you can make and if you do make a mistake, the error report you get is at a higher level and therefore easier to interpret. You don't have to wonder whether you're looking at a real object of type X or just a bunch of random bytes pointed to by an X-pointer.
Java's reflection can do things similar to performSelector, but its syntax is very verbose, so in practice you'll end up declaring explicit interfaces for everything that you would handle with an implicit interface in Objective C. This is the main drawback of Java in my opinion: in order to get the "no unpleasant surprises" benefit you have to spell everything out for the compiler. In my ideal language the compiler would detect the implicit interfaces you are using and make a fuss if you pass something that doesn't fulfill the required interface ("argument of type X is not guaranteed to provide method M").
The original poster claimed that Objective C is as easy as Java without requiring a VM, so I think that makes the comparison meaningful in this context. It might be possible to get most of the benefits from languages like Java by having a smarter compiler instead of a VM, but I haven't seen it happen yet.
In Objective C you have to manually retain and release, unlike for example Python where the refcounting is done by the language itself (Python has mark-and-sweep too, but you can disable it at runtime and break reference cycles manually). Recently automatic reference counting support was added to Clang, if that is transparent enough to the user I think it would be valid to call that a form of garbage collection, but I haven't been in a situation where I could use it yet.
I've never used Vala, but Objective C is certainly not as easy as Java. Especially if you target iOS, where you don't have garbage collection. The main difference is that bugs are much easier to spot in Java: much is checked at compile time and if something goes wrong at run time you get a stack trace that is at least semi-informative. In Objective C, a lot of problems only show up at run time and then you might get useless stack traces, especially if the top of the stack is in a library of which you don't have the source code (again, iOS). Even calling a non-existing method is a run time error; for a direct call you do get a warning from the compiler, but if you call via @selector, one ":" too many or too little only is the difference between running fine and a crash.
I do think (hope?) you're right in theory, but Objective C vs Java is not a valid example in my opinion.
No, that is Unladen Swallow.
It's made by Logilab, who also made pylint, a static code checker for Python. The logilab.org site runs on CubicWeb, so they are eating their own dog food.
I'd seriously doubt that a government funded project for voting polls would have such _easy_ to compromise security features.
Diebold employees said their ATMs are more secure than their voting machines because the customer is willing to pay for security. It seems the government wants cheap machines even if that means less secure.
you will find that statistical anomalies will be verified, things like 1 machine (or 1 vote counter) has an unusual candidate count compared to counts done by adjacent machines.
But how can you verify if there is no paper trail or if the paper trail cannot be trusted either?
Also how exactly would a single machine be able to falsify votes on any meaningful scale undetected? there would be huge statistical anomalies
Attacks might not be limited to a single machine. There are thousands of identical machines, so compromising for example 100 machines is not 100 times as hard as compromising a single one. If the attacker can modify the code before it is deployed on the machines, all machines of a certain type would be compromised. If the attacker can modify the machines after installation but before transport, for example by breaking into or otherwise having access to a storage facility, large numbers could be compromised. If the machines have WiFi enabled (this has been reported), a single attack might be able to compromise multiple machines very quickly.
then there is also the challenge of accessing the machines, (as difficult as accessing a balled box really).
The main problem is that it's very hard to detect whether a machine has been compromised. If you have a ballot box that for example already contains votes before the election begins, it's easy to spot. If a voting machine has been compromised, it will look exactly the same as one that has not.
Also, voting machines are much more complex equipment than a ballot box, so there are far more opportunities to exploit (much larger attack surface). For example, the voting software itself is audited, but what about the OS, the drivers, the compilers, the hardware?
there are ways of doing this right to be more secure than paper voting, as well as cheaper in the long term (paper voting requires people counting...)
I do believe secure voting machines could be built. However, insecure voting machines have been built and are being used in elections and I'm surprised few people have a problem with that.
to get away with it completely unscathed, the political party would have to have control over all the regional media (to give people the impression they are winning), access to the machine that takes the votes, access to the server who counts the votes, tackle the paper trail that's designed to prevent exactly this kind of abuse etc. etc. etc.
Vote results rarely turn out exactly as predicted; only if the differences are really large it will be seen as a sign of fraud. If a new party would win an election out of the blue, it would be very suspicious. Because of gerrymandering and winner-takes-all systems, the overall winner between the two established parties can be decided by a relatively small amount of votes. The local media headlines won't say "fraud!" if a party that was predicted to get 48% of the votes gets 53% on election day.
If the machine that takes the votes is compromised, it will report the wrong count to the central server, so the central server does not have to be compromised for the fraud to work. A paper trail would help against tampering with the machine that takes the votes, but a lot of the machines either have no paper trail or have one that could be compromised just as easy as the electronic count.
Auditing is useful, but you have to be sure that the software that was audited is also the software that is used on election day (there have been reports of this not being the case) and that the software is secure against exploitation after the voting machine's installation (some voting machine software is of very low quality, so likely to be prone to exploits).
I think in theory it is possible to design a hybrid system that has a proper paper trail for safety and an electronic count to get the results quickly on election night. But today's practice of electronic voting has such low security standards that it's better to vote using paper only.
SDL is actually pretty modular. You can tell SDL_Init() which subsystems you want to use. For example, you could use SDL for video and input, use libao for audio and use pthreads for threading.
For most games, SDL is good enough. If you're going to be pushing thousands of custom events per seconds through the queue, it should be optimized. If you're just going to process button presses, SDL's event queue implementation is not going to be the bottleneck. And if you're targeting a device with only 1 CPU core, you're probably better off running the entire game on the main thread rather than doing lots of fancy multi-threading.
May I suggest the Dingoo A320? It's cheap, it's powerful enough for 2D games, it can run Linux and it is actually available. Or if you want something more powerful but also more expensive, the Caanoo.
The nD looks nice on paper, but if you've followed the Pandora story you'll know it's far from easy to get a device produced, especially if you've never done such a thing before. Also the $10 price point does not sound very realistic to me.
Even though I do think copyright itself is a good idea, I often find myself on the "pirate side" of the debate because the content industry is abusing copyright:
*1: I don't think those are the only two options but it's important to realize that copyright enforcement at all costs would lead us to a very undesirable society.
*2: There is progress being made here. Nowadays I can buy most music as files without DRM for acceptable prices, although I would like to see more competition (why does Amazon sell songs in fewer EU countries than Apple?). DVD boxes of TV series are now priced at levels where you can consider buying them even if you're going to watch them just once or twice. Streaming video is still hopeless though, nothing like Hulu here yet. Things like football (soccer) matches are available for paid live streaming now, but at 6 euros a match I'm not going to order it unless I want to see that match really bad. Since ad-supported matches on TV can be profitable, then either my semi-attention for ~15 minutes of ads is worth 6 euros or the streaming price is not based costs.
Many articles about copyright are about copyright abuses. I could post every time that while I am against copyright abuse I do think copyright in general should be respected, but like Greyfox said, I don't have the energy for it.
This kind of shite would NEVER be accepted in a mature x86 based project.
Many of the problems that embedded Linux projects have come from packages that are mature on x86 but not on embedded architectures. One reason is that x86 is not strict about memory alignment, but on for example PPC or MIPS (I don't know about ARM) you get hit by a SIGBUS if you break alignment rules. But the main issue is that cross compilation is broken on many packages.
Some try to run the compiled binaries as part of the build process. Some detect cross compilation and then use different implementations of some routines, which are often broken because they are not re-tested as the code around them changes. Some detect cross compilation and then preemptively disable features that they fear might be broken, so you'll end up with a working application lacking a feature you want.
The article was about the kernel, but in my opinion the user space is in even worse shape than the kernel.
It's based on Ingenic JZ4720, a little endian MIPS processor with many integrated peripherals.
The NanoNote has a USB device controller, but no USB host controller. So you can connect it to a PC and run ethernet over USB, but you cannot connect other devices directly to the NanoNote.