I think Linux desktop efforts will largely continue to be a flop when it comes to the consumer or corporate space. Oh, the Gnome and KDE GUIs are about as good as Windows at this point (my mother doesn't even see much difference between KDE in Windows mode and Windows), and the basic applications are fine for home users. But Windows is a money machine for small software houses, which can sell all sorts of expensive little add-ons without fear of being cloned out of existence; these people make up a cottage industry of Microsoft advocates and supporters. And corporations believe they can't live without Outlook and Word because that's what everybody else in the world is supposedly using and because the people in them have invested too much of their careers in it already. These basic dynamics are largely unaffected by the few other developments in Linux GUI space (Mono, etc.).
Another factor hindering Linux desktop adoption is motivation. Traditionally, open source software is developed by developers for people like themselves. They know what to do and what works for them. What's the motivation of people working on Gnome and KDE "for free"? Making a desktop usable by the Windows/Mac crowd is a labor of love, but even when doing such volunteer work, the Gnome and KDE programmers delight in customizability and complexity, not exactly a good feature in a mass market product.
But that's OK. If I wanted to use that kind of software, I would be using it. God knows, I have paid for it with every PC I bought.
If Linux is ever going to take over large chunks of the desktop market, I think it will be because of some radically and snazzy different new design that that by pure chance catches fire and becomes a fad.
You can get some pretty nifty 21"+ monitors, or even the Apple Studio Display. It's easy to make DVDs and broadcast signals appear on those. That's plenty large for personal viewing. With the money left over you can still buy a high quality large screen display for social viewing in large groups.
Where is YOUR common sense? Where are YOUR values? The police has limited resources, that's a fact. Should they spend a lot of time on what amounts to harmless teenage pranks that any responsible on-line business could protect themselves easily and cheaply from, businesses that make billions of dollars in profit? Or should the police spend their time on solving violent crimes, preventing violent crimes, and community outreach? To me the choice is clear. It is your values and your reasoning that, to me, seem completely out of touch with the real world.
There is already lots of software with a "business model". Even Microsoft ships open source software. Troll Tech ships GPL'ed software with a business model. But once there is a business model, people want to make profits. And experience suggests that it is easier to make profits through marketing, sales, dumbing things down for the mass market, and through FUD than through delivering innovative and quality software.
Thanks, but no thanks. I'll stick with open source software without a business model. I'm even suspicious of non-commercial open source efforts whose primary motivation seems to be for someone to get project lead experience or to collect lots of money from donations. And too many resources (including too many programmers) lead to projects that are overly complex (commercial software suffers from the same problem).
Open source software works best when it's done by a few tightly knit programmers working together, developing simple, innovative software. The megaprojects, the projects with commercial tie-ins, and all the other stuff, I can do without. If I wanted that, I wouldn't care about "open source", I'd just use the commercial stuff that I have already paid for.
IBM's desktop PCs have been losing money for years. The products are actually reasonably good, and support is not bad either. The main problem, I believe, is the poor marketing and packaging: their product line is very confusing, and their web site disorganized. As a mail-order supplier, their prices aren't quite good enough, and they aren't in enough (any?) stores.
ThinkPads are only selling because they really are a lot nicer than the competition in many cases. Customers put up with all the other problems in order to get them. But for desktops, there are plenty of alternatives.
If IIS, IE, and Outlook didn't have such gaping holes and weren't so market dominant, worms and viruses wouldn't be very destructive.
Worms and viruses are the equivalent of teenagers skateboarding in a China shop. Sure, technically, if they knock something over, they are responsible. But why the hell did the shop keeper allow skateboards in the shop in the first place?
It would be a sweet deal for Internet businesses to be able to have all their security-related costs to the public. But the people who should pay for Internet security are the ones benefitting from Internet business--the merchants and infrastructure providers. Putting this responsibility on the public amounts to a huge corporate welfare check for Microsoft and Internet businesses, who get to keep making profits without bearing the cost of security.
Terrorism implies creating terror. I'm sorry, but most people are simply not scared by the prospect of finding a virus attachment in their E-mail: it is both common and easily dealt with.
So, Mister Anonymous Coward, are you then an actual member of the Mono development effort? Is everybody on the Mono project as uninformed as you, or are you special?
Calm down, I also read the error-filled Sun/AlJazeera co-sponsored whitepaper on the evils of Microsoft delegates.
Gee, I haven't. In fact, the only stuff from Sun I ever look at is their API and JVM documentation, just like the only stuff from Microsoft I have looked at is their technical documentation on C# and the CLR. Do you spend all your time looking at white papers? No wonder you are so excited about C#/CLR: Microsoft has a lot of marketing experience.
How can you argue with that simplicity and efficiency?
I didn't say "MS delegates" were bad, I merely pointed out that Microsoft misnamed them. And if people writing a Java-based Mono project felt that they were important, they could have added them. As it turns out, in real life, Sun's alternative is just as good. But how would you know?
I would wager that you are reading this post this from a Windows-based browser (don't worry - your secret is safe with me).
Mozilla on Linux, actually. My job from time to time requires me to port to, and use, Windows. So, unfortunately, I have first-hand experience with the platform and its libraries.
Unfortunately, it doesn't quite work that way. For example, it is almost impossible to go to a restaurant and get anything non-alcoholic other than products from the Coca Cola or Pepsi companies. In many public areas, you have a choice of a bunch of generic chain restaurants where there used to be regional cuisine (sometimes bad, sometimes good, but at least different). Old culture does disappear when big corporations move into the neighborhood. You may be able to avoid it if you become a hermit, but for regular human beings who have a normal social life, it becomes impossible to avoid the bland culture imposed by a few big chains--the choices simply aren't realistically there anymore.
Cringely is completely missing the point. KLAT2 uses multiple routes and switches, not channel bonding. And what the project contributes is not the basic idea of using multiple network interfaces (which is decades old), but a specific approach: using genetic algorithms to optimize the network topology. More traditionally, such clusters have used manually designed topologies with known performance bounds.
Outside of games, there aren't many applications that really need much more compute power. The concept of needing a 1GHz CPU in a handheld to work on a spreadsheet, as suggested in the article, is idiotic.
It's only "idiotic" if you don't understand the applications. A 1GHz handheld can be used for better handwriting recognition, speech recognition, face recognition (from that little digital camera), data mining, decision support, text summarization, route planning, GIS, and data compression, to name only the obviously compute-intensive problems that occur on handhelds.
The extra speed can also be used to make it much easier to deliver high quality applications quickly and meet user needs better. It took Palm years of C programming to get decent and reliable little applets. Write the same stuff in Python or Java or some other HLL and you can do it in a few weeks and it won't crash.
The programmers would be forced to leave out unnecessary bloat and program efficiently.
We see the results of that kind of "efficiency": Windows, Word, KDE, and Gnome are all "efficiently" programmed in "efficient" programming languages like C and C++. The result is huge, brittle systems (why does Galeon still crash on exit after months and months of attempts to fix the bug?) that take forever to make it to market.
Program the same stuff in a VHLL and it may make the graphics a little slower, but it will be overall more reliable and more secure, and often more responsive as well.
The problem posed was recurring charges, not one-time real-time charges. Password protection would work this way: once a week/month, someone would walk up to the machine, run a virus check, verify the installation, sign off on a log, and then insert their smartcard into the machine. The server would use the smartcard to temporarily decrypt the CC information and post all the recurring charges to the CC processor. The benefit you gain is that you are guaranteed that security and logs are looked at by a person before any transactions go out.
Use firewalls, and keep a full-time computer-security staff (at least one person) to be responsible for managing the security.
Of course. And what I described is one of the approaches such a person could take if security is paramount (no server ports, manual checks before any information is decrypted).
Why don't you actually read about delegates and you'll find out first hand why Java's inner classes are not a substitute
Why don't you learn about patterns and figure out how to implement "Microsoft delegates" using standard object-oriented techniques (hint: because Microsoft language designers apparently didn't know their OOP basics, "MS delegates" are different from what is commonly called a "delegate", but there are other patterns corresponding to it.)
Please continue wrapping and unwrapping your Java builtin types by hand and write hundreds of lines of mind-numbingly tedious and error-prone code and all the time remind yourself what a noble pursuit it is - because your code is 100% Java(tm).
I don't have such a problem. The JVM supports more than 100 language frontends already. Some of those box/unbox automatically, others don't. They all work together very nicely in a way that is still just vaporware for CLR.
Deflect the point that Sun (a commercial entity) is the sole OWNER of Java and may choose to charge for its now supposedly "free" Java runtime
Who cares? There are open source Java compilers and runtimes that are a lot further along at implementing all of Java than Mono is at implementing C#/CLI/.NET. The fact that Sun makes available a good implementation is an added bonus.
Suckers like you will be left with your mouths gaping wide open asking "Why did Sun lie to us again?".
I have been using UNIX since 1980 and I have never had a problem with Sun's policies. They have contributed more to open source than most other companies. The "suckers" seem to me to be the ones who, after a decade of hardball Microsoft tactics and low-quality Microsoft software, still believe that Microsoft is up to any good.
Do yourself a favor and support an LGPLed standards-based Open Source effort like Mono to ensure software will be free both now and in the future.
If Mono ever gets up to the level of quality of Java, sure, I will consider it. The way it looks right now, that will be many, many years off, and any contributions to it seem like a waste of time. And if the history of the Gnome project is any guide, the people working on Mono will abandon it before it matures anyway.
Initially Java had a lot of grassroots support by Open Source developers until Sun renegged on the verbal promise to submit the Java language to ISO as well as EMCA. This basically showed that they have nothing but contempt for open source development.
Sun's decision had nothing to do with open source. Sun apparently felt that it was necessary to standardize the entire Java platform in order to be useful, and they felt they couldn't do that under ISO's or ECMA's conditions yet.
Microsoft got EMCA approval for C# and its libraries
Microsoft submitted a tiny fraction of the C# libraries for standardization. That isn't comparable to what Sun was doing. What Microsoft did cost them nothing in terms of control or intellectual property, but it was a great publicity stunt.
Sun where you only have a voice if you are a large computer firm that pays $250,000 per year to be heard/ignored in the poorly named "Java Community Process".
Who cares? You don't have to hack Sun's Java. You can hack an open source Java compiler and an open source Java runtime. To go off and start from scratch doing a partial clone of an incompletely specified Microsoft platform instead is throwing out the baby with the bathwater. Mono could be producing a fully backwards compatible, open source system based on Java with any enhancements they like, instead of whining about the JCP.
The CLR VM is also far more advanced than the Java VM from a technical point of view
You have fallen prey to Microsoft propaganda. I have seen no substantial technical enhancements in the CLR over the JVM (although there are a bunch of nice convenience features). And while Microsoft's CLR implementation also has some good parts, it is not as good as Sun's JVM.
and can more efficiently host non garbage collecting languages.
You can only efficiently support manual storage management if you are willing to sacrifice runtime safety. This has been beaten to death in the literature and in practical experiments, and the tradeoff isn't worth it. Just look at the recent experience with garbage collection in gcc to see that manual storage management is both less efficient and more error prone. (Incidentally, C and C++ semantics permit garbage collection, they just don't require it.)
CLR supports delegates which the Java VM has no equivalent.
That's a red herring. You can implement delegates efficiently without changes to the JVM. In fact, Sun considered doing this, but decided to go with nested classes instead. (As an aside, Microsoft's "delegates" have nothing to do with what is commonly understood by "delegates" in the OO literature.)
C# is simply more elegant than Java in a number of ways (such as automatically boxing builtin types for collections,
Automatic boxing/unboxing is an engineering tradeoff, not a question of elegance. Providing it makes it much easier to create performance bottlenecks accidentally. Neither Sun's nor Microsoft's choice is obviously better--it's more a question of psychology than technology.
The most important point is that Microsoft knows how to develop a polished piece of software.
Even if that were true (and I find the claim pretty ridiculous), what possible relevance does it have for Mono, since Mono isn't being developed by Microsoft?
Microsoft has not released a free CLR implementaion for other platforms, and what they have promised (if it ever arrives) is going to be a low-end implementation. Sun has released a high-performance implementation for Windows, Solaris, and Linux, with other platforms based on Sun's code.
Remember until the Sun/Microsoft Java lawsuit that it was Microsoft that had the fastest Java Virtual Machine - not Sun.
That's a myth. The Microsoft Java VM cut lots of corners, sacrificing compliance and safety, and a prerelease version was at some point faster than a delayed update of the JDK. Microsoft lost that temporary lead independent of the Sun lawsuit.
First to market does not necessarily win the race. Sorry, Sun, better luck next time.
Java has already has won the race; it's not going away (and Java wasn't first to market either--both Java and C#/CLR are based on about two decades of experience with other languages). The question is why Mono is getting in bed with Microsoft and picking the runner-up. Sun's support for open source may not be perfect but it has been quite good. Microsoft, however, has declared its fundamental hostility and opposition to open source efforts, and Microsoft, so far, has provided essentially nothing to anybody.
Well, the billing system needs to store the customer data in plaintext in order to present it to the remote machine. That, of course, makes it very vulnerable.
I should add that if you are really worried, you can store the data in encrypted form on the server and use manual intervention (smart card, password) for decrypting it and sending it to the credit card processor. Then, the machine can only be compromised when a human is present, and you could even ensure that multiple employees have to be present for billing, if you wanted to. But that's probably overkill for credit card numbers, which are not that hard to come by and protect consumers fairly well anyway.
Well, the billing system needs to store the customer data in plaintext in order to present it to the remote machine. That, of course, makes it very vulnerable.
I would probably choose an architecture that has a dedicated machine for just the periodic billing to the credit card processor. The machine would sit behind its own hardware firewall (real cheap now) and only be permitted to make outgoing connections (no open ports on the firewall). The web servers would gather updates to user information and make them available for pick-up by the dedicated machine; once picked up, they should get securely deleted from the web servers (keep the data off the disk, purge the swap partition periodically, worry about transaction logs).
The billing server needs to make backups of the billing information. It can encrypt those and push the encrypted data out. When the machine fails, as it will sooner or later, you can restore from the encrypted information outside the firewall.
You still need to ensure that the web servers themselves aren't compromised because otherwise people can collect data there as it is submitted by users, but you always have that problem. Personally, I like continuous monitoring of system files and network connections, together with automatic periodic reinstalls. You probably also should have independent sanity checks on the update records (check for size limits, etc.).
I'd strongly recommend not writing any of this stuff in C/C++ or Perl. In the former, the probability of pointer bugs or buffer overruns is too high, and in the latter, it's too easy to leave out error checking. I'd probably go with Java--it's not perfect, but it's mainstream and reasonably mature.
[machines will be 100x as fast, but] Software that's capable of taking advantage of all this processing muscle is nowhere in sight.
I find this fascinating. On the one hand, we have great programming languages, tools, and libraries whose only disadvantage compared to C, C++, Java, and C# is that they are maybe 10x slower. We have the processors to run them faster than we could run assembly a few years ago. Yet, whenever these new processors come out, everybody goes back, wastes lots of time tuning their C/C++ code and then complains that all those cycles are useless. There are still endless debates even in 2001 whether Gnome or KDE is faster. The Linux kernel developers don't even want to move to C++
Folks, those cycles are very useful. Not for some obscure technology that you know nothing about. They are very useful to let you program faster by worrying less about fine-tuning your software and for automating lots of tasks. They are very useful also for making programs safer and more robust automatically by eliminating common bugs like buffer overflows. And they are very useful for component-based software construction, which requires some form of runtime reflection--much better done automatically.
I just don't understand the dislike of the people involved in the Mono project of anything Java. The people involved in the Mono project already know that they won't be able to produce a fully compliant version of.NET because Microsoft won't release complete specs or a test suite. Functionally, C# and.NET offer no huge improvements over Java and the Java platform.
Now, what about Java? We have open source compilers (e.g., the KOPI kjc compiler), several runtimes (including the ORP runtime, which is quite good), and an open source batch compiler that allows exceptionally easy integration of C++ and Java (GNU gcj). We have lots of open source libraries in Java, more than 100 other language frontends, JNI interface generators (swig), XML libraries, web servers, and lots of tools. Unlike.NET, the Java platform is specified in great detail, with conformance test suites available (in comparison, Microsoft's ECMA submission is a publicity stunt with little real value). The few nice convenience features that C# and.NET have compared to Java could have been added as extensions to Java and its runtime as part of a GNU Java desktop project if people really felt they were necessary. GCC already has a frontend for Java that integrates very nicely with C++, giving developers a migration path from existing C++ code and allowing them to create stand-alone UNIX-style executables. And, unlike C#, Java is very widely taught in schools and at universities and very widely used in industry. And all that Java stuff was available in open source form a couple of years ago already.
Mono just strikes me as a serious case of NIH and people going off wanting to have fun with various new software toys. Well, that's OK, I suppose, it just isn't very utilitarian. OTOH, if this is the route by which Linux programmers finally move to languages and environments that are safe and support component-based software construction, I suppose it's better late than never.
But while.NET won't go away entirely, I believe Java still has the much brighter future, both in industry and in the open source community. You have a handful of open source programmers working impressively and very hard on Mono, but that still pales in comparison to probably thousands of active open source Java developers.
I think you are a little confused about the facts.
People using fsx found bugs in NFS, not security holes. Furthermore, by default, Sun and Linux machines do not export file systems, and NFS is not intended for use on unsecure networks (NFS is intrinsically not secure unless your network is secure, and this is documented). And neither Sun nor Linux are consumer operating systems--if you run them, you should know about proper system management and security.
Microsoft, in contrast, shipped a consumer operating system that, when used as intended, out of the box, was wide open to take-over over the Internet. They have done similar things in the past with browsers and other software. That's not a "little security flaw", it's a major goof.
Finally, both NFS and SMB came out of a closed source big corporate culture. They are both awful. The only reason they are still used is because of their corporate backing. You can blame Sun and Microsoft for that, not the open source community.
It's all a matter of where you put the "center". True, NPR is more left leaning than mainstream US media. But, then, from the perspective of much of the rest of the world, US mainstream media represent the far right fringe, while NPR is closer to a conservative public interest channel.
Altogether, I think we in the US should be glad that we have NPR. It has its problems, but it provides at least a little bit of balance in an otherwise very bleak media landscape.
Actually, lots of banks run both ATM machines and teller workstations off UNIX servers (they are also run off mainframes). So do numerous other large-scale government, information retrieval, and administrative systems. And so do large parts of the telephone network and voice-based services.
As for what "embedded systems" are and what they run, there is obviously a wide spectrum of them. Some don't run much of an OS. Others are full multitasking systems with GUIs, used for applications like data entry, high-end medical devices and scanners, surveillance, and vehicle control. Both NT and UNIX play in that space. When NT is used for those applications, a lot of its desktop heritage shows through; after all, what's the point of using NT if you don't use its "industry standard, advanced development environment (Visual C++)" as Microsoft likes to call it? This is usually not to NT's advantage.
I have written a lot of test cases in my time. I can't quite figure out why I would want to use QMTest.
First, I like writing test cases in a text editor, programmatically. It's tedious enough writing them in the first place, at least I can cut-and-paste and modify them quickly in an editor. Going through a web GUI does not seem like it's very efficient. Also, I don't particularly like using anything other than the implementation language and shell scripts for test cases; otherwise, people receiving the source code need to install additional tools. I also don't see anything in the white paper about support for the hard parts of testing, like configuration and compilation management for lots of extra C/C++ code, GUI testing, or web site testing (the latter usually require recording and playback).
Altogether, I'm not sure I ever felt I needed something like what QMTest seems to be doing. And the things that are actually difficult to test, it doesn't seem to provide useful support for. Can someone explain what I'm missing?
UNIX and Linux power the most usable devices in the world: ATM machines, embedded systems, public terminals, etc. Unlike Windows, Linux has a choice of real transacted file systems and can be completely robust to being powered off suddenly.
In order to achieve real usability and robustness, you need to customize systems. UNIX and Linux are up to it. With Windows, you get a one-size-fits-all user interface that works really well for nobody.
The real question should be: why are people justified with something as primitive and limited as Windows?
Slashdot Mirror
Another factor hindering Linux desktop adoption is motivation. Traditionally, open source software is developed by developers for people like themselves. They know what to do and what works for them. What's the motivation of people working on Gnome and KDE "for free"? Making a desktop usable by the Windows/Mac crowd is a labor of love, but even when doing such volunteer work, the Gnome and KDE programmers delight in customizability and complexity, not exactly a good feature in a mass market product.
But that's OK. If I wanted to use that kind of software, I would be using it. God knows, I have paid for it with every PC I bought.
If Linux is ever going to take over large chunks of the desktop market, I think it will be because of some radically and snazzy different new design that that by pure chance catches fire and becomes a fad.
You can get some pretty nifty 21"+ monitors, or even the Apple Studio Display. It's easy to make DVDs and broadcast signals appear on those. That's plenty large for personal viewing. With the money left over you can still buy a high quality large screen display for social viewing in large groups.
Where is YOUR common sense? Where are YOUR values? The police has limited resources, that's a fact. Should they spend a lot of time on what amounts to harmless teenage pranks that any responsible on-line business could protect themselves easily and cheaply from, businesses that make billions of dollars in profit? Or should the police spend their time on solving violent crimes, preventing violent crimes, and community outreach? To me the choice is clear. It is your values and your reasoning that, to me, seem completely out of touch with the real world.
Thanks, but no thanks. I'll stick with open source software without a business model. I'm even suspicious of non-commercial open source efforts whose primary motivation seems to be for someone to get project lead experience or to collect lots of money from donations. And too many resources (including too many programmers) lead to projects that are overly complex (commercial software suffers from the same problem).
Open source software works best when it's done by a few tightly knit programmers working together, developing simple, innovative software. The megaprojects, the projects with commercial tie-ins, and all the other stuff, I can do without. If I wanted that, I wouldn't care about "open source", I'd just use the commercial stuff that I have already paid for.
ThinkPads are only selling because they really are a lot nicer than the competition in many cases. Customers put up with all the other problems in order to get them. But for desktops, there are plenty of alternatives.
Worms and viruses are the equivalent of teenagers skateboarding in a China shop. Sure, technically, if they knock something over, they are responsible. But why the hell did the shop keeper allow skateboards in the shop in the first place?
It would be a sweet deal for Internet businesses to be able to have all their security-related costs to the public. But the people who should pay for Internet security are the ones benefitting from Internet business--the merchants and infrastructure providers. Putting this responsibility on the public amounts to a huge corporate welfare check for Microsoft and Internet businesses, who get to keep making profits without bearing the cost of security.
Terrorism implies creating terror. I'm sorry, but most people are simply not scared by the prospect of finding a virus attachment in their E-mail: it is both common and easily dealt with.
So, Mister Anonymous Coward, are you then an actual member of the Mono development effort? Is everybody on the Mono project as uninformed as you, or are you special?
Calm down, I also read the error-filled Sun/AlJazeera co-sponsored whitepaper on the evils of Microsoft delegates.
Gee, I haven't. In fact, the only stuff from Sun I ever look at is their API and JVM documentation, just like the only stuff from Microsoft I have looked at is their technical documentation on C# and the CLR. Do you spend all your time looking at white papers? No wonder you are so excited about C#/CLR: Microsoft has a lot of marketing experience.
How can you argue with that simplicity and efficiency?
I didn't say "MS delegates" were bad, I merely pointed out that Microsoft misnamed them. And if people writing a Java-based Mono project felt that they were important, they could have added them. As it turns out, in real life, Sun's alternative is just as good. But how would you know?
I would wager that you are reading this post this from a Windows-based browser (don't worry - your secret is safe with me).
Mozilla on Linux, actually. My job from time to time requires me to port to, and use, Windows. So, unfortunately, I have first-hand experience with the platform and its libraries.
Unfortunately, it doesn't quite work that way. For example, it is almost impossible to go to a restaurant and get anything non-alcoholic other than products from the Coca Cola or Pepsi companies. In many public areas, you have a choice of a bunch of generic chain restaurants where there used to be regional cuisine (sometimes bad, sometimes good, but at least different). Old culture does disappear when big corporations move into the neighborhood. You may be able to avoid it if you become a hermit, but for regular human beings who have a normal social life, it becomes impossible to avoid the bland culture imposed by a few big chains--the choices simply aren't realistically there anymore.
Cringely is completely missing the point. KLAT2 uses multiple routes and switches, not channel bonding. And what the project contributes is not the basic idea of using multiple network interfaces (which is decades old), but a specific approach: using genetic algorithms to optimize the network topology. More traditionally, such clusters have used manually designed topologies with known performance bounds.
It's only "idiotic" if you don't understand the applications. A 1GHz handheld can be used for better handwriting recognition, speech recognition, face recognition (from that little digital camera), data mining, decision support, text summarization, route planning, GIS, and data compression, to name only the obviously compute-intensive problems that occur on handhelds.
The extra speed can also be used to make it much easier to deliver high quality applications quickly and meet user needs better. It took Palm years of C programming to get decent and reliable little applets. Write the same stuff in Python or Java or some other HLL and you can do it in a few weeks and it won't crash.
We see the results of that kind of "efficiency": Windows, Word, KDE, and Gnome are all "efficiently" programmed in "efficient" programming languages like C and C++. The result is huge, brittle systems (why does Galeon still crash on exit after months and months of attempts to fix the bug?) that take forever to make it to market.
Program the same stuff in a VHLL and it may make the graphics a little slower, but it will be overall more reliable and more secure, and often more responsive as well.
Use firewalls, and keep a full-time computer-security staff (at least one person) to be responsible for managing the security.
Of course. And what I described is one of the approaches such a person could take if security is paramount (no server ports, manual checks before any information is decrypted).
Why don't you learn about patterns and figure out how to implement "Microsoft delegates" using standard object-oriented techniques (hint: because Microsoft language designers apparently didn't know their OOP basics, "MS delegates" are different from what is commonly called a "delegate", but there are other patterns corresponding to it.)
Please continue wrapping and unwrapping your Java builtin types by hand and write hundreds of lines of mind-numbingly tedious and error-prone code and all the time remind yourself what a noble pursuit it is - because your code is 100% Java(tm).
I don't have such a problem. The JVM supports more than 100 language frontends already. Some of those box/unbox automatically, others don't. They all work together very nicely in a way that is still just vaporware for CLR.
Deflect the point that Sun (a commercial entity) is the sole OWNER of Java and may choose to charge for its now supposedly "free" Java runtime
Who cares? There are open source Java compilers and runtimes that are a lot further along at implementing all of Java than Mono is at implementing C#/CLI/.NET. The fact that Sun makes available a good implementation is an added bonus.
Suckers like you will be left with your mouths gaping wide open asking "Why did Sun lie to us again?".
I have been using UNIX since 1980 and I have never had a problem with Sun's policies. They have contributed more to open source than most other companies. The "suckers" seem to me to be the ones who, after a decade of hardball Microsoft tactics and low-quality Microsoft software, still believe that Microsoft is up to any good.
Do yourself a favor and support an LGPLed standards-based Open Source effort like Mono to ensure software will be free both now and in the future.
If Mono ever gets up to the level of quality of Java, sure, I will consider it. The way it looks right now, that will be many, many years off, and any contributions to it seem like a waste of time. And if the history of the Gnome project is any guide, the people working on Mono will abandon it before it matures anyway.
Sun's decision had nothing to do with open source. Sun apparently felt that it was necessary to standardize the entire Java platform in order to be useful, and they felt they couldn't do that under ISO's or ECMA's conditions yet.
Microsoft got EMCA approval for C# and its libraries
Microsoft submitted a tiny fraction of the C# libraries for standardization. That isn't comparable to what Sun was doing. What Microsoft did cost them nothing in terms of control or intellectual property, but it was a great publicity stunt.
Sun where you only have a voice if you are a large computer firm that pays $250,000 per year to be heard/ignored in the poorly named "Java Community Process".
Who cares? You don't have to hack Sun's Java. You can hack an open source Java compiler and an open source Java runtime. To go off and start from scratch doing a partial clone of an incompletely specified Microsoft platform instead is throwing out the baby with the bathwater. Mono could be producing a fully backwards compatible, open source system based on Java with any enhancements they like, instead of whining about the JCP.
The CLR VM is also far more advanced than the Java VM from a technical point of view
You have fallen prey to Microsoft propaganda. I have seen no substantial technical enhancements in the CLR over the JVM (although there are a bunch of nice convenience features). And while Microsoft's CLR implementation also has some good parts, it is not as good as Sun's JVM.
and can more efficiently host non garbage collecting languages.
You can only efficiently support manual storage management if you are willing to sacrifice runtime safety. This has been beaten to death in the literature and in practical experiments, and the tradeoff isn't worth it. Just look at the recent experience with garbage collection in gcc to see that manual storage management is both less efficient and more error prone. (Incidentally, C and C++ semantics permit garbage collection, they just don't require it.)
CLR supports delegates which the Java VM has no equivalent.
That's a red herring. You can implement delegates efficiently without changes to the JVM. In fact, Sun considered doing this, but decided to go with nested classes instead. (As an aside, Microsoft's "delegates" have nothing to do with what is commonly understood by "delegates" in the OO literature.)
C# is simply more elegant than Java in a number of ways (such as automatically boxing builtin types for collections,
Automatic boxing/unboxing is an engineering tradeoff, not a question of elegance. Providing it makes it much easier to create performance bottlenecks accidentally. Neither Sun's nor Microsoft's choice is obviously better--it's more a question of psychology than technology.
The most important point is that Microsoft knows how to develop a polished piece of software.
Even if that were true (and I find the claim pretty ridiculous), what possible relevance does it have for Mono, since Mono isn't being developed by Microsoft?
Microsoft has not released a free CLR implementaion for other platforms, and what they have promised (if it ever arrives) is going to be a low-end implementation. Sun has released a high-performance implementation for Windows, Solaris, and Linux, with other platforms based on Sun's code.
Remember until the Sun/Microsoft Java lawsuit that it was Microsoft that had the fastest Java Virtual Machine - not Sun.
That's a myth. The Microsoft Java VM cut lots of corners, sacrificing compliance and safety, and a prerelease version was at some point faster than a delayed update of the JDK. Microsoft lost that temporary lead independent of the Sun lawsuit.
First to market does not necessarily win the race. Sorry, Sun, better luck next time.
Java has already has won the race; it's not going away (and Java wasn't first to market either--both Java and C#/CLR are based on about two decades of experience with other languages). The question is why Mono is getting in bed with Microsoft and picking the runner-up. Sun's support for open source may not be perfect but it has been quite good. Microsoft, however, has declared its fundamental hostility and opposition to open source efforts, and Microsoft, so far, has provided essentially nothing to anybody.
I should add that if you are really worried, you can store the data in encrypted form on the server and use manual intervention (smart card, password) for decrypting it and sending it to the credit card processor. Then, the machine can only be compromised when a human is present, and you could even ensure that multiple employees have to be present for billing, if you wanted to. But that's probably overkill for credit card numbers, which are not that hard to come by and protect consumers fairly well anyway.
I would probably choose an architecture that has a dedicated machine for just the periodic billing to the credit card processor. The machine would sit behind its own hardware firewall (real cheap now) and only be permitted to make outgoing connections (no open ports on the firewall). The web servers would gather updates to user information and make them available for pick-up by the dedicated machine; once picked up, they should get securely deleted from the web servers (keep the data off the disk, purge the swap partition periodically, worry about transaction logs).
The billing server needs to make backups of the billing information. It can encrypt those and push the encrypted data out. When the machine fails, as it will sooner or later, you can restore from the encrypted information outside the firewall.
You still need to ensure that the web servers themselves aren't compromised because otherwise people can collect data there as it is submitted by users, but you always have that problem. Personally, I like continuous monitoring of system files and network connections, together with automatic periodic reinstalls. You probably also should have independent sanity checks on the update records (check for size limits, etc.).
I'd strongly recommend not writing any of this stuff in C/C++ or Perl. In the former, the probability of pointer bugs or buffer overruns is too high, and in the latter, it's too easy to leave out error checking. I'd probably go with Java--it's not perfect, but it's mainstream and reasonably mature.
That wouldn't help. His system needs to present the plain-text data to some other system.
I find this fascinating. On the one hand, we have great programming languages, tools, and libraries whose only disadvantage compared to C, C++, Java, and C# is that they are maybe 10x slower. We have the processors to run them faster than we could run assembly a few years ago. Yet, whenever these new processors come out, everybody goes back, wastes lots of time tuning their C/C++ code and then complains that all those cycles are useless. There are still endless debates even in 2001 whether Gnome or KDE is faster. The Linux kernel developers don't even want to move to C++
Folks, those cycles are very useful. Not for some obscure technology that you know nothing about. They are very useful to let you program faster by worrying less about fine-tuning your software and for automating lots of tasks. They are very useful also for making programs safer and more robust automatically by eliminating common bugs like buffer overflows. And they are very useful for component-based software construction, which requires some form of runtime reflection--much better done automatically.
Now, what about Java? We have open source compilers (e.g., the KOPI kjc compiler), several runtimes (including the ORP runtime, which is quite good), and an open source batch compiler that allows exceptionally easy integration of C++ and Java (GNU gcj). We have lots of open source libraries in Java, more than 100 other language frontends, JNI interface generators (swig), XML libraries, web servers, and lots of tools. Unlike .NET, the Java platform is specified in great detail, with conformance test suites available (in comparison, Microsoft's ECMA submission is a publicity stunt with little real value). The few nice convenience features that C# and .NET have compared to Java could have been added as extensions to Java and its runtime as part of a GNU Java desktop project if people really felt they were necessary. GCC already has a frontend for Java that integrates very nicely with C++, giving developers a migration path from existing C++ code and allowing them to create stand-alone UNIX-style executables. And, unlike C#, Java is very widely taught in schools and at universities and very widely used in industry. And all that Java stuff was available in open source form a couple of years ago already.
Mono just strikes me as a serious case of NIH and people going off wanting to have fun with various new software toys. Well, that's OK, I suppose, it just isn't very utilitarian. OTOH, if this is the route by which Linux programmers finally move to languages and environments that are safe and support component-based software construction, I suppose it's better late than never.
But while .NET won't go away entirely, I believe Java still has the much brighter future, both in industry and in the open source community. You have a handful of open source programmers working impressively and very hard on Mono, but that still pales in comparison to probably thousands of active open source Java developers.
People using fsx found bugs in NFS, not security holes. Furthermore, by default, Sun and Linux machines do not export file systems, and NFS is not intended for use on unsecure networks (NFS is intrinsically not secure unless your network is secure, and this is documented). And neither Sun nor Linux are consumer operating systems--if you run them, you should know about proper system management and security.
Microsoft, in contrast, shipped a consumer operating system that, when used as intended, out of the box, was wide open to take-over over the Internet. They have done similar things in the past with browsers and other software. That's not a "little security flaw", it's a major goof.
Finally, both NFS and SMB came out of a closed source big corporate culture. They are both awful. The only reason they are still used is because of their corporate backing. You can blame Sun and Microsoft for that, not the open source community.
Altogether, I think we in the US should be glad that we have NPR. It has its problems, but it provides at least a little bit of balance in an otherwise very bleak media landscape.
As for what "embedded systems" are and what they run, there is obviously a wide spectrum of them. Some don't run much of an OS. Others are full multitasking systems with GUIs, used for applications like data entry, high-end medical devices and scanners, surveillance, and vehicle control. Both NT and UNIX play in that space. When NT is used for those applications, a lot of its desktop heritage shows through; after all, what's the point of using NT if you don't use its "industry standard, advanced development environment (Visual C++)" as Microsoft likes to call it? This is usually not to NT's advantage.
First, I like writing test cases in a text editor, programmatically. It's tedious enough writing them in the first place, at least I can cut-and-paste and modify them quickly in an editor. Going through a web GUI does not seem like it's very efficient. Also, I don't particularly like using anything other than the implementation language and shell scripts for test cases; otherwise, people receiving the source code need to install additional tools. I also don't see anything in the white paper about support for the hard parts of testing, like configuration and compilation management for lots of extra C/C++ code, GUI testing, or web site testing (the latter usually require recording and playback).
Altogether, I'm not sure I ever felt I needed something like what QMTest seems to be doing. And the things that are actually difficult to test, it doesn't seem to provide useful support for. Can someone explain what I'm missing?
In order to achieve real usability and robustness, you need to customize systems. UNIX and Linux are up to it. With Windows, you get a one-size-fits-all user interface that works really well for nobody.
The real question should be: why are people justified with something as primitive and limited as Windows?