I get your point, but without at least the ability to import legacy documents, it's never gonna get used anywhere near the level it deserves (even if it's a great, new, innovative suite).
There's a reason we all still use QWERTY keyboards, and I'd argue the lock-in there is less onerous than the lock-in of billions of legacy documents. And I'm not one of those who claims that legacy (i.e. MS) import needs to be 'perfect'. Good enough is a great thing. But part of good enough is some level of compatibility with the past.
...I personally use Open Office in GNOME, and KOffice on KDE, occasionally using Gnumeric on either because I like it.
And if all these things fully supported ODF, you could actually use all these apps 'when you feel like it', keeping your data in ODF documents. I'm not sure you manage to mix apps this way today? Or do you use one app consistently for a given set of data? Doesn't sound like a great solution to me.
I sure hope somebody writes a nice plugin for MSOffice pre-OOXML files (since they support Java plugins, maybe this could actually be done using the Apache POI Java library). As it stands,.doc, etc probably provide the best interoperability available today. Not a happy situation, but thanks to OOo, not an unlivable one either. KOffice really needs to join the club with.doc and.xls, or it'll never be anywhere near as useful as it could be.
...any stupid program that tries to write to $PROGDIR or do anything else stupid has the changes re-directed to somewhere safe.
When Vista first came out, and I was asked to test my WIN32 app to make sure it still worked, I was pleasantly surprised to find that all my...PrivateProfile code that uses the default location no longer required me to grant global access to an.ini file in the Windows directory. They seem to make a copy under 'application data' and use that. A very simple and elegant solution that fixes a nasty problem for apps that want to just work on all WIN32 platforms.
Of course, I could've changed the app to explicitly copy the.ini files someplace writeable, but then I'd have to pick different places depending on what version of Windows I was running under. Having a default location that actually works is a much better solution. So, I cancelled my plans to code an app-specified location, figuring Vista would just solve the problem for me. But then again, Vista was Vista, so the problem never got solved. I sure wish they would've just installed this particular shim into XP. But then again, Microsoft is Microsoft, so...
You're right. A real data grid that supports data entry and some basic formatting is essential for building any data-intensive application.
I built and still use a 'smart terminal' browser-like front end for the applications my company writes. It's main 'flashy' component is a nice data grid that allows us to build apps using a web-like, thin client architecture but with a desktop-like look and feel.
At various points over the years, I've considered rewriting the front-end to host the functionality in a standard web browser. And always, the bottom line was that you couldn't duplicate what my grid provides, so it wasn't worth it. I always figured somebody would make it possible at some point, and that's a good thing. Hell, I'm surprised Microsoft's never made an 'Excel' component you could code to in IE. But it's certainly better that it be part of HTML 5.
You got it. The only thing wrong with Linux today is that it's still developed in R&D mode. The distros, desktop environments, etc. are still changing too fast. This is a byproduct of the open source development model, and it's the reason Linux got as complete as it is without billions of investment.
But for general desktop usage, R&D mode won't hack it. And at this point there's not much good reason for Linux to stay in R&D other than inertia. Sure there are a few things that haven't shaken out a good desktop standard yet. As has been mentioned before, the presence of multiple sound and video API's is an ongoing problem. So much so that KDE4 built Phonon to wrap the 'native' API's in a standard one apps can code to (and lots of apps lost functionality in the process of converting to that least common denominator API).
Hopefully, the painful transition from KDE3 to KDE4 was the last 'total rewrite' in that project. And if that accounts for the pain, then it'll prove well worth it. GNOME seems about ready to undertake a similar wholesale update.
What would be wonderful would be for the next development cycle to be concentrated on really nailing down such things and targeting all the major toolkits toward the same underlying plumbing. And then keeping it the same for a good, long time (at least from the app's point of view). Then maybe the 3rd party apps would start to appear. As it stands, WINE is probably the most stable API available under Linux, and (no disrespect toward WINE) that's not a good thing.
>Apple now has made iTunes DRM free, uses open (if not patented) standards for audio codecs, etc.
If the AAC codec is as open as, say, WMA, how come other audio players don't include it? I was looking at an ad for a cheap player from Coby that had OGG fer Chrissake....and WMA. How come no AAC? With all those iPod users out there and all their ready-to-go AAC files, why wouldn't all iPod competitors support AAC?
Is Microsoft just giving away their WMA 'intellectual property'. Or is Apple (or whoever holds the rights to AAC) overcharging?
You act as if running that one missing Windows app under WINE is the equivalent of just using Linux as an app-launcher for Windows apps. What's with this attitude? Lots of companies have a few Windows apps they can't give up or rewrite. Why steer them clear of Linux, when the other 80% of what they need can be accomplished natively?
WINE was never intended to be the standard way for apps to target Linux, but the WINE dev's saw a need and provide a solution for it. It's not perfect, especially with no help from the original app devs. But for stuff like Google Earth, etc, where the app dev's actually do a WINELIB port and verify that it works, it works well. Maybe not as well as a native app, but WINELIB hasn't gotten the attention it deserves to make it work better.
Shuttleworth is probably the biggest supporter (besides Novell) of GNOME. I wonder how he feels about MONO. Which is more 'native' - a.NET app running under MONO (if it even could), or a.EXE running under WINE?
In any case, sure, if you're running only Windows apps, run Windows. If you just need a few, WINE makes sense.
If the spec assumes that all implementers are doing it with the intention of achieving interoperability, then there's not as much need to nail down every byte of the syntax.
If, however, one of your implementers is Microsoft, and you can more or less assume that one of their goals is to assure *incomplete* interoperability, then you've got a whole other thing.
The folks designing ODF were building a standard that they thought all implementers would treat as a standard. Yes, things were left out, and I guess the OOo implementation was assumed as a reference implementation to go to for the details. But it's not quite incompetence to assume people are approaching implementing your standard in good faith.
By the way, wasn't there a Sun-generated plugin for MSOffice to handle ODF? Does that work better?
I'd wager that for most people that are content to use a Mac as their desktop computer, Linux is a viable alternative.
Face it, the main app (that lots of people use) that's available on the Mac that isn't available on Linux is Microsoft Office. And I find that to be one of the easiest apps (as a casual Office user) to replace. In fact, I haven't used Office on a home computer since 2005, and haven't missed it at all. I use OOo on Linux and XP and am happy with the results (and the price).
Sure there's other stuff you can get on a Mac, but my point is, once you choose Mac, you've given up the ability to 'run any software out there'. Well, that's also true once you choose Linux. You get lots of great stuff bundled, but you can't just run any piece of software. And yes, the level of polish may be inconsistent.
So? Nobody's saying the Mac isn't 'ready for the desktop'. And Linux is in a similar position. It's ready for me. Don't I count?
Of course this RedHat honcho may be right in the sense that it'll never be ready for RedHat to make lots of money off of. Making money selling a desktop OS requires huge volume, and that's a long way off. Apple has their hardware sales to pay the bills. That doesn't mean RedHat can afford to ignore the desktop, because if Ubuntu becomes the desktop Linux of choice, and they ever start getting serious about servers, then RedHat has a problem.
There are 2 'new' things about ext4 that are contributing to data loss:
1. The filesystem doesn't flush to disk as often as ext2/3 did.
2. When it *does* flush, the order of operations is such that it's possible to crash and end up with neither the old nor the new version of a file.
Number 1 is definitely a performance enhancer, and may be okay (certainly would be easy to tune down for desktop systems if you want to).
Number 2 is the real problem. A lot of apps were written assuming that if their data didn't get flushed out, it's no big deal. For example, if you write to a temp file and then rename, you were always guaranteed to either have a good copy of the old file or the new file. That being true, it's not 'wrong' do your update without an fsync(). If you don't really care about losing the changes (and *only* the changes), then you don't need to force the disk to spin up just to guarantee you don't lose them.
But ext4 is a game changer here. No guarantees at all, and no way to guarantee a good file other than to do an fsync().
In fact, if order of operations makes it possible to end up with a corrupt file after a crash, it may well be possible that this could happen even if you do an fsync(). The system can still crash in the middle of your fsync(), and if at any time, the filesystem produces something inconsistent on disk, you can end up with a problem. No filesystem should ever be coded that intentionally creates inconsistent data on disk, however transient. Imagine a DBMS doing that.
I don't know how much of a performance gain you get by the order of operations change, but I suspect it's not so much. And if it opens up a window for data corruption, IMHO, it's not worth it.
Actually, that probably depends on having set up repositories for non-free stuff. But I'll take your word for it. In any case, it still assumes you're using Ubuntu (and Totem, for that matter).
My problem was on a Mandriva system, which overall, I prefer to Ubuntu, but which seems more ambivalent about non-free stuff. They also don't use synaptic, but they have an equivalent tool that's just as easy to use. You can get it to work on Mandriva once you get rid of the Codeina thing that keeps shuttling you over to Fluendo to try to get you to pay for the stuff.
So, yeah. It 'can' be easy, but in practice it often isn't. And again, the problem is the conflict between free and non-free in various distros, and willingness of various distros to 'help you violate patents' that all of us Slashdotters presumably agree shouldn't exist.
But none of that helps a non-technical newbie. I agree that reviewers and 'I tried linux for a week' writers should explain why they had problems instead of saying 'I had to use the command line, so Linux sucks'.
I think it's counterproductive for these two to be lumping copyright and patents in the same complaint as hurting innovation. It makes what should be a very reasonable argument read 'lunatic fringe'.
Copyright violation is theft pure and simple (well, maybe not so pure or so simple - fair use, and all). Patents are another thing altogether, in the worst case, granting monopolies on basic ideas. These patents can cover completely separate implementations of those ideas with no theft of the original work.
Sure, there's some kind of mental work involved in thinking up a novel idea, but it's so hard to draw a reasonable line around what's truly an innovation and non-obvious, etc. And there's so much potential for abuse that harms innovation that the benefits of intellectual property patents are really hard to see. The benefits of copyright are much more obvious. And the protection is much more specific and so much more limited.
It's not that apt-get is hard to use, either from the command line or via synaptic. It's that you need to know what you want to install, and lots of the packages have cryptic names that, yes, are not newbie or oldbie friendly.
Try getting your AAC files to play. It's easy if you know *exactly what* to type to get apt-get to install the codecs. But, even if you have the right repositories set up, you can be an old unix hand like me and still not know which packages you need to get the job done.
Of course, there are websites out there that'll give you step-by-step copy and paste instructions for a particular distro, but by the rules governing articles like this, I think 'use google to figure out what website tells you how to do this, and then go there and copy/paste away' isn't going to be accepted.
Now, the reason you need to do this is that nobody's willing to stick their necks out and vouch for the legality of doing that. As far as I'm concerned, even if it's not legal, it's legal. For it not to be legal is clearly anti-competitive, and I'm not about to wait for the US legal system to catch up with reality.
It wouldn't be unreasonable, however, in a 'why Linux is hard' article to explain why it is that some things that should be simple in Linux are hard, and maybe you should write your congressperson...
Again, translation a la Crusoe was translating not only the app code, but the OS and all API libraries. I don't even think the Transmeta processors had 'native' machine code - it was all emulation all the time.
With WINE, those things would be native. No need to translate them. You'd be surprised what portion of time an app spends in system libraries. With native libraries, the speed difference associated with emulation becomes much less noticeable. And remember, this is only for the occasional 'legacy' X86 apps you need to run.
I think Apple's emulation goes the other way, but for the same reason. They emulate legacy PPC code on an X86 Mac. I would assume that, since these are Mac PPC apps they are able to use native X86 code for library calls, and that's what makes their PPC emulation not as horrible as, say, VirtualPC back in the PPC days. VirtualPC had to emulate Windows as well as the apps.
I wonder if these folks would consider GPL'ing the emulation piece of this (somehow removing the stuff that allows it to emulate Windows on the Z-series, so they'd still have something left to sell).
The point would be to allow for X86 emulation in WINE on non-intel devices, like cellphones and ARM-based netbooks. That would be a potent combination that might actually propel WINE to some significant developer mindshare. Think of it. You've got a Windows app, and you want to make it available on an ARM-based device. Might be the only practical way to do it.
In fact, if ARM-based netbooks really took off, Microsoft might want to look into X86 emulation too. Of course, they'd go proprietary with it, but it would let them provide an ARM-based Windows build that can still run X86 apps.
I guess if an ARM-WINE implementation were to prod Microsoft to make an 'even better' one, it might not help WINE so much. Unless WINE gets there first, with a significant lead.
In any case, ARM-WINE or ARM-Windows emulation would only emulate the application code, making it much faster than anything (like this mainframe thing) that attempts to emulate the entire Windows OS.
I agree that for many things WINE is a good solution, with a lot less overhead. And, theoretically, much lower cost (no Windows license required - though Crossover isn't free).
Actually, I wonder why more folks don't use WINE or WINELIB to port Windows stuff to the Mac. I think WINELIB needs higher visibility in general.
Also, with a new generation of ARM-based netbooks on the horizon, I'm wondering whether there's a decent open source X86 emulator that could be paired with WINE to run Windows apps under Linux on these things. X86 emulation with WINE should be much faster than, say, VirtualPC was on the old PowerPC Macs. With VirtualPC, you had to emulate everything, including most of the Windows API. But WINE would provide the Windows API as native ARM code. Only the application logic would have to be emulated. I think that would result in surprisingly acceptable performance.
Interesting. Out of curiosity, would it have made any sense in your case to have the Java part running as a separate application communicating with the main C one over some IPC channel (sockets, RPC or something else)?
Yep. It occurred to me, because someone in the forum that I turned to suggested it. And that's the way I ultimately went. It works great. But still, that doesn't contradict the impression that embedded Java isn't given second-class status by documenting the obvious need for an 'unload JVM' function and then providing one that doesn't really unload the JVM.
I recently had need to access a large Java library from my C app, and was able to do it pretty easily (with ample help from online forums). So yes, you can embed a Java interpreter in C code.
But there's a API documented for embedded Java to unload the VM when you're done with it that turns out to not be implemented. Because of this, embedding Java means incurring a pretty stiff memory usage penalty that isn't transient.
And the 'unload VM' call has stayed unimplemented for several versions of the JRE (at least 1.4 through 1.6). So, while embedding Java in C works, it seems to have less than wholehearted support from Sun.
Sell computers with whatever you want installed, but require an activation key to be typed in in order to use it. Sell the activation key for an extra fee at checkout. If you don't activate, you're free to wipe your computer and use it as you wish.
Kind of like when you get a new credit card in the mail. You need to call an 800 number before you can use it.
Funny that there's another post today about Firefox not wanting to be bundled with Windows. They have a point, but if Microsoft can play fast and funny with the definition of an application in such a way as to limit Firefox to your 2 app limit, while allowing IE to bypass the limit, we're in serious Orwell territory.
The only reasonable definition for 'application' in this sense would be 'something that displays a visible window'. That would include IE - and for that matter, Windows Explorer. I'd argue that Windows Explorer shouldn't count, but presumably that'd allow a loophole for IE running inside the WE window - or for that matter any ActiveX thing.
I'm not saying that. I'm just saying that Mono was largely 'sold' by Miguel as a way to let people code for Windows and magically get Linux support as well. Since to most people, 'code for Windows' means WinForms, that wasn't quite true.
Now when you compare speed to a script language like Perl and compare 'expressiveness' against C++, well yeah, I guess. But how about comparing speed to C++ and expressiveness to Java.
You seem to imply that Java's in a different class 'expressiveness-wise' with Mono. I always thought that the underlying languages were essentially the same. Are the Mono libraries or some other factor that much better than what Java has? If so, please explain. I was never a big fan of Java, but I used it recently for a project, and was very pleasantly surprised.
But how is that better than, say, QT, which is a lot closer to write once, recompile and release everywhere. Or was it QT's GPL restriction (about to go away) that prevented it's being a logical choice?
If you need to rewrite your GUI for each platform, then you obviously need to rebuild for each platform. So what's Mono bringing to the table that QT doesn't. Certainly not smaller binaries, if, as a previous poster points out, you need to include Mono itself with your executables.
Okay, I started this dismal thread, so here's my take on the good news:
Actually, I think the time is ripe for a turnaround. Netbooks actually do count. So do phones, and whatever Apple comes up with as a super iPod touch / tablet thingy to take em all on. And that means standards count too. The age of Internet Explorer is definitely over, and that's a good start.
Case 1: As bizarre as it feels that HP is simultaneously yanking Linux from its British offerings and introducing *their own* Ubuntu front end on their US ones, there's good news in there.
The hardware vendors get it. And ultimately, the hardware vendors will support it. Since we won't do it, they'll set the standards for what constitutes a Linux desktop, and if it's not too awful, we can all use it. If not, we can still get by with today's mess.
Case 2: KDE. Yes, they took a lot of flack for their ground up rewrite. But they also did that at the last possible time opportunity. Maybe they understood and wanted to 'get it right enough to last a long time' now while they still can. QT now belongs to Nokia and is about to be LGPL. And Nokia pays some lead KDE folks to make it good. That's a good thing.
Nokia doesn't really need to dominate the QT ecosystem. HP certainly doesn't need to dominate the Linux ecosystem - or even the netbook Linux ecosystem. These folks make their livings selling hardware. How quaint. But that's what it's going to take for Linux to become mainstream. There can be only one monopoly jackpot. Beyond that, commodity software is the loss leader it always was. There won't be Microsoftian fortunes made selling Linux, but money will be made, and that'll help keep a lot of Linux devs fed.
Linus started me on my rant by saying he didn't think a 'standard desktop distro' was a good idea. Sure, Linus 'doesn't care that much' about the desktop, and he can easily deal with the current status quo. But he does use a Linux desktop, and I'll bet he's glad to have a decent Flash player. I'm sure he goes to youTube too. He's just not the guy to make the desktop happen. It's not what he's interested in. Thank goodness Google, Palm, Nokia and maybe even HP are.
And yes, Photoshop or not, Adobe gets it too. Or at least, they'll open source their stuff before they go under. That's part of the equation too. It doesn't pay Microsoft to kill their competitors any more.
Mono developer = Microsoft.NET developer, but a Microsoft.NET developer != Mono developer.
And that's a good thing? If Mono were merely a separate 'take what you like and leave the rest' clone of.NET it wouldn't be so bad, I guess. It might be yet another potentially portable platform (albeit one that carries vague patent threats).
But Miguel has actively promoted it as a way to get all that great.NET code being developed out there onto Linux. And that it is not. Probably never will be. Microsoft certainly doesn't want it (or won't once they displace Flash), and Miguel can't do it in any practical way.
He'll come close. Achingly close. But Mono code will be limited practically to Linux. Or it might work on Windows in whatever limited way GTK stuff works there today. Certainly not likely to work on Mac's or various phone platforms.
And there are technologies that already work on all those platforms. If Microsoft wanted it (and if anybody would - or could - ever trust them),.NET could work on all those platforms. But they don't, and it won't.
So keep working on Mono. It may someday be a nice technology in its own right. But *please* stop trying to justify it by saying that someday it'll make all Windows code 'just work' on Linux. Does anybody really believe that?
1. This is just FUD spread by people who want to ship binary drivers for Linux. Application level compatibility is actually quite good. For example you can still run GTK 1.x apps on modern Gnome desktops.
If GNOME has that level of compatibility, kudos to them.
2. Backward compatibility mostly matters for legacy proprietary apps. Since there aren't too many of those for Linux, this issue is not an important factor in Linux adoption.
So backward compatibility doesn't matter, because there are no proprietary apps, because there isn't backward compatibility... Fun.
3. Stable kernel ABI would actually be harmful for Linux, because manufacturers wouldn't be as willing to release open-source drivers. Right now they do mainly because it takes considerable manpower to maintain a closed-source driver.
Finally the truth slips out. We don't want stable API's, because we don't want closed source code. Okay. So then say it. We don't want 'the year of the Linux desktop'. Or not enough to compromise ideological purity.
Sure. Open source drivers are definitely better than closed-source ones. But there are better ways to coax device makers along than by making their lives miserable when they actually *want* to support Linux. Like actually gaining enough marketshare so that they *really, really* want to support Linux...
Slashdot Mirror
I get your point, but without at least the ability to import legacy documents, it's never gonna get used anywhere near the level it deserves (even if it's a great, new, innovative suite).
There's a reason we all still use QWERTY keyboards, and I'd argue the lock-in there is less onerous than the lock-in of billions of legacy documents. And I'm not one of those who claims that legacy (i.e. MS) import needs to be 'perfect'. Good enough is a great thing. But part of good enough is some level of compatibility with the past.
...I personally use Open Office in GNOME, and KOffice on KDE, occasionally using Gnumeric on either because I like it.
And if all these things fully supported ODF, you could actually use all these apps 'when you feel like it', keeping your data in ODF documents. I'm not sure you manage to mix apps this way today? Or do you use one app consistently for a given set of data? Doesn't sound like a great solution to me.
I sure hope somebody writes a nice plugin for MSOffice pre-OOXML files (since they support Java plugins, maybe this could actually be done using the Apache POI Java library). As it stands, .doc, etc probably provide the best interoperability available today. Not a happy situation, but thanks to OOo, not an unlivable one either. KOffice really needs to join the club with .doc and .xls, or it'll never be anywhere near as useful as it could be.
...any stupid program that tries to write to $PROGDIR or do anything else stupid has the changes re-directed to somewhere safe.
When Vista first came out, and I was asked to test my WIN32 app to make sure it still worked, I was pleasantly surprised to find that all my ...PrivateProfile code that uses the default location no longer required me to grant global access to an .ini file in the Windows directory. They seem to make a copy under 'application data' and use that. A very simple and elegant solution that fixes a nasty problem for apps that want to just work on all WIN32 platforms.
Of course, I could've changed the app to explicitly copy the .ini files someplace writeable, but then I'd have to pick different places depending on what version of Windows I was running under. Having a default location that actually works is a much better solution. So, I cancelled my plans to code an app-specified location, figuring Vista would just solve the problem for me. But then again, Vista was Vista, so the problem never got solved. I sure wish they would've just installed this particular shim into XP. But then again, Microsoft is Microsoft, so...
You're right. A real data grid that supports data entry and some basic formatting is essential for building any data-intensive application.
I built and still use a 'smart terminal' browser-like front end for the applications my company writes. It's main 'flashy' component is a nice data grid that allows us to build apps using a web-like, thin client architecture but with a desktop-like look and feel.
At various points over the years, I've considered rewriting the front-end to host the functionality in a standard web browser. And always, the bottom line was that you couldn't duplicate what my grid provides, so it wasn't worth it. I always figured somebody would make it possible at some point, and that's a good thing. Hell, I'm surprised Microsoft's never made an 'Excel' component you could code to in IE. But it's certainly better that it be part of HTML 5.
You got it. The only thing wrong with Linux today is that it's still developed in R&D mode. The distros, desktop environments, etc. are still changing too fast. This is a byproduct of the open source development model, and it's the reason Linux got as complete as it is without billions of investment.
But for general desktop usage, R&D mode won't hack it. And at this point there's not much good reason for Linux to stay in R&D other than inertia. Sure there are a few things that haven't shaken out a good desktop standard yet. As has been mentioned before, the presence of multiple sound and video API's is an ongoing problem. So much so that KDE4 built Phonon to wrap the 'native' API's in a standard one apps can code to (and lots of apps lost functionality in the process of converting to that least common denominator API).
Hopefully, the painful transition from KDE3 to KDE4 was the last 'total rewrite' in that project. And if that accounts for the pain, then it'll prove well worth it. GNOME seems about ready to undertake a similar wholesale update.
What would be wonderful would be for the next development cycle to be concentrated on really nailing down such things and targeting all the major toolkits toward the same underlying plumbing. And then keeping it the same for a good, long time (at least from the app's point of view). Then maybe the 3rd party apps would start to appear. As it stands, WINE is probably the most stable API available under Linux, and (no disrespect toward WINE) that's not a good thing.
>Apple now has made iTunes DRM free, uses open (if not patented) standards for audio codecs, etc.
If the AAC codec is as open as, say, WMA, how come other audio players don't include it? I was looking at an ad for a cheap player from Coby that had OGG fer Chrissake. ...and WMA. How come no AAC? With all those iPod users out there and all their ready-to-go AAC files, why wouldn't all iPod competitors support AAC?
Is Microsoft just giving away their WMA 'intellectual property'. Or is Apple (or whoever holds the rights to AAC) overcharging?
You act as if running that one missing Windows app under WINE is the equivalent of just using Linux as an app-launcher for Windows apps. What's with this attitude? Lots of companies have a few Windows apps they can't give up or rewrite. Why steer them clear of Linux, when the other 80% of what they need can be accomplished natively?
WINE was never intended to be the standard way for apps to target Linux, but the WINE dev's saw a need and provide a solution for it. It's not perfect, especially with no help from the original app devs. But for stuff like Google Earth, etc, where the app dev's actually do a WINELIB port and verify that it works, it works well. Maybe not as well as a native app, but WINELIB hasn't gotten the attention it deserves to make it work better.
Shuttleworth is probably the biggest supporter (besides Novell) of GNOME. I wonder how he feels about MONO. Which is more 'native' - a .NET app running under MONO (if it even could), or a .EXE running under WINE?
In any case, sure, if you're running only Windows apps, run Windows. If you just need a few, WINE makes sense.
If the spec assumes that all implementers are doing it with the intention of achieving interoperability, then there's not as much need to nail down every byte of the syntax.
If, however, one of your implementers is Microsoft, and you can more or less assume that one of their goals is to assure *incomplete* interoperability, then you've got a whole other thing.
The folks designing ODF were building a standard that they thought all implementers would treat as a standard. Yes, things were left out, and I guess the OOo implementation was assumed as a reference implementation to go to for the details. But it's not quite incompetence to assume people are approaching implementing your standard in good faith.
By the way, wasn't there a Sun-generated plugin for MSOffice to handle ODF? Does that work better?
I'd wager that for most people that are content to use a Mac as their desktop computer, Linux is a viable alternative.
Face it, the main app (that lots of people use) that's available on the Mac that isn't available on Linux is Microsoft Office. And I find that to be one of the easiest apps (as a casual Office user) to replace. In fact, I haven't used Office on a home computer since 2005, and haven't missed it at all. I use OOo on Linux and XP and am happy with the results (and the price).
Sure there's other stuff you can get on a Mac, but my point is, once you choose Mac, you've given up the ability to 'run any software out there'. Well, that's also true once you choose Linux. You get lots of great stuff bundled, but you can't just run any piece of software. And yes, the level of polish may be inconsistent.
So? Nobody's saying the Mac isn't 'ready for the desktop'. And Linux is in a similar position. It's ready for me. Don't I count?
Of course this RedHat honcho may be right in the sense that it'll never be ready for RedHat to make lots of money off of. Making money selling a desktop OS requires huge volume, and that's a long way off. Apple has their hardware sales to pay the bills. That doesn't mean RedHat can afford to ignore the desktop, because if Ubuntu becomes the desktop Linux of choice, and they ever start getting serious about servers, then RedHat has a problem.
There are 2 'new' things about ext4 that are contributing to data loss:
1. The filesystem doesn't flush to disk as often as ext2/3 did.
2. When it *does* flush, the order of operations is such that it's possible to crash and end up with neither the old nor the new version of a file.
Number 1 is definitely a performance enhancer, and may be okay (certainly would be easy to tune down for desktop systems if you want to).
Number 2 is the real problem. A lot of apps were written assuming that if their data didn't get flushed out, it's no big deal. For example, if you write to a temp file and then rename, you were always guaranteed to either have a good copy of the old file or the new file. That being true, it's not 'wrong' do your update without an fsync(). If you don't really care about losing the changes (and *only* the changes), then you don't need to force the disk to spin up just to guarantee you don't lose them.
But ext4 is a game changer here. No guarantees at all, and no way to guarantee a good file other than to do an fsync().
In fact, if order of operations makes it possible to end up with a corrupt file after a crash, it may well be possible that this could happen even if you do an fsync(). The system can still crash in the middle of your fsync(), and if at any time, the filesystem produces something inconsistent on disk, you can end up with a problem. No filesystem should ever be coded that intentionally creates inconsistent data on disk, however transient. Imagine a DBMS doing that.
I don't know how much of a performance gain you get by the order of operations change, but I suspect it's not so much. And if it opens up a window for data corruption, IMHO, it's not worth it.
Actually, that probably depends on having set up repositories for non-free stuff. But I'll take your word for it. In any case, it still assumes you're using Ubuntu (and Totem, for that matter).
My problem was on a Mandriva system, which overall, I prefer to Ubuntu, but which seems more ambivalent about non-free stuff. They also don't use synaptic, but they have an equivalent tool that's just as easy to use. You can get it to work on Mandriva once you get rid of the Codeina thing that keeps shuttling you over to Fluendo to try to get you to pay for the stuff.
So, yeah. It 'can' be easy, but in practice it often isn't. And again, the problem is the conflict between free and non-free in various distros, and willingness of various distros to 'help you violate patents' that all of us Slashdotters presumably agree shouldn't exist.
But none of that helps a non-technical newbie. I agree that reviewers and 'I tried linux for a week' writers should explain why they had problems instead of saying 'I had to use the command line, so Linux sucks'.
I think it's counterproductive for these two to be lumping copyright and patents in the same complaint as hurting innovation. It makes what should be a very reasonable argument read 'lunatic fringe'.
Copyright violation is theft pure and simple (well, maybe not so pure or so simple - fair use, and all). Patents are another thing altogether, in the worst case, granting monopolies on basic ideas. These patents can cover completely separate implementations of those ideas with no theft of the original work.
Sure, there's some kind of mental work involved in thinking up a novel idea, but it's so hard to draw a reasonable line around what's truly an innovation and non-obvious, etc. And there's so much potential for abuse that harms innovation that the benefits of intellectual property patents are really hard to see. The benefits of copyright are much more obvious. And the protection is much more specific and so much more limited.
It's not that apt-get is hard to use, either from the command line or via synaptic. It's that you need to know what you want to install, and lots of the packages have cryptic names that, yes, are not newbie or oldbie friendly.
Try getting your AAC files to play. It's easy if you know *exactly what* to type to get apt-get to install the codecs. But, even if you have the right repositories set up, you can be an old unix hand like me and still not know which packages you need to get the job done.
Of course, there are websites out there that'll give you step-by-step copy and paste instructions for a particular distro, but by the rules governing articles like this, I think 'use google to figure out what website tells you how to do this, and then go there and copy/paste away' isn't going to be accepted.
Now, the reason you need to do this is that nobody's willing to stick their necks out and vouch for the legality of doing that. As far as I'm concerned, even if it's not legal, it's legal. For it not to be legal is clearly anti-competitive, and I'm not about to wait for the US legal system to catch up with reality.
It wouldn't be unreasonable, however, in a 'why Linux is hard' article to explain why it is that some things that should be simple in Linux are hard, and maybe you should write your congressperson...
Again, translation a la Crusoe was translating not only the app code, but the OS and all API libraries. I don't even think the Transmeta processors had 'native' machine code - it was all emulation all the time.
With WINE, those things would be native. No need to translate them. You'd be surprised what portion of time an app spends in system libraries. With native libraries, the speed difference associated with emulation becomes much less noticeable. And remember, this is only for the occasional 'legacy' X86 apps you need to run.
I think Apple's emulation goes the other way, but for the same reason. They emulate legacy PPC code on an X86 Mac. I would assume that, since these are Mac PPC apps they are able to use native X86 code for library calls, and that's what makes their PPC emulation not as horrible as, say, VirtualPC back in the PPC days. VirtualPC had to emulate Windows as well as the apps.
I wonder if these folks would consider GPL'ing the emulation piece of this (somehow removing the stuff that allows it to emulate Windows on the Z-series, so they'd still have something left to sell).
The point would be to allow for X86 emulation in WINE on non-intel devices, like cellphones and ARM-based netbooks. That would be a potent combination that might actually propel WINE to some significant developer mindshare. Think of it. You've got a Windows app, and you want to make it available on an ARM-based device. Might be the only practical way to do it.
In fact, if ARM-based netbooks really took off, Microsoft might want to look into X86 emulation too. Of course, they'd go proprietary with it, but it would let them provide an ARM-based Windows build that can still run X86 apps.
I guess if an ARM-WINE implementation were to prod Microsoft to make an 'even better' one, it might not help WINE so much. Unless WINE gets there first, with a significant lead.
In any case, ARM-WINE or ARM-Windows emulation would only emulate the application code, making it much faster than anything (like this mainframe thing) that attempts to emulate the entire Windows OS.
I agree that for many things WINE is a good solution, with a lot less overhead. And, theoretically, much lower cost (no Windows license required - though Crossover isn't free).
Actually, I wonder why more folks don't use WINE or WINELIB to port Windows stuff to the Mac. I think WINELIB needs higher visibility in general.
Also, with a new generation of ARM-based netbooks on the horizon, I'm wondering whether there's a decent open source X86 emulator that could be paired with WINE to run Windows apps under Linux on these things. X86 emulation with WINE should be much faster than, say, VirtualPC was on the old PowerPC Macs. With VirtualPC, you had to emulate everything, including most of the Windows API. But WINE would provide the Windows API as native ARM code. Only the application logic would have to be emulated. I think that would result in surprisingly acceptable performance.
Interesting. Out of curiosity, would it have made any sense in your case to have the Java part running as a separate application communicating with the main C one over some IPC channel (sockets, RPC or something else)?
Yep. It occurred to me, because someone in the forum that I turned to suggested it. And that's the way I ultimately went. It works great. But still, that doesn't contradict the impression that embedded Java isn't given second-class status by documenting the obvious need for an 'unload JVM' function and then providing one that doesn't really unload the JVM.
I recently had need to access a large Java library from my C app, and was able to do it pretty easily (with ample help from online forums). So yes, you can embed a Java interpreter in C code.
But there's a API documented for embedded Java to unload the VM when you're done with it that turns out to not be implemented. Because of this, embedding Java means incurring a pretty stiff memory usage penalty that isn't transient.
And the 'unload VM' call has stayed unimplemented for several versions of the JRE (at least 1.4 through 1.6). So, while embedding Java in C works, it seems to have less than wholehearted support from Sun.
Sell computers with whatever you want installed, but require an activation key to be typed in in order to use it. Sell the activation key for an extra fee at checkout. If you don't activate, you're free to wipe your computer and use it as you wish.
Kind of like when you get a new credit card in the mail. You need to call an 800 number before you can use it.
Funny that there's another post today about Firefox not wanting to be bundled with Windows. They have a point, but if Microsoft can play fast and funny with the definition of an application in such a way as to limit Firefox to your 2 app limit, while allowing IE to bypass the limit, we're in serious Orwell territory.
The only reasonable definition for 'application' in this sense would be 'something that displays a visible window'. That would include IE - and for that matter, Windows Explorer. I'd argue that Windows Explorer shouldn't count, but presumably that'd allow a loophole for IE running inside the WE window - or for that matter any ActiveX thing.
I'm not saying that. I'm just saying that Mono was largely 'sold' by Miguel as a way to let people code for Windows and magically get Linux support as well. Since to most people, 'code for Windows' means WinForms, that wasn't quite true.
Now when you compare speed to a script language like Perl and compare 'expressiveness' against C++, well yeah, I guess. But how about comparing speed to C++ and expressiveness to Java.
You seem to imply that Java's in a different class 'expressiveness-wise' with Mono. I always thought that the underlying languages were essentially the same. Are the Mono libraries or some other factor that much better than what Java has? If so, please explain. I was never a big fan of Java, but I used it recently for a project, and was very pleasantly surprised.
But how is that better than, say, QT, which is a lot closer to write once, recompile and release everywhere. Or was it QT's GPL restriction (about to go away) that prevented it's being a logical choice?
If you need to rewrite your GUI for each platform, then you obviously need to rebuild for each platform. So what's Mono bringing to the table that QT doesn't. Certainly not smaller binaries, if, as a previous poster points out, you need to include Mono itself with your executables.
And then there's Eclipse. Is Mono so much better?
Okay, I started this dismal thread, so here's my take on the good news:
Actually, I think the time is ripe for a turnaround. Netbooks actually do count. So do phones, and whatever Apple comes up with as a super iPod touch / tablet thingy to take em all on. And that means standards count too. The age of Internet Explorer is definitely over, and that's a good start.
Case 1: As bizarre as it feels that HP is simultaneously yanking Linux from its British offerings and introducing *their own* Ubuntu front end on their US ones, there's good news in there.
The hardware vendors get it. And ultimately, the hardware vendors will support it. Since we won't do it, they'll set the standards for what constitutes a Linux desktop, and if it's not too awful, we can all use it. If not, we can still get by with today's mess.
Case 2: KDE. Yes, they took a lot of flack for their ground up rewrite. But they also did that at the last possible time opportunity. Maybe they understood and wanted to 'get it right enough to last a long time' now while they still can. QT now belongs to Nokia and is about to be LGPL. And Nokia pays some lead KDE folks to make it good. That's a good thing.
Nokia doesn't really need to dominate the QT ecosystem. HP certainly doesn't need to dominate the Linux ecosystem - or even the netbook Linux ecosystem. These folks make their livings selling hardware. How quaint. But that's what it's going to take for Linux to become mainstream. There can be only one monopoly jackpot. Beyond that, commodity software is the loss leader it always was. There won't be Microsoftian fortunes made selling Linux, but money will be made, and that'll help keep a lot of Linux devs fed.
Linus started me on my rant by saying he didn't think a 'standard desktop distro' was a good idea. Sure, Linus 'doesn't care that much' about the desktop, and he can easily deal with the current status quo. But he does use a Linux desktop, and I'll bet he's glad to have a decent Flash player. I'm sure he goes to youTube too. He's just not the guy to make the desktop happen. It's not what he's interested in. Thank goodness Google, Palm, Nokia and maybe even HP are.
And yes, Photoshop or not, Adobe gets it too. Or at least, they'll open source their stuff before they go under. That's part of the equation too. It doesn't pay Microsoft to kill their competitors any more.
Mono developer = Microsoft .NET developer, but a Microsoft .NET developer != Mono developer.
And that's a good thing? If Mono were merely a separate 'take what you like and leave the rest' clone of .NET it wouldn't be so bad, I guess. It might be yet another potentially portable platform (albeit one that carries vague patent threats).
But Miguel has actively promoted it as a way to get all that great .NET code being developed out there onto Linux. And that it is not. Probably never will be. Microsoft certainly doesn't want it (or won't once they displace Flash), and Miguel can't do it in any practical way.
He'll come close. Achingly close. But Mono code will be limited practically to Linux. Or it might work on Windows in whatever limited way GTK stuff works there today. Certainly not likely to work on Mac's or various phone platforms.
And there are technologies that already work on all those platforms. If Microsoft wanted it (and if anybody would - or could - ever trust them), .NET could work on all those platforms. But they don't, and it won't.
So keep working on Mono. It may someday be a nice technology in its own right. But *please* stop trying to justify it by saying that someday it'll make all Windows code 'just work' on Linux. Does anybody really believe that?
1. This is just FUD spread by people who want to ship binary drivers for Linux. Application level compatibility is actually quite good. For example you can still run GTK 1.x apps on modern Gnome desktops.
If GNOME has that level of compatibility, kudos to them.
2. Backward compatibility mostly matters for legacy proprietary apps. Since there aren't too many of those for Linux, this issue is not an important factor in Linux adoption.
So backward compatibility doesn't matter, because there are no proprietary apps, because there isn't backward compatibility... Fun.
3. Stable kernel ABI would actually be harmful for Linux, because manufacturers wouldn't be as willing to release open-source drivers. Right now they do mainly because it takes considerable manpower to maintain a closed-source driver.
Finally the truth slips out. We don't want stable API's, because we don't want closed source code. Okay. So then say it. We don't want 'the year of the Linux desktop'. Or not enough to compromise ideological purity.
Sure. Open source drivers are definitely better than closed-source ones. But there are better ways to coax device makers along than by making their lives miserable when they actually *want* to support Linux. Like actually gaining enough marketshare so that they *really, really* want to support Linux...