4 ms·
Weirdly I dream recently about this (all start imaging a relational language, then it get bigger and bigger), with new CPU arch, memory, etc (with full sci-fi c
by mamcx 9y ago
Weirdly I dream recently about this (all start imaging a relational language, then it get bigger and bigger), with new CPU arch, memory, etc (with full sci-fi capabilities)
The main problem is compatibility. The solution is virtualize. Let's say at least provide headless linux (Docker?). This is enough to start. Imagine that linux run not too bad here (ie: fast enough), just to keep dreaming.
The next is why? Why build for this OS if I "just" can run linux here?
The conventional narrative is that the OS is "boring" "invisible" etc. I think instead that is only true because most OS are boring. If we think as a master integration then is more cool.
Consider the posibility to turn the unix text stream/pipelines as the actual UI paradigm (like react) and have the ability to connect not only apps, but components inside. For example, If I'm in mail and wanna crop the image I just put here, I need to detour a lot to Photoshop then return to mail.
Why?
I think is possible to say "This is a image. Any app/component that could operate on it can do it". So, in short, is a UI manifestation of:
MailApp.currentMail.images | PhotoShop.crop > returnBack
So, like in a REST API, the apps publish their URIs with ACCEPT/HEADERS like "json", "xml", "img" etc and this allow to match to others apps that operate on them.
Having also the apps operate on "docker-like" containers by default (fully isolated) yet communicate as Erlang Actors (send messages) to any other app that "Accept: FORMAT", allowing to express to the USER what we do now on the terminal.
---
Other thing that totally need a revamp is the whole file exploring. Is just not rigth that google answer faster than a local disk search.
Also, why not isolated in containers the files of SYSTEM, APP + CONFIGS + TEMPS/CACHES, USER_DATA so if I wanna do a backup just copy the USER_DATA container and be worry free?
This is just some random ideas. Is about time to think of the OS as APP too, and start doing cool things :)
--
In the area of security is also a lot to do. A minimal thing is to acknowledge that most users perform multiples roles on a system, and the case where exist a dedicated user to be admin or dba is just a special case.
So, is reverse the roles/user.
I'm jhon. Now, I change hat to be admin. Then change to be normal user, then change to be developer. I don't need 3 user accounts to be all of this.
Because I'm all of this.
- seanmcdirmid 9y agoIt turns out all those things can be done in userland, you don’t need a new kind of kernel to support it. Likewise, most of the interesting things going on systems research today (e.g. distributed computing) don’t really touch the kernel either.
- mamcx 9y agoReusing the kernel and some low level is clearly the way to go. But userland is truly where the game is. The important thing to note is that the OS show the way. Similar how iOS change everything
- seanmcdirmid 9y agoThe magic of iOS was in its design and human interface components. That Apple was able to turn OS X so quickly into iOS by reusing all the low level components shows us how little is happening in that space ATM.
- syrrim 9y agoRegarding piping between apps: this is the role the clipboard serves today. When you copy something, the clipboard stores the app you copied from and a list of formats. When you paste something, the app selects a format from the list in the clipboard, then recieves the contents of the clipboard in that format from the app you copied from. Regarding your filesystem suggestions: this is already commonly done on linux. Generally, separate filesystems are created on separate partitions for each of /mnt, /home, and / (everything else). If you wanted to backup all user data, you could find the partition, then run `dd if=/dev/home of=$BACKUP`. Regarding your third point. Windows UAC already allows a user to jump into being an admin when needed. I'm unsure why you would need a separate user account for other roles. Users exist primarily to protect your stuff from other people on the computer. You shouldn't need to protect your files from yourself.
- mamcx 9y agoI understand some hacky, underused and not well designed ways to do some of the ideas exists :) >Regarding piping between app: this is the role the clipboard serves today This is more a "scratch" area than truly piping. If you can't do: map(PhotoShop.listImages, zipToFile) |> map(sendEmail) naturally then is not the idea. > this is already commonly done on linux. In fact this one is almost too close. But think for example in all the trash/caches/temps is stored on the HOME. The problem is that the whole thing rely on ad-hoc, let's imagine developers and users will respect the filesystem layout... You can totally store your photos on /bin. You can't trust ONLY your personal data is on HOME. > Windows UAC already allows a user to jump into being an admin when needed. I'm unsure why you would need a separate user account for other roles. Not, is the opposite, is not to create more accounts, but to switch roles per context. I'm jhon/admin when managing computer I'm jhon/user when browsing I'm jhon/developer when compiling
- philsnow 9y ago> Is just not rigth that google answer faster than a local disk search. A while back, I had just bought a new desktop. I couldn't just use the hodgepodge of ~1280 MB worth of RAM from my old desktop because it was a different technology, but I also couldn't afford a GB of ram that would work with the new desktop. I kept my old desktop on the network, made a big ramdisk out of 1GB of its RAM, and exposed it to the network as a network block device (kernel driver was called 'nbd'). I mounted that device on my new desktop and used it for swap, because it was orders of magnitude to eat all the transmission, TCP, etc delays in exchange for not having to hit disk platters. .... which is _really not all that different_ from why google can return search results faster than you can search your local hard drive.