Like, plug and play OS support, and its a go.
Like, plug and play OS support, and its a go.
I've seen some great looking desktops that I still need to mimic, and the make them more fluid/responsive for multiple devices. I would like to review and look at what George Singer is up to:
https://github.com/SimulaVR/Simula
Seems like he may be offering VR devices for developers that are able to demonstrate some requirements. How cool is that? I would like to take something like Sway, and add or combine it with a project similar to SimularVR, with a Vulkan backend. That is the end goal.
I will likely just start with Sway and build a kick ass plugin and application manager that uses containers. I will re-explore the current application isolation solutions, such as AppImage vs FLatpak vs Snap, but likely try my hand at building my own.
Part of that process is repeatable builds. I would like to build the OS compilation into the decentralization process, and make distributed (and localized) compilation a core component of the crypto solution, as it will later be used for rendering all types of resources on top of something like IPFS and Git.
Ideally, package maintainers will be solely focused on automated builds directly from source repos, so that everything is compiled and versioned automatically, so that you can switch software versions at anytime, with some compatibility-script support for DB and data changes.
Anyway, that is a lot of talk, so I will have to share more when I make more progress. It is a longer term goal, but feel free to help me get started:
For example, you can see a UI kit here that I would like to utilize initially, although I am still inclined to try to implement my own idea here, which involves combining a
What would be awesome is something like this little bit of hypothetical Python code:
import ipfs
file = ipfs.file(FILE_HASH, keep=True, share=True) # THIS LINE
with open(file) as fin:
# Do stuff like a normal file.
No need to distinguish between local files and cloud files! You can choose whether to keep the file permanently or temporarily, and whether to share it back to other IPFS nodes. You would probably need a system service to do this seamlessly as you suggested.Sure, it might take a some time to download it at first - but you have to deal with that either way. On subsequent runs, it all just works. (I assume for popular enough files you don't have to worry about the availability of the file, especially if people tend to share back by default).
The big benefit being it is simpler to share datasets and actually use datasets - you can do both at the same time with one little file content identifier (FILE_HASH above).
I wonder how purging less important files is/could be handled through this? It would be good if there was some way to say, "this file is likely only going to be used temporarily (or just once), so feel free to delete it if disk space is required". That hinting might not be necessary as IPFS could use some least-recently used algorithm, but there should be some way to at least pin files, "this is really important, don't delete this".
I think you want something like KeyBase for encrypted storage which can be shared among groups, right?
Once the scale problem starts to be solved, the question becomes discoverability. And the answer to that is, there is an infinite namespace of things - one might suggest it up to the distro maintainers to adopt policies - behind which one can hide ones content. Like, if the distro has a button that says 'publish your stuff' and a button that says 'keep this stuff secret' but inform your closest friends when there are updates so they can get approved copies, well .. thats a distro thing.