Getting an "improved" version of your music back does sound kind of silly.
But a lot of GPL software is released because the writer wants their software to be used and appreciated, to make themselves known, or perhaps even to get a job by proving their programming abilities. These motives seem to match why a musician would release their music.
Yes, reference and pointer are very much alike. That is why I want '->' and '.' to be the same, since having to change these back and forth is the only difference in most cases.
I think the point is that the tables of jumps do not change, and thus the icache is not invalidated. The table being talked about is the vtab for a given class and it is a constant.
It looks like the problem is that the CPU designers figured the reason that somebody would jump to *(ptr+offset) is because the entry at *(ptr+offset) changes. But C++ (and all other OO languages, I would think) that entry is a constant, and instead it is the ptr that changes to point at different (but still constant) tables.
This jmp-to-jmp stuff is a way to fool the CPU cache and predictor circuitry into assumming the location is constant, because it figures that jmp instructions are constant. It does seem kind of annoying that it is worth doubling the table size (and thus halving how much fits in the cache) in order to get around a mistaken programming assumpition by the CPU designers.
I think it would be better for a CPU jump predictor to assumme *everything*, whether in instruction, read only, or read/write data, is constant. Modern C++ code typically accesses a given location many orders of magnitude more times than it modifies it!
Besides the fact that you returned a reference to a temporary, a quick comparison of the size and readability of his example and your "solution" should make it pretty obvious why!
Shared libraries for functions like this are NOT efficient, despite all the hopes and dreams of morons. How big is the identifier that matches up the program with the shared library? I would not be suprised if it is 2 or 3 dozen times larger than the code (take a look at some mangled template names if you don't believe me).
And you have just made this poor sap's program into another entry in DLL (or.so) hell. Now they have to "install" it in order for it to work. Wow, what great advanced in Comp Sci. Someday it will be totally impossible to run anything!
The fact that I can't take some code and change a pointer to a reference (or back) without a huge amount of search & replace of . and -> is very annoying and often I end up leaving inefficient code as it was because of this.
There is no reason for this distinction. There isn't even a reason in C ever since the very first version that remembered the type of variables.
Probably more drastic, but I would like to see '.' usable everywhere '::' is. This means class and variables are in the same namespace, which is incomptable, but it would make the code much nicer to read.
I don't understand this. Is this because the processor assummes that any location you jump to is involitile? It seems that an indirect jump could be "predicted" just as well by assumming the contents of the pointed-to memory location is the same as last time and this would require no more circuitry than the jump-to-jump predictor.
Transparency is only supported for rendering into existing windows, as far as I know. The windows themselves do not have transparency.
Supporting this nicely requires a good deal of changes to the X interface. I believe it will require all windows to be stored with off-screen backing stores. This requires changes to Xlib because there is no "update the screen" command in the current X protocol, Xlib would have to send this when the appliation waits for events (plus there should be interface to turn off the automatic update and let the program control it).
Double buffering would vastly change the internals of the X server. It would also defeat the hardware acceleration on most systems.
Any alternative to double buffering would require transparency to be seperate from the drawing and very difficult to alter. This is not nice because you cannot animate the transparent edge, or it will not animate cleanly with respect to the interior. For this reason I would rather have a complete solution or none at all, not some half-way and hard to program arrangement.
However making half-way and hard-to-program interfaces seems to match the current X design!
I find it hard to believe that the pain of saving in that editor, telling Emacs to run (or reload) the file, running whatever fancy Emacs thing you want, saving it again, and telling your editor to reload, is less than the pain of learning the Emacs key bindings.
There are certainly people that never use Emacs, but I've never heard of any editor so superior that it is worth it to do this when you still want some Emacs functionality.
PS: I use Emacs and I think it is a bloated mess. And I never use those fancy lisp programs. But I can't give it up because all the other editors seem intent on copying MicroSoft's stupid control key bindings (ie ^P prints: I believe most people move up one line much more often than they print!). I have deleted way to much stuff because ^A selects all the text rather than move to the start of line.
Comon, designers, it is not hard to make intelligent key bindings, the only important MicroSoft/Mac bindings are the ZXCV keys, which fortunately don't intersect anything of value in Emacs, so keep those and make all the rest be Emacs. (I'm sure somebody will point out that ^X is important in Emacs, but that is also the obvious user-unfriendly key and thus it should be replaced).
I think the question was not why *you* keep the code secret, but why the ASIC supplier has a NDA.
The idea is that they would sell more hardware if anybody in the world could write a driver. And people would still pay money for your closed-source driver if it provides added functionality that they cannot figure out for themselves.
A distribution is not allowed to change/opt, right?
Also there seems to be very strong feelings amoung Linux developers that/opt is a mistake and/usr/local should be used instead. They serve the same purpose and there is no reason for two locations, and/usr/local seems to be winning.
Of course the distribution can't write over/usr/local either.
What is wrong with requiring a compiler in the OS?
Imagine user-friendly applications that can rely on the existence of a compiler to produce their own plugins or compile user instructions into very fast machine code.
And even dumb users may appreciate the ability to get an application in a small package that they know will work on their system.
It is true that the compilation should be hidden from the user. The download should be a single file that you double-click, it then compiles with a nice "N% done" meter, it then pops up a window with two buttons, one says "try the program" (which runs it, and it can be pushed repeatedly). The other says "install the program", this then asks for the root password and does the installation.
The real win would be a standard and documented file format. Then people could run *any* program on Linux to edit their file. Obviously some will work better than others and there would be preferences. It would also help if the programs would preserve sections of the file that they don't understand and write them unchanged to the output.
The only way I see a standard file format coming out is if a free program is included with distributions that reads and writes it. A free Windows program that does the same will probably be necessary as well.
I think what he is getting at, which I agree with mostly, is we want an X that is nicely designed. This cannot be done without replacing the client-server communication model.
In my opinion the client-server model is much easier to program and debug and can be FASTER than direct calls due to the reduction in context switches (since many graphics calls are easily batched together). The fact that it makes it trivial to get network transparency is just gravy and not the main reason for X's design.
X's insane flaws are the extremely bad graphics interface that ruins the client-server model by requiring synchronous communication, and a mess they created by making the window manager be a process.
Graphics should be powerful (not necessarily high-level) and should work without the program having to "inquire" anything about the device. For instance you should pick a color by specifying a r,g,b triple and the server decides what actual color it can display and does it.
The window manager should be scrapped and all programs control exactly all the pixels drawn on the screen. "consistency" (a very highly overrated thing, in my opinion) can be done by toolkit libraries, the same way they make buttons and menus consistent.
Both of these things require such significant changes that the result will not be X.
No, that is not a valid complaint. The few X primitives that exist are about the right size for hardware acceleration. The XRender extension actually *reduces* the X interface for drawing arbitrary shapes: Xlib allows an arbitrary path to be filled, while XRender only allows you to specify trapazoids (horizontal top & bottom edges). This was done purposely to reduce it to the level that hardware acceleration handles.
X's problem is a *lack* of primitives, not that they are too low level. This results in people who want to do something being forced to draw the entire thing in a local image buffer and thus losing all hardware acceleration.
Although there have not been much lately, I seem to recall the whole publicity about "Viruses" started with Macintosh ones.
In the original Mac system, due to the very structured executable file format (ie the resource fork) it was trivial to write a virus that infected *any* executable, and perhaps many documents, since you just had to add something to the resources. At the same time DOS (and I think the Unix a.out format) made it a lot more difficult because you had to modify the file so that the code at least jumped to the virus.
This was also combined with the Mac's encouragement for people to mail floppys with stored files and programs around (these virii were transmitted by mail, mostly!)
I'm not sure if the Macintosh system has been fixed, or it is just that it is even easier to write Word virii, but there have been far fewer of these lately. But they were the first well-known ones.
I suspect distributing the binaries is allowed, but that sounds like an interesting variation for a license: If you are not copetent enough to recompile the program, then you cannot give it away (or sell it). Or even stricter: require that you have to make some "useful" modification to the program in order to distribute your new binaries and source.
Has anybody tried a license like this?
I suspect it is not GPL compatable and so you cannot use it for code that is already GPL, but it could be used for new software.
I am not being contradictary. What I am saying is that the file system should have NO "case insensitive rules". This is extremely simple to describe and thus unless the programmer is a total idiot the program will agree with the file system as to what filenames are unique.
Once this horrid problem is solved, the program is free to make up any rules it wants to map stuff typed by the user to file names. My best example is that they can now do spelling correction reliably, something that nobody in their right mind would put into a file system, but something I consider equivalent to case matching.
In general the problem is that programs may scan the directory in order to determine if they are going to write over a file and fail to detect if they are. This is a serious problem even if the program is aware that the file system is case insensitive, because the program's idea of what letters match may be different than the file systems (especially true for Unicode filenames!)
For this reason I have said many many times here that file systems should be case sensitive, in fact the file system should just treat filenames as strings of bytes and only an identical stream of bytes will identify the same file (thus if UTF-8 is used, only a single encoding of a name works even though the UTFUnicode mapping is not really 1:1). Only by using such a scheme can the file systems be fast and free of security holes.
The problem is, many people seem to think that if the file system is case sensitive, that the user has to type filenames with the correct case. This is false, there is no reason that user-level programs cannot do their own case-insensitive search for a matching file (they could also do more complex things like spelling correction).
I'm not sure why so many otherwise bright people are under this delusion, but it is causing a great deal of trouble.
It is good to see that Apple is supporting a case-dependent file system. It would be interesting to see their user-level solutions to making this user friendly, perhaps when (if?) they do it it will wake up all the idiot FS designers and NT defenders out there.
Steve Jobs has something against multi-button mice, I think he had a bad experience in his childhood where he pressed the wrong button. It appears he has been fighting his engineers on this ever since.
This is most evident in the NeXT, which had a 2-button mouse. There was a control-panel "preference" that said "make the buttons act alike". This made the right-mouse button act like the left one so it was a single button. The machine shipped with this mode set by default.
The really odd thing about it was the implementation: turning on this mode actually changed the "server" (similar to an X server) so that clicking the right mouse button returned an event indistinguisable from a left button. It was not done inside the NeXTStep code which ran in user space, which would seem to be the obvious implementation. Unlike everything else on the server (like keyboard mapping!), you could not change it with PostScript code, and only a program with suid privleges could change the setting (and even then it was undocumented). As far as I can tell, every other preference on the control panel was done simply in user space by NeXTStep.
He really really wanted to make sure it was impossible to write a program that used the right button, and was willing to make bad software design just to enforce it!
Some of his stuff is a bit skewed, in that he purposely made the alternative he did not like harder. For command keys the placement of the necessary shift key was awkward and often he used the top-row function keys, both of which are the slowest to type. I also complain a lot about his dismissal of contextual pop-up menus and insistance that top-of-screen pull down menus are faster, because he refused to test pop-up menus where they pop up with the mouse already pointing at the last item that was chosen (which imho makes it many many times faster than any pull-down menu system).
However he has many good points as well. Just ranting that not everything he says should be taken as gospel...
People keep saying "but in some cases those services are needed". I say, so what. It is a lot easier to turn them on than to turn them off. This is because it is obvious when you need to turn them on (something you want to do does not work), and it is obvious when you succeed in doing it (that thing you want starts working).
Slashdot Mirror
And Direct-X!
But a lot of GPL software is released because the writer wants their software to be used and appreciated, to make themselves known, or perhaps even to get a job by proving their programming abilities. These motives seem to match why a musician would release their music.
Yes, reference and pointer are very much alike. That is why I want '->' and '.' to be the same, since having to change these back and forth is the only difference in most cases.
It looks like the problem is that the CPU designers figured the reason that somebody would jump to *(ptr+offset) is because the entry at *(ptr+offset) changes. But C++ (and all other OO languages, I would think) that entry is a constant, and instead it is the ptr that changes to point at different (but still constant) tables.
This jmp-to-jmp stuff is a way to fool the CPU cache and predictor circuitry into assumming the location is constant, because it figures that jmp instructions are constant. It does seem kind of annoying that it is worth doubling the table size (and thus halving how much fits in the cache) in order to get around a mistaken programming assumpition by the CPU designers.
I think it would be better for a CPU jump predictor to assumme *everything*, whether in instruction, read only, or read/write data, is constant. Modern C++ code typically accesses a given location many orders of magnitude more times than it modifies it!
Besides the fact that you returned a reference to a temporary, a quick comparison of the size and readability of his example and your "solution" should make it pretty obvious why!
Shared libraries for functions like this are NOT efficient, despite all the hopes and dreams of morons. How big is the identifier that matches up the program with the shared library? I would not be suprised if it is 2 or 3 dozen times larger than the code (take a look at some mangled template names if you don't believe me).
And you have just made this poor sap's program into another entry in DLL (or .so) hell. Now they have to "install" it in order for it to work. Wow, what great advanced in Comp Sci. Someday it will be totally impossible to run anything!
The fact that I can't take some code and change a pointer to a reference (or back) without a huge amount of search & replace of . and -> is very annoying and often I end up leaving inefficient code as it was because of this.
There is no reason for this distinction. There isn't even a reason in C ever since the very first version that remembered the type of variables.
Probably more drastic, but I would like to see '.' usable everywhere '::' is. This means class and variables are in the same namespace, which is incomptable, but it would make the code much nicer to read.
I don't understand this. Is this because the processor assummes that any location you jump to is involitile? It seems that an indirect jump could be "predicted" just as well by assumming the contents of the pointed-to memory location is the same as last time and this would require no more circuitry than the jump-to-jump predictor.
Supporting this nicely requires a good deal of changes to the X interface. I believe it will require all windows to be stored with off-screen backing stores. This requires changes to Xlib because there is no "update the screen" command in the current X protocol, Xlib would have to send this when the appliation waits for events (plus there should be interface to turn off the automatic update and let the program control it).
Double buffering would vastly change the internals of the X server. It would also defeat the hardware acceleration on most systems.
Any alternative to double buffering would require transparency to be seperate from the drawing and very difficult to alter. This is not nice because you cannot animate the transparent edge, or it will not animate cleanly with respect to the interior. For this reason I would rather have a complete solution or none at all, not some half-way and hard to program arrangement.
However making half-way and hard-to-program interfaces seems to match the current X design!
I find it hard to believe that the pain of saving in that editor, telling Emacs to run (or reload) the file, running whatever fancy Emacs thing you want, saving it again, and telling your editor to reload, is less than the pain of learning the Emacs key bindings.
There are certainly people that never use Emacs, but I've never heard of any editor so superior that it is worth it to do this when you still want some Emacs functionality.
PS: I use Emacs and I think it is a bloated mess. And I never use those fancy lisp programs. But I can't give it up because all the other editors seem intent on copying MicroSoft's stupid control key bindings (ie ^P prints: I believe most people move up one line much more often than they print!). I have deleted way to much stuff because ^A selects all the text rather than move to the start of line.
Comon, designers, it is not hard to make intelligent key bindings, the only important MicroSoft/Mac bindings are the ZXCV keys, which fortunately don't intersect anything of value in Emacs, so keep those and make all the rest be Emacs. (I'm sure somebody will point out that ^X is important in Emacs, but that is also the obvious user-unfriendly key and thus it should be replaced).
The idea is that they would sell more hardware if anybody in the world could write a driver. And people would still pay money for your closed-source driver if it provides added functionality that they cannot figure out for themselves.
Also there seems to be very strong feelings amoung Linux developers that /opt is a mistake and /usr/local should be used instead. They serve the same purpose and there is no reason for two locations, and /usr/local seems to be winning.
Of course the distribution can't write over /usr/local either.
Imagine user-friendly applications that can rely on the existence of a compiler to produce their own plugins or compile user instructions into very fast machine code.
And even dumb users may appreciate the ability to get an application in a small package that they know will work on their system.
It is true that the compilation should be hidden from the user. The download should be a single file that you double-click, it then compiles with a nice "N% done" meter, it then pops up a window with two buttons, one says "try the program" (which runs it, and it can be pushed repeatedly). The other says "install the program", this then asks for the root password and does the installation.
We still need some documentation that says what \lt;SHRB, size="40 gleems"> does, though.
Somebody suggested that the voter be allowed to print a fake receipt that says anything you want.
The real win would be a standard and documented file format. Then people could run *any* program on Linux to edit their file. Obviously some will work better than others and there would be preferences. It would also help if the programs would preserve sections of the file that they don't understand and write them unchanged to the output.
The only way I see a standard file format coming out is if a free program is included with distributions that reads and writes it. A free Windows program that does the same will probably be necessary as well.
In my opinion the client-server model is much easier to program and debug and can be FASTER than direct calls due to the reduction in context switches (since many graphics calls are easily batched together). The fact that it makes it trivial to get network transparency is just gravy and not the main reason for X's design.
X's insane flaws are the extremely bad graphics interface that ruins the client-server model by requiring synchronous communication, and a mess they created by making the window manager be a process.
Graphics should be powerful (not necessarily high-level) and should work without the program having to "inquire" anything about the device. For instance you should pick a color by specifying a r,g,b triple and the server decides what actual color it can display and does it.
The window manager should be scrapped and all programs control exactly all the pixels drawn on the screen. "consistency" (a very highly overrated thing, in my opinion) can be done by toolkit libraries, the same way they make buttons and menus consistent.
Both of these things require such significant changes that the result will not be X.
X's problem is a *lack* of primitives, not that they are too low level. This results in people who want to do something being forced to draw the entire thing in a local image buffer and thus losing all hardware acceleration.
In the original Mac system, due to the very structured executable file format (ie the resource fork) it was trivial to write a virus that infected *any* executable, and perhaps many documents, since you just had to add something to the resources. At the same time DOS (and I think the Unix a.out format) made it a lot more difficult because you had to modify the file so that the code at least jumped to the virus.
This was also combined with the Mac's encouragement for people to mail floppys with stored files and programs around (these virii were transmitted by mail, mostly!)
I'm not sure if the Macintosh system has been fixed, or it is just that it is even easier to write Word virii, but there have been far fewer of these lately. But they were the first well-known ones.
Has anybody tried a license like this?
I suspect it is not GPL compatable and so you cannot use it for code that is already GPL, but it could be used for new software.
Once this horrid problem is solved, the program is free to make up any rules it wants to map stuff typed by the user to file names. My best example is that they can now do spelling correction reliably, something that nobody in their right mind would put into a file system, but something I consider equivalent to case matching.
For this reason I have said many many times here that file systems should be case sensitive, in fact the file system should just treat filenames as strings of bytes and only an identical stream of bytes will identify the same file (thus if UTF-8 is used, only a single encoding of a name works even though the UTFUnicode mapping is not really 1:1). Only by using such a scheme can the file systems be fast and free of security holes.
The problem is, many people seem to think that if the file system is case sensitive, that the user has to type filenames with the correct case. This is false, there is no reason that user-level programs cannot do their own case-insensitive search for a matching file (they could also do more complex things like spelling correction).
I'm not sure why so many otherwise bright people are under this delusion, but it is causing a great deal of trouble.
It is good to see that Apple is supporting a case-dependent file system. It would be interesting to see their user-level solutions to making this user friendly, perhaps when (if?) they do it it will wake up all the idiot FS designers and NT defenders out there.
This is most evident in the NeXT, which had a 2-button mouse. There was a control-panel "preference" that said "make the buttons act alike". This made the right-mouse button act like the left one so it was a single button. The machine shipped with this mode set by default.
The really odd thing about it was the implementation: turning on this mode actually changed the "server" (similar to an X server) so that clicking the right mouse button returned an event indistinguisable from a left button. It was not done inside the NeXTStep code which ran in user space, which would seem to be the obvious implementation. Unlike everything else on the server (like keyboard mapping!), you could not change it with PostScript code, and only a program with suid privleges could change the setting (and even then it was undocumented). As far as I can tell, every other preference on the control panel was done simply in user space by NeXTStep.
He really really wanted to make sure it was impossible to write a program that used the right button, and was willing to make bad software design just to enforce it!
However he has many good points as well. Just ranting that not everything he says should be taken as gospel...
People keep saying "but in some cases those services are needed". I say, so what. It is a lot easier to turn them on than to turn them off. This is because it is obvious when you need to turn them on (something you want to do does not work), and it is obvious when you succeed in doing it (that thing you want starts working).
They should ship with everything off.