It is possible that developing BeOS may be the most efficient use of resources for getting a user-friendly desktop onto Linux. If you strip out X and the BeOS GUI, I believe what is left is pretty much identical, and lots of people think the solution for fixing Linux on the desktop is to get rid of X.
Actually I think RMS is ok with dual licenses. What he does not like is modifying the GPL by adding restrictions so the other license is more valuable.
Actually I think either Steve Jobs or Scott McNealy (from Sun) would be far worse than Gates in that position. What about the guy who ran Lotus? Or Phillipe Kahn of Borland?
It would seem likely that anybody able to get to CEO of a rapidly growing company would not be the nicest person in the world and would have a strong desire for controlling everything.
That's a rather ludricous suggestion. In what world do non-profits have the ability to grant tax exemptions, if that was legal I have a great idea for a "non profit...." Also it seems pretty stupid to try to put expense or work on non-profits rather than try to get money somehow from for-profit companies.
You can do what dozens of people have done: dual license.
If you write something, put it out GPL, so everybody can see how it works. Any companies that want to use your code in a closed-source product has to purchase a seperate license that costs more.
In reality this is impractical for the individual developer, but it makes a lot of sense for large companies which have the ability to make such a sale and control of a large enough project to make purchase worthwhile.
You can also make your own more restrictive license in attempts to make the purchased license more valuable. Typical restrictions are to limit any commercial use, or limit use to non-profit organizations, or disallow modification. For some reason RMS does not like these ideas, but it seems to me they serve the main purpose of letting people see the code.
You were infected with 2 viruses? That's not something to brag about.
If you mean you just saw two viruses, then that means you are not receiving any. I would be much more impressed if you said you received thousands of viruses, but that you have proof that Outlook de-fanged or filtered them.
Are you on crack? In 1992 I personally had a NeXT cube and it was considered obsolete, it ran BSD Unix with the Mach kernel. I had a 14.4 modem. Email was in extremely common use, and AOL was used by tens of millions and the average idiot on the street knew pretty well what email was.
Bill Gates was a f**king lucky individual and if there was a slight change in history around about 1980 he would be here on SlashDot complaining bitterly about whoever did become the meglamanical monopolist. He did absolutly nothing that tens of thousands of other people could see as obvious ways to progress, and in fact made serious errors in judgement such as dismissing the internet and thinking information delivered on CD's such as encylopaedias was the future.
Because the commands are abbreviated by removing the vowles, they fail to type easily on Dvorak, which is designed for the fact that normal text alternates consonants and vowles.
Except for the hjkl in vi (which I don't use) it seems that most shortcuts are mnemonic on Unix, like all the Emacs commands, like ^N and ^P.
I'm suprised nobody mentions Apple's extremely positional assignment of zxcv for undo, cut, copy, paste. This must be a real pain on Dvorak, though you could revert when the ctrl or alt key is held down, but that would be a pain for mnemonic commands.
There is no correspondance between "easy to learn" and "easy to use". These are two subsets of all interfaces, and these sets intersect.
Unfortunately there is a huge number of people who think "easy to use" implies "easy to learn", or worse they think "learn" is all the work they will ever have to do with an interface (which is stupid if you plan to use a program more than once).
There are also lots of examples where interfaces are *both* hard to use and hard to learn. Perhaps this is the majority of interfaces. But this in no way implies that the sets "easy to learn" and "easy to use" are identical, all it implies is that they are small compared to the set of all interfaces. Their intersection may still be quite small compared to their non-intersecting parts (this is what I suspect).
Actually the selection buffer and the clipboard I am talking about are the same thing. There can be an infinite number of selection buffers with different names, but the only ones in any common use are "SELECTION", "CLIPBOARD", and "SECONDARY_SELECTION". "SELECTION" was supposed to be the highlighted text and "CLIPBOARD" was intended to be used for cut/copy/paste commands. "SECONDARY" was for some weird and obsolete idea involving the ability to swap two pieces of data with the mouse and nobody supports it.
Perhaps unfortunately the middle-mouse paste of SELECTION turned out to be so incredibly convienent that everybody forgot about the CLIPBOARD, and most people implementing copy/paste commands put it into the SELECTION because a vast number of X programs could only paste with that middle mouse.
Only with the need to make Windows users happy has the original design of the CLIPBOARD reappeared.
The selection buffers have "type" information so it is in theory possible to cut any kind of data, just like Windows. What X lacks is any standard for much other than text, or a library that can draw the object on the screen or store it in a file without much thought from the programmer. This is the primary reason that anything other than text does not cut/paste. This is also true on Windows as soon as you get to more complex programs that want to analyze the pasted data and not just draw it on the screen, suddenly a lot of things don't paste (go ahead and try to paste that image into your IDE...)
That's right, there was new standards added so a program that wants to draw a background can communicate with the program that is drawing other things like icons on the window.
Older solutions required X to keep seperate the background area and the icons, which had to be done by making each icon a seperate shaped X window. This was tremendously slow and required the program drawing the icons to send a lot of information to the X server. And there was no antialiasing of the edges and serious limitations on what you could draw.
A program that just thinks it has a big window and can draw anything into it is *much* faster, and will always be faster no matter how many new features are added to X. So instead these programs can now read a desktop image stored on the server and merge their own display with it to make the window.
Older desktop image programs that do not know how to communicate this information to these new desktop programs will not work.
I would like to see some of these idiot GUI experts figure out that "menubar" and "toolbar" are the same thing (especially now that the toolbar buttons often bring up a menu) and get them on the SAME LINE!!! That would make me think that these designers (both at MicroSoft and at all other companies and in open source) are not just a bunch of sheep who refuse to make the slightest tiny changes because of a morbid fear that some poor stupid user will be "confused" by it.
Although there are problems with X, you can easily put the URL into Netscape from the terminal. Select it in the terminal, go to Netscape, and click the middle mouse button on the text field.
The seperate clipboards are necessary to get the behavior that Windows users expect. And it has one minor technical advantage: you can select the text to replace after you have selected the replacement.
The seperate clipboards are used by GTK and Motif, it was older Qt that did not do this (also true of a lot of other programs and toolkits, including fltk which I fixed a few months ago to match GTK). Newer Qt has been changed to match GTK.
I think the bug you are talking about exists on the most modern machines. The problem is that.1 cannot be accurately represented in binary floating point. Adding it 10 times produces a number that is less that 1.0, though the output functions will usually round it so it prints 1.0.
On a i686 running Linux and using gcc this program:
void main() {
double i;
for (i = 0; i < 1.0; i +=.1) printf("%g ", i);
}
Produces this output:
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Notice that it printed "1" even though it looks like it shouldn't.
Of course the kernel should not do that, but it would help a LOT if there was a standard program (probably called "start" or "open") that did the same thing that double-clicking an icon did. Obviously not kernel stuff, but right now all these solutions are tied to GUI and should not be there as well.
Exactly *how* start works can be left up to different implementations but what is needed is the ability to be able to assumme the program is there and can be called and will do reasonably well so programmers are not tempted to write their own implementations.
Old shells would require the user to type "start " but I would expect newer shells to just take " " directly.
I think this is a vital addition to Linux and should be done.
Maximize has been added to the Extended Window Manager Hints publicized by the X Desktop Group, and apparently used by the newer Gnome and KDE window managers.
However they should write the program to detect if this is supported, and if not they can set the window size to the screen dimensions, which will work on older window managers.
It sounds to me like you are proposing an operating system that *only* runs programs written for the VM. This is a totally viable idea and I would agree it would produce the fastest VM possible.
Probably the main thing that makes people not consider this idea is that it would be a new OS that does not run any existing programs. Although there are plenty of alternative OS's out there, most people see VM as a way to get their new interface onto an existing system so they never consider this way of writing it.
If the GC is considered part of the VM then it can be implemented in low-level code and be fast. If it is not part of the VM then most likely programs will have to implement GC (or at least C malloc/free) in the VM language, which would never be as fast and would be just a bug-prone as doing it now, and would also probably make assumptions about whatever memory allocation is provided by the VM that would prevent it from taking advantage of new system designs. It also allows services provided by the VM to create objects that can be manipulated like any other objects.
Even the earliest VMs did garbage collection (take a look at Lisp which for some reason nobody has mentioned here yet).
However it is true that this argument could be made for any feature added to the VM, but it does seem that using the VM design to get away from numerically-addressed memory is a natural division that most designers go for.
This question was asked several times here, and from the responses, nothing stops a person from doing this.
However they will not be able to call it "United Linux" and their binary will not have the "certification" from Oracle and other companies that their software works on it. Thus this will have no effect on United Linux's business plans because their market will be uninterested in this free version.
My recomendation is that XFree86 be changed so the "old" interface claims there is exactly one 24-bit truecolor visual. It will claim this no matter what the memory on the screen is. If you have set it to 8-bit mode then the server does dithering to a color cube. All X programs can handle this nowadays. There would also be a "new" interface that lets a program peek at the actual memory layout and contents of the colormap on 8-bit displays.
The main speed requirement is for image buffers. I would also support a fixed set of image buffer types no matter what the display really uses: 1,2,4,8,16 bit monochrome, 8 and 16 bit versions of rgb and rgba, and a 16-bit format that matches the 5-6-5 format used by many XFree86 displays. All programs can assumme they have exactly this set of image formats and can continue using the current X interface.
Slashdot Mirror
It is possible that developing BeOS may be the most efficient use of resources for getting a user-friendly desktop onto Linux. If you strip out X and the BeOS GUI, I believe what is left is pretty much identical, and lots of people think the solution for fixing Linux on the desktop is to get rid of X.
Actually I think RMS is ok with dual licenses. What he does not like is modifying the GPL by adding restrictions so the other license is more valuable.
It would seem likely that anybody able to get to CEO of a rapidly growing company would not be the nicest person in the world and would have a strong desire for controlling everything.
You can do what dozens of people have done: dual license.
If you write something, put it out GPL, so everybody can see how it works. Any companies that want to use your code in a closed-source product has to purchase a seperate license that costs more.
In reality this is impractical for the individual developer, but it makes a lot of sense for large companies which have the ability to make such a sale and control of a large enough project to make purchase worthwhile.
You can also make your own more restrictive license in attempts to make the purchased license more valuable. Typical restrictions are to limit any commercial use, or limit use to non-profit organizations, or disallow modification. For some reason RMS does not like these ideas, but it seems to me they serve the main purpose of letting people see the code.
If you mean you just saw two viruses, then that means you are not receiving any. I would be much more impressed if you said you received thousands of viruses, but that you have proof that Outlook de-fanged or filtered them.
I'd like to know exactly what logic you use to equate "filtered" with "didn't get it in the first place".
Because the worse gcc is, the clearer the structure or the original code. Optimization tends to hide the original code.
Bill Gates was a f**king lucky individual and if there was a slight change in history around about 1980 he would be here on SlashDot complaining bitterly about whoever did become the meglamanical monopolist. He did absolutly nothing that tens of thousands of other people could see as obvious ways to progress, and in fact made serious errors in judgement such as dismissing the internet and thinking information delivered on CD's such as encylopaedias was the future.
Except for the hjkl in vi (which I don't use) it seems that most shortcuts are mnemonic on Unix, like all the Emacs commands, like ^N and ^P.
I'm suprised nobody mentions Apple's extremely positional assignment of zxcv for undo, cut, copy, paste. This must be a real pain on Dvorak, though you could revert when the ctrl or alt key is held down, but that would be a pain for mnemonic commands.
Unfortunately there is a huge number of people who think "easy to use" implies "easy to learn", or worse they think "learn" is all the work they will ever have to do with an interface (which is stupid if you plan to use a program more than once).
There are also lots of examples where interfaces are *both* hard to use and hard to learn. Perhaps this is the majority of interfaces. But this in no way implies that the sets "easy to learn" and "easy to use" are identical, all it implies is that they are small compared to the set of all interfaces. Their intersection may still be quite small compared to their non-intersecting parts (this is what I suspect).
I'm certainly not an NRA member, but even I would admit that only a small fraction of guns are used to harm/kill (or even threaten) people.
Perhaps unfortunately the middle-mouse paste of SELECTION turned out to be so incredibly convienent that everybody forgot about the CLIPBOARD, and most people implementing copy/paste commands put it into the SELECTION because a vast number of X programs could only paste with that middle mouse.
Only with the need to make Windows users happy has the original design of the CLIPBOARD reappeared.
The selection buffers have "type" information so it is in theory possible to cut any kind of data, just like Windows. What X lacks is any standard for much other than text, or a library that can draw the object on the screen or store it in a file without much thought from the programmer. This is the primary reason that anything other than text does not cut/paste. This is also true on Windows as soon as you get to more complex programs that want to analyze the pasted data and not just draw it on the screen, suddenly a lot of things don't paste (go ahead and try to paste that image into your IDE...)
Older solutions required X to keep seperate the background area and the icons, which had to be done by making each icon a seperate shaped X window. This was tremendously slow and required the program drawing the icons to send a lot of information to the X server. And there was no antialiasing of the edges and serious limitations on what you could draw.
A program that just thinks it has a big window and can draw anything into it is *much* faster, and will always be faster no matter how many new features are added to X. So instead these programs can now read a desktop image stored on the server and merge their own display with it to make the window.
Older desktop image programs that do not know how to communicate this information to these new desktop programs will not work.
I would like to see some of these idiot GUI experts figure out that "menubar" and "toolbar" are the same thing (especially now that the toolbar buttons often bring up a menu) and get them on the SAME LINE!!! That would make me think that these designers (both at MicroSoft and at all other companies and in open source) are not just a bunch of sheep who refuse to make the slightest tiny changes because of a morbid fear that some poor stupid user will be "confused" by it.
Although there are problems with X, you can easily put the URL into Netscape from the terminal. Select it in the terminal, go to Netscape, and click the middle mouse button on the text field.
The seperate clipboards are used by GTK and Motif, it was older Qt that did not do this (also true of a lot of other programs and toolkits, including fltk which I fixed a few months ago to match GTK). Newer Qt has been changed to match GTK.
On a i686 running Linux and using gcc this program:
void main() { .1) printf("%g ", i);
double i;
for (i = 0; i < 1.0; i +=
}
Produces this output:
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Notice that it printed "1" even though it looks like it shouldn't.
Technically it is not a bug but documented behavior. The man page writer is trying to discourage you from using the function by calling it a bug.
Another way to look at this is to make sets of only the numbers that change, then '0' is not in *either* set, so they are again unequal in size.
Exactly *how* start works can be left up to different implementations but what is needed is the ability to be able to assumme the program is there and can be called and will do reasonably well so programmers are not tempted to write their own implementations.
Old shells would require the user to type "start " but I would expect newer shells to just take " " directly.
I think this is a vital addition to Linux and should be done.
However they should write the program to detect if this is supported, and if not they can set the window size to the screen dimensions, which will work on older window managers.
Probably the main thing that makes people not consider this idea is that it would be a new OS that does not run any existing programs. Although there are plenty of alternative OS's out there, most people see VM as a way to get their new interface onto an existing system so they never consider this way of writing it.
Even the earliest VMs did garbage collection (take a look at Lisp which for some reason nobody has mentioned here yet).
However it is true that this argument could be made for any feature added to the VM, but it does seem that using the VM design to get away from numerically-addressed memory is a natural division that most designers go for.
However they will not be able to call it "United Linux" and their binary will not have the "certification" from Oracle and other companies that their software works on it. Thus this will have no effect on United Linux's business plans because their market will be uninterested in this free version.
My recomendation is that XFree86 be changed so the "old" interface claims there is exactly one 24-bit truecolor visual. It will claim this no matter what the memory on the screen is. If you have set it to 8-bit mode then the server does dithering to a color cube. All X programs can handle this nowadays. There would also be a "new" interface that lets a program peek at the actual memory layout and contents of the colormap on 8-bit displays.
The main speed requirement is for image buffers. I would also support a fixed set of image buffer types no matter what the display really uses: 1,2,4,8,16 bit monochrome, 8 and 16 bit versions of rgb and rgba, and a 16-bit format that matches the 5-6-5 format used by many XFree86 displays. All programs can assumme they have exactly this set of image formats and can continue using the current X interface.