I think that is a good idea. The most successful method of internationalizing programs have been things that look up the english word, ie it is a lot easier to write i18n("File not found") than to write i18n(MSG_ID_18384A). This idea should also be applied to files. There is really no reason the identifiers cannot be english words, that works exactly as well as any computer hash symbol, with the advantage that at least one language is easily decoded from it.
the only reason this is not getting done is political-correctness that thinks this introduces Euro-Anglo bias to the programming. So the alternative is to bias towards computers and away from ALL humans?
I mostly agree with the original poster, but I do not think the filenames need to be forced to be UTF-8 by the kernel. The kernel/filesystem should enforce that they be strings of bytes where no byte is equal to zero or '/' and that the same string of bytes is not used more than once in a directory. This is easy enough to get right.
If there is any kind of mistake, or disagreement between two systems, on whether a UTF-8 is legal, you are going to have problems like un-deletable files or other exploitable security problems.
Note that I think programs treating filenames as UTF-8 is a VERY GOOD IDEA! But there is no reason for this information to be below the application level.
Extremely powerful "case independence" including spelling correction could be done, but only if the morons out there would stop thinking it is part of the filesystem. It is part of the application, and the biggest impediment to it is the damn "case insensitive" file systems which actually make the algorithims more complicated. They are also the biggest impediment to UTF-8, as case-insensitive treatement of ISO-8859-1 accented characters will completely destroy UTF-8 data. The sooner we are rid of them the better, and I am extremely disappointed with Apple for not doing this in OS/X.
But an attacker could *fill* the underlying window with the borderless window, thus hiding the fact that the data disappeared.
Why not make the "security indicator" disappear when the window is not on top. If this indicator is really going to work that will do it. I don't believe it will, I certainly don't notice the window title, even if animated (like KDE does with long titles that scroll back and forth).
Or why not force some border or obvious shadow around the overlapping borderless window so it cannot be disguised.
My suspicion is they want to make it more difficult for the user to copy information (such as a serial number) from one window to another. They would have to write it down and then type it into another. This of course serves no purpose for the user's security, but can make it easier for web sites.
Just done C++ but the main advantage I see here is that you can make read-only properties with Java (apparently you can't in C#). For a lot of my code this would make things much easier to read as it would eliminate a lot of "()" from the expressions.
Oddly enough, I don't see so much need to assign to properties. Almost always in my code their values are set as a side effect of some other method, or it is much more convienent to set a bunch of them at once. For instance though box->x, box->y, box->width and box->height are useful properties, it is often more useful to set them with box->set(x,y,w,h) than with four assignment statements, and only with that type of assignment could some invariant like "w*h must be greater than 10" can be enforced.
A thing I would like to see are static properties (just like static methods), and some kind of "unchanging" property for optimization, where you mark the fact that the property will not change value no matter what methods you do to the operator, or that it will not change value as long as const methods only are used. In my box example this would allow box->width to be implemented as box->right-box->left, yet the compiler would be smart enough not to do this subtraction 100 times if the calling function asked for the width 100 times.
Only large corporations and the government will be able to sign things in this way. You don't have to worry about the lone stalker. You also won't be able to use it for your own purposes, either.
No, the article clearly stated that it crashed IE. I supposed it is possible that due to the shared DLL's with writable data, that some "exploit" was left in the system that is not there when Mozilla crashes, but I don't think so, and that is really grasping at straws. As far as I can tell the result is the same: the browser exits but the system is unchanged and the browser may be run again. The annoyance level is exactly equal. MS fanboys can even claim the Mozilla crash is more annoying, as it takes longer to start up Mozilla again.
I agree with others here that the poster claiming there was a difference does not have a clue.
The exploits are a bit different in that the Mozilla one is slightly more complex in that it contains attributes ("position:fixed") and not just bare html commands. The IE one should be a warning to everybody, not just to MicroSoft. It is incredibly trivial, and the fact that nobody noticed it crashed shows just how likely it is that there is untested text out there. I suppose it is possible as well that Microsoft knew it crashed and did not bother to fix it.
Here's a possibly silly idea: use filenames for drag & drop. The Windows (and X) design was done when writing files to the local disk was slow. Now it is actually a pretty good method of IPC.
When you get a drop, it is either text or a filename. Programs that can't handle filenames just treat it as text, so you can drop files into documents and you get the filename. Other programs are expected to open that file and do something with it. There must be some way to tell if the file is temporary, which indicates that the destination program should copy or move the data somewhere if it wants to keep it.
The big advantage here is that programs already know how to read and write files, and figure out what type of data the file contains. And dropping an image on a file browser would put the data-writing portion into the source application, which probably has a better idea how to do it.
The main disadvantage is that the files must be created in some location that is writable by the source program and readable by the destination program. It also is not a good idea for small bits of data, but it is not clear if there are any "small" bits of data other than pieces of text.
The framework is there, but not being used. There is a "data type" with the X selections.
The problem is that there is no standard for any types of data other than text. Microsoft back in windows 3 introduced several types, most importantly one for.bmp file data. They did fail to make a "filename" type, which would have been a big win and probably given them the imbedded objects much better and easier than COM and so on.
And even text is confusing, I have found the following types used to mark text: "XA_STRING", "text/plain", "TEXT", and "text/uri-list". Now technically these are all slightly "different" but there my program (and I figure most) completely ignore this. It is easier to look for the colon to identify uri-list than to remember the type. My recommendation: scrap all of this, there is exactly one type of text, called "TEXT" and it means bytes in UTF-8 encoding.
You are right, I think the number 17 that I quoted are the number of calls having to do with manipulating files. There are other calls are for process and memory management.
We did not bother trying to port anything with Motif, even though Lesstif was available. First of all we were also interested in porting to Windows so Lesstif was out of the question. But even ignoring that I have heard that porting programs that are relying on all the odd behavior and bugs of Motif is pretty near impossible. Instead all of our stuff was rewritten to use Qt or FLTK.
Though I agree with you, saying that you are saved from the central machine going down is a myth. On all setups I have seen when some central machine goes down all the clients lock up and are useless. There is always some vital piece of information stored on or behind that central machine. Redundancy in the servers does not really help, it will just help locate what thing you forgot to make redundant, and when you fix that you will just find the next thing...
The execute bit is really there because original Unix systems ran on very limited memory, and for reasonable performance needed to cache a list of all runnable programs in the shell. By having an executable bit, valuable memory was not wasted storing the names of files that were not commands. Actually opening the files to examine if they were some executable format was prohibitively expensive.
It does not prevent shell scripts from running, just type "interpreter script" and it will run even if the bit is off.
Actually the executable bit is a pain, as you often need to turn it on manually after retrieving a file from some other location that has no capability of storing the executable bit. It really is an "attribute" and because of the difficulty it causes it makes me think that any idea of using "attributes" on files is wrong. Attributes should be designed to always be determined from the contents of files, though the file system could store them after they are determined.
Migrating to Linux forced us to rewrite our stuff to use POSIX threads. We were using SPROC before on Irix, as it worked better than pthreads, especially before 6.5.
For 99% of the usage the Linux emulation of pthreads is fine. We also took advantage of the recursive mutexes, these are a total pain under pure POSIX threads.
If they are smart, they will emulate the old interface atop the new one, and release the code that does it. By putting it above the new interface they guarantee to the software developers that they are not losing any functionality or speed by switching to the new interface. And by releasing the code they provide a trusted source for instructions on how to convert their programs to the new system, and this code is enormously more useful than any documentation in showing how the new interface works.
I expect they will screw it up however. They probably won't release the source to the emulation layer, which means lots of software will use the old API for a LONG time. The real problem is that some program will fail with the emulated API and they will decide to do it "beside" the new API, rather than on top. Then everybody will discover that if you use the old api, or some weird combination, it works better (or at all) and then they will be stuck with not 8K calls or 76K calls but 76K+8K or 84K calls.
All recent versions of Linux, Windows, and OS/X have a "log in as this user by default on boot up" as a feature, so this is not an argument against multi-user anymore.
One of the reasons so many Windows programs require Administrator privledges is because that is the default. I think this is the primary worry: if Lindows as designed becomes quite popular to the point that there is commercial software released for it, that software will likely require root, and Lindows (and Linux in general) will be unable to fix it, no more than MicroSoft has been able to fix it.
Believe me, MicroSoft would love to have the default be non-Administrator, they would probably just make the control panel and so on be effectively setuid, but the fact that they did not do this originally means they are stuck with this design. We don't want to see the same thing happen to Linux.
As several others have pointed out, WalMart also sells "blank" boxes. If I wanted to install a pirated copy of Windows I would certainly choose that machine instead.
If there is shared memory (which is actually the only plausable reason for getting rid of network-transparency) then unless you use hardware traps you cannot send the image over the network. Even with hardware traps the best you can do is something like VNC where it sends enormously larger amounts of data than necessary because it does not have the slightest idea what was done to update the display. Slight changes by adding calls like "I am done updating the screen now" would make the network work better, but as soon as you add such calls you are desiging a system for networked use.
As you said, any kind of interface where there are "calls" or any other trappable operation could be made network-transparent. The biggest problem is that for any reasonable speed the calls must be designed so that they either return no result, or the result can be calculated locally. If you do this then you are again designing for networked use.
My big complaint is with people who say "network transparency should be an option". This is a total nonsense position to take. The only logical positions are "network transparency will not be supported", or to design for network transparency. Any plausable design where network transparency is an "option" is exactly the same criteria as supporting network transparency, as small considerations in the design can make enormous benifits for the network performance while having no effect on local performance. And in fact this is exactly the way X is designed right now. Therefore anybody saying "make network transparency an option and X will be fast" is wrong, because X is already this way and it is slow.
You do not know what you are talking about. Windows does not use "direct rendering" either. It would be WAY too slow and would make it impossible to use hardware acceleration.
If this was a good idea we should also be writing files to disk by memory-mapping the disk into the application.
The problem with X is bad Xlib design and their paranoid refusal to jettison parts of it because it might break some obscure program. Oddly enough X does not dictate the communication protocol, since you call XOpenDisplay() and it can do whatever it wants, so they were able to improve this to use the best mechanisms available.
Think hard. Imagine how network transparency would be "added on" to an API that is designed to not be network transparent, for instance one that uses shared memory to read/write to the screen pixels.
Answer: it is not possible. Network transparency requires design considerations in the API. Fortunately these requirements are exactly the same as are needed for all security and stability reasons so that crashing programs or hostile programs cannot take down the window system.
X already bypasses network code when the system is local. This is the only way to make "network transparency" a "plugin", and it is already being done.
Why is X slow? It is because of the horrid design of the Xlib api so that lots of graphics are impossible without huge amounts of communication, and because of huge numbers of synchronous value-returning calls (a mistake done, interestingly enough, because the designers were using local servers with low latency, thinking about the network would have prevented this), and because of the seperate window manager that makes synchronous update impossible no matter how fast your hardware or communication is.
Took a look at the autopackage email. It looks like you have located a lot of stuff./proc/self/maps would work for getting the location of a library, or even the program, and it has addresses in it so the library does not need to know it's own name to locate where it came from.
Also there was discussion with locating scripts. This can be done with reasonable reliablility by some code that parses $PATH and searches it. However it would be a lot better if argv[0] was always a fully-expanded path name.
most installs alter things out of prefix, adding.desktop files for menus, icons, CORBA registrations etc etc.
I would consider that to be bugs in Corba or the desktop. Any system requiring such installation should be fixed to search a path. Unix shells show how it can be done: a program can be "deinstalled" by removing it and typing "rehash", exactly the same mechanism should be used for the desktop and CORBA and so on. Otherwise it is a registry and we know that is bad.
Interesting. The difference from shavers is that the consumer thinks most of the value of the printer is the big heavy box with motors and moving parts in it, not containers of ink. While most of the value and engineering in a shaver is in those blades. Notice that shaver companines have not been successful in getting people to buy their shaving cream.
The problem with/proc/self/exe is that it only works for binaries, not libraries
Yes this is a problem. In our own example we would like people to be able to write programs of their own that use our shared library, but our shared library will not work unless it can find it's other support files. Currently it relies on the caller setting a "where is the library" variable, and our main program uses/proc/self/exe to do this, on the assumption that the library is in that same location.
I think the equivalent of this Windows code is all that is needed (ie there is no need for a "module handle", we only need to find the name of this module:
what_linux_should_do(char* buffer, int length) {
HMODULE hModule = GetModuleHandle(NULL);
GetModuleFileName(hModule, buffer, 1024);
}
What is the application directory? What's wrong with/etc and ~/.appname?
The idea is to get all the files that a program needs into a single directory, so "installation" can be "put the directory somewhere on your path", and more imporantly "de-installation" is "rm -r thedirectory". I do recommend that programs look in ~/.appname first and perhaps in/etc/appname for configuration, then look in their install directory last. But they should work if their config files only exist in the app directory.
AppFolders could be implemented on Linux with the changes you describe, but I've yet to be convinced that they don't suffer fundamental design flaws.
I think the flaws area addressed by changing how directories are read/written so that most programs can treat these AppFolders as plain files. That is why I made my fourth suggestion. I believe AppFolders are far superior to adding cruft to coff to make "resources" or any of the kludges that Windows or OS-9 did for this.
This is one of the changes Reiser5/Reiser6 will introduce (but far more flexibly)
You are right this probably requires file-system support. We may also need some OS support so that if a directory is turned into a tar file by being copied to a filesystem that does not understand this, it still works as an AppDir. This could be done with VFS support, which is something a lot of other people suggested is very important for making a user-friendly Linux system.
Our software will be released as a.tgz file almost certainly. "installation" will consist of "untar the file somewhere, and then symbolically link the executable in there to somewhere on your path, and symbolically like the.so file(s) in there to somewhere on your LD_LIBRARY_PATH"
What I am trying to do is eliminate the need for the.so links first. And then maybe eliminate the need for the executable link, if they just untar this somewhere in their path.
Slashdot Mirror
the only reason this is not getting done is political-correctness that thinks this introduces Euro-Anglo bias to the programming. So the alternative is to bias towards computers and away from ALL humans?
If there is any kind of mistake, or disagreement between two systems, on whether a UTF-8 is legal, you are going to have problems like un-deletable files or other exploitable security problems.
Note that I think programs treating filenames as UTF-8 is a VERY GOOD IDEA! But there is no reason for this information to be below the application level.
Extremely powerful "case independence" including spelling correction could be done, but only if the morons out there would stop thinking it is part of the filesystem. It is part of the application, and the biggest impediment to it is the damn "case insensitive" file systems which actually make the algorithims more complicated. They are also the biggest impediment to UTF-8, as case-insensitive treatement of ISO-8859-1 accented characters will completely destroy UTF-8 data. The sooner we are rid of them the better, and I am extremely disappointed with Apple for not doing this in OS/X.
Why not make the "security indicator" disappear when the window is not on top. If this indicator is really going to work that will do it. I don't believe it will, I certainly don't notice the window title, even if animated (like KDE does with long titles that scroll back and forth).
Or why not force some border or obvious shadow around the overlapping borderless window so it cannot be disguised.
My suspicion is they want to make it more difficult for the user to copy information (such as a serial number) from one window to another. They would have to write it down and then type it into another. This of course serves no purpose for the user's security, but can make it easier for web sites.
Oddly enough, I don't see so much need to assign to properties. Almost always in my code their values are set as a side effect of some other method, or it is much more convienent to set a bunch of them at once. For instance though box->x, box->y, box->width and box->height are useful properties, it is often more useful to set them with box->set(x,y,w,h) than with four assignment statements, and only with that type of assignment could some invariant like "w*h must be greater than 10" can be enforced.
A thing I would like to see are static properties (just like static methods), and some kind of "unchanging" property for optimization, where you mark the fact that the property will not change value no matter what methods you do to the operator, or that it will not change value as long as const methods only are used. In my box example this would allow box->width to be implemented as box->right-box->left, yet the compiler would be smart enough not to do this subtraction 100 times if the calling function asked for the width 100 times.
Only large corporations and the government will be able to sign things in this way. You don't have to worry about the lone stalker. You also won't be able to use it for your own purposes, either.
I agree with others here that the poster claiming there was a difference does not have a clue.
The exploits are a bit different in that the Mozilla one is slightly more complex in that it contains attributes ("position:fixed") and not just bare html commands. The IE one should be a warning to everybody, not just to MicroSoft. It is incredibly trivial, and the fact that nobody noticed it crashed shows just how likely it is that there is untested text out there. I suppose it is possible as well that Microsoft knew it crashed and did not bother to fix it.
When you get a drop, it is either text or a filename. Programs that can't handle filenames just treat it as text, so you can drop files into documents and you get the filename. Other programs are expected to open that file and do something with it. There must be some way to tell if the file is temporary, which indicates that the destination program should copy or move the data somewhere if it wants to keep it.
The big advantage here is that programs already know how to read and write files, and figure out what type of data the file contains. And dropping an image on a file browser would put the data-writing portion into the source application, which probably has a better idea how to do it.
The main disadvantage is that the files must be created in some location that is writable by the source program and readable by the destination program. It also is not a good idea for small bits of data, but it is not clear if there are any "small" bits of data other than pieces of text.
The problem is that there is no standard for any types of data other than text. Microsoft back in windows 3 introduced several types, most importantly one for .bmp file data. They did fail to make a "filename" type, which would have been a big win and probably given them the imbedded objects much better and easier than COM and so on.
And even text is confusing, I have found the following types used to mark text: "XA_STRING", "text/plain", "TEXT", and "text/uri-list". Now technically these are all slightly "different" but there my program (and I figure most) completely ignore this. It is easier to look for the colon to identify uri-list than to remember the type. My recommendation: scrap all of this, there is exactly one type of text, called "TEXT" and it means bytes in UTF-8 encoding.
You are right, I think the number 17 that I quoted are the number of calls having to do with manipulating files. There are other calls are for process and memory management.
We did not bother trying to port anything with Motif, even though Lesstif was available. First of all we were also interested in porting to Windows so Lesstif was out of the question. But even ignoring that I have heard that porting programs that are relying on all the odd behavior and bugs of Motif is pretty near impossible. Instead all of our stuff was rewritten to use Qt or FLTK.
The benifits of client/server are elsewhere.
It does not prevent shell scripts from running, just type "interpreter script" and it will run even if the bit is off.
Actually the executable bit is a pain, as you often need to turn it on manually after retrieving a file from some other location that has no capability of storing the executable bit. It really is an "attribute" and because of the difficulty it causes it makes me think that any idea of using "attributes" on files is wrong. Attributes should be designed to always be determined from the contents of files, though the file system could store them after they are determined.
For 99% of the usage the Linux emulation of pthreads is fine. We also took advantage of the recursive mutexes, these are a total pain under pure POSIX threads.
Plan 9 has I believe 17 calls in their interface. Compared to this, MicroSoft's new 8000, or Linux's several hundred, is pretty bad.
I expect they will screw it up however. They probably won't release the source to the emulation layer, which means lots of software will use the old API for a LONG time. The real problem is that some program will fail with the emulated API and they will decide to do it "beside" the new API, rather than on top. Then everybody will discover that if you use the old api, or some weird combination, it works better (or at all) and then they will be stuck with not 8K calls or 76K calls but 76K+8K or 84K calls.
All recent versions of Linux, Windows, and OS/X have a "log in as this user by default on boot up" as a feature, so this is not an argument against multi-user anymore.
Believe me, MicroSoft would love to have the default be non-Administrator, they would probably just make the control panel and so on be effectively setuid, but the fact that they did not do this originally means they are stuck with this design. We don't want to see the same thing happen to Linux.
As several others have pointed out, WalMart also sells "blank" boxes. If I wanted to install a pirated copy of Windows I would certainly choose that machine instead.
As you said, any kind of interface where there are "calls" or any other trappable operation could be made network-transparent. The biggest problem is that for any reasonable speed the calls must be designed so that they either return no result, or the result can be calculated locally. If you do this then you are again designing for networked use.
My big complaint is with people who say "network transparency should be an option". This is a total nonsense position to take. The only logical positions are "network transparency will not be supported", or to design for network transparency. Any plausable design where network transparency is an "option" is exactly the same criteria as supporting network transparency, as small considerations in the design can make enormous benifits for the network performance while having no effect on local performance. And in fact this is exactly the way X is designed right now. Therefore anybody saying "make network transparency an option and X will be fast" is wrong, because X is already this way and it is slow.
If this was a good idea we should also be writing files to disk by memory-mapping the disk into the application.
The problem with X is bad Xlib design and their paranoid refusal to jettison parts of it because it might break some obscure program. Oddly enough X does not dictate the communication protocol, since you call XOpenDisplay() and it can do whatever it wants, so they were able to improve this to use the best mechanisms available.
Think hard. Imagine how network transparency would be "added on" to an API that is designed to not be network transparent, for instance one that uses shared memory to read/write to the screen pixels.
Answer: it is not possible. Network transparency requires design considerations in the API. Fortunately these requirements are exactly the same as are needed for all security and stability reasons so that crashing programs or hostile programs cannot take down the window system.
X already bypasses network code when the system is local. This is the only way to make "network transparency" a "plugin", and it is already being done.
Why is X slow? It is because of the horrid design of the Xlib api so that lots of graphics are impossible without huge amounts of communication, and because of huge numbers of synchronous value-returning calls (a mistake done, interestingly enough, because the designers were using local servers with low latency, thinking about the network would have prevented this), and because of the seperate window manager that makes synchronous update impossible no matter how fast your hardware or communication is.
Also there was discussion with locating scripts. This can be done with reasonable reliablility by some code that parses $PATH and searches it. However it would be a lot better if argv[0] was always a fully-expanded path name.
most installs alter things out of prefix, adding.desktop files for menus, icons, CORBA registrations etc etc.
I would consider that to be bugs in Corba or the desktop. Any system requiring such installation should be fixed to search a path. Unix shells show how it can be done: a program can be "deinstalled" by removing it and typing "rehash", exactly the same mechanism should be used for the desktop and CORBA and so on. Otherwise it is a registry and we know that is bad.
Interesting. The difference from shavers is that the consumer thinks most of the value of the printer is the big heavy box with motors and moving parts in it, not containers of ink. While most of the value and engineering in a shaver is in those blades. Notice that shaver companines have not been successful in getting people to buy their shaving cream.
Yes this is a problem. In our own example we would like people to be able to write programs of their own that use our shared library, but our shared library will not work unless it can find it's other support files. Currently it relies on the caller setting a "where is the library" variable, and our main program uses /proc/self/exe to do this, on the assumption that the library is in that same location.
I think the equivalent of this Windows code is all that is needed (ie there is no need for a "module handle", we only need to find the name of this module:
what_linux_should_do(char* buffer, int length) {
HMODULE hModule = GetModuleHandle(NULL);
GetModuleFileName(hModule, buffer, 1024);
}
What is the application directory? What's wrong with/etc and ~/.appname?
The idea is to get all the files that a program needs into a single directory, so "installation" can be "put the directory somewhere on your path", and more imporantly "de-installation" is "rm -r thedirectory". I do recommend that programs look in ~/.appname first and perhaps in /etc/appname for configuration, then look in their install directory last. But they should work if their config files only exist in the app directory.
AppFolders could be implemented on Linux with the changes you describe, but I've yet to be convinced that they don't suffer fundamental design flaws.
I think the flaws area addressed by changing how directories are read/written so that most programs can treat these AppFolders as plain files. That is why I made my fourth suggestion. I believe AppFolders are far superior to adding cruft to coff to make "resources" or any of the kludges that Windows or OS-9 did for this.
This is one of the changes Reiser5/Reiser6 will introduce (but far more flexibly)
You are right this probably requires file-system support. We may also need some OS support so that if a directory is turned into a tar file by being copied to a filesystem that does not understand this, it still works as an AppDir. This could be done with VFS support, which is something a lot of other people suggested is very important for making a user-friendly Linux system.
What I am trying to do is eliminate the need for the .so links first. And then maybe eliminate the need for the executable link, if they just untar this somewhere in their path.