So wait. What you're saying is that If I choose to develop my app as a modular set of libraries with a "shell" application that keeps everything together, that those libraries aren't part of my app? Even though I probably spend 99% of my time writing for my app in those libraries?
That makes no sense. MS wrote DirectShow as part of the Windows Media Player project. Just like MS wrote the HTML libraries in Windows as part of the IE project.
What you're saying is "We don't want you to ship the bit that anyone with VB and few stray hours could write, but all the rest must stay"?
Not really. Novell has a staff of support people who know the OS and apps inside and out because they sell that service to others. They simply tap into that for their own help desk support, which is subsidized by everyone that has bought a copy of SuSE or a support contract.
Sure, a large company will have a help desk, but not of the same calibre that a distro vendor would have.
You can't download a copy of SuSE for free, and there are licensing restrictions on some of the code on the CD's. Apparently, you can't even FTP install anymore.
True, they do have to pay someone to do the work, but that's a someone they have on staff anyways because they're providing support for others as well. Basically, everyone buying a copy of SuSE is paying Novell's support costs.
I hope you're right. SuSE has always had one big pain in the ass, and that's SuSEConfig. If you go in and edit files manually, it screws things up. This wouldn't be a problem if YaST weren't such a pig to run and you didn't have to outwit it to get the configuration you want.
Novell needs to come up with a truly easy to use configuration interface that doesn't overwrite config files and recognizes hand editing.
Ie, it needs to interpret the config files for each managed service and support all features, and do so without being a pig and taking forever to load.
Basically, if they want people to use their GUI tools, they need to actually work, even if you hand edit the files.
Microsoft would be laughing all the way to the bank?
Why should MS support a Mac and Windows version of Office with double the staff? Why not have one product for both? How do you think MS plans to make products for 64 bit versions of Windows? They're already using.NET heavily with SQL Server 2005 64 bit.
Microsoft can't just go changing the standard without breaking lots of client apps, and that's something MS won't tolerate (other than ones that compete with their own;)
I think what is meant is that you can say you saved $900,000 last year alone on MS licenses, but what did you pay in new costs to make up for it?
Now, Novell is in a unique situation. Since they own SuSE they don't have to pay SuSE license fees, so i'm sure that saves them a chunk of change, and they don't have to purchase service contracts because they're their own service facility.
While the core part of Office isn't likely to change anytime soon (too much legacy), Most new bits are being written in.NET. Check out the.NET Tools for Office, you can do some amazing shit with them.
An interpreter interprets code *EVERY* time it executes. A JIT compiles it once and executes compiled code that's no different than any other compiled code every time it executes.
Interpretation also occurs command by command. This creates an interpreter latency between each instruction, limiting the speed at which interpreted code can execute.
If you want to see a good example of interpreted vs JIT compiled, check out PearPC. PearPC offers two modes, one is straight emulation (or interpreting each instruction as it encounters them) and the other is a compiled cache. The first runs about 300x slower than a real computer, the second runs about 15x slower.
Conversely, name a product that's NOT Microsoft's that correctly implements them. Chances are, if there is one, it's not commonly used or more than an educational exercise.
MS's current C++ compiler is more standard compliant than GCC is, from my experience. Neither implement esoteric features like "export". Java isn't a standard, by the way.
You mean other than the 10x longer it would take to develop the C++ program? Statistics show that developers are 3-10x as productive with garbage collected languages such as Java and C# as they are with C++.
Further, as I said, one day it will require ZERO work to convert from legacy to Mono, as opposed to that 10-20% you will NEVER get rid of.
Yes, if you write code from scratch expecting it to be portable between Windows and Linux or other platforms, you can make it so.
What if you wrote code but didn't expect that? What if, later on, you decided you wanted to port to Linux, but you have 10 million lines of code targeted towards Windows?
If that code is written in.NET, you can use Mono to (one day) convert it without problem. Even today, you could convert it with only about 10-20% code modification.
Why is it that people like you always forget about legacy code? Now, granted, Most of a companies legacy code TODAY isn't going to be.NET based, but in a few years it might be.
If LISP were going to succeed, it would have done so by now. LISP is a fairly arcane language that has a very steep learning curve, especially compared to BASIC and C++. It's true that C++ can also get quite arcane in the more advanced features (Templates, STL, etc..) but basic useage is pretty easy to "get".
C# (and Java) have a huge advantage in that C++ programmers can pick it up relatively easily, and there are orders of magnitude more C++ programmers than LISP programmers.
Then don't use the Mono libraries that are copies of non-ISO standard MS libraries. Use GTK# instead of Windows forms, etc.
Mono is still a great environment even if you avoid the MS centric stuff. Remember, it's an ISO standard, and that requires reasonable and non-discriminatory licensing (RAND).
Mono isn't interpreted in the 1.1 release. Sure, they still include the mint interpreter for backwards compatibility but the default is to use the JIT compiler.
A C# front-end to Gcc might have some value for compiling programs so unwisely written in that language, but a bytecode interpreter seems just silly.
You seem to have a fundamental misunderstanding of.NET and Mono. While it's true that the first version of mono was interpreted, no version of MS's.NET ever has been and the most recent version of Mono does not interpret either. It uses JIT compilers to compile code at runtime as it's accessed.
This is actually a nice situation in some ways, since the JIT compiler knows more about the machine's runtime situation than a static compiler can.
For example, it can compile to 64 bit on 64 bit machines with zero changes in the source bytecode. It can also adapt to runtime situations (such as low memory conditions) more easily.
Of course this has the penalty of a slightly less responsive application the first time the code executes, but that's a small price to pay.
Lol. I love these kinds of conspiracy theories. They completely ignore the facts.
Microsoft is now wedded to.NET, whether it wants to or not. Longhorn's userland is now largely.NET based (WinFX) making.NET apps first class citizens of the OS. Core Longhorn technlogies such as Avalon and Indigo are written in.NET.
I think GTK# will end up being more useful because it's just a binding to GTK, and GTK is most likely getting a *LOT* more eyes on it than SWT because it's used in a lot more applications.
While you could certainly do that, you wouldn't have any of the support libraries, and you wouldn't gain the features of a virtual machine (Such as garbage collection, which is very difficult to do without a background VM controlling things).
You can already compile.NET code to native code using MS's ngen tool, but that won't reduce the dependancy on the CLR or the framework since those libraries have to be there to make the language useful.
Indeed. One area that Linux has woefully inadequate support for is contact management. The most recent version of Act! was completely rewritten in.NET. Though I doubt it runs right now (a very heavy dependance upon SQL Server and Windows forms) I'm sure the day will come when it will run unchanged.
There are a lot of people that would like Act on Linux.
Slashdot Mirror
So wait. What you're saying is that If I choose to develop my app as a modular set of libraries with a "shell" application that keeps everything together, that those libraries aren't part of my app? Even though I probably spend 99% of my time writing for my app in those libraries?
That makes no sense. MS wrote DirectShow as part of the Windows Media Player project. Just like MS wrote the HTML libraries in Windows as part of the IE project.
What you're saying is "We don't want you to ship the bit that anyone with VB and few stray hours could write, but all the rest must stay"?
Not really. Novell has a staff of support people who know the OS and apps inside and out because they sell that service to others. They simply tap into that for their own help desk support, which is subsidized by everyone that has bought a copy of SuSE or a support contract.
Sure, a large company will have a help desk, but not of the same calibre that a distro vendor would have.
You can't download a copy of SuSE for free, and there are licensing restrictions on some of the code on the CD's. Apparently, you can't even FTP install anymore.
True, they do have to pay someone to do the work, but that's a someone they have on staff anyways because they're providing support for others as well. Basically, everyone buying a copy of SuSE is paying Novell's support costs.
I hope you're right. SuSE has always had one big pain in the ass, and that's SuSEConfig. If you go in and edit files manually, it screws things up. This wouldn't be a problem if YaST weren't such a pig to run and you didn't have to outwit it to get the configuration you want.
Novell needs to come up with a truly easy to use configuration interface that doesn't overwrite config files and recognizes hand editing.
Ie, it needs to interpret the config files for each managed service and support all features, and do so without being a pig and taking forever to load.
Basically, if they want people to use their GUI tools, they need to actually work, even if you hand edit the files.
No corporation is going to trust their desktop to an FTP'd version. They're going to buy official licenses so that they get official support.
Microsoft would be laughing all the way to the bank?
.NET heavily with SQL Server 2005 64 bit.
;)
Why should MS support a Mac and Windows version of Office with double the staff? Why not have one product for both? How do you think MS plans to make products for 64 bit versions of Windows? They're already using
Microsoft can't just go changing the standard without breaking lots of client apps, and that's something MS won't tolerate (other than ones that compete with their own
I think what is meant is that you can say you saved $900,000 last year alone on MS licenses, but what did you pay in new costs to make up for it?
Now, Novell is in a unique situation. Since they own SuSE they don't have to pay SuSE license fees, so i'm sure that saves them a chunk of change, and they don't have to purchase service contracts because they're their own service facility.
While the core part of Office isn't likely to change anytime soon (too much legacy), Most new bits are being written in .NET. Check out the .NET Tools for Office, you can do some amazing shit with them.
An interpreter interprets code *EVERY* time it executes. A JIT compiles it once and executes compiled code that's no different than any other compiled code every time it executes.
Interpretation also occurs command by command. This creates an interpreter latency between each instruction, limiting the speed at which interpreted code can execute.
If you want to see a good example of interpreted vs JIT compiled, check out PearPC. PearPC offers two modes, one is straight emulation (or interpreting each instruction as it encounters them) and the other is a compiled cache. The first runs about 300x slower than a real computer, the second runs about 15x slower.
And of course, how many average programmers out there would actually do that? Not many.
Conversely, name a product that's NOT Microsoft's that correctly implements them. Chances are, if there is one, it's not commonly used or more than an educational exercise.
MS's current C++ compiler is more standard compliant than GCC is, from my experience. Neither implement esoteric features like "export". Java isn't a standard, by the way.
It is, it's also an ISO standard.
You mean other than the 10x longer it would take to develop the C++ program? Statistics show that developers are 3-10x as productive with garbage collected languages such as Java and C# as they are with C++.
Further, as I said, one day it will require ZERO work to convert from legacy to Mono, as opposed to that 10-20% you will NEVER get rid of.
No, "the dubious developers" means "the doubtful developers", not that the developers are doubted.
Yes, if you write code from scratch expecting it to be portable between Windows and Linux or other platforms, you can make it so.
.NET, you can use Mono to (one day) convert it without problem. Even today, you could convert it with only about 10-20% code modification.
.NET based, but in a few years it might be.
What if you wrote code but didn't expect that? What if, later on, you decided you wanted to port to Linux, but you have 10 million lines of code targeted towards Windows?
If that code is written in
Why is it that people like you always forget about legacy code? Now, granted, Most of a companies legacy code TODAY isn't going to be
If LISP were going to succeed, it would have done so by now. LISP is a fairly arcane language that has a very steep learning curve, especially compared to BASIC and C++. It's true that C++ can also get quite arcane in the more advanced features (Templates, STL, etc..) but basic useage is pretty easy to "get".
C# (and Java) have a huge advantage in that C++ programmers can pick it up relatively easily, and there are orders of magnitude more C++ programmers than LISP programmers.
Then don't use the Mono libraries that are copies of non-ISO standard MS libraries. Use GTK# instead of Windows forms, etc.
Mono is still a great environment even if you avoid the MS centric stuff. Remember, it's an ISO standard, and that requires reasonable and non-discriminatory licensing (RAND).
Mono isn't interpreted in the 1.1 release. Sure, they still include the mint interpreter for backwards compatibility but the default is to use the JIT compiler.
A C# front-end to Gcc might have some value for compiling programs so unwisely written in that language, but a bytecode interpreter seems just silly.
.NET and Mono. While it's true that the first version of mono was interpreted, no version of MS's .NET ever has been and the most recent version of Mono does not interpret either. It uses JIT compilers to compile code at runtime as it's accessed.
You seem to have a fundamental misunderstanding of
This is actually a nice situation in some ways, since the JIT compiler knows more about the machine's runtime situation than a static compiler can.
For example, it can compile to 64 bit on 64 bit machines with zero changes in the source bytecode. It can also adapt to runtime situations (such as low memory conditions) more easily.
Of course this has the penalty of a slightly less responsive application the first time the code executes, but that's a small price to pay.
Lol. I love these kinds of conspiracy theories. They completely ignore the facts.
.NET, whether it wants to or not. Longhorn's userland is now largely .NET based (WinFX) making .NET apps first class citizens of the OS. Core Longhorn technlogies such as Avalon and Indigo are written in .NET.
.NET anytime soon.
Microsoft is now wedded to
MS isn't dumping
I think GTK# will end up being more useful because it's just a binding to GTK, and GTK is most likely getting a *LOT* more eyes on it than SWT because it's used in a lot more applications.
While you could certainly do that, you wouldn't have any of the support libraries, and you wouldn't gain the features of a virtual machine (Such as garbage collection, which is very difficult to do without a background VM controlling things).
.NET code to native code using MS's ngen tool, but that won't reduce the dependancy on the CLR or the framework since those libraries have to be there to make the language useful.
You can already compile
Indeed. One area that Linux has woefully inadequate support for is contact management. The most recent version of Act! was completely rewritten in .NET. Though I doubt it runs right now (a very heavy dependance upon SQL Server and Windows forms) I'm sure the day will come when it will run unchanged.
There are a lot of people that would like Act on Linux.
dubious ( P ) Pronunciation Key (db-s, dy-)
adj.
Fraught with uncertainty or doubt; undecided.
Arousing doubt; doubtful: a dubious distinction.
Of questionable character: dubious profits.
You seem to be implying the third definition, while the author seems to be implying the second.