I think "restricing rights" means passing laws or changing the constitution. Now you could claim that the RIAA etc are doing that with the DMCA, but when the term "DRM" is used it usually refers to technical mechanisms that are designed to restrict your ability to use your rights, without actually changing the rights. Therefore "restrictions" is a more accurate term.
To the average user, the home computer *is* Windows (or OS/X or Lindows). The fact that the operating system can be replaced with a different one has as much impact on them as the fact that the engine in their car can be replaced with a different one to make it into a hot rod.
If buying a Lexus meant you had to go to special Lexus gas stations that are only in a few cities and you could not drive on some roads that were "optimized for Hyandai" then I don't think you would see very many Lexus on the road.
If you could take a Hyandai and modify it into a Lexus-like car but with the crappy Hyandai interior, you might do that, even though you are still forced to use the special gas stations and can't use all the roads. You could always convert the Hyandai back, also the Hyandais are cheap enough that you might consider this as a hobby.
Your first few sound valid, but the program bringing up IE is not. Certainly they must have an easy test using grep on the source code to find out if a program is calling the "bring up IE" call or the "bring up the user's selected browser" call. They should be required to run this on all their code.
However there may be parts of it that are not under the GPL, you will have to seperate these. By the time you are done you will have your own Linux distribution that may have little to do with Lindows.
Re:Another step in the wrong direction
on
Lindows 2.0.0 Released
·
· Score: 3, Insightful
A lot of people here are saying "you don't have to replace X, you can fix it". And this is true, so in fact the original poster is wrong. But what is correct is that I don't see any sign of anybody "fixing" X. And it very much needs it.
Want some examples:
1. "Extensions" should not be allowed without a library that detects the extension and simulates (however crudly) the extension when it is not there. The purpose is not to make your program work on older systems, but to make it so you don't have to put any "if" statements in there when writing software that uses the extension. Becasue of the lack of this, NO extensions since about 1986 have ever been successful, all the ones that anybody uses are assummed to be there by the software (shared memory, shape). The only example I know of a correctly-written extension is Xft, which does emulate itself on old X11 servers, and you will notice that it is being used quite a lot!
2. Get rid of colormaps. I mean totally, they are GONE. The server should not report any "visuals" other than a single "true color" visual. If the hardware is not true color then it simulates it by using a color cube, the contents of this cube cannot be accessed or queried by an application and it cannot tell this is being done.
3. Absolute guaranteed support of every image format of 1, 3, and 4 channels with any number of bits that is a power of 2 from 1 to 32. Currently a library that wants to do this has to make an NxM set of translations, from an arbitrary input image format to an arbitrary one depending on the X server. If this crap was moved to the server it would only be an Nx1 set of transformations, vastly less, because the server knows exactly what the output format is. Also do alpha mixing of 4 channels images. I don't care how freaking slow it is, just do it so we don't have to do something even slower in the program. While you are at it, you should be able to read back an arbitrary image format from the screen and the server does the conversion. And it should use shared memory or whatever the fastest possible communication is *automatically*, not by me setting up the shared memory extension!
4. Keith, if you are writing Xrender extension, please try to make the interface so it is not confusing! I have a window id, I want to say "draw_into(window)" and then "moveto(x,y); lineto(x,y),... fill()". The main thing is that there is no reason for a "context" argument. OpenGL has worked without one forever, even in multithreaded, and you will notice that OpenGL is portable between systems and toolkits.
Digital Restrictions Management is actaully a lot more accurate than what they say, and is also more accurate than most of the very negative things coming up here (digital rights restricion or management is wrong, as it is not restricting rights, just the ability to use your rights on the devices. Also it may be restricting a few things that you don't have rights to do).
I also think "Copy Prevention" or "Copy Prevented" is pretty good too. Very accurate and same acronym as the RIAA is using.
In both cases there is a reasonable chance that our wording will catch on, if everybody uses it consistently in all documentation, including ones in support of DRM or DRM schemes.
I don't mind that but I don't like the fact that their file browser shows a fake hierarchy just like Windows. I consider this very confusing because the same directory can appear twice (ie MyDesktop on Windows). Also it does not match the arrangement that is revealed by file open/save dialog boxes.
These designers have to make a rule that the browser shows exactly the real hierarchy so there is never any confusion.
Of course the default hierarchy is confusing. There are a two ways to fix it:
First, make the program open already navigated to somewhere other than root, such as to your desktop or to the "My documents" type of folder.
Second, ignore the LSB and make it make sense to the user. In their example "/disks" makes sense, but why aren't the MSDOS disks in there? They should be, though they can name them C: if they want (this is a perfectly legal Unix filename).
I agree with most of your points except about client-server. Client-server is actually one of the fastest ways to get things done because it is naturally multi-threaded. Check up on what the most advanced graphics cards have on them before you say that client-server is obsolete (hint a "graphics processer" which is (in X terms) a SERVER!!!)
Basically a correctly designed client/server requires many ORDERS OF MAGNITUDE fewer context switches to get data on the screen. Not a measly 2 or 3 like people claim kernel servers give you, I'm talking about a reduction of 10000 times in system overhead. The reason is that it is trivial to batch requests together.
The known problem with client-server is latency. This has to be addressed anyway if you want any kind of remote interaction, even if it is supposed to be an add-on like VNC. Also everybody doing network programming is well aware of latency, and latency between the program and the screen ain't so bad if there is also latency between
The other problem with X is incredibly bad design such that many of the calls require a round-trip synchronization with the server. If you want to draw in arbitrary color c you must send c to the server, wait for it to respond with a "color cell" n and send n as the current color, and then you are ready to draw a thousand line segments in that color. But if you want to draw 1000 line segments in different colors, suddenly you have 2000 times more system overhead than before! Of course you could cache the colors, but that just shows the bad design of X so that you have to write complex stuff on the local end to talk to it. Any sensible design would take the original color c directly to set the color. (of course my description is simplified, but X is loaded with this crap).
PostScript was originally designed to be a 3-D system with perspective projection (I'm not sure if they intended to do depth buffer, probably not). 3D projections should not be much overhead if you have a bit that detects it so you use the 2D pipeline when possible. Some hardware will do a 4x4 perspective matrix multiply as fast as a 2x3 PostScript matrix, so it may not matter.
Variable-width splines are best handled at the near end. A more efficient communication would be to send the outline of the resulting fill area.
Pixmaps (what I think you meant by "bitmap") should be 3D as well, drawing them should be transformed through the 3D projection so that each pixel is a 1x1 square in the input coordianate space with z=0. All 3D graphics hardware can do this easily, it's what texture mapping is.
"Windows" could be off-screen images that you draw, using the normal graphics, and these are then mapped through 3D transformations and comped on the screen, giving you not only overlapping with transparency but the ability to distort windows arbitrarily without messing up programs that assumme they can read the bits back.
We have tried and all you guys do is complain that "it doesn't match Windows and therefore is not user friendly".
I would dearly love to see point-to-type be the default on a "novice" system. I would also REALLY like to see them stop raising the windows when you click on their contents.
This would be a HUGE breakthrough, I think similar to the invention of insertion mode-always back in about 1980 or the treatment of Newline as an insertable character, both of which made huge differences to the ability to use text editors, and both (I know because I was forced to write 4 freaking pages in a manual about how "insert mode" worked in 1984) were considered considerably user-unfriendly and geeky.
I do think there has to be some differences from Windows. User interface design has pretty much been frozen now for 7 years (since windows 95). Innovation does not necessarily mean "3d desktop" or "mind reading interface", it means remembering the forgotten ideas of ten or fifteen years ago, realizing what was good, and trying to introduce it to a public that has been brainwashed by never seeing anything other than a Mac or Windows.
Maybe when you stop complaining when every single little attempt to innovate in Linux (like doing point-to-type) is met with "that's user unfriendly because it does not match Windows!".
The price of pirating music is not zero. There is a price of guilt (I'm not joking, though for some people guilt is really cheap). More importantly there is the price of the time it takes to locate and download a usable version.
Because this price is not zero, your argument is wrong. It is not impossible for the RIAA to sell for less than this price. They can also raise the price in legal ways by going after the people who post the music so it gets harder to find.
The "type./image.jpg runs the image viewer", though a good idea, has nothing to do with the method by which it determines that image.jpg should run the image viewer program. I would agree that shells need this added. Without changing the shells I highly recommend that KDE/Gnome get together and make an "open" command line program so that everybody else can "double click files to open" without having to parse their data, and also so they agree on the method.
You are arguing for a method. From my experience that absolute best, without question method of determining file type is "magic bytes". This may seem strange, but magic bytes have the amazing capability of being preserved by virtually every interface anybody uses to copy files. That makes them infinitely better than any attribute. And don't give me any crap about magic bytes colliding or not identifying text files, I challenge you to find *any* file format that a real user would "double click to open" that cannot be identified by magic bytes.
The problem with magic bytes is filesystems that return the filename vastly faster than they return the data from the file. This makes it inefficient to look it up. Though probably no big deal for double-clicking, people seem to be addicted to the "icon" in the file viewer, though I have never seen anybody rely on this (try rearranging the small icons randomly on Windows and see who notices) and that requires opening every file. However "thumbnail views" seem to be catching on and these require opening the file anyway. I believe ReiserFS is addressing this and making it fast to open files. There is also a problem if the file viewer does not have read access to the files, though it probably could not read the attributes either in that case.
If you refuse to use magic bytes you must use attributes. Unfortunately you are seriously constrained by requiring an attribute that will copy by most file copying mechanisms and will be written by existing programs. It also helps if it is obvious to the user how to fix the attribute. Unfortunately I think the only workable solution is what Windows did, which was to use the file extension. My only experience with attributes is Mac OX9 and OS/X and I have always been annoyed with them, as a.jpg file will often lauch an unexpected program (such as a Classic app).
If a file system supports attributes, I strongly recommend that they be used as a "cache". This should be the obvious way to use them for "thumbnail views", but there is no reason to not do the same scheme for "types", if the type attribute is missing you then spend the time to use magic bytes to determine the type. File copying programs can strip all the attributes and the effect will be invisible to the user except for a slight slowdown the first time the file is used.
I also want to say that the Mac HFS system that preserves files is equivalent to the older Unix "hard" links that existed in the very first versions in 1970. I think these are rather an embarrassing part of Unix history and can actually be proven to be a mistake, and led to all kinds of horrible file system mantinence problems. They tried to fix it by disallowing hard links to directories, which coincidentally eliminated about 95% of the usefulness of them. "soft" links like ln -s make are much more useful, predictable, and the user and programs can control them in obvious ways.
DRM is not needed by the top echelons of business. At that level you assumme both parties are interested in keeping information secret, either because it is in both interest's, or because party A can severly party B if they reveal the information.
DRM is an attempt to force somebody to keep something secret when that party has no motivation for doing so.
Are you kidding? A real Digital Restrictions Management that works without assumming the bad guys are incapable of reverse-engineering would be incredibly useful. Yes it would be used to restrict fair-use rights and all that, but such a system would be infinitely more powerful than the closed-source stuff that MicroSoft/RIAA is pushing because it could be proven to work. With the ability to assumme it really works I'm sure there are an infinite number of uses such as national security, interesting encryption methods, on-line games, etc.
Personally I think it is physically impossible, but cryptography and advanced math is complex and may do things that don't seem logical. I mean I never would have thought PK encryption was possible, either.
Actually it won't work even as a one->one distribution mechanism. The problem is that somebody with access to the source code can capture the sent decoding key and the sent encoded data, and decrypt it and save it.
MSoft is certainly going to try to make it impossible to capture the encoded data and save it by coming up with some way for their system to "prove" to the server that it is currently only running trusted software. At least that is what they should try to do. They are probably idiots however and are going to try a closed-source decoder program, which of course will be cracked very quickly.
Yea, this seems incredibly stupid and expensive. Why not go to each city, get the reviewers in a room, make sure they don't have any recording devices, and play the music for them? While they are at it, give them a lot of free food and liquor. It's got to be less expensive and is guaranteed to prevent piracy.
Though there is nothing really wrong with the design of the C# language itself, there are a few weird MicroSoftisms in even the basic design that lead me to think they are up to no good:
The most obvious one is the special-quoted strings with no escapes. Those were obviously put in there so that people would stop typing forward slashes into filenames. There is a huge contingent of people who think you have to #ifdef every filename to make code portable between Windows and Unix, and the more that people think this the better for MicroSoft, because it discourages people writing portable code. In fact all Windows calls take forward slashes and I strongly encourage anybody writing code for Windows to use forward slashes at every moment possible so that they have no temptation to break this.
This language was not designed as a "better Java". The people told to make it got a chance to put in their ideas for a "better Java" so there is some good stuff there. But they were also ordered to make this a lock-into-Windows language and this is scary.
Qt/KDE applications work fine under other window managers. In fact they work better than the Gnome ones, many of which insist on launching the Gnome toolbar which I don't want.
The problem with that theory is that there is no GPL code needed to write the program. You are free to use LGPL libraries all you want, and except for a single example where RMS is being an ass (readline) the makers of the code have done a very good job of putting things that are useful for other software under the LGPL while GPL'ing end programs that cannot be used by another program except to duplicate the function.
You can also read every detail of every part of Linux and every GPL program and use this knowledge to improve your program so it works better with them and you still are not violating any licenses.
Any program with "same functionality as the Windows version" that is violating the GPL means the Windows version is violating the GPL, too. If it is not, take the non-violating code out of the Windows version and put it in the Linux one!
The main reason functionality is missing is due to proprietary libraries on Win32, actually. If you can't get the source or you are not allowed to port the library to Linux, then you have to cut the functions out.
I agree. This is probably a worse problem with commercial software than with open source as they often buy the newest machines.
I have seen a serioius deterioration in the speed of my own code when I switched from developeing on a 250mhz Irix to a dual-processor 1.5Ghz Linux box (in both cases the software was being targeted to both those machines and NT as well). Going back to the Irix for testing and some stuff is suddenly painfully slow. Trying the old version of the program proves that it was much better, it is not just that I am used to the Linux machine's speed.
Conversely though I had to switch to the Linux box, as it matches what most people here are using and I was wasting too much time making the OpenGL efficient for the Irix rather than Linux. Also the Irix c++ compiler has problems with namespaces and stl. And of course compiling is way faster on the Linux box.
They sure did. The original IBM PC packed every location in the 256 character lookup table for the text screen with an image, apparently picked almost at random (the ordering of the line drawings is extremely mysterious). Of course you can't have a data stream with these characters and also control information and the fact that programs relied on drawing all these except for cr, lf, tab made it impossible to add escape sequences to the data stream and probably set back computer communications and text peripherals on PC's back several years.
The smile was put in location 1, there was an inverse-video smile in location 2. There does not appear to be any frowns or other expressions. The newline character \n would draw as an inverse circle. MSDOS line endings would draw as a quarter-note symbol folowed by an inverse circle.
You *can* be prosecuted. You gave the music to Bob, which is a violation of copyright! So in fact there is nothing wrong with the system.
The biggest problem is that you can claim that Bob stole the music from you. However they can still go and prosecute Bob in this case, and if he can prove you gave it to him they can come back and get you.
Slashdot Mirror
I think "restricing rights" means passing laws or changing the constitution. Now you could claim that the RIAA etc are doing that with the DMCA, but when the term "DRM" is used it usually refers to technical mechanisms that are designed to restrict your ability to use your rights, without actually changing the rights. Therefore "restrictions" is a more accurate term.
You are confusing "open source" with "free as in beer". Common mistake, many people do it, so don't feel too bad about your stupidity.
To the average user, the home computer *is* Windows (or OS/X or Lindows). The fact that the operating system can be replaced with a different one has as much impact on them as the fact that the engine in their car can be replaced with a different one to make it into a hot rod.
If you could take a Hyandai and modify it into a Lexus-like car but with the crappy Hyandai interior, you might do that, even though you are still forced to use the special gas stations and can't use all the roads. You could always convert the Hyandai back, also the Hyandais are cheap enough that you might consider this as a hobby.
Your first few sound valid, but the program bringing up IE is not. Certainly they must have an easy test using grep on the source code to find out if a program is calling the "bring up IE" call or the "bring up the user's selected browser" call. They should be required to run this on all their code.
Yes you can do this.
However there may be parts of it that are not under the GPL, you will have to seperate these. By the time you are done you will have your own Linux distribution that may have little to do with Lindows.
Want some examples:
1. "Extensions" should not be allowed without a library that detects the extension and simulates (however crudly) the extension when it is not there. The purpose is not to make your program work on older systems, but to make it so you don't have to put any "if" statements in there when writing software that uses the extension. Becasue of the lack of this, NO extensions since about 1986 have ever been successful, all the ones that anybody uses are assummed to be there by the software (shared memory, shape). The only example I know of a correctly-written extension is Xft, which does emulate itself on old X11 servers, and you will notice that it is being used quite a lot!
2. Get rid of colormaps. I mean totally, they are GONE. The server should not report any "visuals" other than a single "true color" visual. If the hardware is not true color then it simulates it by using a color cube, the contents of this cube cannot be accessed or queried by an application and it cannot tell this is being done.
3. Absolute guaranteed support of every image format of 1, 3, and 4 channels with any number of bits that is a power of 2 from 1 to 32. Currently a library that wants to do this has to make an NxM set of translations, from an arbitrary input image format to an arbitrary one depending on the X server. If this crap was moved to the server it would only be an Nx1 set of transformations, vastly less, because the server knows exactly what the output format is. Also do alpha mixing of 4 channels images. I don't care how freaking slow it is, just do it so we don't have to do something even slower in the program. While you are at it, you should be able to read back an arbitrary image format from the screen and the server does the conversion. And it should use shared memory or whatever the fastest possible communication is *automatically*, not by me setting up the shared memory extension!
4. Keith, if you are writing Xrender extension, please try to make the interface so it is not confusing! I have a window id, I want to say "draw_into(window)" and then "moveto(x,y); lineto(x,y),... fill()". The main thing is that there is no reason for a "context" argument. OpenGL has worked without one forever, even in multithreaded, and you will notice that OpenGL is portable between systems and toolkits.
I also think "Copy Prevention" or "Copy Prevented" is pretty good too. Very accurate and same acronym as the RIAA is using.
In both cases there is a reasonable chance that our wording will catch on, if everybody uses it consistently in all documentation, including ones in support of DRM or DRM schemes.
These designers have to make a rule that the browser shows exactly the real hierarchy so there is never any confusion.
Of course the default hierarchy is confusing. There are a two ways to fix it:
First, make the program open already navigated to somewhere other than root, such as to your desktop or to the "My documents" type of folder.
Second, ignore the LSB and make it make sense to the user. In their example "/disks" makes sense, but why aren't the MSDOS disks in there? They should be, though they can name them C: if they want (this is a perfectly legal Unix filename).
Basically a correctly designed client/server requires many ORDERS OF MAGNITUDE fewer context switches to get data on the screen. Not a measly 2 or 3 like people claim kernel servers give you, I'm talking about a reduction of 10000 times in system overhead. The reason is that it is trivial to batch requests together.
The known problem with client-server is latency. This has to be addressed anyway if you want any kind of remote interaction, even if it is supposed to be an add-on like VNC. Also everybody doing network programming is well aware of latency, and latency between the program and the screen ain't so bad if there is also latency between
The other problem with X is incredibly bad design such that many of the calls require a round-trip synchronization with the server. If you want to draw in arbitrary color c you must send c to the server, wait for it to respond with a "color cell" n and send n as the current color, and then you are ready to draw a thousand line segments in that color. But if you want to draw 1000 line segments in different colors, suddenly you have 2000 times more system overhead than before! Of course you could cache the colors, but that just shows the bad design of X so that you have to write complex stuff on the local end to talk to it. Any sensible design would take the original color c directly to set the color. (of course my description is simplified, but X is loaded with this crap).
PostScript was originally designed to be a 3-D system with perspective projection (I'm not sure if they intended to do depth buffer, probably not). 3D projections should not be much overhead if you have a bit that detects it so you use the 2D pipeline when possible. Some hardware will do a 4x4 perspective matrix multiply as fast as a 2x3 PostScript matrix, so it may not matter.
Variable-width splines are best handled at the near end. A more efficient communication would be to send the outline of the resulting fill area.
Pixmaps (what I think you meant by "bitmap") should be 3D as well, drawing them should be transformed through the 3D projection so that each pixel is a 1x1 square in the input coordianate space with z=0. All 3D graphics hardware can do this easily, it's what texture mapping is.
"Windows" could be off-screen images that you draw, using the normal graphics, and these are then mapped through 3D transformations and comped on the screen, giving you not only overlapping with transparency but the ability to distort windows arbitrarily without messing up programs that assumme they can read the bits back.
I would dearly love to see point-to-type be the default on a "novice" system. I would also REALLY like to see them stop raising the windows when you click on their contents.
This would be a HUGE breakthrough, I think similar to the invention of insertion mode-always back in about 1980 or the treatment of Newline as an insertable character, both of which made huge differences to the ability to use text editors, and both (I know because I was forced to write 4 freaking pages in a manual about how "insert mode" worked in 1984) were considered considerably user-unfriendly and geeky.
I do think there has to be some differences from Windows. User interface design has pretty much been frozen now for 7 years (since windows 95). Innovation does not necessarily mean "3d desktop" or "mind reading interface", it means remembering the forgotten ideas of ten or fifteen years ago, realizing what was good, and trying to introduce it to a public that has been brainwashed by never seeing anything other than a Mac or Windows.
Maybe when you stop complaining when every single little attempt to innovate in Linux (like doing point-to-type) is met with "that's user unfriendly because it does not match Windows!".
Because this price is not zero, your argument is wrong. It is not impossible for the RIAA to sell for less than this price. They can also raise the price in legal ways by going after the people who post the music so it gets harder to find.
You are arguing for a method. From my experience that absolute best, without question method of determining file type is "magic bytes". This may seem strange, but magic bytes have the amazing capability of being preserved by virtually every interface anybody uses to copy files. That makes them infinitely better than any attribute. And don't give me any crap about magic bytes colliding or not identifying text files, I challenge you to find *any* file format that a real user would "double click to open" that cannot be identified by magic bytes.
The problem with magic bytes is filesystems that return the filename vastly faster than they return the data from the file. This makes it inefficient to look it up. Though probably no big deal for double-clicking, people seem to be addicted to the "icon" in the file viewer, though I have never seen anybody rely on this (try rearranging the small icons randomly on Windows and see who notices) and that requires opening every file. However "thumbnail views" seem to be catching on and these require opening the file anyway. I believe ReiserFS is addressing this and making it fast to open files. There is also a problem if the file viewer does not have read access to the files, though it probably could not read the attributes either in that case.
If you refuse to use magic bytes you must use attributes. Unfortunately you are seriously constrained by requiring an attribute that will copy by most file copying mechanisms and will be written by existing programs. It also helps if it is obvious to the user how to fix the attribute. Unfortunately I think the only workable solution is what Windows did, which was to use the file extension. My only experience with attributes is Mac OX9 and OS/X and I have always been annoyed with them, as a .jpg file will often lauch an unexpected program (such as a Classic app).
If a file system supports attributes, I strongly recommend that they be used as a "cache". This should be the obvious way to use them for "thumbnail views", but there is no reason to not do the same scheme for "types", if the type attribute is missing you then spend the time to use magic bytes to determine the type. File copying programs can strip all the attributes and the effect will be invisible to the user except for a slight slowdown the first time the file is used.
I also want to say that the Mac HFS system that preserves files is equivalent to the older Unix "hard" links that existed in the very first versions in 1970. I think these are rather an embarrassing part of Unix history and can actually be proven to be a mistake, and led to all kinds of horrible file system mantinence problems. They tried to fix it by disallowing hard links to directories, which coincidentally eliminated about 95% of the usefulness of them. "soft" links like ln -s make are much more useful, predictable, and the user and programs can control them in obvious ways.
DRM is an attempt to force somebody to keep something secret when that party has no motivation for doing so.
Personally I think it is physically impossible, but cryptography and advanced math is complex and may do things that don't seem logical. I mean I never would have thought PK encryption was possible, either.
MSoft is certainly going to try to make it impossible to capture the encoded data and save it by coming up with some way for their system to "prove" to the server that it is currently only running trusted software. At least that is what they should try to do. They are probably idiots however and are going to try a closed-source decoder program, which of course will be cracked very quickly.
However, it is not ok for Linux to have 2 different interfaces, even though the IT department can force one.
All makes sense to me. No wonder Linux sucks and Windows rules.
Yea, this seems incredibly stupid and expensive. Why not go to each city, get the reviewers in a room, make sure they don't have any recording devices, and play the music for them? While they are at it, give them a lot of free food and liquor. It's got to be less expensive and is guaranteed to prevent piracy.
The most obvious one is the special-quoted strings with no escapes. Those were obviously put in there so that people would stop typing forward slashes into filenames. There is a huge contingent of people who think you have to #ifdef every filename to make code portable between Windows and Unix, and the more that people think this the better for MicroSoft, because it discourages people writing portable code. In fact all Windows calls take forward slashes and I strongly encourage anybody writing code for Windows to use forward slashes at every moment possible so that they have no temptation to break this.
This language was not designed as a "better Java". The people told to make it got a chance to put in their ideas for a "better Java" so there is some good stuff there. But they were also ordered to make this a lock-into-Windows language and this is scary.
Qt/KDE applications work fine under other window managers. In fact they work better than the Gnome ones, many of which insist on launching the Gnome toolbar which I don't want.
You can also read every detail of every part of Linux and every GPL program and use this knowledge to improve your program so it works better with them and you still are not violating any licenses.
Any program with "same functionality as the Windows version" that is violating the GPL means the Windows version is violating the GPL, too. If it is not, take the non-violating code out of the Windows version and put it in the Linux one!
The main reason functionality is missing is due to proprietary libraries on Win32, actually. If you can't get the source or you are not allowed to port the library to Linux, then you have to cut the functions out.
I have seen a serioius deterioration in the speed of my own code when I switched from developeing on a 250mhz Irix to a dual-processor 1.5Ghz Linux box (in both cases the software was being targeted to both those machines and NT as well). Going back to the Irix for testing and some stuff is suddenly painfully slow. Trying the old version of the program proves that it was much better, it is not just that I am used to the Linux machine's speed.
Conversely though I had to switch to the Linux box, as it matches what most people here are using and I was wasting too much time making the OpenGL efficient for the Irix rather than Linux. Also the Irix c++ compiler has problems with namespaces and stl. And of course compiling is way faster on the Linux box.
The smile was put in location 1, there was an inverse-video smile in location 2. There does not appear to be any frowns or other expressions. The newline character \n would draw as an inverse circle. MSDOS line endings would draw as a quarter-note symbol folowed by an inverse circle.
The biggest problem is that you can claim that Bob stole the music from you. However they can still go and prosecute Bob in this case, and if he can prove you gave it to him they can come back and get you.