"even if you're not directly using them, and not even aware, this makes all your custom app code AGPL too?"
No it doesn't. This is one of the many FUDs spread against GPL and related licenses. Your own software will never, EVER, suddenly and magically become GPL/LGPL/AGPL/WhateverPL.
What could happen is that you'll have a license violation. You can choose how you want to solve this violation: 1. Relicense your application under a compatible license. Again: this is completely up to you! Nobody can force you to relicense your software. 2. Remove any dependencies on the library in question, by rewriting (parts of) your code. 3. Ask the copyright holders of the library in question whether they'll grant you a commercial license, possibly for a fee.
"Compare Linux 2003 with XP or Linux 2007 with Vista, Linux still has a long way to go."
Actually I have to disagree on that. GTK 2 and QT 2+ have had superb internationalization support since the very beginning, and I think they were released in 2001 or 2002. Linux has supported multiple language packs since... well... as long as I can remember. Linux internationalization support is pretty much the same as it was in 2003, with the exception of better input methods these days.
"Not sure where you are going with this. Notepad itself has been fully unicode since 1992 on the NT platform."
It doesn't produce Unicode *by default*.
"Windows has had some of the best non-english support of any OS since the NT 4.0 days"
And that's great if the user only uses one locale at the same time. Not when he needs many locales at the same time. On Linux I just set LC_ALL to anything I want and whola, all apps that I start on that console magically use that locale. On Windows I need to restart, and the setting applies to all applications. Furthermore, the Windows core uses UTF-16, which is not compatible with ASCII. This has led to many compatibility issues.
Not too long ago I was working on internationalization and localization support for my application. On Linux, it was a breeze. On Windows, I had to go through hell with workaround after workaround on top of compatibility layers.
Windows may support internationalization, but not easily. Linux does.
I don't consider this impressive at all. Linux has supported all of this since, what, 2004? Since 2002, with the coming of GTK 2 and QT 3, 99% of the Linux applications are fully Unicode-enabled (UTF-8). Since 2005, everything in Linux is UTF-8. I've been able to run Chinese and English environments side-by-side for years.
It seems that Windows is, again, the only operating system that falls behind. There are tons of often-used apps in Windows that are not Unicode-enabled. Writing Unicode-enabled applications is a huge pain in Windows because my application depends on output of other arbitrary applications (such as text files produced by Notepad) but not all of them produce Unicode output.
But frankly, most people just don't care. They don't understand Unicode. They just think, "I type Chinese/Japanese/whatever. You cannot read it so there is something wrong with your computer". Things like being able to run Japanese and English side by side, is something only 0.1% of the population truly cares about.
The reason why they have only 65000 people in the right parking spaces, is because they still use 16-bit identifiers to store the parking space IDs. DOS is not dead after all.
"Firstly your not considering the extra power consumed by the extra ram."
Actually, I am. The $14 extra per month (or one-time $150) that I pay my hosting provider includes power bills. For 500 machines it may matter, but in practice few non-technical people will actually care. Let's say I work in a company and I gave my manager two choices: - "I'll spend the next 100 hours optimizing software, and I expect 33% memory savings." - "I'll spend the next 100 hours developing productivity tools so that our future products' time-to-market will be lowered by 33%." It's not hard to guess that he'll choose the latter.
Optimization doesn't happen in vacuum people. All the time that a developer spent/wasted on optimizing software, is time that he could have used to do something else, possibly something more economical.
I spent several months optimizing Ruby's garbage collector to be copy-on-write friendly, so that I can save more memory in my Ruby on Rails applications. I did this because I didn't want to spend an additional $14 per month (or a one-time payment of $150) for 1 GB more RAM in my server. I spent at least 40 hours in research and development. If I had a fulltime job that pays $12 per hour, then I would have $480. It's obvious that hardware *is* cheaper than developer time.
And that's the problem with you people, all you do is complaining.
Now someone is actually doing his best to solve the sound problem instead of sitting around and complaining and doing nothing productive, and what do they get? MORE complaints. Get this into your head, nothing's going to happen if you complain and do nothing. The hard work is done by other people, for you, for free. The least you can do is show some respect.
FYI, I don't work for a software company. The "customers" I talked about were hypothetical.
"But in practice, the native library often has not been ported, or if it is, the end user cannot install it on the target system. The.NET framework is bigger on disk than the Java runtime."
That totally depend on the native library in question. I'm a Linux user and I love cross platform support, so I'll make sure that all the native libraries I use are portable. The situation really isn't much different from writing C++ programs, or writing Python apps that make use of C libraries. In C++, you also have to make sure that your dependencies are portable. Dito with Python apps that use C libraries. Now, with C#, parts of the program are already portable, and if I choose to use native libraries, I just make sure that those are portable as well. So I really don't see the problem.
"But can GtkSharp applications be deployed over the Internet as easily as Java, SWF, or AJAX applications can?"
I deploy them by creating an installer for them and creating a.tar.gz with the source code. Most of my target groups consist of 99% Windows users and 1% Linux users so they're already used to software installers.
If the software in question can be a web application, then yes, I'll write a web application with PHP or Ruby on Rails or whatever. If easy web-based no-software-installation deployment is important for the software in question, then yes, I'll choose Java or Flash. If the functionality in question cannot be easily or efficiently implemented with the web platform, and my target group has a lot of Windows users, then C# is a good option. It all boils down to the right tool for the right job. The last GtkSharp application I wrote is a.FLD file editor. FLD files define walkable and non walkable blocks on a map in a game, and are typically 500 KB each. It would not be user friendly to ask the user to upload.FLD files to the web server and then using clucky JavaScript-based GUIs to manipulate the blocks, would it? This is why I chose to make it a client application. And since I'm a user myself, I chose to write it in C# and GtkSharp so that I can use it on Linux too.
Ajax and Java are not C# killers, nor is C# a Java or Ajax killer - Ajax and Java are merely alternatives which may be more suitable in different situations.
"So what do you do when your bundled DLL is x86, but your customers suddenly ask for ARM? Or when your bundled DLL calls Win32 or WinCE, but your customers ask for Linux or Mac versions? If your program relies on unmanaged code that is not included as part of the.NET or Mono system libraries, then why are you using managed code in the first place?"
I'll handle it like I'll handle any portability issue - port the code, or telling the customer that it's not possible.
I use managed code in the first place not because of portability, but because of developer productivity and maintenance benefits. C# is more high level language than say, C and C++. It does things like garbage collection. The C# languages has advantages over Java: delegates and closures come in mind.
Realistically speaking, 100% portability is almost never possible. You should have heard of the saying "write once, debug everywhere" about Java. Regardless of whether I use native libraries, I'll have to test the code on the target platform anyway. Things like hardcoded path delimiters can pose problems on portability. A while ago I wrote a Java application. I developed it mainly on Linux. Then I tested it on Windows and I noticed that the Swing GUI looks weird, so I had to fix things up a little. Some unit tests failed on Windows - turned out that it's because of a line ending issue (CRLF on Windows vs LF on Unix).
So suppose I don't use any native libraries at all. If customers ask me for an ARM version I'll still refuse, because I just don't have experience with ARM. I cannot guarantee that my application will run fine on an ARM because I don't have the ability to test it, even if Java/.NET claim to run on ARM. The best I could tell my customers is "use this at own risk" but I doubt they'd buy that.
"The majority of commercial off-the-shelf software publishers stating that Microsoft Windows is a required dependency for an application is exactly what got us into this mess."
I'm not sure what you mean by "this mess". If your.NET app doesn't depend on any obvious Windows-specific things like Windows.Forms or the NTFS API, but does depend on native libraries, then theoretically you can run that app on both Windows and Linux, provided that the native library has been ported to both platforms.
It has proven to work in practice. A while ago I wrote a GtkSharp application. The app ran on both Windows and Linux, without recompilation, because GtkSharp (which is a native library, which serves as a binding to GTK+) is available for Windows and Linux.
"By "C" I assume you mean "unmanaged code", not the common subset of the C language and C++/CLI."
Yes. Specifically, I'm referring to the [DllImport("foo")] syntax. This makes it very, very easy to import functions from a C library, without the need to write boilerplate binding code like I have to with, e.g., Perl, Python and Ruby. I realize that for Perl there's Win32::API, but it's not portable. [DllImport("foo")] works on the MS implementation and in Mono, on all supported platforms. In fact, GtkSharp uses DllImport to implement its GTK+ bindings.
"But how do you know what unmanaged libraries will be present on computer systems that you do not control?"
I don't. That's why I use DllImport only when I have to. Valid reasons for using DllImport could be: - I need platform-specific integration. - I need functionality that cannot be easily provided in C#, but can be easily provided in C or C++. In this case, I'll bundle the required libraries with my application. Or I could specifically state that libfoo is a required dependency for my application.
Well, for me, C# is not a waste of effort. It has advantages over Java, for instance: - Properties. - Delegates. - Structs. - Easy integration with C libraries. - VM-level generics support, making it easier to integrate with other.NET languages. - Mono starts faster than the Sun JVM (or even GCJ for that matter). - Ahead-of-time compilation with Mono. - Language-integrated queries (LINQ).
"further Microsoft's stronghold over the market"? There is nothing to further, they already have 98% of the desktop market and even Apple can't make a significant dent in it. They can't be any more powerful than they already are.
"Because recreating the.Net framework should not be a requirement for writing GTK applications in a nicer way." It isn't, has never been, and will never be a requirement. It is an extra alternative for those who prefer it, just like PyGTK and Java-GNOME.
"Would it not have been better to come up with something original, with some new ideas?" Original != better. As they say, "good artists create, great artists copy". C# already has many good things: is similar to Java, but with a different VM design (generics implemented in VM instead of language), support for Delphi-style properties, language-integrated queries, partial classes, preprocessor support, structs, easy integration with C libraries, a large class library, etc. None of those things (except parts of the class library, like Windows.Forms) are Windows specific and are very well-suited for cross-platform, general purpose development. What's the point in rewriting all those things? Just to get rid of the "MS" label?
I couldn't care less whether a language is copied from something else, as long as it does the job well. They can copy all they want.
That's ridiculous, Python and Java don't make C# obsolete. That's like saying that there's a complete lack of need for Python because Perl and Ruby already exist. The only reason why people dislike C# is because it's created by MS.
"Because it's not possible to do that, and it's a fool's errand. All it's doing is following Microsoft's latest programming fad."
I've written GTK applications in C#, and it was a very pleasant experience. It allowed me to be productive in writing Linux applications. So just how is that "following Microsoft's latest programming fad"? Mono, as it is right now, is a very capable development environment even for Unix-only apps.
As AC pointed out, FUSE has been in the kernel for a while. I think more than a year now. FUSE and NTFS-3g are both enabled by default on Ubuntu Gutsy so most people have it by default.
I don't understand your logic at all. "My main concern [is]... Mono would almost certainly make the same change, leaving a bunch of open-source developers to deal with the whims of Microsoft."
Just how will developers have to deal with the whims of Microsoft? So Microsoft decides to add a language-level assert statement, so what? All the open source C# software will happily keep running just like they did yesterday. Microsoft can't decide to break compatibility because they have too many enterprise customers depending on.NET backwards compatibility.
That's X at fault, not the distros at fault. The problem is that XFree86 was so conservative, and wasn't very cooperative with contributors. Now that XFree86 has forked into X.org, development is finally speeding up again, and they're working hard on eliminating the need for a configuration file.
Slashdot Mirror
Why? The regular GPL only applies to distribution, not usage.
"even if you're not directly using them, and not even aware, this makes all your custom app code AGPL too?"
No it doesn't. This is one of the many FUDs spread against GPL and related licenses. Your own software will never, EVER, suddenly and magically become GPL/LGPL/AGPL/WhateverPL.
What could happen is that you'll have a license violation. You can choose how you want to solve this violation:
1. Relicense your application under a compatible license. Again: this is completely up to you! Nobody can force you to relicense your software.
2. Remove any dependencies on the library in question, by rewriting (parts of) your code.
3. Ask the copyright holders of the library in question whether they'll grant you a commercial license, possibly for a fee.
"Compare Linux 2003 with XP or Linux 2007 with Vista, Linux still has a long way to go."
Actually I have to disagree on that. GTK 2 and QT 2+ have had superb internationalization support since the very beginning, and I think they were released in 2001 or 2002. Linux has supported multiple language packs since... well... as long as I can remember. Linux internationalization support is pretty much the same as it was in 2003, with the exception of better input methods these days.
"How useful is 1 million dollars if, in 5 years, the wealth of a nation can be wiped out by irresponsible government?"
Smart people will take the 1 million dollars and move to a prosperous nation far away with a democratic government.
"Not sure where you are going with this. Notepad itself has been fully unicode since 1992 on the NT platform."
It doesn't produce Unicode *by default*.
"Windows has had some of the best non-english support of any OS since the NT 4.0 days"
And that's great if the user only uses one locale at the same time. Not when he needs many locales at the same time. On Linux I just set LC_ALL to anything I want and whola, all apps that I start on that console magically use that locale. On Windows I need to restart, and the setting applies to all applications. Furthermore, the Windows core uses UTF-16, which is not compatible with ASCII. This has led to many compatibility issues.
Not too long ago I was working on internationalization and localization support for my application. On Linux, it was a breeze. On Windows, I had to go through hell with workaround after workaround on top of compatibility layers.
Windows may support internationalization, but not easily. Linux does.
I don't consider this impressive at all. Linux has supported all of this since, what, 2004? Since 2002, with the coming of GTK 2 and QT 3, 99% of the Linux applications are fully Unicode-enabled (UTF-8). Since 2005, everything in Linux is UTF-8. I've been able to run Chinese and English environments side-by-side for years.
It seems that Windows is, again, the only operating system that falls behind. There are tons of often-used apps in Windows that are not Unicode-enabled. Writing Unicode-enabled applications is a huge pain in Windows because my application depends on output of other arbitrary applications (such as text files produced by Notepad) but not all of them produce Unicode output.
But frankly, most people just don't care. They don't understand Unicode. They just think, "I type Chinese/Japanese/whatever. You cannot read it so there is something wrong with your computer". Things like being able to run Japanese and English side by side, is something only 0.1% of the population truly cares about.
The reason why they have only 65000 people in the right parking spaces, is because they still use 16-bit identifiers to store the parking space IDs. DOS is not dead after all.
"Firstly your not considering the extra power consumed by the extra ram."
Actually, I am. The $14 extra per month (or one-time $150) that I pay my hosting provider includes power bills. For 500 machines it may matter, but in practice few non-technical people will actually care. Let's say I work in a company and I gave my manager two choices:
- "I'll spend the next 100 hours optimizing software, and I expect 33% memory savings."
- "I'll spend the next 100 hours developing productivity tools so that our future products' time-to-market will be lowered by 33%."
It's not hard to guess that he'll choose the latter.
Optimization doesn't happen in vacuum people. All the time that a developer spent/wasted on optimizing software, is time that he could have used to do something else, possibly something more economical.
"Remains to be seen"? Oh no.
I spent several months optimizing Ruby's garbage collector to be copy-on-write friendly, so that I can save more memory in my Ruby on Rails applications. I did this because I didn't want to spend an additional $14 per month (or a one-time payment of $150) for 1 GB more RAM in my server.
I spent at least 40 hours in research and development. If I had a fulltime job that pays $12 per hour, then I would have $480. It's obvious that hardware *is* cheaper than developer time.
Because the average user *wants* the installer to auto-run when they insert a CD, otherwise they'd panick and scream "OMG it doesn't work!"
And that's the problem with you people, all you do is complaining.
Now someone is actually doing his best to solve the sound problem instead of sitting around and complaining and doing nothing productive, and what do they get? MORE complaints. Get this into your head, nothing's going to happen if you complain and do nothing. The hard work is done by other people, for you, for free. The least you can do is show some respect.
It would become like Vista. Isn't that great? :D
"Not possible, or just not profitable?"
.NET framework is bigger on disk than the Java runtime."
.tar.gz with the source code. Most of my target groups consist of 99% Windows users and 1% Linux users so they're already used to software installers.
.FLD file editor. FLD files define walkable and non walkable blocks on a map in a game, and are typically 500 KB each. It would not be user friendly to ask the user to upload .FLD files to the web server and then using clucky JavaScript-based GUIs to manipulate the blocks, would it? This is why I chose to make it a client application. And since I'm a user myself, I chose to write it in C# and GtkSharp so that I can use it on Linux too.
FYI, I don't work for a software company. The "customers" I talked about were hypothetical.
"But in practice, the native library often has not been ported, or if it is, the end user cannot install it on the target system. The
That totally depend on the native library in question. I'm a Linux user and I love cross platform support, so I'll make sure that all the native libraries I use are portable.
The situation really isn't much different from writing C++ programs, or writing Python apps that make use of C libraries. In C++, you also have to make sure that your dependencies are portable. Dito with Python apps that use C libraries. Now, with C#, parts of the program are already portable, and if I choose to use native libraries, I just make sure that those are portable as well. So I really don't see the problem.
"But can GtkSharp applications be deployed over the Internet as easily as Java, SWF, or AJAX applications can?"
I deploy them by creating an installer for them and creating a
If the software in question can be a web application, then yes, I'll write a web application with PHP or Ruby on Rails or whatever. If easy web-based no-software-installation deployment is important for the software in question, then yes, I'll choose Java or Flash. If the functionality in question cannot be easily or efficiently implemented with the web platform, and my target group has a lot of Windows users, then C# is a good option. It all boils down to the right tool for the right job.
The last GtkSharp application I wrote is a
Ajax and Java are not C# killers, nor is C# a Java or Ajax killer - Ajax and Java are merely alternatives which may be more suitable in different situations.
"So what do you do when your bundled DLL is x86, but your customers suddenly ask for ARM? Or when your bundled DLL calls Win32 or WinCE, but your customers ask for Linux or Mac versions? If your program relies on unmanaged code that is not included as part of the .NET or Mono system libraries, then why are you using managed code in the first place?"
.NET app doesn't depend on any obvious Windows-specific things like Windows.Forms or the NTFS API, but does depend on native libraries, then theoretically you can run that app on both Windows and Linux, provided that the native library has been ported to both platforms.
I'll handle it like I'll handle any portability issue - port the code, or telling the customer that it's not possible.
I use managed code in the first place not because of portability, but because of developer productivity and maintenance benefits. C# is more high level language than say, C and C++. It does things like garbage collection. The C# languages has advantages over Java: delegates and closures come in mind.
Realistically speaking, 100% portability is almost never possible. You should have heard of the saying "write once, debug everywhere" about Java. Regardless of whether I use native libraries, I'll have to test the code on the target platform anyway. Things like hardcoded path delimiters can pose problems on portability. A while ago I wrote a Java application. I developed it mainly on Linux. Then I tested it on Windows and I noticed that the Swing GUI looks weird, so I had to fix things up a little. Some unit tests failed on Windows - turned out that it's because of a line ending issue (CRLF on Windows vs LF on Unix).
So suppose I don't use any native libraries at all. If customers ask me for an ARM version I'll still refuse, because I just don't have experience with ARM. I cannot guarantee that my application will run fine on an ARM because I don't have the ability to test it, even if Java/.NET claim to run on ARM. The best I could tell my customers is "use this at own risk" but I doubt they'd buy that.
"The majority of commercial off-the-shelf software publishers stating that Microsoft Windows is a required dependency for an application is exactly what got us into this mess."
I'm not sure what you mean by "this mess". If your
It has proven to work in practice. A while ago I wrote a GtkSharp application. The app ran on both Windows and Linux, without recompilation, because GtkSharp (which is a native library, which serves as a binding to GTK+) is available for Windows and Linux.
"By "C" I assume you mean "unmanaged code", not the common subset of the C language and C++/CLI."
Yes. Specifically, I'm referring to the [DllImport("foo")] syntax. This makes it very, very easy to import functions from a C library, without the need to write boilerplate binding code like I have to with, e.g., Perl, Python and Ruby. I realize that for Perl there's Win32::API, but it's not portable. [DllImport("foo")] works on the MS implementation and in Mono, on all supported platforms. In fact, GtkSharp uses DllImport to implement its GTK+ bindings.
"But how do you know what unmanaged libraries will be present on computer systems that you do not control?"
I don't. That's why I use DllImport only when I have to. Valid reasons for using DllImport could be:
- I need platform-specific integration.
- I need functionality that cannot be easily provided in C#, but can be easily provided in C or C++. In this case, I'll bundle the required libraries with my application.
Or I could specifically state that libfoo is a required dependency for my application.
Well, for me, C# is not a waste of effort. It has advantages over Java, for instance: .NET languages.
- Properties.
- Delegates.
- Structs.
- Easy integration with C libraries.
- VM-level generics support, making it easier to integrate with other
- Mono starts faster than the Sun JVM (or even GCJ for that matter).
- Ahead-of-time compilation with Mono.
- Language-integrated queries (LINQ).
"further Microsoft's stronghold over the market"? There is nothing to further, they already have 98% of the desktop market and even Apple can't make a significant dent in it. They can't be any more powerful than they already are.
"Because recreating the .Net framework should not be a requirement for writing GTK applications in a nicer way."
It isn't, has never been, and will never be a requirement. It is an extra alternative for those who prefer it, just like PyGTK and Java-GNOME.
"Would it not have been better to come up with something original, with some new ideas?"
Original != better. As they say, "good artists create, great artists copy". C# already has many good things: is similar to Java, but with a different VM design (generics implemented in VM instead of language), support for Delphi-style properties, language-integrated queries, partial classes, preprocessor support, structs, easy integration with C libraries, a large class library, etc. None of those things (except parts of the class library, like Windows.Forms) are Windows specific and are very well-suited for cross-platform, general purpose development. What's the point in rewriting all those things? Just to get rid of the "MS" label?
I couldn't care less whether a language is copied from something else, as long as it does the job well. They can copy all they want.
That's ridiculous, Python and Java don't make C# obsolete. That's like saying that there's a complete lack of need for Python because Perl and Ruby already exist. The only reason why people dislike C# is because it's created by MS.
So? Why should I care?
"Interoperability is one thing, writing Gnome components in .NET is quite another. The former is good while the latter is really bad."
.NET on Linux.
Why? It works, it's Unix-only and doesn't work on Windows, it allows developers to be productive. Seems like good reasons to use
"Because it's not possible to do that, and it's a fool's errand. All it's doing is following Microsoft's latest programming fad."
I've written GTK applications in C#, and it was a very pleasant experience. It allowed me to be productive in writing Linux applications. So just how is that "following Microsoft's latest programming fad"? Mono, as it is right now, is a very capable development environment even for Unix-only apps.
As AC pointed out, FUSE has been in the kernel for a while. I think more than a year now. FUSE and NTFS-3g are both enabled by default on Ubuntu Gutsy so most people have it by default.
I don't understand your logic at all. "My main concern [is] ... Mono would almost certainly make the same change, leaving a bunch of open-source developers to deal with the whims of Microsoft."
.NET backwards compatibility.
Just how will developers have to deal with the whims of Microsoft? So Microsoft decides to add a language-level assert statement, so what? All the open source C# software will happily keep running just like they did yesterday. Microsoft can't decide to break compatibility because they have too many enterprise customers depending on
That's X at fault, not the distros at fault. The problem is that XFree86 was so conservative, and wasn't very cooperative with contributors. Now that XFree86 has forked into X.org, development is finally speeding up again, and they're working hard on eliminating the need for a configuration file.