8 ms·

Amiga's real death blow was a frivolous patent lawsuit IIRC. Still, your ideals mirror mine quite a bit. I have long been against discrete GPUs and specialize

• EdSharkey 10y ago
  You are my people!
• walterbell 10y ago
  Are you familiar with Alan Kay's Viewpoints research on KSWorld and OMeta? What do you think about Qubes on a Skylake Skull Canyon NUC (small desktop with Iris Pro and Thunderbolt) as a desktop research platform? Qubes/Xen would allow existing Linux/Windows to run in parallel with an experimental OS. There is a cross-OS compositing graphics stack (like VMware Workstation Unity) in Qubes that tries to balance security with usability - could be extended. Qubes also has hardware-rooted measured launch ("anti evil maid") to verify the integrity of the TCB, with keys under user/owner control. As systems get more complex, we need boot-and-runtime integrity measurement to ensure components have not been unexpectedly modified. An interesting area of research is "data sovereignty" as a counterpoint to "surveillance capitalism". We need a modern storage API that shares the data portability goals of the EA/Amiga Interchange File Format, http://www.martinreddy.net/gfx/2d/IFF.txt http://www.martinreddy.net/gfx/2d/IFF.txt & http://www.fileformat.info/format/iff/egff.htm http://www.fileformat.info/format/iff/egff.htm. As new data rendering capabilities are added to the OS, apps get support for free, as IFF delivered on the Amiga. In exchange, apps cannot lock user data into proprietary formats. This data interoperability then enables multi-app data analytics and UX compositing, with OS enforcement of user ownership and policy, rather than vendor or cloud policy. Since app/service vendors are impermanent, standardize data interchange APIs with OSS implementations, ensuring the survival of user data. Combine this with KSWorld/Rebol ideas about DSLs for OS-enforced user extension of apps (think Excel declarative programming), and "apps" become data pipeline components, instead of fixed-function GUIs where users have to plead for changes.
  • 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 ago
      If 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.