“A startup in Alameda, Calif. plans to release a kind of holy software grail the third or fourth week of June. Lina said its dual-licensed Lina virtual Linux machine will run more or less normal Linux applications under Windows, Mac, or Linux, with a look and feel native to each.”
I’m just posing a question, so please don’t flame me:
Why is this necessary? Most applications are written in GTK+/GNOME or Qt/KDE APIs, and these APIs have already been ported to OS X and Windows.
Implementations aren’t perfect. There have always been more bugs with GTK+ for Windows than for X (though it seems to work quite well now). Then you have the problem of parallel library installations – having different versions of the same library in different places on the system. But most software just ignores that and keeps it’s own, old-but-tested copy in with the rest of it’s files in the “Program Files” forest, and ignores anything else.
That said, yes, you’re quite right. It’s nothing like as hard to port from Linux to Windows as it is, Windows to Linux.
People develop for Windows and then port elsewhere because Windows is the largest market, not because of some technical isssue associated with doing it the other way round.
Shouldn’t the other way around be better? I mean, writing a VM where you could compile Windows apps and then run them in Linux or Mac?
Do they really think that Adobe is going to rewrite their programs for Linux so they can compile them against Lina and that way be able to run them in Windows? Or did I miss something?
Shouldn’t the other way around be better? I mean, writing a VM where you could compile Windows apps and then run them in Linux or Mac?
That’s basically what wine libs are, right?
Yes, that would certainly be better. However, I doubt it would be feasible, or even possible. Microsoft obviously doesn’t like the idea of Windows apps running on other platforms, so I’m sure they would be less than willing to provide the necessary documentation.
This could be useful for proprietary software vendors to target Linux with a single build as opposed to several (RH, Novell, Ubuntu, Mandriva…). Then they also get Windows and Mac compatibility for free. Linux distributions are hard for proprietary vendors to support because they aren’t designed for proprietary software. Given the source code, the system works great, but it kinda falls apart without it.
LINA is essentially a “common Linux runtime” that also runs on Windows and Mac. But if the idea catches on, there might be alternative common Linux runtimes that totally destroy the idea of a unified userspace ABI. As new development frameworks and libraries emerge, LINA will have to remain binary-compatible with older versions, and competitors will be able to offer more features.
Linux has a bright future ahead, but proprietary software vendors are going to have to work to stay compatible. I don’t see any evolutionary force that’s going to produce a stable, unified ABI that remains relevant for long periods of time. The platform is going to evolve whether the proprietary vendors like it or not, and distributors are going to be pushing in slightly different directions.
Someday, Linux compatibility will be more important than trade secrets for most vendors. Until then, proprietary vendors will be forced to hit a moving target, whether it’s a unified moving target or not. That’s just the way the platform works, and if you think that this amounts to “not getting it,” then we’ll just have to see where the software industry winds up in ten years.
I’m more convinced than ever that proprietary software will go the way of the polar bear, outmoded by change and sustained in small numbers and at great expense in specialized environments. Except, of course, that what is happening to the polar bears is a foreboding tragedy, whereas free software is generally a good thing for the planet.
Most open source software (about 90%) on Linux are ported to Windows and other Unix-like/Unix OSes.
So this product is not necessary.
Whats needed is a painless, truely effective way of bringing commercial Windows apps to FOSS platforms.
Wine is still not painless and truely effective after 14 years of development.
When the Windows developer community migrates fully to .NET, Wine and it’s Win32 API implementation will become irrelevent in the quest to run future Windows apps on *nix.
Edited 2007-05-27 20:23
Gotta agree with you. After those 14 years Wine still doesn’t make for much more than a curiosity. I mean, what is the fun of running apps on a reverse engineered implementation of an already bogus platform..?
I don’t mean to come down on all the hard and good work of the Wine team, but for me it’s just not working and believe me I’ve tried.
Try running crossover office, if you can’t make wine work for you. The Crossover office folks take care of a lot of small details to make sure that the packaging and installation of both wine and of windows applications on Linux is easy and more reliable.
I wish that were true for me, but I too have pretty much given up both on Wine and on CXOffice. Both used to support my Studio MX (2002) apps very nicely, but both have since gone to pot.
I still use Fireworks MX and Freehand MX from time to time, but Dreamweaver (which is really what I bought the damn suite for) is dead to me now. Never mind, I actually think I like Quanta Plus better now
So this could be used to bring the remaining 10%, and closed-source Linux apps (there are some, you know) to Windows and other platforms, all in one swoop (for those apps that work under this environment).
Yet another way to make apps cross-platform, and thus easier switch the underlying OS, if you want to. Read: let Windows users play with apps that are popular on Linux, and (at some later time), have less reason to object to a Windows -> Linux move. Or simply 1 more option to “run something on anything”. Sounds good to me, regardless of how much real-life use it finds.
I hope they make licensing such that free (as in: gratis) re-distribution is possible. Too many restrictions, and widespread adoption/use won’t happen.
“Read: let Windows users play with apps that are popular on Linux, and (at some later time), have less reason to object to a Windows -> Linux move”
Windows users can already play with all the popular Linux apps on Windows, no vm needed. I run the same apps on Windows as I do in Linux or BSD, OpenOffice, Firefox, Gaim, xchat, the gimp, celestia, you name it. Maybe this might help people run KDE or gnome on Windows, now that’s not such a bad idea.
Wine is still not painless and truely effective after 14 years of development.
It’s already good enough for thousands of apps and games, and it gets better and better all the time.
When the Windows developer community migrates fully to .NET, Wine and it’s Win32 API implementation will become irrelevent in the quest to run future Windows apps on *nix.
The Windows developer community will never migrate fully to .NET, and even if they do it will mean nothing: people using .NET hardcode paths with backslashes making them unusable on Linux – there is Path.Separator, but nobody uses it. It’s also costly to rewrite code in .NET, you’re more likely to see mixed Windows/.NET apps like Visual Studio 2005 is. Using wine + Microsoft’s .NET or wine + Windows version of Mono will probably work better than using only the Linux version of Mono.
So every one of those 90% have to port individualy, lina could help alleviate porting by providing one platform.
The .Net itself is implemented on top of Win32 API and that won’t change in near future. Although is huge adoption in windows community there still quite a lot of sceptics which won’t use .Net.
Overall I think lina is quite nice, it’s like UML but portable
Amigaanywhere
http://www.amiga.com/about/history/?t=anywhere
Edited 2007-05-27 22:31
I’m going to use it if it works! I like writing relative easy applications in basic, now I’m using the commercial Realbasic but it doesn’t run well on linux. So if I could switch to Gambas and be able to run me software on windows and mac OS X I would switch. For me this solves a lot of problems, but it will depend on the price they ask if it will save me money.
One thing folks are missing here is that, in theory, this is a single binary that is cross platform.
While there are libraries that are ported cross platform, the final executables need to be natively compiled.
This offers a single binary with cross platform compatability, much like Java does, yet promotes a more generic developing meme (C, C++, scripting languages, anything targeted at the x86).
So, in that sense, this can be an interesting concept. The next issue will be the issue of resources, startup time, performance, etc. that others systems like the JVM face.
But it does harken back to an interesting comment by _I think_ Andreesen’s (it could have certainly been someone else) latest (or at least a recent) venture when he basic said that cross platform was dead — everyone will just run Linux on x86, so you may as well target that.
This kind of VM can certainly make that more of a reality.
There arn’t any open source apps I want to run under windows which arn’t already ported, or don’t have better windows counterparts.
What we need is a WINDOWS VM we can run under Linux! That would be the nail in the coffin for needing to run Windows because of all the great applications!
What we need is a WINDOWS VM we can run under Linux! That would be the nail in the coffin for needing to run Windows because of all the great applications!
“Nail in the coffin”??? Hardly.
You’d still run Windows, only inside VM, right? That is, you’d still have to pay for it.
“Nail in the coffin”??? Hardly.
You’d still run Windows, only inside VM, right? That is, you’d still have to pay for it.
Thats certainly an idea. Most computers today come with Windows. Linux users can make a backup CD/DVD of their Windows installation prior to installing Linux and use it for seamless virtualization as a guest OS. You could hide the Windows environment except for the applications and taskbar.
3D hardware acceleration support is coming to virtualized environments too. There is already OpenGL and DirectX acceleration drivers under development.
Hmm, well, I can understand their point of view: using Lina you would reduce the amount of code by having to only write for one platform and instantly have the result available on three platforms. It sure seems handy, but is it really that necessary? At least at the moment all the popular open-source apps are already ported to all the major platforms, and most likely to most less popular ones too!
If, and that’s a big if, they could get some big company to abandon their windows specific code and to rewrite the whole app for Linux/Lina, then this would start to look like a worthy project. But I just don’t think any single one of the software biggies are going to do that: it’d just require them too much time, they’d have to find new devs who know Linux programming well enough, and they’d just burn up a whole lot of money by throwing away an already functioning base.
I do wish them well, but I have to say that I’m not expecting too much of a success in the end..
Hello,
I just don’t see this working well because of a few factors:
1. Many people want Windows desktop apps, such as iTunes, Photoshop CS3, and the many bespoke Visual Basic corporate apps out there running on Linux. This is the other way around. As applications like Evolution have shown, imitation is the sincerest form of flattery.
1a. The number of good apps out there that require Gtk+ or KDE’s libraries is a very large chunk of the good Linux desktop apps. This doesn’t have that level of support yet.
1b. For the ones that aren’t, I can compile them on Cygwin or run them in VMWare
. What’s the point of running these apps in Windows if I have to recompile them?
2. Many of the good Linux apps out there depend on the whole Linux software stack, not just the kernel. Adding a whole other layer in OS X or the various flavors of Windows makes debugging a lot more complex. As any developer can tell you, this is where it starts to make life really suck when you have bugs.
3. Virtual PC 2007 is free and runs Linux or BSD in a window. Granted, it’s not the fastest thing in the world, but it works.
4. If you want to pay and get rock-solid support, get VMWare. If you work for a company and have to run Windows, chances are you’re already doing this.
5. Wine isn’t 100% of the way there yet, but it runs on Linux and OS X, and is capable of running most Windows apps on all three without special compiles.
Honestly, if I had to choose to run a cross-platform app these days, I’d end up writing something in Windows that Wine could run. At least then I could run it on OS X with Parallels in Coherence Mode (or Wine, depending on how advanced the support is), and on Linux with the assistance of Wine.
This is one of those projects that appears to be a solution in search of a problem.
I would rather see Parallels as a Linux product with Coherence Mode support under KDE or Gnome than this. At least then I’d be able to run my favorite (and have-to-use apps like Outlook 2003) Windows apps under Linux with better support than Wine (this is no fault of the Wine developers, rather of Microsoft and the fact that reverse-engineering is involved).
Virtual PC 2007 is free and runs Linux or BSD in a window. Granted, it’s not the fastest thing in the world, but it works.
Tangent: I’ve had two instances of Virtual PC running Minix doing disc operations (formatting two virtual hard drives for experimentation) along with a not-small number of native apps running, and all programs ran smoothly simultaneously. And my computer was hardly new when I got it years ago…
Well.. My Bicycle’s pretty fast, especially when going downhill, or in heavy traffic.
That doesn’t mean that my Bike’s any faster than a Car tho does it.
5. Wine isn’t 100% of the way there yet, but it runs on Linux and OS X, and is capable of running most Windows apps on all three without special compiles.
Not really sure what your definition of “most” is, but the fact of the matter is that WINE really doesn’t run a whole lot of software without having to do a lot of tweaking, and even then it’s not reliable.
It’s a valiant effort by the WINE team, but just too hit or miss.
Not everyone’s definition of running Windows apps means Office/Quickbooks/Photoshop.
There’s a need to use Windows applications on Unix, and WINE has attempted in vain to do it. But I can’t think of Unix applications that I would like to run on Windows. There are good cross-platform applications that I can run on Windows and Unix (OpenOffice.org, Opera, Firefox, etc…) so… What Unix-only applications could I want to use on Windows? It’s more the other way around, especially that there is a number of Windows-only applications that are excellent, for instance Adobe and CAD products.
Are there functional differences between Lina and Cygwin or Interix?
Edited 2007-05-28 02:20
This might be useful if it were written on a platform that isn’t a direct recompile out of the box anyway. Some Python scripts do this and Mono does this too.
Also, if this supports SDL too, there might be some point to this.
I won’t say that I really know what the problem is, but I think it was already solved by Java and (to some respect) again by .net and mono. I’m all for a better wheel, but I’m getting the idea that some people are simply trying to reinvent the same wheel over and over again and slap a new slant on it.
Then again I might just be missing the whole point.
Update: My bad. After a quick reread I’ve come to the conclusion that it’s more like Java and VMWare combined. So it’s more like two old wheels joined together with a brand new tire.
Edited 2007-05-28 03:46
While I certainly have nothing against the concept, it always makes me chuckle a bit when some startup somewhere attempts to tackle something huge like this that A) doesn’t really need to be tackled (reasons as to why are mentioned throughout the comments above and B) others have attempted and either failed or gave up (Lindows comes to mind…granted it was a different concept, but a similar sized undertaking, i.e. mimicking the entire Win32 API on Linux) as does Wine. Both of these companies have poured hundreds of thousands of man-hours into true cross platform compatibility, and either gave up, or accepted defeat and focused on other obtainable goals.
I also don’t see businesses really going for a model like this. Businesses are fine with Windows, they have legions of developers trained on Windows development, plus Microsoft is a stable company who (business practices aside) are in it for the long haul as far as supporting Windows, and furthering development on the Windows platform.
Success for Lina will be similar in scale to something like Wine…an interesting concept which will be useful to power users (mostly power Linux users). Outside of that group of folks, I don’t see anyone else who would be willing to take them too seriously until they’ve been around for a while and are able to show their commitment to the advancement of the Lina platform.
Lofty goals indeed, and they have a serious amount of work cut out for them.
“Success for Lina will be similar in scale to something like Wine”
Only difference being that Wine is actually useful. It’s not like there’s a gigantic volume of *nix Desktop applications that needs to run on Windows that aren’t already ported.
I’m amazed how companies like this manage to get funding. I guess there’s some truth to the saying “a fool and his money are soon parted”.
And how is this a holy grail? It’s not like virtualization is a new technology.
It’s been said on numerous occasions that the big things that are holding Linux back are Adobe [for graphics software] and Intuit [for its personal finance software] because they write to Windows, and people can’t give up those two pieces of software. As soon as companies like that, or companies that want to compete with them, start writing to LINA, things are going to change fast.”
It’s raining kool-aid in this guy’s world, and in anyone else’s world who believes that those are the two biggest things holding Linux back. Any company spearheading an effort like this needs to have MS Office somewhere in their business plan. Microsoft will obviously never write software that targets Lina (or if they do, it would of course never be Office).
I’m also a bit perplexed as to this statement: “the goal is really to bring the huge world of open source software to the masses.” I’ve been in the computing biz for almost a decade now, and am hard pressed to think up any killer Linux only applications that don’t have a Windows equivalent. It’s almost as if they equate the “huge world of open source software” as some magical mystical land that only Linux users know about. Guess what, the rest of the world doesn’t really care about open source apps (the free part is great, but who cares about source code? They especially aren’t going to be keen on jumping through hoops so they can get YAEC (yet another email client) running on Windows/Mac boxen.
Time will tell, but I’m definitely not buying it right now. A very cool and interesting concept, but very hard to take seriously as it reeks of OSS arrogance. Linux has such a tiny desktop presence as it is, so please explain to me that if the rest of the world is missing out on such incredible applications that are Linux only, why don’t they already know that and asking for a solution like Lina?
To support the majority of applications they need low-level VM.
This kind of VMs is too limited and unlikely can outperform Java.
And of course the idea of massive cross-platform environment is too ambitious.
…about the look and feel. Stories about the speed of these apps would be more interesting.
If people would develop software for SDL and OpenGL on Linux and distribute ONE binary and have it convert at install time then it wouldn’t have to be open-source to run on multiple platforms.
Sure if it WERE open-source software it should be as simple as ./configure followed by make but often this isn’t the case. Besides, some platforms don’t have Posix shells to run ./configure in the first place.
If this proves to be portable to other platforms besides the “Big 3” of Windows and MacOSX and standard Linux installs it will be useful. If the article weren’t slashdotted I would reread it to find out if it were Intel-specific.
-edit- According to the Slashdot article, it is x86 specific so there should be no speed concerns.
Edited 2007-05-28 13:52
“-edit- According to the Slashdot article, it is x86 specific so there should be no speed concerns.”
Wow, I sure didn’t know x86 removed all speed concerns for virtualization. When did this happen?
This doesn’t use virtualization AFAIK, it’s just a custom Linux Kernal that has been modified so that certain library functions call the Windows/Mac/Unix native equivalents.