Gad. We should just say that "bytes with the high bit set must be sent unchanged" through everything and scrap everything that does not obey this.
This would allow all transports to ignore the character encoding as long as the encoding only uses bytes with the high bit for non-ascii. It also means that case-independence of non-ascii would be illegal, thus stopping the emergence of a dangerous (for security) mess of incompatable implementations of equality tests for URLs.
This would allow us to use UTF-8 for the URL, for the page contents, for email, for everything, and we would not have this horrid mess of prefixes and mime types.
Yes, some programs, routers, etc, would not pass this stuff through. Well, tough, those should be obsolete!
Anybody manufacturing a device or system that can run an end-user algorithim capable of translating stored bits into audio/video will be declared illegal. This includes Linux and any open-source software, all hardware with documentation, and any closed-source language that can control the audio any finer than "play this song".
This is not a joke, and is of course the real reason that all computer professionals fear the DMCA.
Not quite. As I understand it, the watermark stops the playback. There is also some scheme where the streaming audio or other code tells the hardware that "this watermark is ok right now" (otherwise it would be impossible to play the original).
But your scheme is workable, while what I described will never work, because destroying the watermark is much easier than creating a legal one. The problem is that nobody can make a recording without sending it to the RIAA to be "stamped" (no local device can stamp the watermark, even if it checks for an existing one, because that reduces cracking to the ability to destroy a watermark again).
This means nobody (like an independent band) can record music! Of course this is the goal the RIAA wants ultimately!
Does this actually modify the system (or perhaps libc) so that the files appear to all programs? As far as I know this is a user-level library. If doing this differentiation there is good, perhaps Linux should be designed so that pipes, devices, sockets, and each disk is a different system call. My feeling is that it is better to put this switching on the other side of the context switch into the system.
Then again, I really don't know what I'm talking about. libc may actually be doing the entire file system and translating it to disk block read/writes and I would not be able to tell.
Still, I want "open()" (and not "vfs_fopen()") to read these files, as I don't like complicating the interface with new calls.
I think this is a very good point! Why isn't all this stuff that allows the same program to view http pages, ftp sites, the contents of tar files, and the local and nfs file systems put at some lower level so that average programs can take advantage of it?
It would be really nice if fopen("http://www.slashdot.org") worked.
Which is easier, `cp
~/docs/1999-2000/somefile.abw/mnt/floppy/homework` or dragging an icon across the screen?
The "cp" is easier if you have filename completion. It is *far* easier if that destination directory has not been "opened" yet in the GUI.
What about D&D support?
Everybody should by now realize that the "stupid" Unix middle-button cut/paste is in fact exactly equivalent to D&D, except because you are not holding the mouse button down in the middle of an operation you suddenly realize how limited D&D is and complain that you cannot select the destination location without losing the selection.
I recommend that "middle mouse selection" be merged with D&D (and split from Alt+XCV cut/paste text selection). All "drop targets" should accept a middle-mouse click and should use the clipboard as the URL that is dropped.
Selection of an object anywhere should put the URL into the clipboard. You can then drag & drop like Windoze, or middle-mouse click to drop. Selection of text should allow the text to be dropped, the drop target decides if it should be treated as text or a URL (this will allow URL's to be pulled from email or other text sources)
For CLI there should be a program ("drag"?) that takes it's arguments and puts them all as URLs into the clipboard for dropping, and a program ("drop"?) that prints the URL's (with proper quoting) to stdout. This requires a method for a CLI program to identify the X server, I hope this can be done without too much ugliness.
It would be nice if terminal emulators accepted drops and middle-mouse clicks and caused the URL to be typed, perhaps with delimiting spaces and proper quoting.
I don't mind that people use the GPL, but the code I am writing I would prefer to release under the LGPL (the largest thing I wrote is the FLTK toolkit, www.fltk.org).
This is because I believe the existence of these free toolkits encourages software developers to write portable code that runs on Linux and other free systems. I very much disagree with Stallman's opinion that LGPL is bad. In my experience proprietery software developers will give up and use MFC or other MicroSoft solutions when the alternative is GPL. This hurts much worse than not having their source code.
I hope that despite Stallman's lack of support, the LGPL will continue to exist and be enhanced.
My specific question is that the current wording of the LGPL makes use of my software or any other small LGPL library very difficult. This is because it effectively requires dynamic linking. Dynamic linking is very bad, as it requires that the resulting program be "installed" before the user can run it. It also strongly discourages modifications to the library (to avoid version incompatabilities) which imho defeats the whole reason for free software! In my opinion dynamic linking causes my software to be so nearly useless that nobody would want it.
I have explicitly stated on my web pages that static linking with fltk is allowed and even encouraged, no matter what the LGPL says. But is there any legal way to do this, or any way to fix the LGPL, or make a LLGPL (lesser lesser gpl?) that explicitly allows this? I would prefer to reuse the careful legal work done for the LGPL rather than risk writing my own.
Oh come on. Yes, the network transparency is nice and should be preserved. But the inane rendering model has got to go!
There is no excuse in the modern world for a program to have to manage "visuals" or "colormaps". And it is horrible that you have to write many pages of code in Xlib (and allocate many tens of thousands of structures to enumerate every font) to make code that will reliably locate and use the "Helvetica" font on any X machine.
I really propose the entire graphics system be scrapped (and emulated in Xlib). Replace it with a new gc that contains a window id, make it act as though it is True Color always (use server local allocation of colors on old hardware), and replace the entire font system with one where you find the font Helvetica by sending the damn string "Helvetica" to the server! (and of course make it antialias and make it draw UTF-8 encoded text!)
The data would be completely visible to read(). Like you say, if this were not true you would lose the whole point of it. Yes this would require some apps to be rewritten to skip over it.
In most cases I expect the format to be flexible enough that the data can be hidden in a comment in existing file formats. A good example is the "#!" syntax used by executable scripts in Unix.
EXACTLY! The Unix decision is arbitrary. The only non-arbitrary decision is NO ATTRIBUTES. Certainly adding a few more arbitrary attributes is just going to make it worse!
I would like to see a system where the file permissions, the file name, the date, everything is stored in the data in the file. In your attempt to disagree with me I think you reinforced my position.
I think there is some work being done on this. Permissions are controlled by the parent directories as well as the file, since you are allowed to set the permission and user of your file to anything you want with this.
The basic problem is that information vital to the use of the file is not stored in the data that you get with read()/write(). This makes it impossible to cleanly store this data on another system or to transfer it. Yes, you can "encode" (or "binhex") it, but if you do that, why not just store the encoded version on the disk, and remove a large and complex mess from the OS?
In fact there is absolutly no reason for this information to be stored in any way that the OS sees. The data is only used by user-level programs (for instance a file browser that selects what program to launch).
Another problem is that the id space gets used up quickly and then only commercial software vendors who talk to the official Linux ID assignment consortium can make new IDs. With magic bytes in the file, if there is a collision, you just make a more complex test for distinguishing files that looks at more bytes.
The biggest problem is that there is zero chance that once you add this database feature that there will not be dozens or even thousands of new id/value pairs added to the system, and dozens of standards for encoding these so that files can be copied. I would much rather force everybody to use simple files and thus get all this mess into user space.
Personally I feel that everything about the file, even it's name, could be stored in the data somehow, though I'm not sure how. Some of the ReiserFS stuff is looking at this, I think, since the Unix overhead of name/permission/date is larger than most of the files they want to use.
#include
int main() {
printf("Hello, World!\n");
}
You are right, it is possible to write a small program without any bugs and - wait, sorry, I forgot to make it return an exit code. Let me get back to you...
You can get the C compiler ccc for free from Compaq. I tested this on several tiny programs that simulated our usage of FP and arrays and it was MUCH faster, like 15 times faster in a few cases! Be sure to use the "-fast" switch when compiling, it removes some IEEE compliance and turns on all the optimizations.
Unfortunately they charge $400 for the C++ compiler, and it does not seem to take the "-fast" switch, and the man pages are miswritten so that you cannot read the names of any switches. When I compiled our "real" application (about 100K lines of C++) the result was about equal in speed to the -O3 gcc version, which was a real disappointment. I don't know if the failure was due to the C++, the lack of the correct switch, or because my tiny test programs did not accurately simulate what we really did.
Still, $400 is not much. Anybody know if they have compiled the kernel with this?
The Siggraph demo was at HDTV resolution, but was nowhere near the quality of the actual movie renders. It basically was a high resolution image of high-resolution texture maps but otherwise like a game box. An obvious indication that this was not used to generate the movie is that you could use the joystick to move the camera around while the action played, obviously an unnecessary feature for final renders of the movie.
The box was quite impressive. I was told it was 12 PS2's running in parallel, each doing a video-sized piece of the image. There may have been more PS2's coordinating it.
Unix shared libraries way predate MSDOS. This includes position-independent versions, which are needed to allow more than a few vendor-supplied libraries to be shared. That is why, clumsy as it is, Unix at least has a scheme to manage huge numbers of shared libraries.
Windows DLL's are position independent though. The 80386 design allows PIC code without too much loss, this was certainly due to a desire to allow the chip to be used for Unix with shared libraries.
I suspect the main reason for the smaller size is that by default all symbols in a DLL are local to the library, while by default all symbols are public in a Unix library and thus harder to "strip". They did this by requiring "_dllexport" macros to be stuck before any symbols that can be linked outside the library, in effect adding something that should have been added to C a long time ago... (of course they royally screwed it up so that you cannot write a header file for a DLL without using macros, as the syntax changes for code inside and outside the library!)
Let's see. MacOS X, NeXTSTep, and BeOS all use something similar to attributes. Hell, UNIX uses it in the form of attribute bits (owner, group, date, etc.)
NeXTStep used the Unix file system and thus has no more attributes than any Unix system. They used ".app" directories, which is a good example of storing such information in a way that is easily copied to other systems, and in a way that avoids complicating the file system. Each "attribute" is a standard file and thus can be read/written using the standard file I/O mechanisms. MacOS X does the exact same thing.
I would argue that "directories as files" should be supported, but this can be done entirely at the application library level. This would mean that reading a "directory" and then writing the same bytes to another system would produce an identical directory with identical contents on that system. I would argue that this is an area where Linux should abandon Unix/Posix and really try to make something better. But it is still not an "attribute" in that there is nothing special about the internal data and it is not inserted into a database.
I also think that the Unix owner/group/date stuff is a mistake and should be imbedded in the file data somehow.
The basic problem is we need a simple block of data that 100% describes the file. To most users, the date, creator, comments, document type, etc, are all parts of the file and thus anything that does not replicate it is not user friendly. And I don't for a minute believe that application designers are only going to put "unnecessary" data into the attributes.
Therefore I think *all* attributes (including the Unix date, permissions, group, etc) are a mistake. ALL data should be copyable by reading the file and writing the same bytes to a destination. Anything else, especially a system with low-level knowledge like BeOS, is going to make computers hard to use.
Hi! You are right about the hardware modifications they want. But whether such obnoxious hardware is ok or bad, I believe that if they are really going to succeed in this they must design the hardware such that they don't mind having an open-source driver.
If they think closed-source drivers means they are safe they are completely wrong. They must design hardware so that they are not afraid of people knowing the entire interface in detail. The trick is that the interface does not allow anybody to do what they don't want you to do.
First, the MacroVision can be tied on the DVD decoding card to the decoding. It can be impossible to turn it off if the card is decoding a DVD.
Second, I expect the video picture to go direct from the card to a plug on graphics card. The X11 driver (open source) will be unable to give the card any directions other than "put the video here". Attempts to grab that area off the screen will result in garbage, as the video image will not reside in the graphics memory.
The biggest way to combat piracy is to allow people to grab images. The DVD card can also put still frames on the bus, but will have a timeout so that no more than a few per minute will work. The ability to grab a still or a very short clip will get rid of the desire to hack this cable to the video card.
Goddamm, I'm going to stop listening to all those people using crap analog instruments. And don't even get me started on the crap sound that vocalists produce!
The plan is to implant a reciever in your audio cortex. Data will be encoded until that. There is also the necessity of disconnecting portions of your brain so that you are unable to hum or otherwise describe the music to another person.
Slashdot Mirror
This would allow all transports to ignore the character encoding as long as the encoding only uses bytes with the high bit for non-ascii. It also means that case-independence of non-ascii would be illegal, thus stopping the emergence of a dangerous (for security) mess of incompatable implementations of equality tests for URLs.
This would allow us to use UTF-8 for the URL, for the page contents, for email, for everything, and we would not have this horrid mess of prefixes and mime types.
Yes, some programs, routers, etc, would not pass this stuff through. Well, tough, those should be obsolete!
This is not a joke, and is of course the real reason that all computer professionals fear the DMCA.
But your scheme is workable, while what I described will never work, because destroying the watermark is much easier than creating a legal one. The problem is that nobody can make a recording without sending it to the RIAA to be "stamped" (no local device can stamp the watermark, even if it checks for an existing one, because that reduces cracking to the ability to destroy a watermark again).
This means nobody (like an independent band) can record music! Of course this is the goal the RIAA wants ultimately!
Then again, I really don't know what I'm talking about. libc may actually be doing the entire file system and translating it to disk block read/writes and I would not be able to tell.
Still, I want "open()" (and not "vfs_fopen()") to read these files, as I don't like complicating the interface with new calls.
It would be really nice if fopen("http://www.slashdot.org") worked.
The "cp" is easier if you have filename completion. It is *far* easier if that destination directory has not been "opened" yet in the GUI.
What about D&D support?
Everybody should by now realize that the "stupid" Unix middle-button cut/paste is in fact exactly equivalent to D&D, except because you are not holding the mouse button down in the middle of an operation you suddenly realize how limited D&D is and complain that you cannot select the destination location without losing the selection.
I recommend that "middle mouse selection" be merged with D&D (and split from Alt+XCV cut/paste text selection). All "drop targets" should accept a middle-mouse click and should use the clipboard as the URL that is dropped.
Selection of an object anywhere should put the URL into the clipboard. You can then drag & drop like Windoze, or middle-mouse click to drop. Selection of text should allow the text to be dropped, the drop target decides if it should be treated as text or a URL (this will allow URL's to be pulled from email or other text sources)
For CLI there should be a program ("drag"?) that takes it's arguments and puts them all as URLs into the clipboard for dropping, and a program ("drop"?) that prints the URL's (with proper quoting) to stdout. This requires a method for a CLI program to identify the X server, I hope this can be done without too much ugliness.
It would be nice if terminal emulators accepted drops and middle-mouse clicks and caused the URL to be typed, perhaps with delimiting spaces and proper quoting.
This is because I believe the existence of these free toolkits encourages software developers to write portable code that runs on Linux and other free systems. I very much disagree with Stallman's opinion that LGPL is bad. In my experience proprietery software developers will give up and use MFC or other MicroSoft solutions when the alternative is GPL. This hurts much worse than not having their source code.
I hope that despite Stallman's lack of support, the LGPL will continue to exist and be enhanced.
My specific question is that the current wording of the LGPL makes use of my software or any other small LGPL library very difficult. This is because it effectively requires dynamic linking. Dynamic linking is very bad, as it requires that the resulting program be "installed" before the user can run it. It also strongly discourages modifications to the library (to avoid version incompatabilities) which imho defeats the whole reason for free software! In my opinion dynamic linking causes my software to be so nearly useless that nobody would want it.
I have explicitly stated on my web pages that static linking with fltk is allowed and even encouraged, no matter what the LGPL says. But is there any legal way to do this, or any way to fix the LGPL, or make a LLGPL (lesser lesser gpl?) that explicitly allows this? I would prefer to reuse the careful legal work done for the LGPL rather than risk writing my own.
You seem ot have misread.
Preferrably the original Gosling NeWS server, not the X11/NeWS hybrid. Both would be even better, though...
There is no excuse in the modern world for a program to have to manage "visuals" or "colormaps". And it is horrible that you have to write many pages of code in Xlib (and allocate many tens of thousands of structures to enumerate every font) to make code that will reliably locate and use the "Helvetica" font on any X machine.
I really propose the entire graphics system be scrapped (and emulated in Xlib). Replace it with a new gc that contains a window id, make it act as though it is True Color always (use server local allocation of colors on old hardware), and replace the entire font system with one where you find the font Helvetica by sending the damn string "Helvetica" to the server! (and of course make it antialias and make it draw UTF-8 encoded text!)
I still dream that something will replace X but it is looking hopeless now...
In most cases I expect the format to be flexible enough that the data can be hidden in a comment in existing file formats. A good example is the "#!" syntax used by executable scripts in Unix.
I would like to see a system where the file permissions, the file name, the date, everything is stored in the data in the file. In your attempt to disagree with me I think you reinforced my position.
I think there is some work being done on this. Permissions are controlled by the parent directories as well as the file, since you are allowed to set the permission and user of your file to anything you want with this.
In fact there is absolutly no reason for this information to be stored in any way that the OS sees. The data is only used by user-level programs (for instance a file browser that selects what program to launch).
Another problem is that the id space gets used up quickly and then only commercial software vendors who talk to the official Linux ID assignment consortium can make new IDs. With magic bytes in the file, if there is a collision, you just make a more complex test for distinguishing files that looks at more bytes.
The biggest problem is that there is zero chance that once you add this database feature that there will not be dozens or even thousands of new id/value pairs added to the system, and dozens of standards for encoding these so that files can be copied. I would much rather force everybody to use simple files and thus get all this mess into user space.
Personally I feel that everything about the file, even it's name, could be stored in the data somehow, though I'm not sure how. Some of the ReiserFS stuff is looking at this, I think, since the Unix overhead of name/permission/date is larger than most of the files they want to use.
int main() {
printf("Hello, World!\n");
}
You are right, it is possible to write a small program without any bugs and - wait, sorry, I forgot to make it return an exit code. Let me get back to you...
Don't make excuses. This is exactly the same type of crap that MicroSoft dishes up, and RedHat is guilty of delivering it.
Unfortunately they charge $400 for the C++ compiler, and it does not seem to take the "-fast" switch, and the man pages are miswritten so that you cannot read the names of any switches. When I compiled our "real" application (about 100K lines of C++) the result was about equal in speed to the -O3 gcc version, which was a real disappointment. I don't know if the failure was due to the C++, the lack of the correct switch, or because my tiny test programs did not accurately simulate what we really did.
Still, $400 is not much. Anybody know if they have compiled the kernel with this?
The box was quite impressive. I was told it was 12 PS2's running in parallel, each doing a video-sized piece of the image. There may have been more PS2's coordinating it.
This could prove your point, actually, as SGI also may have considered and rejected such designs.
Windows DLL's are position independent though. The 80386 design allows PIC code without too much loss, this was certainly due to a desire to allow the chip to be used for Unix with shared libraries.
I suspect the main reason for the smaller size is that by default all symbols in a DLL are local to the library, while by default all symbols are public in a Unix library and thus harder to "strip". They did this by requiring "_dllexport" macros to be stuck before any symbols that can be linked outside the library, in effect adding something that should have been added to C a long time ago... (of course they royally screwed it up so that you cannot write a header file for a DLL without using macros, as the syntax changes for code inside and outside the library!)
Sorry, that code is not going to be open-source.
NeXTStep used the Unix file system and thus has no more attributes than any Unix system. They used ".app" directories, which is a good example of storing such information in a way that is easily copied to other systems, and in a way that avoids complicating the file system. Each "attribute" is a standard file and thus can be read/written using the standard file I/O mechanisms. MacOS X does the exact same thing.
I would argue that "directories as files" should be supported, but this can be done entirely at the application library level. This would mean that reading a "directory" and then writing the same bytes to another system would produce an identical directory with identical contents on that system. I would argue that this is an area where Linux should abandon Unix/Posix and really try to make something better. But it is still not an "attribute" in that there is nothing special about the internal data and it is not inserted into a database.
I also think that the Unix owner/group/date stuff is a mistake and should be imbedded in the file data somehow.
The basic problem is we need a simple block of data that 100% describes the file. To most users, the date, creator, comments, document type, etc, are all parts of the file and thus anything that does not replicate it is not user friendly. And I don't for a minute believe that application designers are only going to put "unnecessary" data into the attributes.
Therefore I think *all* attributes (including the Unix date, permissions, group, etc) are a mistake. ALL data should be copyable by reading the file and writing the same bytes to a destination. Anything else, especially a system with low-level knowledge like BeOS, is going to make computers hard to use.
If they think closed-source drivers means they are safe they are completely wrong. They must design hardware so that they are not afraid of people knowing the entire interface in detail. The trick is that the interface does not allow anybody to do what they don't want you to do.
First, the MacroVision can be tied on the DVD decoding card to the decoding. It can be impossible to turn it off if the card is decoding a DVD.
Second, I expect the video picture to go direct from the card to a plug on graphics card. The X11 driver (open source) will be unable to give the card any directions other than "put the video here". Attempts to grab that area off the screen will result in garbage, as the video image will not reside in the graphics memory.
The biggest way to combat piracy is to allow people to grab images. The DVD card can also put still frames on the bus, but will have a timeout so that no more than a few per minute will work. The ability to grab a still or a very short clip will get rid of the desire to hack this cable to the video card.
Goddamm, I'm going to stop listening to all those people using crap analog instruments. And don't even get me started on the crap sound that vocalists produce!
The plan is to implant a reciever in your audio cortex. Data will be encoded until that. There is also the necessity of disconnecting portions of your brain so that you are unable to hum or otherwise describe the music to another person.