But root is still the key capability in configuring the environment.
And Linux distros always have a way for root to disable boot-time or run-time SE Linux.
in SE/Linux, root is "parallel-tracked". in SE/Linux it's just yet another username. in fact, there is no such concept as usernames under FLASK. uids are just a convenient piece of information to place into the "security context" but so is the filename, directory name, port number, protocol (UDP, TCP), ip address - all these things are *also* part of the security context. more recently they've extended SE/Linux so that X11 primitives can also be added to the security context.
the classic example is "root", which is a drastic binary oversimplification which is simply very convenient.
Indeed, but in the case of SE Linux the Five Star General ( root ) is also the guy who writes the rules about where he is allowed to go and what he is allowed do ( SE Linux config ).
ah *no*! he most definitely is not! again, you may be under the mistaken impression that the 5 star general has more power than he appears. if he were to start ordering people to bypass security measures, that would seriously be a breach of standard security protocol and his subordinates would report him.
but you may have misunderstood: if a 5 star general walks out of a secure area without his passport, how is he going to get on a commercial flight? he doesn't have a passport, because he didn't return his badge at the gate. mr 5 star general doesn't have control over commercial flights, does he? without identification papers, he doesn't even have control over *military* flights, let alone commercial ones.
in other words, you've misunderstood the analogy, because you are under the mistaken assumption that even a 5 star general actually has any "power" or "authority" outside of his domain and responsibilities: he doesn't. it's *all* about context, *not* about the "person". in other words it doesn't matter if he's a 5 star general, if he steps outside of the bounds of responsibility within the context that he's SPECIFICALLY been tasked to do, in that physical location, at that specific time, and under the specific circumstances, then all hell breaks loose and security alarms go off like mad.
is that clearer?
taking this away from the analogy, the OEM would prepare the OS, set the SE/Linux files up, digitally-sign the bootloader, flash it into ROM, digitally-sign the kernel, require the bootloader to check it.... then give *you* the root password, knowing full well that because SE/Linux is permanently enabled it is flat-out impossible for you - even though you have root access (a 5 star general) - to even replace the kernel, because the SE/Linux permissions explicitly forbid overwriting of the boot partition. and even though you have root, the SE/Linux permissions forbid you from chmodding the boot subdirectory.
SE Linux doesn't make root go away, it just usefully reduces the need for root day-to-day. But root is still the key capability in configuring the environment.
And Linux distros always have a way for root to disable boot-time or run-time SE Linux.
not in treacherous DRM-locked systems they don't - the ones where the bootloader is in a digitally-signed ROM which you cannot modify, where the kernel and its boot parameters are also digitally-signed and cannot be modified.
this is really important. people who don't know what ssh keys are will typically send you the id_rsa (private) key file.
IT IS VERY IMPORTANT that you say to them EXPLICITLY and VERY CLEARLY, "please send me the public key file *only*. DO NOT send me the PRIVATE key. you can identify the private key because it is named xyz. i ONLY want you to send me the PUBLIC key, it is named xyz.pub. if you send me the private key, you will have to destroy it and we will have to start again, so ONLY send me the PUBLIC key, ok?"
and get them to acknowledge what you've said. do not be afraid to "piss them off" by having to be so absolutely specific. make sure you end the sentence with what you *want* them to do, *not* what you *don't* want them to do. depending on the person they could potentially remove the "negative" by their subconscious and do exactly what you ask... with the words "no", "not", "don't" etc. removed.
also if you want to be paranoid then use the signature-thing (fingerprint). get them to read it out to you over the phone (not by email).
doctor who is great because he always "solves the problem". so many TV programs - especially soap operas - teach and encourage people to complain or to take revenge on others.
there's an extremely common mistake made which needs to be pointed out: the clue is in the phrase "This kind of top-down thinking". the fundamental assumption is that there is a concept of "more privilege is required than before" to achieve privileged tasks. people imagine that security is hierarchical - that the further towards "the top" you get, the more access you are permitted. this is simply NOT TRUE. the classic example is "root", which is a drastic binary oversimplification which is simply very convenient.
so, people invent new security systems, but they invent them without actual proper thought towards design, and they invent them thinking that this "top down" hierarchical approach is the only way. thus, new APIs have to be invented.
there is another way: it's called SE/Linux (and there's a variant called SE/Android). SE/Linux follows the FLASK model, which basically says that based on the current context, the current application, that a new executable is given a COMPLETELY new security context, where the new privileges have to be explicitly given. the most important implication of this model is: it absolutely does not matter how "powerful" you were in the previous context - the one that fires up the new executable; the new one is literally a completely and utterly separate security context.
to give an example: take a 5 Star General, and send him to a security base. when he gets there, standard security procedure: they take away his passport and all his credentials, and they give him a security pass (a new context). that security pass has a pre-prepared set of restricted corridors and rooms that the 5 Star General can go to. he can go to the conference room, and the bathroom. if he tries to leave without returning the security pass, he has no passport, and no papers.
this incredibly powerful security model - FLASK basically fits on top of an OS *without* interfering with it. it's particularly fascinating because it can watch which programs exec() other programs, and it can watch what APIs those programs use.... *without* needing to actually modify those programs.
basically what i'm saying is that the problem that cyanogen is trying to solve already has a way in which it can be solved, if the SE/Android team haven't already solved it. and that's because, under SE/Linux and SE/Android, you can operate both the normal "root access" system *in parallel* with SE/Linux. all you need to do is create a FLASK security context which restricts access to only those applications that *should* be accessing the restricted APIs. you don't need to modify the applications, nor do anything special to the underlying OS.
I mean, does a tablet with a removable CPU card make any sense whatsoever?
ah you've heard of the openmoko and the openpandora, then? how long did their designs take, and did the components go end-of-life in one case before they'd completed the design?:)
Well, the big philosophical idea is that ANY EOMA-68 CPU card slots in ANY EOMA-68 machine (note that EOMA is not entirely, or even primarily about tablets -- that's just the first hardware product using it), and works. That's why Luke (aka lkcl) is quite adamant there are no "optional" features in the spec -- the only exception is for interfaces (e.g. USB, 10/100/1000-BASE-T) that can fully autonegotiate in both directions, so that there's neither a slow-machine/fast-cpu-card, nor slow-cpu-card/fast-machine case where it becomes incompatible.
yup. that's about the long and short of it. although it's at first consideration a complete pain for system designers on both sides of the interface - a nuisance for CPU Card designers because they have to substitute extra ICs such as USB-to-SATA in cases where they pick a SoC that doesn't have SATA - and bewilderment for I/O Board designers because why would they use a CPU Card in e.g. a tablet that has features they don't need such as Ethernet?? - the alternatives are absolute chaos.
the advantage: you can tell the average end-user "just buy one of these, it will work".
the alternative: think about this scenario as it is in many other standards such as Q-Seven , where you allow ethernet to be "optional" and you allow the I/O boards to "recreate" ethernet say using USB-to-Ethernet. how do you route that? well, if you think about it what you have to do is actually put down an Ethernet Hub IC on *every single I/O board*, and some sort of crazed switching, as well as put down a USB-to-Ethernet converter IC and probably a USB Hub IC as well... because the designers of the I/O board will never know if an end-user is going to plug in a CPU Card that has native Ethernet or is expecting it to be left up to the I/O Board using USB.
now expand that chaos out to SATA as well, as well as any other interfaces, and you can see immediately that a non-optional standard results in instant chaos. it's fine for Q-Seven (well... it's not. not really) where the expectation is that the Q-Seven Cards will never be removed from their carrier boards, but then why build a standard where the end-user is never expected to upgrade their system without needing a specialist degree in engineering in order to assess if the upgrade will even work?
the guiding principles behind the EOMA standards are: it must be SIMPLE, it must be OPEN, and it must work in HUGE volume.
why didn't they post stories on slashdot?? then they would have got some attention. in fact... hang on: why have i *never* seen an article on h-online cross-referenced anywhere, and why have i *never* seen them in a google search??
how about... just accepting that the country's bringing up kids who are dumb, and being happy with that? by contrast: in japan, kids are taught to be able to do mental arithmetic at lightning speed. tests involve flashing up 6-digit sums for 1/3 of a second every couple of seconds.
hmmm... is this the password that by default if you've never set it is set to the 1st 4 digits of your Social Security Number, like it is for Bell South? and how many retries are you allowed on the login? it's not 9,999 is it? and what are the first 3 digits of a SSN? why that'll be the area you were born, which probably closely match with the area code of the telephone number. that just leaves 2 digits left to guess...
there's a story i heard about the origins of linux, which was told to me a few years ago at a ukuug conference by a self-employed journalist called richard. he was present at a meeting in a secure facility where the effects of "The Unix Wars" were being exploited by Microsoft to good effect. the people at the meeting could clearly see the writing on the wall - that the apx-$10,000s cost of Unixen vs the appx-$100s of windows would be seriously, seriously hard to combat from a security perspective. their primary concern was that the [expensive] Unixen at least came with source: microsoft was utterly proprietary, uncontrolled, out of control, yet would obviously be extremely hard to justify *not* being deployed in sensitive government departments based on cost alone.... so the decision was made to *engineer* a free version of Unix. one of the people at the meeting was tasked with finding a suitable PhD student to "groom" and encourage. he found linux torvalds: the rest is history.
now we have SE/Linux - designed and maintained primarily by the NSA.
the bottom line is that the chances of this speculation being true - that the NSA has placed back-doors in GNU/Linux or its compiler toolchain - are extremely remote. you have to bear in mind that the NSA is indirectly responsible for securing its nation's infrastructure. adding in backdoors would be extremely foolish.
the problem with the proposal that you've created is that if the phone is hacked then any number of one-off closed accounts can be created and transferred from your "actual bank account". what this tells us is that the actual problem is the concept of trying to use a general-purpose processor which is capable of running unverifiably-complex general-purpose software as a method of payment. it.... just.... doesn't.... add... up.
what's the very next article right here on slashdot? an article about how the inventor of PGP cannot properly implement ZRTP, a security application for smart phones. clinkle - starting from scratch - on a payment system for smart phones, making it a high-profile target. this is going to end well.
the PDP-11 is awesome. i believe its instruction set was the inspiration for the 6800 (http://en.wikipedia.org/wiki/Motorola_6800#MC6800_microprocessor_design yes it was) which then resulted in the 68000 all the way up to the 68040, processors which both commodore and amiga used to great effect up until the early 90's. at imperial college we didn't write a compiler for 68000 or even x86, we wrote a compiler for the PDP-11 instruction set.
the other thing is: if they're still running PDP-11's in large geometries (.35 micron or even bigger) then chances are it'll be much more robust and less prone to random radiation hits/changes. the kind of thing you really really REALLY want to be still working and under computer control is the "emergency shutdown" procedures in the event of a radiation leak. the LAST thing you want is one of the bits changing a floodgate to "open" instead of "shut" due to a random gamma ray flipping a bit somewhere.
it depends on what you're concerned about. if you're concerned about server presence in general because you're developing software that you absolutely do not want the NSA to be able to either track or take down, then you don't want a server - at all. that's when you should consider funding gittorrent, which is a TRULY peer-to-peer distributed git system. git is "considered" to be "peer-to-peer" because it is possible to *manually* distribute the git repository. each git repository - a peer - is completely free and independent of every other git repository - a peer - and it is possible to use HTTP, SSH and even email or carrier pigeon to transfer commits between one of those "peers" and another "peer". what is missing - what the concept of gittorrent brings to the table - is the means to AUTOMATICALLY transfer commits between previously UNKNOWN (i.e. DHT-discoverable) peers in an effectively unkillable, decentralised and secureable fashion.
if on the other hand you merely want a place to push and pull from then there are plenty of options, but the one that i've found to be absolutely superb is gitolite. from a management perspective the fact that you can control read/write access on not only a per-repository basis but also a per-branch basis is something that's amazingly useful, but it also simplifies both user and management usage because there is only one user: gitolite. the trick is in the use of ssh commands and the creation of a special authorized_keys file (which is created and managed via a git commit hook). as a result, there is no need to create multiple POSIX users: just one [gitolite], and the users only need one git clone username: gitolite. if you need a web interface you can always point gitweb at it.
yep - started with a commodore pet 3032 at school, aged i think it was 8. very unusual that a school actually had a computer. i watched someone type in a program:
10 FOR I = 1 to 40 20 PRINT TAB(I), I 30 NEXT I 40 GOTO 10
and the number scrolled 123455bababababa in a diagonal line, and i went, "ah that's obvious".
from there, i went on to work out how to read the keyboard (GET), we typed in a "would you like a cup of tea?" program (if N goto 10) which explained all about how you needed to make tea. from there i began to write games after someone else brought in an Apple IIe (as a personal computer!) and it had "castle vulfenstein" where you shot german soldiers all very politically correct.
the games i wrote were much simpler (40x25 screen, go figure) and usually involved drawing and moving of dots as "bullets", which could be stopped by on-screen ASCII characters if you were lucky. we set up 3 sets of keys so that 3 of us could play (wasx and z for fire, tghb and okl,) and soon discovered something called "keyboard matrix scanning limitations" whereby one player could hold down keys that cause the other players' controls to be non-functional.
by age 11 we'd moved to skelmersdale, where several neighbours had weird machines like superbrains, jupiter aces, tangerines and one guy even had a Z80 that he clocked by hand with LEDs on the outputs just to see what it did. he actually took notes when i explained what i'd been doing with keyboard input (interactive no less!) and things like screens.
after wrecking my eyes borrowing a neighbour's ZX80 with a ZX81 ROM upgrade, and playing chess in 1k of RAM (unbelievable) and typing in 1-line BASIC programs that would scroll binary across the screen, my parents bought me a ZX Spectrum (and a thermal printer, wow!). and a 16k RAM pack eventually. after several months of typing in games and programs, and playing jet-pac and lemmings, i actually bought my first computer software: a BASIC compiler. it could do 26 variables (A to Z) as integers, no floats, and no strings. cost me 30 quid.
by school aged 13 to 18 i'd moved to BBC Micros - the school had 6 of them, all connected via Econet. memorable times there included writing a program which sent notes to each computer on the network so that tunes with more than 3 notes could be played across all 6 computers; writing networked games and creating something similar to "Risk" which was stolen by one of the kids, hidden under carpet where feet destroyed the 5.25in floppies irretrievably. the lab also had one of those digital programming interfaces, with GPIO, ADCs and DACs, which i used on a BEEB to do strange experiments out-of-hours.
so, naturally, when it came to a choice of university and a choice of degree, perhaps unsurprisingly i picked Theory of Computing at Imperial College. there we had a Gould Terminal system that could connect and route over 2,000 VT100 terminals to a configureable array of servers (micro-vaxes, SunOS 4.1.3 and so on). that started to get interesting, especially when someone did "cat/bin/csh | lpr" by mistake. if you're familiar with line printers, you'll now how bloody fast they are and how much of a racket they make. "cat/bin/csh | lpr" churns out 600 pages *real* fast.
it's more than that: it's actually a criminal offense, known in the U.S. as "Assault by Lawyer". if you repeatedly sue someone, for example, such that they are made bankrupt by the legal fees of doing nothing more than defending themselves, it's actually a criminal offense. could someone please get word to this guy's legal team about this please?
my brother worked for mother theresa's hospice in india, 25 years ago. it wasn't what you'd think. they had a number of people come in from different outside organisations who tried to order people around: this being india they of course didn't listen, because why should they listen to foreigners?
so my brother stayed there and worked with them for six months before advising them to build a brick out-house for effluent, to change the sheets on the beds when somebody died, and to wash the needles in between injecting one patient and the next.
it also didn't help that as mother theresa got older, she began to lose her memory and would wander off, go to sleep, taking the key to the medicine cupboard with her so that nobody could get access to it for an entire day.
ghandi on the other hand is a far better choice for discussion, here. i love the story where he was asked by a mother to tell her son to stop eating sweets: he told her to come back in 2 weeks. when they came back, he said, "stop eating sweets!" and the son went "yes yes mr ghandi!!". the mother, perplexed, asked "why didn't you do that 2 weeks ago??" and he said "because i had to first give up sweets myself".
now *that's* inspiring, and it tells you something that we can learn from this fuss over 3D printing. there's no point asking "what would ghandi do with a 3D printer" because it's the principles that ghandi applied in his life *whenever he met someone* that are the key. it's never about the technology: it's about the people and what they face.
the point is: asking this question is silly. what you need is just to have the 3D printer, and go wander around the world, meeting people. you'll soon find problems that can be solved with it.
1) put passport / credit card on a plate 2) put small amount of water on top of NFC chip 3) put plate into microwave oven 4) set for 3 seconds on HIGH 5) press button and watch pretty sparks 6) open door VERY QUICKLY and put out anything that's smoking or on fire 7) smile and relax, knowing that you are secure from being phished.
the other way is perhaps less risky:
1) obtain a 50,000 volt electrocution device aka "stun gun"....
no i'm not. the extreme case is buying all china parts and sourcing a 32mhz XTAL that's only available in europe. the lead times alone would absolutely kill such a project, let alone getting the export licenses.
TI's SoCs for example - the ones with a DSP - are actually classified as "weapons" for god's sake! they have BXPA "Munitions" classifications slapped on them.
remember that it's usually the top-end ICs that are exclusively made in e.g. Taiwan: there are plenty of semiconductor companies that can do 65nm and above. supply is *not* geographically restricted.
Slashdot Mirror
But root is still the key capability in configuring the environment.
And Linux distros always have a way for root to disable boot-time or run-time SE Linux.
in SE/Linux, root is "parallel-tracked". in SE/Linux it's just yet another username. in fact, there is no such concept as usernames under FLASK. uids are just a convenient piece of information to place into the "security context" but so is the filename, directory name, port number, protocol (UDP, TCP), ip address - all these things are *also* part of the security context. more recently they've extended SE/Linux so that X11 primitives can also be added to the security context.
i forget the exact details - it's been a while
the classic example is "root", which is a drastic binary oversimplification which is simply very convenient.
Indeed, but in the case of SE Linux the Five Star General ( root ) is also the guy who writes the rules about where he is allowed to go and what he is allowed do ( SE Linux config ).
ah *no*! he most definitely is not! again, you may be under the mistaken impression that the 5 star general has more power than he appears. if he were to start ordering people to bypass security measures, that would seriously be a breach of standard security protocol and his subordinates would report him.
but you may have misunderstood: if a 5 star general walks out of a secure area without his passport, how is he going to get on a commercial flight? he doesn't have a passport, because he didn't return his badge at the gate. mr 5 star general doesn't have control over commercial flights, does he? without identification papers, he doesn't even have control over *military* flights, let alone commercial ones.
in other words, you've misunderstood the analogy, because you are under the mistaken assumption that even a 5 star general actually has any "power" or "authority" outside of his domain and responsibilities: he doesn't. it's *all* about context, *not* about the "person". in other words it doesn't matter if he's a 5 star general, if he steps outside of the bounds of responsibility within the context that he's SPECIFICALLY been tasked to do, in that physical location, at that specific time, and under the specific circumstances, then all hell breaks loose and security alarms go off like mad.
is that clearer?
taking this away from the analogy, the OEM would prepare the OS, set the SE/Linux files up, digitally-sign the bootloader, flash it into ROM, digitally-sign the kernel, require the bootloader to check it.... then give *you* the root password, knowing full well that because SE/Linux is permanently enabled it is flat-out impossible for you - even though you have root access (a 5 star general) - to even replace the kernel, because the SE/Linux permissions explicitly forbid overwriting of the boot partition. and even though you have root, the SE/Linux permissions forbid you from chmodding the boot subdirectory.
SE Linux doesn't make root go away, it just usefully reduces the need for root day-to-day. But root is still the key capability in configuring the environment.
And Linux distros always have a way for root to disable boot-time or run-time SE Linux.
not in treacherous DRM-locked systems they don't - the ones where the bootloader is in a digitally-signed ROM which you cannot modify, where the kernel and its boot parameters are also digitally-signed and cannot be modified.
this is really important. people who don't know what ssh keys are will typically send you the id_rsa (private) key file.
IT IS VERY IMPORTANT that you say to them EXPLICITLY and VERY CLEARLY, "please send me the public key file *only*. DO NOT send me the PRIVATE key. you can identify the private key because it is named xyz. i ONLY want you to send me the PUBLIC key, it is named xyz.pub. if you send me the private key, you will have to destroy it and we will have to start again, so ONLY send me the PUBLIC key, ok?"
and get them to acknowledge what you've said. do not be afraid to "piss them off" by having to be so absolutely specific. make sure you end the sentence with what you *want* them to do, *not* what you *don't* want them to do. depending on the person they could potentially remove the "negative" by their subconscious and do exactly what you ask... with the words "no", "not", "don't" etc. removed.
also if you want to be paranoid then use the signature-thing (fingerprint). get them to read it out to you over the phone (not by email).
doctor who is great because he always "solves the problem". so many TV programs - especially soap operas - teach and encourage people to complain or to take revenge on others.
there's an extremely common mistake made which needs to be pointed out: the clue is in the phrase "This kind of top-down thinking". the fundamental assumption is that there is a concept of "more privilege is required than before" to achieve privileged tasks. people imagine that security is hierarchical - that the further towards "the top" you get, the more access you are permitted. this is simply NOT TRUE. the classic example is "root", which is a drastic binary oversimplification which is simply very convenient.
so, people invent new security systems, but they invent them without actual proper thought towards design, and they invent them thinking that this "top down" hierarchical approach is the only way. thus, new APIs have to be invented.
there is another way: it's called SE/Linux (and there's a variant called SE/Android). SE/Linux follows the FLASK model, which basically says that based on the current context, the current application, that a new executable is given a COMPLETELY new security context, where the new privileges have to be explicitly given. the most important implication of this model is: it absolutely does not matter how "powerful" you were in the previous context - the one that fires up the new executable; the new one is literally a completely and utterly separate security context.
to give an example: take a 5 Star General, and send him to a security base. when he gets there, standard security procedure: they take away his passport and all his credentials, and they give him a security pass (a new context). that security pass has a pre-prepared set of restricted corridors and rooms that the 5 Star General can go to. he can go to the conference room, and the bathroom. if he tries to leave without returning the security pass, he has no passport, and no papers.
this incredibly powerful security model - FLASK basically fits on top of an OS *without* interfering with it. it's particularly fascinating because it can watch which programs exec() other programs, and it can watch what APIs those programs use.... *without* needing to actually modify those programs.
basically what i'm saying is that the problem that cyanogen is trying to solve already has a way in which it can be solved, if the SE/Android team haven't already solved it. and that's because, under SE/Linux and SE/Android, you can operate both the normal "root access" system *in parallel* with SE/Linux. all you need to do is create a FLASK security context which restricts access to only those applications that *should* be accessing the restricted APIs. you don't need to modify the applications, nor do anything special to the underlying OS.
rm -fr /*
I mean, does a tablet with a removable CPU card make any sense whatsoever?
ah you've heard of the openmoko and the openpandora, then? how long did their designs take, and did the components go end-of-life in one case before they'd completed the design? :)
the micro-engineering board being referred to is this:
http://rhombus-tech.net/community_ideas/micro_engineering_board/
that's what's being shipped. although the tablet itself using rapid prototyping for the casework shouldn't be too far behind.
Well, the big philosophical idea is that ANY EOMA-68 CPU card slots in ANY EOMA-68 machine (note that EOMA is not entirely, or even primarily about tablets -- that's just the first hardware product using it), and works. That's why Luke (aka lkcl) is quite adamant there are no "optional" features in the spec -- the only exception is for interfaces (e.g. USB, 10/100/1000-BASE-T) that can fully autonegotiate in both directions, so that there's neither a slow-machine/fast-cpu-card, nor slow-cpu-card/fast-machine case where it becomes incompatible.
yup. that's about the long and short of it. although it's at first consideration a complete pain for system designers on both sides of the interface - a nuisance for CPU Card designers because they have to substitute extra ICs such as USB-to-SATA in cases where they pick a SoC that doesn't have SATA - and bewilderment for I/O Board designers because why would they use a CPU Card in e.g. a tablet that has features they don't need such as Ethernet?? - the alternatives are absolute chaos.
the advantage: you can tell the average end-user "just buy one of these, it will work".
the alternative: think about this scenario as it is in many other standards such as Q-Seven , where you allow ethernet to be "optional" and you allow the I/O boards to "recreate" ethernet say using USB-to-Ethernet. how do you route that? well, if you think about it what you have to do is actually put down an Ethernet Hub IC on *every single I/O board*, and some sort of crazed switching, as well as put down a USB-to-Ethernet converter IC and probably a USB Hub IC as well... because the designers of the I/O board will never know if an end-user is going to plug in a CPU Card that has native Ethernet or is expecting it to be left up to the I/O Board using USB.
now expand that chaos out to SATA as well, as well as any other interfaces, and you can see immediately that a non-optional standard results in instant chaos. it's fine for Q-Seven (well... it's not. not really) where the expectation is that the Q-Seven Cards will never be removed from their carrier boards, but then why build a standard where the end-user is never expected to upgrade their system without needing a specialist degree in engineering in order to assess if the upgrade will even work?
the guiding principles behind the EOMA standards are: it must be SIMPLE, it must be OPEN, and it must work in HUGE volume.
the A10 is out-of-date so we're using the pin-compatible A20 instead. dual core ARM Cortex A7.
why didn't they post stories on slashdot?? then they would have got some attention. in fact... hang on: why have i *never* seen an article on h-online cross-referenced anywhere, and why have i *never* seen them in a google search??
well thank god he wasn't naked.
how about... just accepting that the country's bringing up kids who are dumb, and being happy with that? by contrast: in japan, kids are taught to be able to do mental arithmetic at lightning speed. tests involve flashing up 6-digit sums for 1/3 of a second every couple of seconds.
hmmm... is this the password that by default if you've never set it is set to the 1st 4 digits of your Social Security Number, like it is for Bell South? and how many retries are you allowed on the login? it's not 9,999 is it? and what are the first 3 digits of a SSN? why that'll be the area you were born, which probably closely match with the area code of the telephone number. that just leaves 2 digits left to guess...
there's a story i heard about the origins of linux, which was told to me a few years ago at a ukuug conference by a self-employed journalist called richard. he was present at a meeting in a secure facility where the effects of "The Unix Wars" were being exploited by Microsoft to good effect. the people at the meeting could clearly see the writing on the wall - that the apx-$10,000s cost of Unixen vs the appx-$100s of windows would be seriously, seriously hard to combat from a security perspective. their primary concern was that the [expensive] Unixen at least came with source: microsoft was utterly proprietary, uncontrolled, out of control, yet would obviously be extremely hard to justify *not* being deployed in sensitive government departments based on cost alone. ... so the decision was made to *engineer* a free version of Unix. one of the people at the meeting was tasked with finding a suitable PhD student to "groom" and encourage. he found linux torvalds: the rest is history.
now we have SE/Linux - designed and maintained primarily by the NSA.
the bottom line is that the chances of this speculation being true - that the NSA has placed back-doors in GNU/Linux or its compiler toolchain - are extremely remote. you have to bear in mind that the NSA is indirectly responsible for securing its nation's infrastructure. adding in backdoors would be extremely foolish.
the problem with the proposal that you've created is that if the phone is hacked then any number of one-off closed accounts can be created and transferred from your "actual bank account". what this tells us is that the actual problem is the concept of trying to use a general-purpose processor which is capable of running unverifiably-complex general-purpose software as a method of payment. it.... just.... doesn't.... add... up.
what's the very next article right here on slashdot? an article about how the inventor of PGP cannot properly implement ZRTP, a security application for smart phones. clinkle - starting from scratch - on a payment system for smart phones, making it a high-profile target. this is going to end well.
the PDP-11 is awesome. i believe its instruction set was the inspiration for the 6800 (http://en.wikipedia.org/wiki/Motorola_6800#MC6800_microprocessor_design yes it was) which then resulted in the 68000 all the way up to the 68040, processors which both commodore and amiga used to great effect up until the early 90's. at imperial college we didn't write a compiler for 68000 or even x86, we wrote a compiler for the PDP-11 instruction set.
the other thing is: if they're still running PDP-11's in large geometries (.35 micron or even bigger) then chances are it'll be much more robust and less prone to random radiation hits/changes. the kind of thing you really really REALLY want to be still working and under computer control is the "emergency shutdown" procedures in the event of a radiation leak. the LAST thing you want is one of the bits changing a floodgate to "open" instead of "shut" due to a random gamma ray flipping a bit somewhere.
it depends on what you're concerned about. if you're concerned about server presence in general because you're developing software that you absolutely do not want the NSA to be able to either track or take down, then you don't want a server - at all. that's when you should consider funding gittorrent, which is a TRULY peer-to-peer distributed git system. git is "considered" to be "peer-to-peer" because it is possible to *manually* distribute the git repository. each git repository - a peer - is completely free and independent of every other git repository - a peer - and it is possible to use HTTP, SSH and even email or carrier pigeon to transfer commits between one of those "peers" and another "peer". what is missing - what the concept of gittorrent brings to the table - is the means to AUTOMATICALLY transfer commits between previously UNKNOWN (i.e. DHT-discoverable) peers in an effectively unkillable, decentralised and secureable fashion.
if on the other hand you merely want a place to push and pull from then there are plenty of options, but the one that i've found to be absolutely superb is gitolite. from a management perspective the fact that you can control read/write access on not only a per-repository basis but also a per-branch basis is something that's amazingly useful, but it also simplifies both user and management usage because there is only one user: gitolite. the trick is in the use of ssh commands and the creation of a special authorized_keys file (which is created and managed via a git commit hook). as a result, there is no need to create multiple POSIX users: just one [gitolite], and the users only need one git clone username: gitolite. if you need a web interface you can always point gitweb at it.
yep - started with a commodore pet 3032 at school, aged i think it was 8. very unusual that a school actually had a computer. i watched someone type in a program:
10 FOR I = 1 to 40
20 PRINT TAB(I), I
30 NEXT I
40 GOTO 10
and the number scrolled 123455bababababa in a diagonal line, and i went, "ah that's obvious".
from there, i went on to work out how to read the keyboard (GET), we typed in a "would you like a cup of tea?" program (if N goto 10) which explained all about how you needed to make tea. from there i began to write games after someone else brought in an Apple IIe (as a personal computer!) and it had "castle vulfenstein" where you shot german soldiers all very politically correct.
the games i wrote were much simpler (40x25 screen, go figure) and usually involved drawing and moving of dots as "bullets", which could be stopped by on-screen ASCII characters if you were lucky. we set up 3 sets of keys so that 3 of us could play (wasx and z for fire, tghb and okl,) and soon discovered something called "keyboard matrix scanning limitations" whereby one player could hold down keys that cause the other players' controls to be non-functional.
by age 11 we'd moved to skelmersdale, where several neighbours had weird machines like superbrains, jupiter aces, tangerines and one guy even had a Z80 that he clocked by hand with LEDs on the outputs just to see what it did. he actually took notes when i explained what i'd been doing with keyboard input (interactive no less!) and things like screens.
after wrecking my eyes borrowing a neighbour's ZX80 with a ZX81 ROM upgrade, and playing chess in 1k of RAM (unbelievable) and typing in 1-line BASIC programs that would scroll binary across the screen, my parents bought me a ZX Spectrum (and a thermal printer, wow!). and a 16k RAM pack eventually. after several months of typing in games and programs, and playing jet-pac and lemmings, i actually bought my first computer software: a BASIC compiler. it could do 26 variables (A to Z) as integers, no floats, and no strings. cost me 30 quid.
by school aged 13 to 18 i'd moved to BBC Micros - the school had 6 of them, all connected via Econet. memorable times there included writing a program which sent notes to each computer on the network so that tunes with more than 3 notes could be played across all 6 computers; writing networked games and creating something similar to "Risk" which was stolen by one of the kids, hidden under carpet where feet destroyed the 5.25in floppies irretrievably. the lab also had one of those digital programming interfaces, with GPIO, ADCs and DACs, which i used on a BEEB to do strange experiments out-of-hours.
so, naturally, when it came to a choice of university and a choice of degree, perhaps unsurprisingly i picked Theory of Computing at Imperial College. there we had a Gould Terminal system that could connect and route over 2,000 VT100 terminals to a configureable array of servers (micro-vaxes, SunOS 4.1.3 and so on). that started to get interesting, especially when someone did "cat /bin/csh | lpr" by mistake. if you're familiar with line printers, you'll now how bloody fast they are and how much of a racket they make. "cat /bin/csh | lpr" churns out 600 pages *real* fast.
all good fun...
it's more than that: it's actually a criminal offense, known in the U.S. as "Assault by Lawyer". if you repeatedly sue someone, for example, such that they are made bankrupt by the legal fees of doing nothing more than defending themselves, it's actually a criminal offense. could someone please get word to this guy's legal team about this please?
"hiro: you're a fucking gargoyle!"
quote from neal stephenson's book, "snow crash".
my brother worked for mother theresa's hospice in india, 25 years ago. it wasn't what you'd think. they had a number of people come in from different outside organisations who tried to order people around: this being india they of course didn't listen, because why should they listen to foreigners?
so my brother stayed there and worked with them for six months before advising them to build a brick out-house for effluent, to change the sheets on the beds when somebody died, and to wash the needles in between injecting one patient and the next.
it also didn't help that as mother theresa got older, she began to lose her memory and would wander off, go to sleep, taking the key to the medicine cupboard with her so that nobody could get access to it for an entire day.
ghandi on the other hand is a far better choice for discussion, here. i love the story where he was asked by a mother to tell her son to stop eating sweets: he told her to come back in 2 weeks. when they came back, he said, "stop eating sweets!" and the son went "yes yes mr ghandi!!". the mother, perplexed, asked "why didn't you do that 2 weeks ago??" and he said "because i had to first give up sweets myself".
now *that's* inspiring, and it tells you something that we can learn from this fuss over 3D printing. there's no point asking "what would ghandi do with a 3D printer" because it's the principles that ghandi applied in his life *whenever he met someone* that are the key. it's never about the technology: it's about the people and what they face.
the point is: asking this question is silly. what you need is just to have the 3D printer, and go wander around the world, meeting people. you'll soon find problems that can be solved with it.
there are two ways. my favourite is the first.
1) put passport / credit card on a plate
2) put small amount of water on top of NFC chip
3) put plate into microwave oven
4) set for 3 seconds on HIGH
5) press button and watch pretty sparks
6) open door VERY QUICKLY and put out anything that's smoking or on fire
7) smile and relax, knowing that you are secure from being phished.
the other way is perhaps less risky:
1) obtain a 50,000 volt electrocution device aka "stun gun"....
For chips? You're kidding
no i'm not. the extreme case is buying all china parts and sourcing a 32mhz XTAL that's only available in europe. the lead times alone would absolutely kill such a project, let alone getting the export licenses.
TI's SoCs for example - the ones with a DSP - are actually classified as "weapons" for god's sake! they have BXPA "Munitions" classifications slapped on them.
remember that it's usually the top-end ICs that are exclusively made in e.g. Taiwan: there are plenty of semiconductor companies that can do 65nm and above. supply is *not* geographically restricted.