Enligtenment and Gnome "support" does not cut it, because it is on the client end. If this was sufficient X could have one graphics call (putpixel) and we could quit working because all the work is done!
Hey, I wrote a program that did radiosity and drew the result on the screen, but I don't think anybody would claim that because of that Linux graphics now supports radiosity!
We need advanced graphics in the server. And we need to stop making excuses.
I seem to be in the minority here, but I don't think the "network protocol" is the problem. The problem is in the horrid design of the Xlib calls themselves! Implementing Xlib as local calls will just remove the only advantage of X and would be totally wrong.
There is nothing wrong with buffered network protocols. In fact they use less context switches than api's. If this were not true, why do we have interfaces that write more than one character (or one bit) to a device? Isn't the overhead of copying those characters to a buffer from where they originally were inefficient? NO!
Another way to look at it: if Xlib puts 10,000 requests in a buffer and sends it, we get TWO context switches (one to the kernel, one to the server). Win32 gets 10,000 context switches (each one to the kernel for each call). And X, despite being 5000 times more efficient in context switches, does not have the risks of putting complex code in the kernel! (PS: yea I know Win32 ain't that bad, but their solution is exactly equivalent to buffering multiple requests!)
What does lose in network protocols is synchronous communication. When Xlib has to wait for an answer from the server, we get at least 4 context switches, plus the network overhead, and we lose. But we don't need so much synchronous communication!
The solution is to chuck out most of the Xlib design except for the fact that it is a network protocol. A program that displays a non-interactive display should be writable with a *single* "write" to the server (plus it may have to wait for redraw events and send that write again).
Get rid of colormaps! Trash the horrid font system and put in something so that if I ask for "Times" and 12 points, I get something (even if it is not Times at 12 points, if it has letters in it it would be an improvement over Xlib!). Either get rid of window managers, or make it sequential so I can create a window and send drawing to it in one block, without waiting for a stupid expose event to indicate syncrhonization with the window manager. Get rid of atoms, or make it so I can define thousands of atoms in a single round trip.
While we are at it, put some non-primitive graphics in. It is inexcusable that we don't have anti-aliased fonts, or anti-aliased polygons (even though Win32 does not have these), or a call that draws a color image without me having to figure out how to dither it to the hardware!
has the reliance on X to drive graphics hardware directly strangled the development of alternatives on Unix?
YES!
All the stuff going into XFree86 has killed development of fb or gdi or other simpler protocols. It does not matter how well they are designed, if you want your fancy card to run at full resolution, you have to use X, because all the hardware control is hidden in the X server.
One plausible solution: could new replacements interface with the binary plug-in interface that the new XFree86 4.0 has? Then they could get all the hardware. I'm sure the interface will be painful because it will make X assumptions, but not impossible to program for. Once an acceptable replacement for X has been made, a new low-level interface can be designed, and instructions on how to change the drivers.
If this is true, we need now to get Joe Consumer to know that open-sourced dvd playback will allow them to skip over being forced to watch the commercials and FBI announcement!
To the average user, this is MILLIONS of times more persuasive than any argument about freedom or copyrights or the studio's money or Linux or anything. The masses will instantly be on our side, in forces you cannot comprehend!
Yes, it can't be said officially, but this has to become public, common, knowledge!. It closely resembles the freedom we desire, but in a form that directly affects joe user and a way they can understand trivially.
If necessary, figure out the worst things the DVD consortium can do (force you to watch a half hour? I dunno) and threaten the masses with it.
It sounds like they may have good reason to not use the DRI layer. From my very limited knowledge, it seems like it is a lot more work for them to modify the X server than to use the already-existing interface. If they were just interested in hiding the specs you would think they would release a DRI binary plugin, or if they thought that was too hard, they would not do anything about Linux at all.
It should be perfectly ok to write an entire X server if that is the software writer thinks that is the best way. Layers of software can become slow and the interfaces between them can grow far more complex than the layers themselves. One huge advantage Linux has is that large modules can be replaced, and that modules can be merged, or split, and we should not disallow this.
Of course it would be nice if they released the specs, but it sounds like they cannot becuase of license agreements.
I also wondered if anybody open software authors write Windoze drivers for those Matrox cards based on their specs. One big selling point for these companies to release their specs would be if they, for free, got faster and better Windowz drivers than their competitors! Or is this impossible (it may require NDI info from MicroSoft to write the driver?).
If a group like planned parent hood, the NRA, the KKK or whatever sends out a message to a large group of people unsolicited, couldnt this be considered spam?
Even if Mother Teresa's ghost sent out the messages, it would be spam. Your argument is totally flawed.
Right now the cheapest solution is large numbers of NT machines. Using Linux allows the same hardware to be used, but we get an extra 80-120 Megabytes per machine (approximate memory savings over NT2000 of Linux without X), which when multiplied by the hundred or more machines in the farm is a huge savings! The local disk space may be a savings as well, though the time when we don't have to dual-boot NT is still in the future, sigh...
Also, being able to rlogin to any farm machine and run tests is a huge win! And not having some monkey whose job is to switch the monitor between each machine and hit the "OK" button on the error messages would also help a good deal...
Believe me, we need Linux in the render farm much more than on the desktop.
I think you misunderstood. X is crap, the biggest problem with Linux acceptance. It is inexcusable that no advanced graphics (like draw an rgb image) have been added in 20 years.
X should be replaced. But there is a tiny germ of an idea that needs to be kept. What I want is something that can tunnel over a network. This means bufferable commands. This can also greately improve performance on local machines by reducing the number of context switches. Microsoft says they need to put the graphics in the kernel because it halves the number of context switches. But a well-designed buffered command system (mostly without need for bi-directional communication that requires a sync) can reduce the number of context switches by 10,000 or more (and still leave the server in user space!).
GLX is a sample of how you can take a call-based system and lay it atop a buffered command system.
I would dearly love to see X replaced. I want antialiased and transparency everything, and it is inexcusable that I have to use a library to do even the simplest graphics!
I don't really get this. At least on the projects I'm working on (about 200 source files, of which I often change just one), the compile of that single source file (which may only be 100 lines) takes much longer than the linking step. This is true on NT as well. An "incremental linker" would be the last thing I would consider to speed up work, I would rather have an "incremental compiler" (and yes MicroSoft has this, though it is nearly useless for our work).
Building a library on Linux is S L O W though, apparently because of the huge number of debugging symbols put in. That really ought to be fixed, it is apparently caused by the Dwarf file format.
The transparency people are talking about is not a hardware issue, it is a software one (mostly, like anything else hardware *acceleration* may help, but is not required).
What this means is that you can somehow specify an image, get it drawn, and some of the pixels contain a mixture of what the pixel contained before and the values from the image. Usually this is controlled by the "alpha" channel of the image.
This alpha from the image can (and usually is) thrown away. You can also do useful things by storing it, much like a Z buffer, but the only one I know is a hack so that anti-aliased polygons may be drawn and they cover the pixels 100% where they join.
"Overlay" hardware is, IMHO, not very useful on modern fast computer systems. Only limited graphics can be drawn in it (or if the graphics are unlimited, all that memory would be better used for Z or accumulation or alpha buffers!).
Pardon me, but you are obviously an idiot who has never programmed a real application.
You cannot program a good OO api atop another OO api. You can program a good OO api atop a functional api, like the computer hardware, or a low-level abstraction like OpenGL. Just try it.
Trying to make the low-level portable interface "object oriented" is entirely against object orientation.
Okay, you can go back to playing with your HBRUSHES and HPENS now.
Direct X is pretty split up into libraries as well. The equivalent in Linux would be to concatenate this library with Xlib and call it "libmultimedia". It does not change the interface to the functions at all.
Now it would be nice if a GLX-like tunnel was defined so that the destination of the sound can be determined by the display you opened with X. In fact I can see it useful to have the sound linked with an X window, so that they can have individual volume controls or be muted when iconized, without program support...
I disagree with the reasons given that "mounting" must exist. This can be done with symbolic links.
What I want Linux to do is have/dev/sda be the damn drive like everybody expects! I should be able to "ls/dev/sda" and see what is on that drive, immediately, no matter what file system is in there, and give me an acceptable "no disk in drive" error if there is no disk, or "unreadable disk" if the file system is not recognized. Now I know internally that Linux will have to install the correct file system module, and run a test to find out which one, etc, but this can obvioiusly all be done automatically.
"But how do I make that disk be/usr?" I'm sure people are asking. Simple: "ln -s/dev/sda1/usr" That isn't too hard!
Also if the hardware has a button that gets the disk out, the driver should sync the disk enough that it will be ejected with a good file system. If it is noticably hard to get the disk out, the driver can lock it in until the disk is synched. If it is impossible without turning off the computer the driver does not have to do anything.
This really ought to be done. There is no reason for the internal housekeeping of Linux to be visible outside the kernel.
I had little trouble with the multiple compilers on Windows. Fltk (www.fltk.org) was written with only VC++ and was very quickly ported to Borland and Cygnus by users.
The biggest annoyance is that people *expect* the VC++ "ide" files. In fltk's case these are approximately TEN times larger than all the Win32-specific code (and this is an entire GUI library)!!! This is absolutely insane but that's the way it is. Borland and cygwin are supported with normal makefiles (though autoconf does not work).
I would also expect you to see a Linux port as one of the first contributions you get from the OSS community. This should be considered a free gift, there is no need to even test it if your boss refuses to pay for a Linux machine, but put the porting into the official code set and then you will start to see the real bug fixes and improvements roll in.
Like many others here, I agree that you should NOT "force" people to send you their fixes. This will not change the actions of anybody, and just antagonizes the people who would send you fixes (the vast majority). Most software engineers writing for free want to see their stuff publicized, and the way to do that is to put their stuff back into the official version.
Okay, it does sound like *hard* links, and apparently only to the same file system (just like Unix hard links), plus some automatic thing to detect identical files (a cron job?) and make the hard links. It is very unclear if there is any manual way to create these hard links, possibly not? Random notes:
I doubt this will break backups because it does not go between file systems.
A MUCH better way to do this would be to cache identical *blocks* of the file system. This is identical for identical files, and should compress better when files contain identical pieces. This has to be built into the file system, so really they have kludged together a poorer system that does not need to modify the disk layout. Also, this has been done for years and is not an "innovation".
Symbolic links are probably the most serious missing piece of functionality on NT. They prevent the migration of files to/from NT/Unix because of the need to add "drive letters" to the starts of paths. In the software I am working on, the NT version has great amounts of code that basically replaces "/foo/*" with "z:/foo/*" (with a lookup table of values of "foo" and "z") before EVERY SINGLE FILE OPEN! Needless to say this is an incredible pain, especially when dealing with scripting languages.
Symbolic links were purposely removed, too, possibly to discourage Unix/Nt interoperability. MicroSoft will deny it, but versions 4 and above of MSDOS had an "assign" command that was the same as a symbolic link to a disk. If this command still existed our interoperability problems would be solved (and, if MicroSoft is listening, we would be using NT a lot more! Idiots...)
"Shortcuts" are not symbolic links. They are small files containing the actual name of the file and other information such as the hotkey. In fact you can open them in the text editor.
they should do it in big-endian so that fun bugs show up causing them to need to properly ntohl() and htonl() all their data
Uh, no. If you bothered to type "man ntohl" you will see that these calls are no-ops on big-endian machines, and do something on little-endian machines. Developing on a big-endian machine would be even worse for finding these bugs. The only way to find them is to use *both* types of machines.
Also, little-endian makes perfect sense. A memory location can be accessed as an 8,16,32, etc bit quantity, and a significant subset (including the interesting area around zero) is reported as the same value. On a big-endian machine NO integers other than 0 and -1 are reported as the same value.
I for one am very glad that Wintel has switched the standard to little-endian. Human brains are programmed backwards. Nothing about a number can be determined until the entire thing is parsed when we read big-endian. In little-endian a great deal about a number, in particual what it's divisors are, can be determined without reading the whole thing. Admittedly useless for human use, but rather important for a computer.
PDP's stored 16-bit quantities low-byte first. They had no hardware concept of 32-bit quantities. When some joker added the 32-bit support they put the 16-bit pieces in big-endian order resulting in "fucked-endian".
I think this format was used for 32-bit floating point on a lot of machines, even if their 32-bit integers were consistent.
Overlays are extra bits that control the color and thus look like a drawing on a clear sheet laid over whatever was on the screen.
The simplest implementation is to add 1 extra bit to every pixel. If the bit is on, the pixel draws red (or whatever the overlay color is). If the bit is off, the normal color is drawn.
The advantage is that the normal color is not destroyed by turning on the bit, so the bit can be turned off to reveal the original image. If the original image is expensive to calculate the user interface is sped up a lot. This is similar to using XOR but looks much better.
Modern overlay hardware has 4 or 8 or even 24 bits so that many colors (2^n-1) can be drawn in the overlay.
However the advantages of overlays have become less and less over time, due to many reasons: Drawing is getting much faster so the delay of redrawing the background is ok. Double buffering can make the drawing not blink, which may make it less objectionable than the speed loss due to not using the overlay (double-buffered overlays are very rare). Overlapping windows means a program needs to be able to recreate the background image from scratch, eliminating one of the programming advantages of overlays on ancient systems. Modern users are less tolerant of the rubber-banding or outline GUI style that a limited-color overlay forces. And the limited colors usually means totally seperate drawing code must be used to preview in the overlay, resulting in more bugs and programming effort. And you usually have to make your program work anyway if no overlay hardware is available, for portability.
I have pretty much restricted use of the overlays to rubber-band boxes because of this.
Notification of current moderation status of a post should be given before moderation points are committed
Absolutely. It's a wonder this hasn't been implemented yet! Although you realize it's not a complete solution -- there will still be a window of time where people can submit duplicate moderations -- it'd just be a smaller one.
Much simpler: let the moderators pick a number (they can pick any number). When they submit the moderation, the value is moved by 1 toward the chosen number. If it is already equal to the chosen number it does not move at all, and the moderator is not charged for any points.
Also, make the "funny, insightful," etc seperate from the points. Let moderators pick one, and whatever one has been picked the most is displayed in the topic line.
It might also be nice if moderating an AC post from 0 to -1 used up zero points.
I've always wondered why 2 buttons on the mouse are "confusing" while 104 buttons on the keyboard is accepted without comment. Has anybody ever tried printing something on the mouse buttons???
If the right button said "MENU" it might have made popup menus user-friendly and we would not be wasting all our screen space today with menu bars an tool bars. Does anybody know if usability testing was ever done for this?
What you want would is already allowed in a normal negotiated and signed contract. This is what an ISV does when they do a $10,000 deal with a client. It is not what Joe Doe does when he/she goes to Circuit City and picks up a copy of Quicken.
Perhaps Virginia has some sort of ban. Fine, don't sell your software there, or take a risk and do sell it, or try to get that specific ban repealed. But this has nothing to do with shrinkwrapped licences. Your "thirds" software did not come in a shrink-wrapped box, did it?
This complaint is often given as why Unix-style cut/paste is bad, and it is legit and should be addressed. However Unix cut/paste is really a style of drag&drop and actually far more efficient and fast and we should support it.
I have tried a few solutions in the fltk toolkit. This is used on Win32 platforms and people who learn the cut/paste are very happy with there. I have figured out the following ideas to improve this gui that the toolkits may want to implement:
1. Always support the Ctrl+XCV standard as well as Unix cut+paste, and use the same clipboard for both. People who only know the Windoze style will be able to function fine with this, and they never notice that selecting text did Ctrl+C for them. Also, don't turn off the selection highlighting to show which widget owns the clipboard! People hate this.
2. Provide the "geek" solution: allow the user to drag-select with button 2 to indicate a region to replace when pasting. This is not user-friendly but at least it is no longer "impossible" to do this.
3. NYI:-) Do something so the user can select text with the left mouse button, and type Ctrl+V to replace it, and the previous selection goes in there and remains in the clipboard. I have tried to defer doing the automatic Ctrl+C until the mouse or focus leaves the widget or the user clicks in a different place in the widget, this sort of works but is messy. A real solution may require X protocol additions?
I do not want a common graphics API, at least not what you are talking about.
Face it, gui "toolkits" are right now at the development level of how computers talked to file systems in 1965. VMS (designed by the people bringing you NT) had literally thousands of calls to read/write different files types and storage devices. The largest program on VMS was the "copy" program, since it had to understand every one of these protocols. It took the brillance of K&R (and people working on Multics) to make the base set of calls of read/write/seek that we are all familiar with. With only a very light-weight wrapper (the FILE* buffering) this provides the API to files that we use today. Yes it seems obvious now, but this breakthrough evaded thousands of very smart programmers for decades.
I do not want to see and standard GUI API until this breakthrough happens (and I believe it will, although it will probably require very powerful graphics hardware). For now we should standardize at the level of X (although X is crap and should be replaced, but the API should be on the "draw a rectangle" level rather than the "draw a menu" level).
Your other comment about USB is quite correct. Hardware that only supports USB would be a good thing, at it appears to me that things are rather well documented, also I would think it is a lot easier to snoop on a USB line for reverse engineering than to do that to a bus card. Linux needs to dump Unix compatability and get user-friendly device support. In particular I want to see devfs working, and USB devices appearing/disappearing from/dev as they are unplugged. And we need to get rid of "mount", if a disk is/dev/s1d3a4b6 then the user should be able to look right there and see the files. The purpose of "mount" would be done by symbolically linking to where the users wants to see the files.
Slashdot Mirror
Hey, I wrote a program that did radiosity and drew the result on the screen, but I don't think anybody would claim that because of that Linux graphics now supports radiosity!
We need advanced graphics in the server. And we need to stop making excuses.
There is nothing wrong with buffered network protocols. In fact they use less context switches than api's. If this were not true, why do we have interfaces that write more than one character (or one bit) to a device? Isn't the overhead of copying those characters to a buffer from where they originally were inefficient? NO!
Another way to look at it: if Xlib puts 10,000 requests in a buffer and sends it, we get TWO context switches (one to the kernel, one to the server). Win32 gets 10,000 context switches (each one to the kernel for each call). And X, despite being 5000 times more efficient in context switches, does not have the risks of putting complex code in the kernel! (PS: yea I know Win32 ain't that bad, but their solution is exactly equivalent to buffering multiple requests!)
What does lose in network protocols is synchronous communication. When Xlib has to wait for an answer from the server, we get at least 4 context switches, plus the network overhead, and we lose. But we don't need so much synchronous communication!
The solution is to chuck out most of the Xlib design except for the fact that it is a network protocol. A program that displays a non-interactive display should be writable with a *single* "write" to the server (plus it may have to wait for redraw events and send that write again).
Get rid of colormaps! Trash the horrid font system and put in something so that if I ask for "Times" and 12 points, I get something (even if it is not Times at 12 points, if it has letters in it it would be an improvement over Xlib!). Either get rid of window managers, or make it sequential so I can create a window and send drawing to it in one block, without waiting for a stupid expose event to indicate syncrhonization with the window manager. Get rid of atoms, or make it so I can define thousands of atoms in a single round trip.
While we are at it, put some non-primitive graphics in. It is inexcusable that we don't have anti-aliased fonts, or anti-aliased polygons (even though Win32 does not have these), or a call that draws a color image without me having to figure out how to dither it to the hardware!
YES!
All the stuff going into XFree86 has killed development of fb or gdi or other simpler protocols. It does not matter how well they are designed, if you want your fancy card to run at full resolution, you have to use X, because all the hardware control is hidden in the X server.
One plausible solution: could new replacements interface with the binary plug-in interface that the new XFree86 4.0 has? Then they could get all the hardware. I'm sure the interface will be painful because it will make X assumptions, but not impossible to program for. Once an acceptable replacement for X has been made, a new low-level interface can be designed, and instructions on how to change the drivers.
To the average user, this is MILLIONS of times more persuasive than any argument about freedom or copyrights or the studio's money or Linux or anything. The masses will instantly be on our side, in forces you cannot comprehend!
Yes, it can't be said officially, but this has to become public, common, knowledge!. It closely resembles the freedom we desire, but in a form that directly affects joe user and a way they can understand trivially.
If necessary, figure out the worst things the DVD consortium can do (force you to watch a half hour? I dunno) and threaten the masses with it.
It should be perfectly ok to write an entire X server if that is the software writer thinks that is the best way. Layers of software can become slow and the interfaces between them can grow far more complex than the layers themselves. One huge advantage Linux has is that large modules can be replaced, and that modules can be merged, or split, and we should not disallow this.
Of course it would be nice if they released the specs, but it sounds like they cannot becuase of license agreements.
I also wondered if anybody open software authors write Windoze drivers for those Matrox cards based on their specs. One big selling point for these companies to release their specs would be if they, for free, got faster and better Windowz drivers than their competitors! Or is this impossible (it may require NDI info from MicroSoft to write the driver?).
Even if Mother Teresa's ghost sent out the messages, it would be spam. Your argument is totally flawed.
Right now the cheapest solution is large numbers of NT machines. Using Linux allows the same hardware to be used, but we get an extra 80-120 Megabytes per machine (approximate memory savings over NT2000 of Linux without X), which when multiplied by the hundred or more machines in the farm is a huge savings! The local disk space may be a savings as well, though the time when we don't have to dual-boot NT is still in the future, sigh...
Also, being able to rlogin to any farm machine and run tests is a huge win! And not having some monkey whose job is to switch the monitor between each machine and hit the "OK" button on the error messages would also help a good deal...
Believe me, we need Linux in the render farm much more than on the desktop.
Devfs can be used, and in fact i hope it would be used! The link points from /usr to the file in /dev. Get it?
Your examples:
mount -t nfs foo.umbc.edu:/usr/local /usr/local
We need a network-transparent file naming scheme. Then this is done by:
ln -s /net/foo.umbc.edu/usr/local /usr/local
smbmount //bar.umbc.edu/public /samba -o username autechre
The username could be done with ioctl calls to /samba (after the link is made) or with a naming scheme like this:
ln -s /net/bar.umbc.edu/public/username.autechre /samba
X should be replaced. But there is a tiny germ of an idea that needs to be kept. What I want is something that can tunnel over a network. This means bufferable commands. This can also greately improve performance on local machines by reducing the number of context switches. Microsoft says they need to put the graphics in the kernel because it halves the number of context switches. But a well-designed buffered command system (mostly without need for bi-directional communication that requires a sync) can reduce the number of context switches by 10,000 or more (and still leave the server in user space!).
GLX is a sample of how you can take a call-based system and lay it atop a buffered command system.
I would dearly love to see X replaced. I want antialiased and transparency everything, and it is inexcusable that I have to use a library to do even the simplest graphics!
Building a library on Linux is S L O W though, apparently because of the huge number of debugging symbols put in. That really ought to be fixed, it is apparently caused by the Dwarf file format.
What this means is that you can somehow specify an image, get it drawn, and some of the pixels contain a mixture of what the pixel contained before and the values from the image. Usually this is controlled by the "alpha" channel of the image.
This alpha from the image can (and usually is) thrown away. You can also do useful things by storing it, much like a Z buffer, but the only one I know is a hack so that anti-aliased polygons may be drawn and they cover the pixels 100% where they join.
"Overlay" hardware is, IMHO, not very useful on modern fast computer systems. Only limited graphics can be drawn in it (or if the graphics are unlimited, all that memory would be better used for Z or accumulation or alpha buffers!).
You cannot program a good OO api atop another OO api. You can program a good OO api atop a functional api, like the computer hardware, or a low-level abstraction like OpenGL. Just try it.
Trying to make the low-level portable interface "object oriented" is entirely against object orientation.
Okay, you can go back to playing with your HBRUSHES and HPENS now.
Now it would be nice if a GLX-like tunnel was defined so that the destination of the sound can be determined by the display you opened with X. In fact I can see it useful to have the sound linked with an X window, so that they can have individual volume controls or be muted when iconized, without program support...
What I want Linux to do is have /dev/sda be the damn drive like everybody expects! I should be able to "ls /dev/sda" and see what is on that drive, immediately, no matter what file system is in there, and give me an acceptable "no disk in drive" error if there is no disk, or "unreadable disk" if the file system is not recognized. Now I know internally that Linux will have to install the correct file system module, and run a test to find out which one, etc, but this can obvioiusly all be done automatically.
"But how do I make that disk be /usr?" I'm sure people are asking. Simple: "ln -s /dev/sda1 /usr" That isn't too hard!
Also if the hardware has a button that gets the disk out, the driver should sync the disk enough that it will be ejected with a good file system. If it is noticably hard to get the disk out, the driver can lock it in until the disk is synched. If it is impossible without turning off the computer the driver does not have to do anything.
This really ought to be done. There is no reason for the internal housekeeping of Linux to be visible outside the kernel.
The biggest annoyance is that people *expect* the VC++ "ide" files. In fltk's case these are approximately TEN times larger than all the Win32-specific code (and this is an entire GUI library)!!! This is absolutely insane but that's the way it is. Borland and cygwin are supported with normal makefiles (though autoconf does not work).
I would also expect you to see a Linux port as one of the first contributions you get from the OSS community. This should be considered a free gift, there is no need to even test it if your boss refuses to pay for a Linux machine, but put the porting into the official code set and then you will start to see the real bug fixes and improvements roll in.
Like many others here, I agree that you should NOT "force" people to send you their fixes. This will not change the actions of anybody, and just antagonizes the people who would send you fixes (the vast majority). Most software engineers writing for free want to see their stuff publicized, and the way to do that is to put their stuff back into the official version.
I doubt this will break backups because it does not go between file systems.
A MUCH better way to do this would be to cache identical *blocks* of the file system. This is identical for identical files, and should compress better when files contain identical pieces. This has to be built into the file system, so really they have kludged together a poorer system that does not need to modify the disk layout. Also, this has been done for years and is not an "innovation".
Symbolic links are probably the most serious missing piece of functionality on NT. They prevent the migration of files to/from NT/Unix because of the need to add "drive letters" to the starts of paths. In the software I am working on, the NT version has great amounts of code that basically replaces "/foo/*" with "z:/foo/*" (with a lookup table of values of "foo" and "z") before EVERY SINGLE FILE OPEN! Needless to say this is an incredible pain, especially when dealing with scripting languages.
Symbolic links were purposely removed, too, possibly to discourage Unix/Nt interoperability. MicroSoft will deny it, but versions 4 and above of MSDOS had an "assign" command that was the same as a symbolic link to a disk. If this command still existed our interoperability problems would be solved (and, if MicroSoft is listening, we would be using NT a lot more! Idiots...)
"Shortcuts" are not symbolic links. They are small files containing the actual name of the file and other information such as the hotkey. In fact you can open them in the text editor.
Uh, no. If you bothered to type "man ntohl" you will see that these calls are no-ops on big-endian machines, and do something on little-endian machines. Developing on a big-endian machine would be even worse for finding these bugs. The only way to find them is to use *both* types of machines.
Also, little-endian makes perfect sense. A memory location can be accessed as an 8,16,32, etc bit quantity, and a significant subset (including the interesting area around zero) is reported as the same value. On a big-endian machine NO integers other than 0 and -1 are reported as the same value.
I for one am very glad that Wintel has switched the standard to little-endian. Human brains are programmed backwards. Nothing about a number can be determined until the entire thing is parsed when we read big-endian. In little-endian a great deal about a number, in particual what it's divisors are, can be determined without reading the whole thing. Admittedly useless for human use, but rather important for a computer.
PDP's stored 16-bit quantities low-byte first. They had no hardware concept of 32-bit quantities. When some joker added the 32-bit support they put the 16-bit pieces in big-endian order resulting in "fucked-endian".
I think this format was used for 32-bit floating point on a lot of machines, even if their 32-bit integers were consistent.
The simplest implementation is to add 1 extra bit to every pixel. If the bit is on, the pixel draws red (or whatever the overlay color is). If the bit is off, the normal color is drawn.
The advantage is that the normal color is not destroyed by turning on the bit, so the bit can be turned off to reveal the original image. If the original image is expensive to calculate the user interface is sped up a lot. This is similar to using XOR but looks much better.
Modern overlay hardware has 4 or 8 or even 24 bits so that many colors (2^n-1) can be drawn in the overlay.
However the advantages of overlays have become less and less over time, due to many reasons: Drawing is getting much faster so the delay of redrawing the background is ok. Double buffering can make the drawing not blink, which may make it less objectionable than the speed loss due to not using the overlay (double-buffered overlays are very rare). Overlapping windows means a program needs to be able to recreate the background image from scratch, eliminating one of the programming advantages of overlays on ancient systems. Modern users are less tolerant of the rubber-banding or outline GUI style that a limited-color overlay forces. And the limited colors usually means totally seperate drawing code must be used to preview in the overlay, resulting in more bugs and programming effort. And you usually have to make your program work anyway if no overlay hardware is available, for portability.
I have pretty much restricted use of the overlays to rubber-band boxes because of this.
Absolutely. It's a wonder this hasn't been implemented yet! Although you realize it's not a complete solution -- there will still be a window of time where people can submit duplicate moderations -- it'd just be a smaller one.
Much simpler: let the moderators pick a number (they can pick any number). When they submit the moderation, the value is moved by 1 toward the chosen number. If it is already equal to the chosen number it does not move at all, and the moderator is not charged for any points.
Also, make the "funny, insightful," etc seperate from the points. Let moderators pick one, and whatever one has been picked the most is displayed in the topic line.
It might also be nice if moderating an AC post from 0 to -1 used up zero points.
I've always wondered why 2 buttons on the mouse are "confusing" while 104 buttons on the keyboard is accepted without comment. Has anybody ever tried printing something on the mouse buttons???
If the right button said "MENU" it might have made popup menus user-friendly and we would not be wasting all our screen space today with menu bars an tool bars. Does anybody know if usability testing was ever done for this?
Perhaps Virginia has some sort of ban. Fine, don't sell your software there, or take a risk and do sell it, or try to get that specific ban repealed. But this has nothing to do with shrinkwrapped licences. Your "thirds" software did not come in a shrink-wrapped box, did it?
I have tried a few solutions in the fltk toolkit. This is used on Win32 platforms and people who learn the cut/paste are very happy with there. I have figured out the following ideas to improve this gui that the toolkits may want to implement:
1. Always support the Ctrl+XCV standard as well as Unix cut+paste, and use the same clipboard for both. People who only know the Windoze style will be able to function fine with this, and they never notice that selecting text did Ctrl+C for them. Also, don't turn off the selection highlighting to show which widget owns the clipboard! People hate this.
2. Provide the "geek" solution: allow the user to drag-select with button 2 to indicate a region to replace when pasting. This is not user-friendly but at least it is no longer "impossible" to do this.
3. NYI :-) Do something so the user can select text with the left mouse button, and type Ctrl+V to replace it, and the previous selection goes in there and remains in the clipboard. I have tried to defer doing the automatic Ctrl+C until the mouse or focus leaves the widget or the user clicks in a different place in the widget, this sort of works but is messy. A real solution may require X protocol additions?
Face it, gui "toolkits" are right now at the development level of how computers talked to file systems in 1965. VMS (designed by the people bringing you NT) had literally thousands of calls to read/write different files types and storage devices. The largest program on VMS was the "copy" program, since it had to understand every one of these protocols. It took the brillance of K&R (and people working on Multics) to make the base set of calls of read/write/seek that we are all familiar with. With only a very light-weight wrapper (the FILE* buffering) this provides the API to files that we use today. Yes it seems obvious now, but this breakthrough evaded thousands of very smart programmers for decades.
I do not want to see and standard GUI API until this breakthrough happens (and I believe it will, although it will probably require very powerful graphics hardware). For now we should standardize at the level of X (although X is crap and should be replaced, but the API should be on the "draw a rectangle" level rather than the "draw a menu" level).
Your other comment about USB is quite correct. Hardware that only supports USB would be a good thing, at it appears to me that things are rather well documented, also I would think it is a lot easier to snoop on a USB line for reverse engineering than to do that to a bus card. Linux needs to dump Unix compatability and get user-friendly device support. In particular I want to see devfs working, and USB devices appearing/disappearing from /dev as they are unplugged. And we need to get rid of "mount", if a disk is /dev/s1d3a4b6 then the user should be able to look right there and see the files. The purpose of "mount" would be done by symbolically linking to where the users wants to see the files.
At Digital Domain we use Qt and Fltk. We did use Motif some, but it was incredibly slow. Usually a rewrite into Tk (interpreted!) was faster.
Even before these new toolkits, it appears that most commercial software for the SGI used proprietery toolkits or Forms.