4 ms·
I am familiar with pretty much everything related to Alan Kay (in fact, he was an advisor to OpenAI, where I had a brief contracting stint). :) I like the form
by gavanwoolery 10y ago
I am familiar with pretty much everything related to Alan Kay (in fact, he was an advisor to OpenAI, where I had a brief contracting stint). :)
I like the form factor of many NUCs but would be willing to go even bigger (maybe up to the size of a tactical suitcase, something like this but with user-friendly design: http://www.governmentvideo.com/Portals/0/IMT%20Suitcase%20Receiver%20-%20SCRx_web.jpg http://www.governmentvideo.com/Portals/0/IMT%20Suitcase%20Re...).
I am the least qualified person to comment on security, but I'll give my viewpoint for what it is worth:
For me, there are two types of security: passive and reactive. Passive being that secure measures are in place to prevent foul-doing. Reactive being that threats are identified as they are created and appropriately eliminated. In the real world, our law system is passive and reactive. We are allowed to buy guns (but only by going through a passive security process [1]), but (severe) punishment is issued for misusing them (reactive security). In a way, reactive security functions as passive security - i.e. people do not steal because they are afraid of going to jail.
I believe in a little bit of both. I do not like security that obstructs users from doing what they want to do, especially if there are ways to circumnavigate that security anyway. A large problem I see in the software world is that we are too afraid to enforce security reactively, or the laws are simply not in place to be able to effectively do it.
([1] unless via a blackmarket/etc)
- walterbell 10y agoIf you spend enough time with a system like Qubes, you realize there's no need for a tradeoff between freedom/experimentation/learning and security — everything is contextual. There is a natural lifecycle where tasks move from experimental to predictable. In the experimental phase, you want security to create strong isolation between the open area and the rest of the world, to maximize freedom within the protected area. As experimental code matures and wants to interact with external systems, and (possibly) the entire world via public internet, we can whitelist expected behavior and impose contextual limits, to regulate transitions across the biological system/world membrane. One question is, who determines policy for non-experimental systems that interact with the world? Centralized app-stores are a blunt policy instrument, not to mention their propensity for business conflicts of interest. On the one hand, we want to encourage reuse of known-good policy defaults, which have been proven by other users against known threats. On the other hand, the long tail has many corner cases and even non-expert users can search the web to tweak config/policy settings to manage their own policies. One techno-political precedent is CSS style sheets which at least tried to model a separation between "publisher" and "user" style sheets, acknowledging (a) the conflict of interest, (b) that users can override publishers. What if every policy layer in client systems involved late-binding runtime negotiation among different stakeholders? An unplanned variation is happening with ad-blockers and anti-adblockers and anti-anti ... what if we developed DSLs for the purpose of efficient runtime and contextual policy negotiation? That would move us a lot closer to behavioral and contextual policy rather than semantic central policy.