Rather annoyed at Ubuntu. It worked great on my Dell Precision M90 laptop in 6.? (whatever the one before this was). I upgraded to 7.10 and the sound, wireless, and suspend all broke.
I managed to fix them by doing a lot of Google and package installation (here is what worked: the sound required the installation of something like "ubuntu_backports". The wireless (an Intel chip) required the installation of the i386 drivers (as opposed to the "generic" drivers used by the non-default version of the kernel). The suspend required installation of something called "ps_suspend" though I tried a lot of scary-looking other suggestions before this worked, with the annoying fact that I had to reboot every time a test failed. I'm quite certain that most people would not have figured out or tried any of these. (hint for googling: use the animal name, ie "gutsy")
Normally you can blame lack of hardware manufacturer support and/or lack of resources to test things, but not when it worked in the previous version AND the system can be fixed to work in the new version.
From my Google searching it sounds like a lot of people complained about the lack of such quality compared to the previous Ubuntu.
Any word on whether I can expect the same, better, or worse from this new version?
The problem is that in this case it is the *same* attacks on both platforms (mostly guessing or brute-forcing the password so that new pages can be uploaded). Thus the percentages on each platform almost exactly match the installed base percentages, in fact if they were different then the whole thing would be suspect.
The same thing is becoming increasingly true for malware on desktop machines.
The most common method of invading a machine is to fool the user into clicking on a download, and in this case I would expect the same number of people to be fooled when running either Windows or Linux (assumming the same level of intelligence and experience and insight, all of which is increasingly irrelevant as people buy preinstalled Linux machines). Now the fact that the malware won't work on Linux is 100% (alright maybe 99%) due to Windows larger market share (it is quite obvious that a Linux malware can send email and damage users files and install itself so it starts up when X starts up, even if it never gets root access. Linux's main advantage technically is the variation in the systems at the accessible exploit level, the same thing that makes it a pain to install non-repository software also protects against malware).
I believe if you added up all the downloaded files (whether the malware was stopped because it was run on Linux, or due to UAC, or conversely it did run on Linux because it ran using Wine) then the percentages would get really close to the installed bases of Windows and Linux.
I get thousands of ssh attempted logins an hour so Linux is certainly being targeting. My impression is though that both Windows and Linux are far, far better than they used to be for anything happening without the user doing something stupid. Even if Windows is a hundred times worse, direct attacks are so small compared to the stupid-user problem that the difference here disappears into the noise. With scripting I expect portable attacks to be possible and in that case I would expect to see matching percentages between Linux and Windows for sources of malware.
Why is there never any comment when somebody writes "Microsuck" or "Winblows", but this rather harmless dollar sign (which I personally find very useful to avoid reading the abbreviation as Multiple Sclerosis or Miss) always brings out this troll? I think somebody's feelings are being hurt. Awwwww....
I don't understand. Sure not everybody is going to read the source. But not everybody is going to decompile a program either.
If I was to place bets, I would bet on the number reading the source to be slightly higher than the number running the decompiler. Asumming that is true, this is a good thing for open source.
In either case it only takes one person to do it, as long as they communicate any interesting things they find to others.
- What is the value of being able to express illegal utf-8 strings? It seems you would want to reject them anyway before using such a string to store file names.
This is necessary if your file system has a file on it named by an illegal utf-8 string and you want to open it!
If you take a case-sensitive view, why can't a stream of wide characters be viewed as a stream of bytes for string comparison purposes?
Because you can translate more than one utf-8 string into the same utf-16 string (this will happen if the utf-8 string contains an illegal encoding or an encoding of a the surrogate half-characters). This means that comparing the utf-16 strings does not return the same result as comparing the utf-8 strings. OS/X decomposed characters are also a problem
How does this lead to the problems that you say?
It basically comes down to a program saying "these two utf-8 strings are not equal, therefore I know that I can write the file named by one and not clobber the file named by the other". When the program gets this wrong you get security vulnerabilities and you lose data and you get weird error messages.
Whether case-independent file systems is bad is probably another discussion
They are bad because the filenames are no longer a plain string of bytes. What you are really asking for is a spelling corrector, and it is unclear why you (and so many others) think a spelling corrector should be part of the file system. The system should provide a way to quickly list matching filenames to an arbitrary regexp (this is needed rather than just readdir because some file systems have an infinite number of available names) so that a program or back-compatability library can quickly do case changing and other spelling correction if the filename it got was wrong.
So the unadorned interface isn't really a third interface, it just lets you switch between the *A and *W versions with the UNICODE symbol.
I was talking about the a, w, and "mb" interfaces. Though the existence of the the mb interface is due to the poor design of the Asian dual-character encodings. UTF-8 can be used with the old ASCII interface because of the ASCII compatability and the extremely low probability that text in ISO-8859-1 would look like a legal UTF-8 encoding (preserving these, and allowing programs to generate arbitrary streams of bytes, are the reasons I want illegal utf-8 strings to be legal filenames).
Copying a file shouldn't have to know about the attributes... systems should just issue the "copy" system call...
Unfortunately it is nowhere near that simple. *something* has to copy the file, for instance the file system that is on the receiving end of your "copy" system call. If it does not know about extended attributes, you lose. The only solution is to get everything into a single stream.
Emacs, it issues a "rename foo.txt foo.txt~" command, a "open O_CREAT foo.txt" command, and then several writes to the new foo.txt. In other words, foo.txt is a new file.
That is the only safe way to make a backup. A copy might fail. I suppose you could rename to the ~ file, then copy to the new file (with the copy-file api) and then write over the new file, and the safety would be equal. But it would be rather wasteful as the copy-file api would copy stuff you know is going to be overwritten. You might then say "well the copy file api should take some flags to indicate what to copy" but then you have started down the rats nest of adding options to what should be simple api's.
In any case *many* people want exactly what Emacs is doing to be the basic behavior of the OS. Writing a file will *always* get you a completely blank one. When you close the written file, it is an atomic operation and at that point anybody opening the file will see the new one, anybody who previously opened the file sees the old one. The old one either disappears from from the directories (so nobody can open it) or it is given a version number (like VMS used to do) or otherwise placed where it can be readable. This is the way it should be done, but it will mean that nothing can possibly be preserved between copies, and this will happen to *all* programs.
Now, Windows has a capability they call file system tunneling, which I thought I had tested and found that it would keep extended attributes, but I guess I'm wrong, because it doesn't.
Without a preserved reference to the original file there is nothing the OS can do.
You need either something external to the file (extended attributes), to change a large portion of current code so that it doesn't break, or not use a unified way of storing the information. (Comments for source code, EXIF comments for photos,...)
The second version is what I was proposing. There are obvious problems though, so it could never provide a reliable metadata system. What could work is that there are rules to *attempt* to extract metadata from a file, probably done by user-space programs. Thus if the metadata disappears, in many cases it will magically reappear because it can be extracted from the file.
Another possibility is to use directories, but change it so that reading a directory produces a data stream that is something like a tar file of all the contents. Writing this to an aware filesystem would produce a matching directory. Writing this to another file system would produce a file that when copied back to the original filesystem would produce the directory. Then all the branches of data is stored in subfiles. Then programs that want to actually use the data rather than copy it would have to open name/data instead of name.
Also, I don't really WANT to see all the metadata when I'm editing, say, a text file, tough I guess this could be added as a editor feature to turn it off.
Biggest problem I see with Windows is the use of "wide characters" in the filenames. They need to replace this with utf-8 asap and remove all the triplicated interfaces (old, a, and w) that it has now.
As someone who has only recently been reading about Unicode and text encodings and such, what are the problems with wide characters? The only one I know of is wasted space for western alphabets, but utf-8 wastes space for east Asian alphabets.
By far the biggest problem is that wide characters cannot represent an arbitrary stream of bytes, for instance an illegal utf-8 encoding. This means that a program cannot re
Actually on Vista they did make "/Users/name" as a "home" directory with all personal stuff under it. This happens to be the same name used by OS/X. They go through some contortions to avoid using the word "home" or put a picture of a house anywhere, which is pretty funny, but otherwise it works.
I would also like to see:
- Make \n be the newline seperator by changing their file system so all written files are binary mode at all times. Reading files can continue to strip the \r when in text mode, but they will all quickly disappear and then text mode can be eradicated. Fix notepad (the only program I can find that does not like bare newlines in the file). Programs should also be written to treat \r as whitespace and ignore it at the ends of lines (Linux programs should do this as well). And finally we will be rid of this disgusting mess.
- Make UTF-8 be the character set to name all files, and have the system treat filenames as strings of arbitrary bytes. Thus the 'a' interface becomes the native one and the current encoding is forced to utf-8. Remove case independence. This will allow identification of files to be done by "the string of bytes is equal" and thus eliminate a lot of bugs in filesystem implementations. For back-compatabilty add whatever is needed so the win32 api can search for possible matches if the first name it tries does not open because it has the wrong case (adding this is also proposed for Linux, apparently).
- Stop writing "bom" to the start of UTF-8 files. No big deal but it will help with the removal of "text mode" just like the newlines.
And on the Linux end:
- Allow a blank directory name, or some other arrangement, so that "//blah" is a legal filename and different from "/blah". This will allow the much nicer Windows unc remote host names to be used.
- Make FUSE work and be always supported, and have it do the rest of the "//computername" naming. And put all that crap that is in KDE/Gnome libraries into FUSE so that we can do "/http/..." and similar things and access everything.
- Put the damn fonts into/Library/Fonts/NAMEOFFONT.ttf where the filename is actually something user-friendly.
No, you cannot make "/xyz" point at an arbitrary place. As far as I can tell the highest up in the hierarchy you can go is "//localhost/?/a/xyz", the "xyz" can be made to point somewhere.
Since you cannot make arbitrary changes I agree with the gp that NT is not providing a "single rooted file system".
Another HUGE problem is that not all the Win32 calls accept unc filenames, meaning you cannot type them into many programs.
Conversely, I would like Unix to accept a zero-length filename so that the "//" leading syntax is legit. Apparently this is not allowed by the POSIX standard but I think that should be changed. This and FUSE would allow 100% compatability with the Windows unc filenames. And they should get rid of that "prefix:" syntax being used by wrapper libraries to access things, and go with mounted links.
No you are mistaken. At the time a Windows client would not work without that "PAC" information. Thus Windows clients could not use non-Windows hosts.
Also Microsoft did not "publish" the documentation. They specifically threatened Slashdot and told them to remove links to a leaked version of the documentation. Eventually they gave up and thus the leaked information is the "published" information you seem to think exists.
Re #2: this is what Linux does as well (provide a shared library that implements what appears to be the system interface). I'm pretty certain all modern operating systems do this. The actual Linux system api does not exactly match POSIX and does not match exactly between versions.
On extended attributes, you are going to have the same problem as you have with Emacs with *any* program that tries to copy a file and does not know about the attributes. This happens on Windows, and certainly on the Mac with the "resource fork". I would prefer to see a system where the attributes are embedded into the single stream of text that is in the file, so they are always copied and can be stored on any device. Unix sort of has some trivial examples, such as the "#!" at the start of a file to indicate the program to run. Ideally *everything* about the file, even it's name, could be embedded this way. Gets tricky if protection/acls are embedded but not impossible (it would ignore them excessive permissions).
Largest problem I see with Linux is a rather rabid requirement for back-compatability with quite-obsolete file system layout requirements. Every reason for the LSB disappeared 20 years ago with the implementation of symbolic links. Would like to see atomic creation of files (no other program sees changes until the file is closed), union mounts, elimination of most/all environment variables and replacement with the existence of files, etc, make FUSE be the primary way to get files and add enormous numbers of named services using it, etc. All of these will break things but need to be done.
Biggest problem I see with Windows is the use of "wide characters" in the filenames. They need to replace this with utf-8 asap and remove all the triplicated interfaces (old, a, and w) that it has now. And start using forward slash and make "/A/" mean the same as "A:/".
A "non commercial only" restriction is not just incompatable with the GPL. It is incompatable with the BSD license. It is incompatable with public domain. It is even incompatable with Microsoft's own osf-approved licenses!
I think you may be somewhat over-estimating the quality of what IBM was selling. There are reasons why Unix and many other things were developed on non-IBM hardware.
I agree. I would seriously like to see this pledge not to sue over the patents for APIs. It would be interesting to find that it only applied to certain types of used which would still be too restrictive for GPLv3 compliance.
They said "for non-commercial use". This is too restrictive for GPL3. It is too restrictive for GPL2. It is too restrictive for BSD, or for Public Domain. Hell it is even too restrictive for Microsoft's own shared-source licenses!
I think a scheme whereby you can buy extensions to copyright would work, and (just maybe) the government + lobbyists would approve it.
Something like you get the first 10 years for free. Then you must re-register the copyright each year after that. And the price of re-registering it goes up each year, probably linearly.
Disney could keep re-registering Mickey Mouse and whatever else it decides they might make more money from than the registration each year. Stuff that is worthless would drop out of copyright. Also if you found an obscure item and it is more than 10 years old, it would be easy to check to see if it is copyrighted because the registrations would be recorded.
You are talking about putting *graphics drivers* in the kernel, and I agree there could be very good reasons to do this and would at one time have thought this was the only way. It does appear now that providing a device-specific kernel module that provides protected access to the hardware, and having the graphics done by the user process, may be better as it avoids any context switches.
By "gui" most people mean windows/buttons/sliders/etc. Those certainly should *not* be in the kernel.
After all, in Unix, terminals and other IO devices are a part of the core OS
Oddly enough, this is one of the worst aspects of Unix design and easily disproves your whole argument. In fact the Unix tty interface is the perfect argument why gui should *not* be in the system!
An intelligent system would have made the tty driver deliver the bytes unchanged directly as the user typed them to the application. Line editing and echo and so on would be done by the process.
On Unix it is an incredible pain to get the terminal put into "raw" mode so you can get single characters (as any on-screen editor wants). We also have bugs that should have been fixed ages ago, such as the fact that backspace often does not work, these cannot be fixed despite the apparent trivialness due to the fact that there is a complex api that basically dictates the implementation of the user interface (in this instance there is a single "what key does backspace" field, and you cannot add a new one without being incompatable). Also if you want to do *anything* more fancy than the normal io, such as every shell in the world that now does history editing, you have to force the terminal into raw mode and thus you are forced to replicate all the ui code in your own program anyway, thus defeating any possible reason for it to be in the system! It is also why there are "pseudo ttys", these are a horrible hack so that your terminal emulators can work, because all programs were designed to talk to this specialized tty driver, rather than being able to be connected to a plain pipe, which they would have been if they used raw tty i/o.
Putting the GUI into the system is exactly the same mistake as the Unix tty driver. It is pretty sad that nobody is learning from mistakes made 37 years ago and is repeating them even today. Yet they are...
I don't think it is a problem if there is special sim-city stuff in the "dos box" code, as long as it does not effect the main system. This is no different that claiming that the complexity in Wine is a problem with Linux. (though I would guess that maybe it does, a general complaint is that while NT was quite clean, they messed up the kernel by moving stuff into it for compatability).
I don't know anything about.net. I am just worried about anything that relies on other sources for the code it needs. I suppose maybe it includes downloading the correct version of the library from a source, or are the programs in effect statically linked? Another possibility is that the programs are "statically linked" but include code that will run a newer/better version of a library if it is available. This sort of scheme does work and is best seen in OS/X app bundles (you can also do it on Windows and Linux by putting the shared library in the same directory as the program) but in all these it is "reversed" in that the "static" version of the library takes precedence. Also kind of annoying that it relies on directory structure rather than it being part of the executable.
My personal opinion is that *everything* should be statically linked. It is obvious that it works, and any worries about wasting memory or disk space could be solved by using hashes of the read-only pages to locate identical ones and make them be the same memory. The complaint is always that some bug fix in a library will not be available to programs, but I have not seen that in practice. In fact I have seen the reverse: a bug gets introduced into libjpeg, say, and everything is suddenly vulnerable. Previously the programs would all be linked with many different versions of libjpeg and thus whether the bug is there or not is difficult to determine by hositile attackers.
Okay I looked around for 10 year old Linux programs and tried them on Ubuntu 7.1:
xv: worked seahaven card game (I compiled this myself ten years ago): worked A tetris game: worked tcsh: worked tk: worked xpaint: worked
alright, alright, maybe I'm being too easy on it. Lets try something hard:
fvwm: worked Maya 5 (a cracked copy): worked (might only be 7 years old) Old copy of tuxracer: (again may only be 7 years old): worked
In reality software that old does work. What *doesn't* work is software more like 5 or less years old. Tried running old kde programs and they did not work. I bet old Gnome programs would not work either. They both required.so files they could not find (yea they were on the disk the programs were on but not in my LD_LIBRARY_PATH). And even more annoying is software less than 1 year old. Our own commercial software is crashing because of changes to the libstdc++ api because those idiots did not change the version number because they think they were being compatable. Unfortunatly this is not only on Linux though I think Linux is worse. We have horrible problems with changes to QuickTime where again they did not change the version number. I am also very doubtful about the long-term compatability of.net as it is the same mess that the KDE/Gnome environments are foisting on us.
I think Slashdot truncated his joke. He put a bunch of candidate's names (including Clinton) with ^H (backspace) characters between them, as though he kept changing his mind about who was behind it.
I think the general hope is that Microsoft would be replaced by several companies, each of about the power of the current PC manufacturers such as Dell and IBM, and with the ability for tiny companies to compete in some way, just like it is possible to go to a little computer store and buy a computer that works in a way that is competitive with a Dell. It does seem very likely that these machines will run Linux as a fallen Microsoft would probably be unable to release Windows sufficiently to make it an option for price-concious companies, and basing it on Linux will allow them to hire people with experience and cross-hire from their competitors. However the companies will compete on closed-source applications with tight integration into their web services, so it's not like it's going to be some OSS nirvana where you can mess with any program you want and improve it.
I suspect more likely one of those companies would end up dominating, by technology lockin just like Microsoft does. A closed program running on Linux can use an obfuscated proprietary data just as well as one running on Windows. Hardware manufacturers and the RIAA/MPAA might wise up and realize that DRM can be done with a piece of sealed hardware with an api that is like a DVD remote control (ie stop, play, etc) so that the api can be published and nice controls integrated into any system that uses this hardware, and the company with the rights to insert this hardware into their machine could be the winner.
Actually I think "O$$" could be a very useful abbreviation. It would represent the commercial use of open source. This could be anything from "evil company getting work for free" or "using the term because it is a buzzword", to "company contributing lots of code back because it is in their interest".
I think if any of the silly replies above checked my posting history, I always wrote out "Microsoft" (or "MicroSoft" since it was actually called that back when I started working on computers). However I'm going to go through the extra effort of typing "M$" from now on.
I did not think of that. I only know Basic from long ago, is the $ at the end and not at the start?
In any case, I cannot understand why this gets the Microsofties upset so much. Hey, they are free to call Linux "£x", or call open source "O$$" if they want. Do it enough so that it is well-established and easy-to-read as "M$" is. And lets see if that really upsets people. Of course it wont.
Slashdot Mirror
Rather annoyed at Ubuntu. It worked great on my Dell Precision M90 laptop in 6.? (whatever the one before this was). I upgraded to 7.10 and the sound, wireless, and suspend all broke.
I managed to fix them by doing a lot of Google and package installation (here is what worked: the sound required the installation of something like "ubuntu_backports". The wireless (an Intel chip) required the installation of the i386 drivers (as opposed to the "generic" drivers used by the non-default version of the kernel). The suspend required installation of something called "ps_suspend" though I tried a lot of scary-looking other suggestions before this worked, with the annoying fact that I had to reboot every time a test failed. I'm quite certain that most people would not have figured out or tried any of these. (hint for googling: use the animal name, ie "gutsy")
Normally you can blame lack of hardware manufacturer support and/or lack of resources to test things, but not when it worked in the previous version AND the system can be fixed to work in the new version.
From my Google searching it sounds like a lot of people complained about the lack of such quality compared to the previous Ubuntu.
Any word on whether I can expect the same, better, or worse from this new version?
And you need to turn the logo upside down to open the laptop, thus losing the creativity...
The problem is that in this case it is the *same* attacks on both platforms (mostly guessing or brute-forcing the password so that new pages can be uploaded). Thus the percentages on each platform almost exactly match the installed base percentages, in fact if they were different then the whole thing would be suspect.
The same thing is becoming increasingly true for malware on desktop machines.
The most common method of invading a machine is to fool the user into clicking on a download, and in this case I would expect the same number of people to be fooled when running either Windows or Linux (assumming the same level of intelligence and experience and insight, all of which is increasingly irrelevant as people buy preinstalled Linux machines). Now the fact that the malware won't work on Linux is 100% (alright maybe 99%) due to Windows larger market share (it is quite obvious that a Linux malware can send email and damage users files and install itself so it starts up when X starts up, even if it never gets root access. Linux's main advantage technically is the variation in the systems at the accessible exploit level, the same thing that makes it a pain to install non-repository software also protects against malware).
I believe if you added up all the downloaded files (whether the malware was stopped because it was run on Linux, or due to UAC, or conversely it did run on Linux because it ran using Wine) then the percentages would get really close to the installed bases of Windows and Linux.
I get thousands of ssh attempted logins an hour so Linux is certainly being targeting. My impression is though that both Windows and Linux are far, far better than they used to be for anything happening without the user doing something stupid. Even if Windows is a hundred times worse, direct attacks are so small compared to the stupid-user problem that the difference here disappears into the noise. With scripting I expect portable attacks to be possible and in that case I would expect to see matching percentages between Linux and Windows for sources of malware.
Why is there never any comment when somebody writes "Microsuck" or "Winblows", but this rather harmless dollar sign (which I personally find very useful to avoid reading the abbreviation as Multiple Sclerosis or Miss) always brings out this troll? I think somebody's feelings are being hurt. Awwwww....
M$ M$ M$ M$ M$!!!! Whoopie!
I don't understand. Sure not everybody is going to read the source. But not everybody is going to decompile a program either.
If I was to place bets, I would bet on the number reading the source to be slightly higher than the number running the decompiler. Asumming that is true, this is a good thing for open source.
In either case it only takes one person to do it, as long as they communicate any interesting things they find to others.
"Software isolated Processes" and "managed code" are different names for the same thing, aren't they?
- What is the value of being able to express illegal utf-8 strings? It seems you would want to reject them anyway before using such a string to store file names.
This is necessary if your file system has a file on it named by an illegal utf-8 string and you want to open it!
If you take a case-sensitive view, why can't a stream of wide characters be viewed as a stream of bytes for string comparison purposes?
Because you can translate more than one utf-8 string into the same utf-16 string (this will happen if the utf-8 string contains an illegal encoding or an encoding of a the surrogate half-characters). This means that comparing the utf-16 strings does not return the same result as comparing the utf-8 strings. OS/X decomposed characters are also a problem
How does this lead to the problems that you say?
It basically comes down to a program saying "these two utf-8 strings are not equal, therefore I know that I can write the file named by one and not clobber the file named by the other". When the program gets this wrong you get security vulnerabilities and you lose data and you get weird error messages.
Whether case-independent file systems is bad is probably another discussion
They are bad because the filenames are no longer a plain string of bytes. What you are really asking for is a spelling corrector, and it is unclear why you (and so many others) think a spelling corrector should be part of the file system. The system should provide a way to quickly list matching filenames to an arbitrary regexp (this is needed rather than just readdir because some file systems have an infinite number of available names) so that a program or back-compatability library can quickly do case changing and other spelling correction if the filename it got was wrong.
So the unadorned interface isn't really a third interface, it just lets you switch between the *A and *W versions with the UNICODE symbol.
I was talking about the a, w, and "mb" interfaces. Though the existence of the the mb interface is due to the poor design of the Asian dual-character encodings. UTF-8 can be used with the old ASCII interface because of the ASCII compatability and the extremely low probability that text in ISO-8859-1 would look like a legal UTF-8 encoding (preserving these, and allowing programs to generate arbitrary streams of bytes, are the reasons I want illegal utf-8 strings to be legal filenames).
Copying a file shouldn't have to know about the attributes... systems should just issue the "copy" system call...
...)
Unfortunately it is nowhere near that simple. *something* has to copy the file, for instance the file system that is on the receiving end of your "copy" system call. If it does not know about extended attributes, you lose. The only solution is to get everything into a single stream.
Emacs, it issues a "rename foo.txt foo.txt~" command, a "open O_CREAT foo.txt" command, and then several writes to the new foo.txt. In other words, foo.txt is a new file.
That is the only safe way to make a backup. A copy might fail. I suppose you could rename to the ~ file, then copy to the new file (with the copy-file api) and then write over the new file, and the safety would be equal. But it would be rather wasteful as the copy-file api would copy stuff you know is going to be overwritten. You might then say "well the copy file api should take some flags to indicate what to copy" but then you have started down the rats nest of adding options to what should be simple api's.
In any case *many* people want exactly what Emacs is doing to be the basic behavior of the OS. Writing a file will *always* get you a completely blank one. When you close the written file, it is an atomic operation and at that point anybody opening the file will see the new one, anybody who previously opened the file sees the old one. The old one either disappears from from the directories (so nobody can open it) or it is given a version number (like VMS used to do) or otherwise placed where it can be readable. This is the way it should be done, but it will mean that nothing can possibly be preserved between copies, and this will happen to *all* programs.
Now, Windows has a capability they call file system tunneling, which I thought I had tested and found that it would keep extended attributes, but I guess I'm wrong, because it doesn't.
Without a preserved reference to the original file there is nothing the OS can do.
You need either something external to the file (extended attributes), to change a large portion of current code so that it doesn't break, or not use a unified way of storing the information. (Comments for source code, EXIF comments for photos,
The second version is what I was proposing. There are obvious problems though, so it could never provide a reliable metadata system. What could work is that there are rules to *attempt* to extract metadata from a file, probably done by user-space programs. Thus if the metadata disappears, in many cases it will magically reappear because it can be extracted from the file.
Another possibility is to use directories, but change it so that reading a directory produces a data stream that is something like a tar file of all the contents. Writing this to an aware filesystem would produce a matching directory. Writing this to another file system would produce a file that when copied back to the original filesystem would produce the directory. Then all the branches of data is stored in subfiles. Then programs that want to actually use the data rather than copy it would have to open name/data instead of name.
Also, I don't really WANT to see all the metadata when I'm editing, say, a text file, tough I guess this could be added as a editor feature to turn it off.
Biggest problem I see with Windows is the use of "wide characters" in the filenames. They need to replace this with utf-8 asap and remove all the triplicated interfaces (old, a, and w) that it has now.
As someone who has only recently been reading about Unicode and text encodings and such, what are the problems with wide characters? The only one I know of is wasted space for western alphabets, but utf-8 wastes space for east Asian alphabets.
By far the biggest problem is that wide characters cannot represent an arbitrary stream of bytes, for instance an illegal utf-8 encoding. This means that a program cannot re
Actually on Vista they did make "/Users/name" as a "home" directory with all personal stuff under it. This happens to be the same name used by OS/X. They go through some contortions to avoid using the word "home" or put a picture of a house anywhere, which is pretty funny, but otherwise it works.
/Library/Fonts/NAMEOFFONT.ttf where the filename is actually something user-friendly.
I would also like to see:
- Make \n be the newline seperator by changing their file system so all written files are binary mode at all times. Reading files can continue to strip the \r when in text mode, but they will all quickly disappear and then text mode can be eradicated. Fix notepad (the only program I can find that does not like bare newlines in the file). Programs should also be written to treat \r as whitespace and ignore it at the ends of lines (Linux programs should do this as well). And finally we will be rid of this disgusting mess.
- Make UTF-8 be the character set to name all files, and have the system treat filenames as strings of arbitrary bytes. Thus the 'a' interface becomes the native one and the current encoding is forced to utf-8. Remove case independence. This will allow identification of files to be done by "the string of bytes is equal" and thus eliminate a lot of bugs in filesystem implementations. For back-compatabilty add whatever is needed so the win32 api can search for possible matches if the first name it tries does not open because it has the wrong case (adding this is also proposed for Linux, apparently).
- Stop writing "bom" to the start of UTF-8 files. No big deal but it will help with the removal of "text mode" just like the newlines.
And on the Linux end:
- Allow a blank directory name, or some other arrangement, so that "//blah" is a legal filename and different from "/blah". This will allow the much nicer Windows unc remote host names to be used.
- Make FUSE work and be always supported, and have it do the rest of the "//computername" naming. And put all that crap that is in KDE/Gnome libraries into FUSE so that we can do "/http/..." and similar things and access everything.
- Put the damn fonts into
No, you cannot make "/xyz" point at an arbitrary place. As far as I can tell the highest up in the hierarchy you can go is "//localhost/?/a/xyz", the "xyz" can be made to point somewhere.
Since you cannot make arbitrary changes I agree with the gp that NT is not providing a "single rooted file system".
Another HUGE problem is that not all the Win32 calls accept unc filenames, meaning you cannot type them into many programs.
Conversely, I would like Unix to accept a zero-length filename so that the "//" leading syntax is legit. Apparently this is not allowed by the POSIX standard but I think that should be changed. This and FUSE would allow 100% compatability with the Windows unc filenames. And they should get rid of that "prefix:" syntax being used by wrapper libraries to access things, and go with mounted links.
No you are mistaken. At the time a Windows client would not work without that "PAC" information. Thus Windows clients could not use non-Windows hosts.
Also Microsoft did not "publish" the documentation. They specifically threatened Slashdot and told them to remove links to a leaked version of the documentation. Eventually they gave up and thus the leaked information is the "published" information you seem to think exists.
Re #2: this is what Linux does as well (provide a shared library that implements what appears to be the system interface). I'm pretty certain all modern operating systems do this. The actual Linux system api does not exactly match POSIX and does not match exactly between versions.
On extended attributes, you are going to have the same problem as you have with Emacs with *any* program that tries to copy a file and does not know about the attributes. This happens on Windows, and certainly on the Mac with the "resource fork". I would prefer to see a system where the attributes are embedded into the single stream of text that is in the file, so they are always copied and can be stored on any device. Unix sort of has some trivial examples, such as the "#!" at the start of a file to indicate the program to run. Ideally *everything* about the file, even it's name, could be embedded this way. Gets tricky if protection/acls are embedded but not impossible (it would ignore them excessive permissions).
Largest problem I see with Linux is a rather rabid requirement for back-compatability with quite-obsolete file system layout requirements. Every reason for the LSB disappeared 20 years ago with the implementation of symbolic links. Would like to see atomic creation of files (no other program sees changes until the file is closed), union mounts, elimination of most/all environment variables and replacement with the existence of files, etc, make FUSE be the primary way to get files and add enormous numbers of named services using it, etc. All of these will break things but need to be done.
Biggest problem I see with Windows is the use of "wide characters" in the filenames. They need to replace this with utf-8 asap and remove all the triplicated interfaces (old, a, and w) that it has now. And start using forward slash and make "/A/" mean the same as "A:/".
A "non commercial only" restriction is not just incompatable with the GPL. It is incompatable with the BSD license. It is incompatable with public domain. It is even incompatable with Microsoft's own osf-approved licenses!
I think you may be somewhat over-estimating the quality of what IBM was selling. There are reasons why Unix and many other things were developed on non-IBM hardware.
I agree. I would seriously like to see this pledge not to sue over the patents for APIs. It would be interesting to find that it only applied to certain types of used which would still be too restrictive for GPLv3 compliance.
They said "for non-commercial use". This is too restrictive for GPL3. It is too restrictive for GPL2. It is too restrictive for BSD, or for Public Domain. Hell it is even too restrictive for Microsoft's own shared-source licenses!
I think a scheme whereby you can buy extensions to copyright would work, and (just maybe) the government + lobbyists would approve it.
Something like you get the first 10 years for free. Then you must re-register the copyright each year after that. And the price of re-registering it goes up each year, probably linearly.
Disney could keep re-registering Mickey Mouse and whatever else it decides they might make more money from than the registration each year. Stuff that is worthless would drop out of copyright. Also if you found an obscure item and it is more than 10 years old, it would be easy to check to see if it is copyrighted because the registrations would be recorded.
You are talking about putting *graphics drivers* in the kernel, and I agree there could be very good reasons to do this and would at one time have thought this was the only way. It does appear now that providing a device-specific kernel module that provides protected access to the hardware, and having the graphics done by the user process, may be better as it avoids any context switches.
By "gui" most people mean windows/buttons/sliders/etc. Those certainly should *not* be in the kernel.
After all, in Unix, terminals and other IO devices are a part of the core OS
Oddly enough, this is one of the worst aspects of Unix design and easily disproves your whole argument. In fact the Unix tty interface is the perfect argument why gui should *not* be in the system!
An intelligent system would have made the tty driver deliver the bytes unchanged directly as the user typed them to the application. Line editing and echo and so on would be done by the process.
On Unix it is an incredible pain to get the terminal put into "raw" mode so you can get single characters (as any on-screen editor wants). We also have bugs that should have been fixed ages ago, such as the fact that backspace often does not work, these cannot be fixed despite the apparent trivialness due to the fact that there is a complex api that basically dictates the implementation of the user interface (in this instance there is a single "what key does backspace" field, and you cannot add a new one without being incompatable). Also if you want to do *anything* more fancy than the normal io, such as every shell in the world that now does history editing, you have to force the terminal into raw mode and thus you are forced to replicate all the ui code in your own program anyway, thus defeating any possible reason for it to be in the system! It is also why there are "pseudo ttys", these are a horrible hack so that your terminal emulators can work, because all programs were designed to talk to this specialized tty driver, rather than being able to be connected to a plain pipe, which they would have been if they used raw tty i/o.
Putting the GUI into the system is exactly the same mistake as the Unix tty driver. It is pretty sad that nobody is learning from mistakes made 37 years ago and is repeating them even today. Yet they are...
I don't think it is a problem if there is special sim-city stuff in the "dos box" code, as long as it does not effect the main system. This is no different that claiming that the complexity in Wine is a problem with Linux. (though I would guess that maybe it does, a general complaint is that while NT was quite clean, they messed up the kernel by moving stuff into it for compatability).
.net. I am just worried about anything that relies on other sources for the code it needs. I suppose maybe it includes downloading the correct version of the library from a source, or are the programs in effect statically linked? Another possibility is that the programs are "statically linked" but include code that will run a newer/better version of a library if it is available. This sort of scheme does work and is best seen in OS/X app bundles (you can also do it on Windows and Linux by putting the shared library in the same directory as the program) but in all these it is "reversed" in that the "static" version of the library takes precedence. Also kind of annoying that it relies on directory structure rather than it being part of the executable.
I don't know anything about
My personal opinion is that *everything* should be statically linked. It is obvious that it works, and any worries about wasting memory or disk space could be solved by using hashes of the read-only pages to locate identical ones and make them be the same memory. The complaint is always that some bug fix in a library will not be available to programs, but I have not seen that in practice. In fact I have seen the reverse: a bug gets introduced into libjpeg, say, and everything is suddenly vulnerable. Previously the programs would all be linked with many different versions of libjpeg and thus whether the bug is there or not is difficult to determine by hositile attackers.
Okay I looked around for 10 year old Linux programs and tried them on Ubuntu 7.1:
.so files they could not find (yea they were on the disk the programs were on but not in my LD_LIBRARY_PATH). And even more annoying is software less than 1 year old. Our own commercial software is crashing because of changes to the libstdc++ api because those idiots did not change the version number because they think they were being compatable. Unfortunatly this is not only on Linux though I think Linux is worse. We have horrible problems with changes to QuickTime where again they did not change the version number. I am also very doubtful about the long-term compatability of .net as it is the same mess that the KDE/Gnome environments are foisting on us.
xv: worked
seahaven card game (I compiled this myself ten years ago): worked
A tetris game: worked
tcsh: worked
tk: worked
xpaint: worked
alright, alright, maybe I'm being too easy on it. Lets try something hard:
fvwm: worked
Maya 5 (a cracked copy): worked (might only be 7 years old)
Old copy of tuxracer: (again may only be 7 years old): worked
In reality software that old does work. What *doesn't* work is software more like 5 or less years old. Tried running old kde programs and they did not work. I bet old Gnome programs would not work either. They both required
The connection could have been almost *free* if it had been built as part of the "big dig". There are a lot of questions about why it was not done.
I think Slashdot truncated his joke. He put a bunch of candidate's names (including Clinton) with ^H (backspace) characters between them, as though he kept changing his mind about who was behind it.
I think the general hope is that Microsoft would be replaced by several companies, each of about the power of the current PC manufacturers such as Dell and IBM, and with the ability for tiny companies to compete in some way, just like it is possible to go to a little computer store and buy a computer that works in a way that is competitive with a Dell. It does seem very likely that these machines will run Linux as a fallen Microsoft would probably be unable to release Windows sufficiently to make it an option for price-concious companies, and basing it on Linux will allow them to hire people with experience and cross-hire from their competitors. However the companies will compete on closed-source applications with tight integration into their web services, so it's not like it's going to be some OSS nirvana where you can mess with any program you want and improve it.
I suspect more likely one of those companies would end up dominating, by technology lockin just like Microsoft does. A closed program running on Linux can use an obfuscated proprietary data just as well as one running on Windows. Hardware manufacturers and the RIAA/MPAA might wise up and realize that DRM can be done with a piece of sealed hardware with an api that is like a DVD remote control (ie stop, play, etc) so that the api can be published and nice controls integrated into any system that uses this hardware, and the company with the rights to insert this hardware into their machine could be the winner.
Actually I think "O$$" could be a very useful abbreviation. It would represent the commercial use of open source. This could be anything from "evil company getting work for free" or "using the term because it is a buzzword", to "company contributing lots of code back because it is in their interest".
I think if any of the silly replies above checked my posting history, I always wrote out "Microsoft" (or "MicroSoft" since it was actually called that back when I started working on computers). However I'm going to go through the extra effort of typing "M$" from now on.
I did not think of that. I only know Basic from long ago, is the $ at the end and not at the start?
In any case, I cannot understand why this gets the Microsofties upset so much. Hey, they are free to call Linux "£x", or call open source "O$$" if they want. Do it enough so that it is well-established and easy-to-read as "M$" is. And lets see if that really upsets people. Of course it wont.