From the GPL (modified to remove the uppercase because the Lameness filter did not like it):
15. Because the library is licensed free of charge, there is no
warranty for the library, to the extent permitted by applicable law.
except when otherwise stated in writing the copyright holders and/or
other parties provide the library "as is" without warranty of any
kind, either expressed or implied, including, but not limited to, the
implied warranties of merchantability and fitness for a particular
purpose. The entire risk as to the quality and performance of the
library is with you. Should the library prove defective, you assume
the cost of all necessary servicing, repair or correction.
16. In no event unless required by applicable law or agreed to in
writing will any copyright holder, or any other party who may modify
and/or redistribute the library as permitted above, be liable to you
for damages, including any general, special, incidental or
consequential damages arising out of the use or inability to use the
library (including but not limited to loss of data or data being
rendered inaccurate or losses sustained by you or third parties or a
failure of the library to operate with any other software), even if
such holder or other party has been advised of the possibility of such
damages.
The use of linear math to do the compositing should be replaced with something that understands the gamma of the screen. This would result in much better display than Flash or any MicroSoft offerings.
Representing the range of brightness of a screen as 8 bits of intensity is actually very efficient and almost exactly matches human visual capability, if you use an exponential version where brightness(N+1)/brightness(N) is a constant for all 8-bit values N. This means brighness is a function pow(N,1/G) where G is a constant called "gamma". If you normalize N to be 0-1 then G is about 2.2.
Quite by accident this brightness function is exactly what cheap CRT's that are on PC's do when fed the linear conversion from D/A converters. So the hardware is actually perfect.
If the screen has a gamma value of G the correct math for adding images A and B so the result is the sum of brightnesses is pow(pow(A,G)+pow(B,G),1/G). The proper math for multiplying A by a mask M is pow(pow(A,G)*M,1/G).
Fortunately the data is 8 bits and thus both the above functions can be provided by 256x256 lookup tables. You can also use 256-entry tables for the two pow functions. Assumming G==2 may allow a lot of other math tricks as well, and is plenty accurate enough for vision.
The biggest problem with their design is that they specified premultiplied. This prevents the above math from being applied correctly, also gamma introduces questions about exactly what value you premultiply by.
I would recommend that they reformat their stuff to describe everything in an unpremultiplied area, and that all math is in intensities, not numeric values. The gamma is a constant built into the server and frozen at 2.2 or 2.0.
There can be a "premultiplied" flag in a picture. This should be used to fix "bad premultiply" that is produced by most (all?) 3D renderers, where the colors are in a gamma space but have been linearily multiplied by the alpha. To unpremultiply these, replace R with A?(pow(R,G)/A,1/G):R and same for G and B, leave A alone, and continue with the composite.
"Enums are clearly a meaningful concept in C++. We've preserved enums in C# and made them type-safe as well. In C#, enums are not just integers (...) An enum of type "foo" is not interchangeable with an enum of type "bar" without a cast."
Um, try this. It works even with Visual C++:
enum A {A_FOO, A_BAR};
enum B {B_FOO, B_BAR};
void test() {
A a(A_FOO);
B b(B_FOO);
A c(B_FOO);// produces an error
a = A_BAR;// ok
a = B_BAR;// produces an error
a = b;// produces an error
a = A(b);// ok
}
The fact that these guys don't know (or at least refuse to test) the simplest things about C++ is not reassuring. C++ has lots of problems, but it sounds like they are reinventing the wheel, not necessarily better, just different.
Anybody who thinks this thing is going to be remotely cross-platform is totally deluded. The run-time will require Windows, just like they tried to do with Java. They can talk all they want about the standard language but it is a lie.
I also believe that Moody is trolling for page hits. There are legitimate complaints about Linux, such as you have listed
But easily-refuted or flat-out wrong information like Moody is apparently presenting produces a far more visceral and active response.
And why not fix init. There is no reason for the mortal user to rearrange the order of the things that are started. There should be a gui with an array of checkboxes, each column is a run level, each row is a service. And put a comment in the.rc files that this GUI can display so the user knows what they are turning on/off! And also put the turning on/off of net services in that same panel (the etc/inetd file I think it is called?) because most people think those are the same thing! Advanced users can control the start/stop order by renaming the.rc files, there is no reason to do everything in the GUI.
Before anybody complains, I am thinking of writing this myself...
I believe NextStep died because it was a "toolkit" and hid the (otherwise quite good) underlying graphics system.
Programmers do not want to be forced to use a "toolkit". They will use one, but they want to know they have the freedom to replace it. X (and even the Win32 GDI) are much better than NeXTStep in this regard.
I worked on NeXTStep for 2 years, and hated every bit of it: I wanted a program to not display a menu, and that could rise above the "dock". Simple, yet impossible with NeXTStep. I instead wrote a toolkit from scratch, and realized that this is easier than interfacing to an existing toolkit!
Programmers of these systems should swallow their egos and realize that any doofus (like me) can make a functional button or menu. We need the "hard" stuff: fonts, images, high speed complex graphics. Get to work and stop wasting our time with enforced toolkits!
NeWS is not Display PostScript, which is an Adobe product. NeWS had it's own PostScript interpreter, this actually made it much faster and more powerful, and there was no interface other than PostScript needed, since there were PostScript commands to create windows and handle events.
I don't think Apple had anything to do with the X/NeWS merged system. This was just Sun trying to save NeWS in the face of overwhelming adoption of X. X/NeWS was actually quite bad, much slower than either X or NeWS. They should have emulated X atop NeWS but they were paranoid about compatability with X.
NeWS stands for "Network Extensible Windowing System".
They should open-source it. People have been asking for this for 12 years now. I think the original (ie non-X merged) version should be made available. Please, Scott?
Uh, no. Windows has a third button built into their interface. Grep their header files:
WM_LBUTTONDOWN WM_MBUTTONDOWN WM_RBUTTONDOWN
Gosh, what are those things starting with 'M'?
In fact, unless the mouse designers were idiots, that is what is produced when the middle mouse button or mouse wheel is clicked.
However, programs often treat the middle mouse button the same as the left one, which is a better idea than ignoring it. There appears to be no standard for what it should do, at least X has the pasting standard (which I like, it is actually better than dnd since I don't have to hold the button down and can raise windows before dropping).
I don't want Unix locked into a GUI that never changes ever again. And as a programmer, I want to be free to experiment with new (and perhaps better) GUI ideas!
All these suggestions for "consistentcy" will mean total lock-in. As I have said many times, if X was designed this way we would be using the Athena toolkit, have NO CHOICE about it, and pointing out the fact that all our applications agree about the reverse-video setting would be considered a laughable argument.
And the CTRL/ALT crap is MicroSoft's fault! Everybody used the Alt key before, becuase it was in the similar location to the Macintosh Apple key, which was being copied. MicroSoft came up with using the Ctrl key for some of their shortcuts, and in fact they are tremendously inconsistent. But I will blame programmers everywhere for failing to do the simple thing: make BOTH keys work! That's not too hard, is it?
Re:A lovely summary of all that's wrong with X
on
X Windows Must Die!
·
· Score: 1
The backspace problem is the same as a whole lot of other GUI problems on both X and Windoze: the programmer says "what action does this function?" rather than "what function does this action do?". The difference is that the first question does not allow two different actions do the same function.
If the original designers of Unix had thought a little harder, both ^H and ^? would have done backspace, and we never would have had this problem!
Re: f that approach had been adpoted, we wouldn't have distinct Motif apps and KDE apps and GNOME apps. We'd just have X apps, rendered as Motif or KDE or GNOME
While I agree with most of your points, I disagree here. We would actually have Athena apps, with no possibility of even getting a working menu that looks different.
Not putting widgets on the server was one of X's big wins, really. It is the only reason X has survived so long that we are having troubles with it's primitive design.
I very much recommend that the designers of X's replacement not be so arrogant as to think they can dictate the design of user interfaces!
PS: I really loved NeWS but it was the PostScript rendering model, and the ability to download drawing functions, that was the big win for me. I really did not care for their widget set.
That code is running on their machine and you are looking at the output. You are not running the program.
The source code in theory could be useless: It may require special hardware or connections that only the service provider has. Thus having the source code may not allow you to use the service, but you can use the service without having the source code. This implies that they are not really linked.
On a more practical note, it is likely the "modifications" of the software include the insertion of encryption keys and passwords. Distributing this would be extremely detrimental to the service provider. And we can't go and say "the GPL allows you to delete sensitive parts of the code" since that would break the GPL entirely.
I don't even see any problem with the "special enhanced gcc compiler" that was suggested. This is a service. I suppose it could subjugate the GPL on gcc, but I really doubt any possible enhancement would make this service viable anyways (reverse engineering it would be pretty easy and likely).
Now if the service provider helps another provider to set up the service by giving them the program, they must provide the code under the GPL. That second provider can keep the code to itself, modify it, or give it away to the general public.
You are right, VMS version numbers sort of do this. It may be exactly this, I'm not sure. If there was a different call to "create" a file than to "write" a file and the create one always made a new version this would be what I'm thinking of.
Plus it adds the wrinkle that it is *possible* to name every file by appending the right version number. This may not be real important, certainly I never did anything other than purge old versions on the VMS systems I used. But it may be important to say that opening a file by name is defined as opening the *newest* file with that name, rather than a random version as I was suggesting.
Why don't RedHat (and MicroSoft) ship these things with everything turned off? The box should be unable to respond to any command from the outside world.
I am serious. People are willing to follow directions to mess with config files in order to get something they need turned on. Why? Because it is intuitively obvious when they need to turn something on (because something they want to do does not work) and it is intuitively obvious when they have suceeded (because that thing is now working). Also, they need to do this to get the box to work the way they want.
But turning something off, knowing that they need to turn it off, and confirming it is off, are all much more difficult and opaque, even if the instructions are no more complicated. And the complex instructions are likely to make them give up, even if they ever attempt it, because the box "works" without doing this.
I think this discussion is about a system-independent equivalent of lpr. It will probably be far more confusing that lpr. This is a programming interface, just like lpr is supposed to be. One of the reasons people are fans of Linux is that the programming interface is much simpler and logical.
Neither needs to be seen by the user. There is nothing on Linux that prevents the implementation of a "print" button that does popen("lpr") and then pipes the postscript there.
The fact that lots of oss software writers don't bother doing this is a problem that needs to be addressed.
No name: Easy with the Unix filesystem. Create the file and then rm it without closing it. The file will exist until you close it.
Being in no directory: Easily emulated by designating a directory as representing "no directory". Windows and KDE use this technique for the "desktop".
Many names, and many directories: I'm sure these are the other two he thought were impossible, you noticed that they are possible on Unix by using hard or symbolic links.
In fact only one of his ideas is currently impossible. Allowing multiple files with the same name could, and perhaps should, be allowed. If you try to name a file you will get one of the ones with that name, accessing the others requires the first one to be deleted or renamed. This may eliminate some security holes (because creating a new file would be trivial) and would cleanly allow Plan-9 style merge mounts.
Of course the same people who are ignorant of links also clamor for case-insensitive file names, which is getting us even further from the ideal.
Wine provides exactly that, called winelib. IIRC, "emulatation" is only a minor application running atop this Win32 API to translate the exact format of Win32 calls to Linux calls. The real work is in the library. And it allows you to recompile a Win32 program for Linux.
The Posix emulation is absolutely useless. A "posix program" can only make the Posix calls, it cannot make the Win32 calls and thus cannot do graphics or talk to the network. I believe the files created by the Posix programs are invisible to the WIN32 programs and vice-versa. And the Posix support is absolutely minimal so that not much more than "Hello, world" can be run.
It is pretty obvious they designed this purposely to allow them to claim "posix compatability" without running the risk that people would be able to port code between NT and Unix.
I probably know nothing about security, but from what I have seen I'm not sure if complicating the capabilities really helps. It may actually give a false sense of security and make things worse.
The thing that convinced me of this was the recent Linux bug (actually not a bug but a design error, I think) where a program would lose the ability to give up abilities! It could then continue on thinking it was unable to cause damage, and be even more dangerous than a program that was written assumming it is setuid root.
However Unix has far too many programs that are setuid root for no reason. The small job needed (like checking a password) should be put in little programs that are easily confirmed as not having a hole.
Reducing the set of possible privledges to "all" and "nothing" should force people to figure out ways to get things done with "nothing", rather than rely on complex capabilities.
I would also modify Unix so that a setuid program just has the ability to setuid(0), but it starts out with normal privledges. This will encourage bracketing the necessary parts with set/reset uid calls, rather than doing everything like that.
There was a thing called the Apple ][ out several years earlier, it was cheaper and extremely popular. There were more of these in use than CP/M machines. There was also the TRS-80, but I think that did run CP/M, and a whole slew of other companies making "CP/M clones".
CP/M machines had the advantage that the OS was licensable by anyone and open source (!). Bill Gates actually wrote something: he wrote GW Basic, which ran under CP/M. At the time it was considered very important that a personal computer run Basic, and (believe it or not) it was pretty universally believed that Bill Gates' version was the best. So IBM decided that their new 16-bit machine should run a new 16-bit version of CP/M, and that then it could easily run Bill Gates' Basic.
Digital Research (the makers of CP/M) dragged their feet on releasing their new version (called, I think, CPM86). IBM got frustrated, and asked MicroSoft if there was anything they could do. MicroSoft then purchased the CPM-alike system they were using (QDos), modified the copyright to say "PC-DOS" and sold it to IBM. IBM then released the PC and even promised that the "real operating system" (CPM86) would be available soon. That of course never happened.
MS/PC DOS was explicitly designed to be compatable with CP/M and thus did not suck any more or less.
One of the chepest Unix solutions at that time was a MicroSoft product! Called XENIX, Radio Shack put this on their "professional TRS-80" which uses a 68000 chip. MicroSoft intended to merge XENIX and MSDOS, this is where most of the Unix'sms of MSDOS 2.0 came from.
The implanted chip will temporarily disconnect your speech centers while you are listening, preventing this. And they will encode the stored memories so that they can only be played back through the decoder, so you can't sing it later. There will also be protections so that your mind can only think and report positive and pleasurable responses to the music, all negative ones will be stopped, since they violate the license agreement.
I don't get it. Why don't they just delay the American release until the same time they release it in Japan? I would think the ability to release a "quality" version (with Japanese track) would outweigh any loss due to the later release.
You want to steal my rights to make money off my software, and you have the incredible arrogance to accuse me of Communism!
You can pay me for the right to use the software I wrote in your commercial software. Otherwise you do not have the right to use it in any way you see fit. Yet you want to steal this right from me, and use the fact that I was generous enough to reveal the code as a reason!
You are truly a sick and twisted individual.
PS: I actually use the LGPL for any code that I feel might actually be useful in another program, and have thought about rewording it to make it clear that static linking is allowed. The problem with the GPL is that it discourages the use of the software at all by commercial developers, often forcing them to use proprietary solutions. I doubt Windows would use TCP/IP if it were not for the free code in BSD. And, honestly, I doubt anybody would really pay me for the rights to my software... But even though I don't think the GPL should be put on any libraries or library-like functions, I do think this "Communist" argument is sick.
Yes, Corel is pushing Linux for their own selfish reasons, but since they are not the only source for Linux this does not seem harmful. They are trying to make the Linux market bigger so there is more demand for their products in the future, but not to kill anybody else.
MicroSoft on the otherhand did overprice Unix versions of their software in order to kill the Unix market. For instance SoftImage (purchased by MicroSoft, later sold to Avid) was less than half as expensive for the NT version, despite the fact that the Unix (actually Irix) version already existed and did not need any work from them (and certainly did not get any!). MicroSoft could have done many other less evil or illogical things (including discontinuing the Unix version) but did this rather convoluted action to try to make NT look better in comparison.
If Corel's programs required some library or proprietary module that was only on Corel Linux I would say they should be screamed at, but their current actions do not seem evil in any way.
Slashdot Mirror
From the GPL (modified to remove the uppercase because the Lameness filter did not like it):
15. Because the library is licensed free of charge, there is no warranty for the library, to the extent permitted by applicable law. except when otherwise stated in writing the copyright holders and/or other parties provide the library "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the library is with you. Should the library prove defective, you assume the cost of all necessary servicing, repair or correction.
16. In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or redistribute the library as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the library (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the library to operate with any other software), even if such holder or other party has been advised of the possibility of such damages.
Representing the range of brightness of a screen as 8 bits of intensity is actually very efficient and almost exactly matches human visual capability, if you use an exponential version where brightness(N+1)/brightness(N) is a constant for all 8-bit values N. This means brighness is a function pow(N,1/G) where G is a constant called "gamma". If you normalize N to be 0-1 then G is about 2.2.
Quite by accident this brightness function is exactly what cheap CRT's that are on PC's do when fed the linear conversion from D/A converters. So the hardware is actually perfect.
If the screen has a gamma value of G the correct math for adding images A and B so the result is the sum of brightnesses is pow(pow(A,G)+pow(B,G),1/G). The proper math for multiplying A by a mask M is pow(pow(A,G)*M,1/G).
Fortunately the data is 8 bits and thus both the above functions can be provided by 256x256 lookup tables. You can also use 256-entry tables for the two pow functions. Assumming G==2 may allow a lot of other math tricks as well, and is plenty accurate enough for vision.
The biggest problem with their design is that they specified premultiplied. This prevents the above math from being applied correctly, also gamma introduces questions about exactly what value you premultiply by.
I would recommend that they reformat their stuff to describe everything in an unpremultiplied area, and that all math is in intensities, not numeric values. The gamma is a constant built into the server and frozen at 2.2 or 2.0.
There can be a "premultiplied" flag in a picture. This should be used to fix "bad premultiply" that is produced by most (all?) 3D renderers, where the colors are in a gamma space but have been linearily multiplied by the alpha. To unpremultiply these, replace R with A?(pow(R,G)/A,1/G):R and same for G and B, leave A alone, and continue with the composite.
Um, try this. It works even with Visual C++: enum A {A_FOO, A_BAR}; enum B {B_FOO, B_BAR}; void test() { A a(A_FOO); B b(B_FOO); A c(B_FOO); // produces an error
a = A_BAR; // ok
a = B_BAR; // produces an error
a = b; // produces an error
a = A(b); // ok
}
The fact that these guys don't know (or at least refuse to test) the simplest things about C++ is not reassuring. C++ has lots of problems, but it sounds like they are reinventing the wheel, not necessarily better, just different.
Anybody who thinks this thing is going to be remotely cross-platform is totally deluded. The run-time will require Windows, just like they tried to do with Java. They can talk all they want about the standard language but it is a lie.
But easily-refuted or flat-out wrong information like Moody is apparently presenting produces a far more visceral and active response.
And why not fix init. There is no reason for the mortal user to rearrange the order of the things that are started. There should be a gui with an array of checkboxes, each column is a run level, each row is a service. And put a comment in the .rc files that this GUI can display so the user knows what they are turning on/off! And also put the turning on/off of net services in that same panel (the etc/inetd file I think it is called?) because most people think those are the same thing! Advanced users can control the start/stop order by renaming the .rc files, there is no reason to do everything in the GUI.
Before anybody complains, I am thinking of writing this myself...
It is quite possible that the reason they did this is to get a port done to Linux for free.
Programmers do not want to be forced to use a "toolkit". They will use one, but they want to know they have the freedom to replace it. X (and even the Win32 GDI) are much better than NeXTStep in this regard.
I worked on NeXTStep for 2 years, and hated every bit of it: I wanted a program to not display a menu, and that could rise above the "dock". Simple, yet impossible with NeXTStep. I instead wrote a toolkit from scratch, and realized that this is easier than interfacing to an existing toolkit!
Programmers of these systems should swallow their egos and realize that any doofus (like me) can make a functional button or menu. We need the "hard" stuff: fonts, images, high speed complex graphics. Get to work and stop wasting our time with enforced toolkits!
NeWS is not Display PostScript, which is an Adobe product. NeWS had it's own PostScript interpreter, this actually made it much faster and more powerful, and there was no interface other than PostScript needed, since there were PostScript commands to create windows and handle events.
I don't think Apple had anything to do with the X/NeWS merged system. This was just Sun trying to save NeWS in the face of overwhelming adoption of X. X/NeWS was actually quite bad, much slower than either X or NeWS. They should have emulated X atop NeWS but they were paranoid about compatability with X.
NeWS stands for "Network Extensible Windowing System".
They should open-source it. People have been asking for this for 12 years now. I think the original (ie non-X merged) version should be made available. Please, Scott?
WM_LBUTTONDOWN WM_MBUTTONDOWN WM_RBUTTONDOWN
Gosh, what are those things starting with 'M'?
In fact, unless the mouse designers were idiots, that is what is produced when the middle mouse button or mouse wheel is clicked.
However, programs often treat the middle mouse button the same as the left one, which is a better idea than ignoring it. There appears to be no standard for what it should do, at least X has the pasting standard (which I like, it is actually better than dnd since I don't have to hold the button down and can raise windows before dropping).
I don't want Unix locked into a GUI that never changes ever again. And as a programmer, I want to be free to experiment with new (and perhaps better) GUI ideas!
All these suggestions for "consistentcy" will mean total lock-in. As I have said many times, if X was designed this way we would be using the Athena toolkit, have NO CHOICE about it, and pointing out the fact that all our applications agree about the reverse-video setting would be considered a laughable argument.
And the CTRL/ALT crap is MicroSoft's fault! Everybody used the Alt key before, becuase it was in the similar location to the Macintosh Apple key, which was being copied. MicroSoft came up with using the Ctrl key for some of their shortcuts, and in fact they are tremendously inconsistent. But I will blame programmers everywhere for failing to do the simple thing: make BOTH keys work! That's not too hard, is it?
If the original designers of Unix had thought a little harder, both ^H and ^? would have done backspace, and we never would have had this problem!
While I agree with most of your points, I disagree here. We would actually have Athena apps, with no possibility of even getting a working menu that looks different.
Not putting widgets on the server was one of X's big wins, really. It is the only reason X has survived so long that we are having troubles with it's primitive design.
I very much recommend that the designers of X's replacement not be so arrogant as to think they can dictate the design of user interfaces!
PS: I really loved NeWS but it was the PostScript rendering model, and the ability to download drawing functions, that was the big win for me. I really did not care for their widget set.
The source code in theory could be useless: It may require special hardware or connections that only the service provider has. Thus having the source code may not allow you to use the service, but you can use the service without having the source code. This implies that they are not really linked.
On a more practical note, it is likely the "modifications" of the software include the insertion of encryption keys and passwords. Distributing this would be extremely detrimental to the service provider. And we can't go and say "the GPL allows you to delete sensitive parts of the code" since that would break the GPL entirely.
I don't even see any problem with the "special enhanced gcc compiler" that was suggested. This is a service. I suppose it could subjugate the GPL on gcc, but I really doubt any possible enhancement would make this service viable anyways (reverse engineering it would be pretty easy and likely).
Now if the service provider helps another provider to set up the service by giving them the program, they must provide the code under the GPL. That second provider can keep the code to itself, modify it, or give it away to the general public.
Plus it adds the wrinkle that it is *possible* to name every file by appending the right version number. This may not be real important, certainly I never did anything other than purge old versions on the VMS systems I used. But it may be important to say that opening a file by name is defined as opening the *newest* file with that name, rather than a random version as I was suggesting.
Why don't RedHat (and MicroSoft) ship these things with everything turned off? The box should be unable to respond to any command from the outside world.
I am serious. People are willing to follow directions to mess with config files in order to get something they need turned on. Why? Because it is intuitively obvious when they need to turn something on (because something they want to do does not work) and it is intuitively obvious when they have suceeded (because that thing is now working). Also, they need to do this to get the box to work the way they want.
But turning something off, knowing that they need to turn it off, and confirming it is off, are all much more difficult and opaque, even if the instructions are no more complicated. And the complex instructions are likely to make them give up, even if they ever attempt it, because the box "works" without doing this.
Neither needs to be seen by the user. There is nothing on Linux that prevents the implementation of a "print" button that does popen("lpr") and then pipes the postscript there.
The fact that lots of oss software writers don't bother doing this is a problem that needs to be addressed.
Being in no directory: Easily emulated by designating a directory as representing "no directory". Windows and KDE use this technique for the "desktop".
Many names, and many directories: I'm sure these are the other two he thought were impossible, you noticed that they are possible on Unix by using hard or symbolic links.
In fact only one of his ideas is currently impossible. Allowing multiple files with the same name could, and perhaps should, be allowed. If you try to name a file you will get one of the ones with that name, accessing the others requires the first one to be deleted or renamed. This may eliminate some security holes (because creating a new file would be trivial) and would cleanly allow Plan-9 style merge mounts.
Of course the same people who are ignorant of links also clamor for case-insensitive file names, which is getting us even further from the ideal.
Wine provides exactly that, called winelib. IIRC, "emulatation" is only a minor application running atop this Win32 API to translate the exact format of Win32 calls to Linux calls. The real work is in the library. And it allows you to recompile a Win32 program for Linux.
It is pretty obvious they designed this purposely to allow them to claim "posix compatability" without running the risk that people would be able to port code between NT and Unix.
The thing that convinced me of this was the recent Linux bug (actually not a bug but a design error, I think) where a program would lose the ability to give up abilities! It could then continue on thinking it was unable to cause damage, and be even more dangerous than a program that was written assumming it is setuid root.
However Unix has far too many programs that are setuid root for no reason. The small job needed (like checking a password) should be put in little programs that are easily confirmed as not having a hole.
Reducing the set of possible privledges to "all" and "nothing" should force people to figure out ways to get things done with "nothing", rather than rely on complex capabilities.
I would also modify Unix so that a setuid program just has the ability to setuid(0), but it starts out with normal privledges. This will encourage bracketing the necessary parts with set/reset uid calls, rather than doing everything like that.
There was a thing called the Apple ][ out several years earlier, it was cheaper and extremely popular. There were more of these in use than CP/M machines. There was also the TRS-80, but I think that did run CP/M, and a whole slew of other companies making "CP/M clones".
CP/M machines had the advantage that the OS was licensable by anyone and open source (!). Bill Gates actually wrote something: he wrote GW Basic, which ran under CP/M. At the time it was considered very important that a personal computer run Basic, and (believe it or not) it was pretty universally believed that Bill Gates' version was the best. So IBM decided that their new 16-bit machine should run a new 16-bit version of CP/M, and that then it could easily run Bill Gates' Basic.
Digital Research (the makers of CP/M) dragged their feet on releasing their new version (called, I think, CPM86). IBM got frustrated, and asked MicroSoft if there was anything they could do. MicroSoft then purchased the CPM-alike system they were using (QDos), modified the copyright to say "PC-DOS" and sold it to IBM. IBM then released the PC and even promised that the "real operating system" (CPM86) would be available soon. That of course never happened.
MS/PC DOS was explicitly designed to be compatable with CP/M and thus did not suck any more or less.
One of the chepest Unix solutions at that time was a MicroSoft product! Called XENIX, Radio Shack put this on their "professional TRS-80" which uses a 68000 chip. MicroSoft intended to merge XENIX and MSDOS, this is where most of the Unix'sms of MSDOS 2.0 came from.
The implanted chip will temporarily disconnect your speech centers while you are listening, preventing this. And they will encode the stored memories so that they can only be played back through the decoder, so you can't sing it later. There will also be protections so that your mind can only think and report positive and pleasurable responses to the music, all negative ones will be stopped, since they violate the license agreement.
I don't get it. Why don't they just delay the American release until the same time they release it in Japan? I would think the ability to release a "quality" version (with Japanese track) would outweigh any loss due to the later release.
You can pay me for the right to use the software I wrote in your commercial software. Otherwise you do not have the right to use it in any way you see fit. Yet you want to steal this right from me, and use the fact that I was generous enough to reveal the code as a reason!
You are truly a sick and twisted individual.
PS: I actually use the LGPL for any code that I feel might actually be useful in another program, and have thought about rewording it to make it clear that static linking is allowed. The problem with the GPL is that it discourages the use of the software at all by commercial developers, often forcing them to use proprietary solutions. I doubt Windows would use TCP/IP if it were not for the free code in BSD. And, honestly, I doubt anybody would really pay me for the rights to my software... But even though I don't think the GPL should be put on any libraries or library-like functions, I do think this "Communist" argument is sick.
What the hell are you talking about? Yes, MicroSoft has been accused of many things, but stealing intellectual property is not one of them!
MicroSoft on the otherhand did overprice Unix versions of their software in order to kill the Unix market. For instance SoftImage (purchased by MicroSoft, later sold to Avid) was less than half as expensive for the NT version, despite the fact that the Unix (actually Irix) version already existed and did not need any work from them (and certainly did not get any!). MicroSoft could have done many other less evil or illogical things (including discontinuing the Unix version) but did this rather convoluted action to try to make NT look better in comparison.
If Corel's programs required some library or proprietary module that was only on Corel Linux I would say they should be screamed at, but their current actions do not seem evil in any way.