3 ms·

I know Ive wanted to make changes to my own for a while. At very least default ui, menus and shortcuts after installation. These are modtly ux changes though A

I know Ive wanted to make changes to my own for a while. At very least default ui, menus and shortcuts after installation. These are modtly ux changes though Additionally theres a few features I would prefer from a security user experience standpoint - symlinks are indexed anD the move or deletion of the target would trigger a "would you like to change/delete the symlink as well?" - all applications run in a container - the application can never touch os filesystem or know about other apps but themself and what the user allows - requests for hardware trigger permission dialog - requests for files are handled outside the container - shared folders are mounted to the container that the user knows are vulnerable - some folders are an aggregate of the applications folders but the application only views its own - deletion of an applications folder will permanently delete all if its data. No messy installations or artifacts - system monitor shows cpu, memory and network usage per application - applications require permission to use network and outward calls can be captured before being made Additionally there are features from a dev standpoint - there is a discoverability system for modified and alternative applications - there is a focus on ensuring all parts of the os are easily found and modified - changes to the os filesystem creates forces the user to create a virtual machine, make changes to that then "commit" those changes in bulk - the user can make these patches available online along with keywords, problem and a tutorial inorder to recreate for discoverability - heavy focus on user interfaces that can be reused in terminal and gui. Applications that only are available in one or have different experiences will be flagged as such. But I canonly make this if I know how

Sir_Cmpwn 10y ago
> symlinks are indexed anD the move or deletion of the target would trigger a "would you like to change/delete the symlink as well?" Patch your coreutils. Difficulty: easy. Most of your other needs can be addressed by making a specialized Linux distro (difficulty: hard), rather than writing a kernel that does all of this (difficulty: max). Build your packages to be containerized by default. I suggest using chroot containers and writing some kind of FUSE filesystem to mount in the container and provide controlled access to user files. You'll also want to write or modify a Wayland compositor to suit your needs. You can have this provide the permission prompts and similar things. Difficulty: hard, but very much doable. Skills to learn: Linux, thoroughly. You should be comfortable making packages, running things in containers, and writing C before you embark on this. You should definitely build this. I'm working on something similar but my design appeals to fewer people. Feel free to reach out to me if you have questions with anything, email is in my profile.
- formula1 10y ago
  I appreciate the inspirstion, I'll see to get started on it tonight. I was looking into fuse before which inspired much pf the filesystem shinanigans
winter_blue 10y ago
Several of the features you've described are present in mobile operating systems, like Android and iOS. For example, "the application can never touch os filesystem or know about other apps but themself and what the user allows" and "requests for hardware trigger permission dialog". Android and iOS both have this model. Most of what you've described can be implemented in the application layer, and don't require writing a new kernel, and the few others could be implemented with small patches to existing well-established kernels like Linux or FreeBSD. We've already got the infrastructure for the container-related features you've described, so implementing what you want is a matter of creating an system-level policy that allows applications to only run in containers and enforces the other restrictions you've described.
- formula1 10y ago
  Many of the features are certainly inspired by mobile and docker and related technologies certainly it seem possible. I guess writing a new kernal is more for rasberry pi/odroid/dev boards? In that case having a detailed explaination on it would be nice
JdeBP 10y ago
Starting from scratch is one way to achieve this. But I suggest that you look into the GNU Hurd if starting from scratch seems daunting. Its potential is underused by the likes of Arch Hurd and Debian Hurd. One of the things that it can do is substitute user-supplied intermediaries, for just about anything, for selected processes.

Sir_Cmpwn 10y ago

> symlinks are indexed anD the move or deletion of the target would trigger a "would you like to change/delete the symlink as well?" Patch your coreutils. Difficulty: easy. Most of your other needs can be addressed by making a specialized Linux distro (difficulty: hard), rather than writing a kernel that does all of this (difficulty: max). Build your packages to be containerized by default. I suggest using chroot containers and writing some kind of FUSE filesystem to mount in the container and provide controlled access to user files. You'll also want to write or modify a Wayland compositor to suit your needs. You can have this provide the permission prompts and similar things. Difficulty: hard, but very much doable. Skills to learn: Linux, thoroughly. You should be comfortable making packages, running things in containers, and writing C before you embark on this. You should definitely build this. I'm working on something similar but my design appeals to fewer people. Feel free to reach out to me if you have questions with anything, email is in my profile.

formula1 10y ago
I appreciate the inspirstion, I'll see to get started on it tonight. I was looking into fuse before which inspired much pf the filesystem shinanigans

winter_blue 10y ago

Several of the features you've described are present in mobile operating systems, like Android and iOS. For example, "the application can never touch os filesystem or know about other apps but themself and what the user allows" and "requests for hardware trigger permission dialog". Android and iOS both have this model. Most of what you've described can be implemented in the application layer, and don't require writing a new kernel, and the few others could be implemented with small patches to existing well-established kernels like Linux or FreeBSD. We've already got the infrastructure for the container-related features you've described, so implementing what you want is a matter of creating an system-level policy that allows applications to only run in containers and enforces the other restrictions you've described.

formula1 10y ago
Many of the features are certainly inspired by mobile and docker and related technologies certainly it seem possible. I guess writing a new kernal is more for rasberry pi/odroid/dev boards? In that case having a detailed explaination on it would be nice

JdeBP 10y ago

Starting from scratch is one way to achieve this. But I suggest that you look into the GNU Hurd if starting from scratch seems daunting. Its potential is underused by the likes of Arch Hurd and Debian Hurd. One of the things that it can do is substitute user-supplied intermediaries, for just about anything, for selected processes.