Many assets will also work if simply located in the same folder as the application file. This is a way of e.g. providing a library without having to put it in the System folder.There is nothing stopping one from writing and compiling ones applications to behave that way even now. All you need is a small launcher (wrapper script), that tells the dynamic linker about it.
I blame the users. They are completely satisfied working with crappy tools that crash or occasionally corrupt their data.
Whenever I've built services or applications that I could trust, I've had to listen to an endless stream of "It doesn't need to be perfect; it just needs to look good" from cow-orkers, managers, and clients alike. Silly bugger...
In late nineties, I maintained a couple of classrooms full of MacOS 7.5 machines, with Adobe Photoshop, Illustrator, and PageMaker, Macromedia Freehand, Microsoft Word, and so on. As soon as I got the department to switch to bulk licensing, I switched the maintenance from individual machines to cloning, with the master on a CD-R. Didn't even need any cloning software, because of the folder-based approach MacOS used: just boot from the CD-R, clear the hard drive, copy the files and folders to the hard drive, and reboot (pressing a key to rebuild the desktop database).
Saved a crapton of time, and reduced downtimes to just minutes (in case of a machine getting b0rked during a lesson).
Pity the department head (who refused to use a computer themselves, having a personal secretary print and type their emails for them) didn't trust me enough to give me a budget for consumables: every laser printer ink cassette, keyboard, and mouse that could not be refurbished, I had to obtain permission to buy a replacement, separately, in writing. My interactions with administrative types only went downhill from there, and is the reason why I burned out before I turned thirty.
Many assets will also work if simply located in the same folder as the application file. This is a way of e.g. providing a library without having to put it in the System folder.There is nothing stopping one from writing and compiling ones applications to behave that way even now. All you need is a small launcher (wrapper script), that tells the dynamic linker about it.I was talking about now! A launcher script is only needed to force an app that you don't compile yourself to use different libraries than the default ones. (For example, to use the old AirPort Utility on newer versions of Mac OS X.)
People need to feel valued and trusted.
Nope user data resides elsewhere.
here is my concept. A harddisk has 3 folders
- OS
- USER
- APP
When you install an application a single file is saved to the APP folder. Everything an APP needs is contained in that file. ( think of it as a ZIP file : it contains an internal file system with all the subfiles it requires. )
In USER there is also an APP folder . That contains the <application>.SETTINGS file. The APP can only write to its own SETTINGS file (the OS governs that. no stepping out of bounds. APPS can only write to their own .SETTINGS file. The APP package contains a DEFAULT.SETTINGS. when a user lauches the application for the first time that one is saved to the users space ( again the OS does that, not under control of applications)
so
- USERS\ME\APP\excel.settings
- USERS\MYWIFE\APP\excel.settings
- APP\EXCEL.APP <- this contains everything required to run excel , including a default.settings file.
The OS and APP folders are READ only for applications. Applications can only read their own .APP file. No peeking in other files or in the OS folder.
Applications must reqister a file extention during install. They can only WRITE to their registered file extensions. they can read any other data file in \users , so they can always import data from other applications, but they can only muck up their OWN data files.
here is my concept. A harddisk has 3 folders
- OS
- USER
- APP
When you install an application a single file is saved to the APP folder. Everything an APP needs is contained in that file. ( think of it as a ZIP file : it contains an internal file system with all the subfiles it requires. )
In USER there is also an APP folder . That contains the <application>.SETTINGS file. The APP can only write to its own SETTINGS file (the OS governs that. no stepping out of bounds. APPS can only write to their own .SETTINGS file. The APP package contains a DEFAULT.SETTINGS. when a user lauches the application for the first time that one is saved to the users space ( again the OS does that, not under control of applications)
so
- USERS\ME\APP\excel.settings
- USERS\MYWIFE\APP\excel.settings
- APP\EXCEL.APP <- this contains everything required to run excel , including a default.settings file.
The OS and APP folders are READ only for applications. Applications can only read their own .APP file. No peeking in other files or in the OS folder.
Applications must reqister a file extention during install. They can only WRITE to their registered file extensions. they can read any other data file in \users , so they can always import data from other applications, but they can only muck up their OWN data files.
If i need to move to different hardware : i take the APP file and fling it on the other machine. when i first launch it the OS will create a new .SETTINGS file , if i copied over the .SETTINGS file it will use that one.
The OS contains functions to safely move .APP and .SETTINGS file on and off a machine.
How neat would that be. No more viruses , no more runaway programs that overwrite their own , or other programs files. No more data snooping ,They simply can't programs only see their own files contained in their .APP file and that file is read only. They can only write to their own .SETTINGS files and write to approved file extensions.
How do you produce new applications in such an environment ("No peeking in other files")?
How do you produce new applications in such an environment ("No peeking in other files")?
To a first approximation, you don't. You can't for iOS on an iPhone. You need the "messier" environment of a, errm, uh, real computer. For iOS, you'll need to run xcode, which means you'll need a Mac. (I understand there are ways to get around this to use Windows, but I'd be surprised if you could do it from say, an iPad).
I believe this is generally possible for Android using something like AIDE, but I do not know how practical it is. I can't see writing a lot of Java without a proper keyboard, but of course you can always plug one int.
You guys are clearly talking about graphical user interfaces only. When I do real work, I usually use command-line commands to pre/postprocess huge data files, and often chain commands. What you are talking about, does not suit my workflow at all.
However, when I browse the web, or download and open a document, the suggested restrictions would be very useful. They are not even that difficult to implement -- except for the sheer number of libraries those applications rely on, and their need to be able to read from and write to a large number of files (though mostly in personal preferences) and sockets.
In fact, Linux already provides the necessary OS/kernel level support for this, seccomp(). Simply put, a library can install filters that restrict which syscalls the kernel will allow to run. It is also possible for the widget which the human user uses to choose a file, to be a completely separate process, which provides the target file as a descriptor/file handle to the application. My point is, this model is already possible in Linux and OpenBSD at least. It is not an OS problem; they can already do this.
The problem is, nobody is willing to put up the resources and requirements for application and library developers to do this. The pool of developers paranoid enough (to not trust even their own code to behave, necessary for this kind of development) is also pretty small, most developers believing that error checking and security is something that can be added on top later on if there is additional money for it.
So, that discussion is really unfair/off-topic here, considering the thread title, and that GNU/Linux is one of the OSes that would allow that approach right now, with the necessary kernel-level support to make it robust.
Funnily enough, something similar to this already exists for Linux, developed by NSA: SELinux. It is obviously more oriented towards services than applications, but it does assign "security labels" for each service (application) and each file and directory, and tightly controls access across "security labels". Thus far, nobody has bothered to construct a working policy for a desktop environment, that's all.
I think the invention of C/Unix were far more harmful to IT than beneficial. Many people celebrate both, but should we really?
Nope user data resides elsewhere.
here is my concept. A harddisk has 3 folders
- OS
- USER
- APP
When you install an application a single file is saved to the APP folder. Everything an APP needs is contained in that file. ( think of it as a ZIP file : it contains an internal file system with all the subfiles it requires. )
In USER there is also an APP folder . That contains the <application>.SETTINGS file. The APP can only write to its own SETTINGS file (the OS governs that. no stepping out of bounds. APPS can only write to their own .SETTINGS file. The APP package contains a DEFAULT.SETTINGS. when a user lauches the application for the first time that one is saved to the users space ( again the OS does that, not under control of applications)
so
- USERS\ME\APP\excel.settings
- USERS\MYWIFE\APP\excel.settings
- APP\EXCEL.APP <- this contains everything required to run excel , including a default.settings file.
The OS and APP folders are READ only for applications. Applications can only read their own .APP file. No peeking in other files or in the OS folder.
Applications must reqister a file extention during install. They can only WRITE to their registered file extensions. they can read any other data file in \users , so they can always import data from other applications, but they can only muck up their OWN data files.How do you produce new applications in such an environment ("No peeking in other files")?
It is an OS problem because doing that is incredibly complicated.
I think the invention of C/Unix were far more harmful to IT than beneficial.
I like to think the world would be different if they delivered ARX.
What if Microsoft had never achieved a near-monopoly on the desktop computer arena, and we had several competing OSes there?
Since 2017, all 500 of world's most powerful supercomputers -- those used to do the best weather forecasts, for example -- run Linux.
Almost all programming languages today use the standard C library.
Typically, their own standard libraries are written in C, or sometimes C++.
Do you understand that if there was no C, we'd have Fortran, Pascal, some varieties of BASIC, Forth, some Lisp varieties?