At present it has tanked > 7% which is at the $4.00 mark. Given the severity of the news, I would have expected it to take a dump a lot further than that - 7% is severe but stocks have lost more than that for relatively minor or unfathomable reasons before now.
A set of binaries that allow you to run Windows programs on x86 Linux.
Headers, source and libraries that allow you to compile Win32 applications to run as native executables on *nix systems.
The Win32 API is a big mess of APIs living in various DLLs with apps requiring files and the registry to be structured like its Windows counterpart. Clearly Microsoft have discovered that there is a registry key in WINE that does not exist in normal Win32 apps and have decided to dump out a vague error when they detect it.
The reason I suspect they don't like WINE is that its reached a level of maturity which means that major applications run just fine under it. In fact Mono uses WINE as well to deal with the large number of tainted.NET application.
I still don't get it. Surely they should be scrambling to get players any way they can. What do they care if someone grabs it from the net or from a store?
If they're *that* concerned it will cut into sales they could charge a nominal $5 "new key" fee or for the downloaders. I bet after you deduct distribution costs, printing, returns and the middle man they're not making much more than $15 from the store copy anyway. So $5 plus $15 for a months sub makes a downloaded signup even more profitable than if they'd sold it off the shelves.
To be honest, I'm a bit confused as to why you think your legacy C++ code and your decision to embed it all in your.NET products reflect badly on Mono.
I'm not dissing Mono except to say that this is the kind of junk it will have to handle. Granted this is an extreme case, but I'm not aware of a single in-house.NET project which doesn't target Win32 with Mono as non-existent or faint target on the radar. Consequently, they'll all be tainted in some way or another - be it the use of COM interop, PInvoke, MS SQL or whatever.
Even Microsoft doesn't care about cross-platform calls. They just released an Enterprise Library that contains no fewer than 16 imported Win32 function calls that are called 44 times directly.
If Mono and its stack could be made more prominent to.NET developers it would go a whole way towards putting it onto the radar. Even MS can't ignore it if half their customers are screaming at them for releasing crap ware that doesn't work with it. My suggestion concerning wizards etc. was one way I see of that happening.
Yes, but Mozilla already had string and collection classes by the time.NET 2002 turned up with a decent STL so there was no point.
Even if someone were to try to port to STL as an exercise, they would quickly realise that each implementation would be grossly inefficient compared to the existing classes and that fixes for one implementation wouldn't work in another.
For example, the Dinkum / VS2002 basic_string implementation allocates memory for strings over 16 bytes (i.e. 16 chars or 8 wchar_ts). Mozilla has an explicit class for stack based strings, and it would be next to impossible to engineer the Dinkum class to support larger stack strings, short of hacking that header with the appropriate changes or cutting and pasting an substantially similar class with a different memory management routine.
And that's just one class. You'd have to repeat for VS2003, plus all popular implementations of libstdc++. And by the end of which you're left with code which is no more efficient than the existing code, but is considerably more bloated due to excessive inlining, rtti & exceptions.
Sadly Mozilla doesn't have the luxury of running on "any decent compiler". While a good number of hosts use gcc 2.95 or cl.exe 12.x it has to support them.
Sorry if I sound skeptical, but I'm involved in.NET projects too within a company that is predominantly Java & C++. For them the qualities they look for are reliability and stability. They don't care that the language is syntactically nicer - just that when they start the thing up, it doesn't stop until they take it down to add more features. Thus they use Java on the server side because it is rock solid. A highly desirable side effect of course is that they can take that code and move it from one box to another, one J2EE impl to another with minor to fair amounts of effort (fixing config files and such). Thus they're shifting a bunch of stuff from Solaris over to Red Hat Linux.
Despite that, management have caught the.NET bug for client applications. This is where Java is weak. JFC might be great on paper, but it just blows as far as performance is concerned, looks weird even with a theme engine and is just plain difficult to programme. Eclipse & SWT demonstrate that a Java UI doesn't have to be such a pain, but SWT hasn't really spun off into something that 3rd party apps can rely on yet.
So traditionally we've always coded C++ on the client side. There's nothing wrong with that in my book, but management have been sold on the idea that.NET will increase product stability and lessen development times. Which is great except they've decided we will migrate by wrapping the old legacy code with managed classes and use a.NET based UI. Thus we get the instability of C++ and the overhead of.NET! The alternative would be to rewrite the product entirely in.NET which would take years.
Thus my skepticism about Mono. The real world (and the world Microsoft wants) has lots of unsafe and unmanaged code tied together with.NET. Unless Mono links to the whole of winelib and provides x86 emulation for non-x86 hosts, this code will never run outside of Win32. To cap it off, our app executes code in MS SQL, so we have yet another dependency. We have no intention of testing on Mono and I sincerely doubt it would work even if we tried.
That's the real world. Mono isn't on the radar and never will be while it's considered some sideshow. The onus will always be on Mono to cope with whatever crap gets flung at it and not the other way around. Thus my belief is they need to push the great stuff they have so it is shown on the same level as the Microsoft code. If GTK# and other open stack APIs are made easy to develop and run from Dev Studio.NET 2003 it might sway someone sufficiently to use them in some major projects. Word will get around soon enough.
I don't think.NET programmers are shy of good open source libraries (NUnit, Log4Net & Spring.NET are popular ports from Java), but they have to work in the first place for people to bother with them.
GTK plainly sucks for development. No, really, I tried, and it's worse than MFC. GTK is a C API. If you don't like it, use a binding such as gtkmm or wxWidgets. Basically it can live underneath any API you care for it.
Windows.Form is THE thing that will allow true Linux WIndows portability. And it's a good widget library.. It's good but many apps end up PInvoking Win32 because Windows.Forms doesn't do something they need. Thus it isn't that portable. Even a full implementation of Windows.Forms won't do you much good for a program that makes a single call to Win32, or which drags in some "safe" C++ compiled native DLL. But getting back to Windows.Forms, it exposes some particularly non-portable things such as WndProc, windows messages etc.
.NET is better than Java in my opinion. The CLR & core are architecturally cleaner, but Java kicks seven shades of shit out of.NET when it comes to sheer breadth of implementations, platforms, 3rd party libraries, enterprise level specifications and so on.
I'm in no doubt that Mono is a good thing, but neither.NET nor Mono offer anything remotely as compelling as Java at the moment at least in the enterprise domain. Let's see Mono go through a birth of fire on the desktop first.
Speaking of which, I see a lot of potential there (after all half the system tools in most dists are python / perl etc. with bindings). But Mono really has to start encouraging people other than Linux users to use the open source stack - even.NET users. That means producing an installer containing the stack with some wizards & designers so that Visual Studio.NET users can use them with ease.
No it's not paranoia. It's a legitimate problem that digital signing is there to detect. You might ask how this relates to Firefox, well consider this.
By default Firefox automatically checks for updates for itself and its extensions. Therefore on any one day there could potentially be a million browsers calling home for updates. If a hacker could crack the site, or redirect DNS lookups to their own bogus updates.mozilla.org, they could compromise tens of thousands of machines if not more before anyone noticed any different.
You tell me that is paranoia. You tell me that any cracker wouldn't give their right eye to own an automated update service, be it for Mozilla, Red Hat, Microsoft or anyone else. The updates mechanism is an obvious attack vector.
At least with digital signing it would allow packages to checked for authenticity first. For example if updates.mozilla.org claims there is a new.xpi update patch for Firefox, that patch should be signed by mozilla.org. Firefox should ignore patches that are *not* signed. The same goes for extensions - if the new extension is not signed with the same key as the older version, it should not be updated.
As for the user not being stupid... You tell me how a user is meant to know that when Firefox says an extension has an update, that it's really a trojan. There's no signature, so how are they meant to know? If updates.mozilla.org says it's new, why shouldn't they trust it?
Firefox is using domain trust as a poor man's code signing.
It doesn't do you much good if the site in question has been hacked or is subject to a man in the middle attack. You as the user have no idea in either case if that extension has been tampered with because it has no signature.
Neither domain trust work well when the domain in question hosts hundreds of controls. For example, once you've trusted the Mozilla extensions website, the domain check is not going to protect you from downloading something malicious.
Personally I believe signing should be in addition to the domain check with future versions of firefox supporting GPG signing. Also, the mozilla extension site should crack open xpi files so interested people can browse inside it.
Nothing is going to be a magic bullet, but the mantra should be safe by default, with enough checks and safeguards to quickly identify and zap anything malicious.
Because signing means that if you download (for example) the Yahoo toolbar you can see and inspect the signature against it and determine it really was written by Yahoo. If some cracker decides to tamper with the XPI package, it will be immediately obvious, because either there will be no signature or Firefox will warn you that the Yahoo signature does not correspond with the contents.
Without the signature, you haven't the faintest idea who wrote that XPI or if its been tampered with.
That's not the point. The point is that the version of STL that ships with Visual C++ is different and behaves differently from the version that ships with GNU libc++ which is different and behaves differently from [insert commercial Unix compiler here]. Even versions of the same STL library differ (e.g. comparing VC98 to VC2002). Reconciling those differences (and incompatibilities) in Mozilla is a waste of time. Mozilla has to build a broad range of platforms, not just the small fraction that possess sane STL implementations.
For example, the STL that ships with VC98 is atrociously inefficient and non-compatible. It doesn't even support fundamental methods such as basic_string::clear. The string buffer allocation reallocs the buffer in fixed 16 byte increments - just imagine what that does for performance. I'm sure libstdc++ has had similar problems in various iterations too.
It's no good either to suggest moving to.NET 2002 or later (which does have better STL), since these decisions were made before such a product even existed. Nor can you insist that everyone in Unix-land upgrade either since they often don't have the choice. Besides, Mozilla now has extremely mature and robust string and collection classes of its own which negates any reason to use anything else. Not only are they mature but they're tailored for multiple purposes. For example, the string classes come in several flavours for handling stack and heap based memory allocations - no such concept exists in STL. There are other flavours for dealing with nsIMemory allocated buffers and so on.
Using STL would be to replace these classes with bloaty and general purpose classes from varying and incompatible implementations. It would be a lot of effort and would make the executable considerably more inefficient and larger than it already is. And to even use STL would require enabling rtti & exception handling on Mozilla which would bloat the code by another 25%.
The thing though is, that at least IE insists controls be signed. Firefox does not insist that extensions be signed.
Now controls are unarguably the bigger danger, but that does not excuse the weak security defaults that Firefox uses for extensions. A user can install any extension without a clue as to who wrote it, or even if it was tampered with. The default policy should be accept signed extensions and not accept unsigned ones at all. If people want to change that preference, that's their own business, but secure by default should still be the order of the day.
Take a look at what Mozilla does. Basically it uses the same build system (& autoconf script) for Unix and Win32 but it invokes gcc (or cc / icc etc.) on Unix and cl on Win32. It manages this trick by using lots and lots of macros - project makefiles use macros to specify paths, libs, targets etc. and pull in global rule files to turn these into compiler switches.
Building on multiple compilers also requires writing code to the subset of functionality common to all of them and avoiding dangerous stuff like STL / exceptions etc. Instead of STL, Mozilla uses its own string classes and portable functionality for threads, collections, memory allocation etc. exposed by the NSPR.
To be frank, those things are trivial to fix and can be expected when moving any Unix program to some other platform. Once a program goes through a few iterations, gains an autoconf script and some maintainers, it will build and run happily on lots of platforms.
Contrast that with Win32 vs Linux where the API is different, the compiler is different, the build system is different, the underlying OS is totally different etc.
Yesterday I received 7 email viruses. And a similar number the day before that and the day before, etc. going back two years or more. I have to install a firewall on my machine before plugging it into the internet because I could be instantly rooted. I have to buy and run anti-virus software all the time and anti-spyware tools weekly to ensure that I haven't picked up something nasty. I can't use the MS supplied tools for email or web browsing because they are basically attack vectors.
In short, if I used Microsoft Windows without protecting it with a whole a bunch of 3rd party products and lots of diligence, it would be a steaming spyware infested heap at this moment. Which is clearly what a great number of machines are.
Even protecting yourself is not perfect. First it costs money - maybe as much as the OS itself to protect it properly. And having to run all that software impacts machine performance. I would not be surprised if the anti-virus scanner alone eats up 5-15% of file performance all by itself.
Anyone who claims Windows is safer than *any* other operating system clearly isn't living in the real world.
An application is generally considered to be a program with a user interface. Most people would reasonably expect a book with a title Linux Application Development to cover development of such programs. It doesn't.
Perhaps the distinction wasn't so obvious in 1998 or whenever the first edition came out, but it is now.
Fedora does contain console apps such as vi, emacs, mc, etc. that run through curses and respond to user input, but the vast majority are GUI based applications.
Command-line programs like grep, ls etc. are tools, not applications. Programs like sshd, inetd, apache etc. are daemons, not applications.
I would expect a book about application development to concern itself with such matters as how to create a window, draw buttons, respond to keystrokes, draw graphics and well... how to write applications. As in, how to write graphic user interface programs. That is what most people would interpret the title to mean.
While such things as pipes, regular expressions, setting date & time etc. are all fundamentals of any kind of programming, it seems a more apt name for the book would be Linux Command-Line Application Development, or Linux Daemon Development.
From reading the blog, it sounds like the ass thought that blogging was some magical medium completely immune from the usual rules concerning disclosing confidential or sensitive company information.
Slashdot Mirror
According to the news release, they'll be delisted on February 25 - i.e. one full week from now unless they appeal.
At present it has tanked > 7% which is at the $4.00 mark. Given the severity of the news, I would have expected it to take a dump a lot further than that - 7% is severe but stocks have lost more than that for relatively minor or unfathomable reasons before now.
The Win32 API is a big mess of APIs living in various DLLs with apps requiring files and the registry to be structured like its Windows counterpart. Clearly Microsoft have discovered that there is a registry key in WINE that does not exist in normal Win32 apps and have decided to dump out a vague error when they detect it.
The reason I suspect they don't like WINE is that its reached a level of maturity which means that major applications run just fine under it. In fact Mono uses WINE as well to deal with the large number of tainted
If they're *that* concerned it will cut into sales they could charge a nominal $5 "new key" fee or for the downloaders. I bet after you deduct distribution costs, printing, returns and the middle man they're not making much more than $15 from the store copy anyway. So $5 plus $15 for a months sub makes a downloaded signup even more profitable than if they'd sold it off the shelves.
What does it matter to them where someone gets the game so long as they've slapped the money down to play it?
And since the beta was a .torrent, it's not like it would eat up their bandwidth either.
I'm not dissing Mono except to say that this is the kind of junk it will have to handle. Granted this is an extreme case, but I'm not aware of a single in-house
Even Microsoft doesn't care about cross-platform calls. They just released an Enterprise Library that contains no fewer than 16 imported Win32 function calls that are called 44 times directly.
If Mono and its stack could be made more prominent to
Even if someone were to try to port to STL as an exercise, they would quickly realise that each implementation would be grossly inefficient compared to the existing classes and that fixes for one implementation wouldn't work in another.
For example, the Dinkum / VS2002 basic_string implementation allocates memory for strings over 16 bytes (i.e. 16 chars or 8 wchar_ts). Mozilla has an explicit class for stack based strings, and it would be next to impossible to engineer the Dinkum class to support larger stack strings, short of hacking that header with the appropriate changes or cutting and pasting an substantially similar class with a different memory management routine.
And that's just one class. You'd have to repeat for VS2003, plus all popular implementations of libstdc++. And by the end of which you're left with code which is no more efficient than the existing code, but is considerably more bloated due to excessive inlining, rtti & exceptions.
Sadly Mozilla doesn't have the luxury of running on "any decent compiler". While a good number of hosts use gcc 2.95 or cl.exe 12.x it has to support them.
Despite that, management have caught the .NET bug for client applications. This is where Java is weak. JFC might be great on paper, but it just blows as far as performance is concerned, looks weird even with a theme engine and is just plain difficult to programme. Eclipse & SWT demonstrate that a Java UI doesn't have to be such a pain, but SWT hasn't really spun off into something that 3rd party apps can rely on yet.
So traditionally we've always coded C++ on the client side. There's nothing wrong with that in my book, but management have been sold on the idea that .NET will increase product stability and lessen development times. Which is great except they've decided we will migrate by wrapping the old legacy code with managed classes and use a .NET based UI. Thus we get the instability of C++ and the overhead of .NET! The alternative would be to rewrite the product entirely in .NET which would take years.
Thus my skepticism about Mono. The real world (and the world Microsoft wants) has lots of unsafe and unmanaged code tied together with .NET. Unless Mono links to the whole of winelib and provides x86 emulation for non-x86 hosts, this code will never run outside of Win32. To cap it off, our app executes code in MS SQL, so we have yet another dependency. We have no intention of testing on Mono and I sincerely doubt it would work even if we tried.
That's the real world. Mono isn't on the radar and never will be while it's considered some sideshow. The onus will always be on Mono to cope with whatever crap gets flung at it and not the other way around. Thus my belief is they need to push the great stuff they have so it is shown on the same level as the Microsoft code. If GTK# and other open stack APIs are made easy to develop and run from Dev Studio .NET 2003 it might sway someone sufficiently to use them in some major projects. Word will get around soon enough.
I don't think .NET programmers are shy of good open source libraries (NUnit, Log4Net & Spring.NET are popular ports from Java), but they have to work in the first place for people to bother with them.
I would assume that Firefox has learnt it's mistake from the last IDnames exploit and do something to highlight such tricks.
GTK is a C API. If you don't like it, use a binding such as gtkmm or wxWidgets. Basically it can live underneath any API you care for it.
It's good but many apps end up PInvoking Win32 because Windows.Forms doesn't do something they need. Thus it isn't that portable. Even a full implementation of Windows.Forms won't do you much good for a program that makes a single call to Win32, or which drags in some "safe" C++ compiled native DLL. But getting back to Windows.Forms, it exposes some particularly non-portable things such as WndProc, windows messages etc.
The CLR & core are architecturally cleaner, but Java kicks seven shades of shit out of
I'm in no doubt that Mono is a good thing, but neither .NET nor Mono offer anything remotely as compelling as Java at the moment at least in the enterprise domain. Let's see Mono go through a birth of fire on the desktop first.
Speaking of which, I see a lot of potential there (after all half the system tools in most dists are python / perl etc. with bindings). But Mono really has to start encouraging people other than Linux users to use the open source stack - even .NET users. That means producing an installer containing the stack with some wizards & designers so that Visual Studio .NET users can use them with ease.
By default Firefox automatically checks for updates for itself and its extensions. Therefore on any one day there could potentially be a million browsers calling home for updates. If a hacker could crack the site, or redirect DNS lookups to their own bogus updates.mozilla.org, they could compromise tens of thousands of machines if not more before anyone noticed any different.
You tell me that is paranoia. You tell me that any cracker wouldn't give their right eye to own an automated update service, be it for Mozilla, Red Hat, Microsoft or anyone else. The updates mechanism is an obvious attack vector.
At least with digital signing it would allow packages to checked for authenticity first. For example if updates.mozilla.org claims there is a new
As for the user not being stupid... You tell me how a user is meant to know that when Firefox says an extension has an update, that it's really a trojan. There's no signature, so how are they meant to know? If updates.mozilla.org says it's new, why shouldn't they trust it?
It doesn't do you much good if the site in question has been hacked or is subject to a man in the middle attack. You as the user have no idea in either case if that extension has been tampered with because it has no signature.
Neither domain trust work well when the domain in question hosts hundreds of controls. For example, once you've trusted the Mozilla extensions website, the domain check is not going to protect you from downloading something malicious.
Personally I believe signing should be in addition to the domain check with future versions of firefox supporting GPG signing. Also, the mozilla extension site should crack open xpi files so interested people can browse inside it.
Nothing is going to be a magic bullet, but the mantra should be safe by default, with enough checks and safeguards to quickly identify and zap anything malicious.
Without the signature, you haven't the faintest idea who wrote that XPI or if its been tampered with.
For example, the STL that ships with VC98 is atrociously inefficient and non-compatible. It doesn't even support fundamental methods such as basic_string::clear. The string buffer allocation reallocs the buffer in fixed 16 byte increments - just imagine what that does for performance. I'm sure libstdc++ has had similar problems in various iterations too.
It's no good either to suggest moving to .NET 2002 or later (which does have better STL), since these decisions were made before such a product even existed. Nor can you insist that everyone in Unix-land upgrade either since they often don't have the choice. Besides, Mozilla now has extremely mature and robust string and collection classes of its own which negates any reason to use anything else. Not only are they mature but they're tailored for multiple purposes. For example, the string classes come in several flavours for handling stack and heap based memory allocations - no such concept exists in STL. There are other flavours for dealing with nsIMemory allocated buffers and so on.
Using STL would be to replace these classes with bloaty and general purpose classes from varying and incompatible implementations. It would be a lot of effort and would make the executable considerably more inefficient and larger than it already is. And to even use STL would require enabling rtti & exception handling on Mozilla which would bloat the code by another 25%.
Now controls are unarguably the bigger danger, but that does not excuse the weak security defaults that Firefox uses for extensions. A user can install any extension without a clue as to who wrote it, or even if it was tampered with. The default policy should be accept signed extensions and not accept unsigned ones at all. If people want to change that preference, that's their own business, but secure by default should still be the order of the day.
Building on multiple compilers also requires writing code to the subset of functionality common to all of them and avoiding dangerous stuff like STL / exceptions etc. Instead of STL, Mozilla uses its own string classes and portable functionality for threads, collections, memory allocation etc. exposed by the NSPR.
Contrast that with Win32 vs Linux where the API is different, the compiler is different, the build system is different, the underlying OS is totally different etc.
In short, if I used Microsoft Windows without protecting it with a whole a bunch of 3rd party products and lots of diligence, it would be a steaming spyware infested heap at this moment. Which is clearly what a great number of machines are.
Even protecting yourself is not perfect. First it costs money - maybe as much as the OS itself to protect it properly. And having to run all that software impacts machine performance. I would not be surprised if the anti-virus scanner alone eats up 5-15% of file performance all by itself.
Anyone who claims Windows is safer than *any* other operating system clearly isn't living in the real world.
So unless your definition of application is restricted to fscanf, the term makes no sense for non-graphical UIs either.
Oh sure.
Perhaps the distinction wasn't so obvious in 1998 or whenever the first edition came out, but it is now.
Fedora does contain console apps such as vi, emacs, mc, etc. that run through curses and respond to user input, but the vast majority are GUI based applications.
Command-line programs like grep, ls etc. are tools, not applications. Programs like sshd, inetd, apache etc. are daemons, not applications.
While such things as pipes, regular expressions, setting date & time etc. are all fundamentals of any kind of programming, it seems a more apt name for the book would be Linux Command-Line Application Development, or Linux Daemon Development.
He knows better now.
Or Maporama. Much better than MapQuest, offers customizable sizes and has very comprehensive maps for most of the world.