“In short, it allows Wine applications to be run just as easily as those native to Linux, meaning that they can be linked to or run from any directory, whether from a terminal or even a file manager like nautilus. It also handles some of the more awkward Wine extensions like .lnk and .msi, allowing them to be run with a double click.”
Wine has matured quite a bit in the last few years with respect to its ability to run windows applications, its good to see the process of Actually setting it up to run those applications is being improved as well. Hopefully this will go across multiple DE’s and not just Gnome, or just KDE centric focus.
good job to all involved!
Yes. Nice to see the community taking the important step of making Wine more easily manageable.
I use Crossover Office Professional, strategically, and in a limited way, to give select business desktop users access to IE, when all else fails and they need it to conduct their business.
It is extremely slick. But I generally prefer community solutions.
“akkowing them to be run with a double click”
Nonsense, nothing wrong thwrw.
hopefully somebody gets this stuff into wine proper
… then Linux systems with Wine installed will be taken over by Windows viruses and worms. Doesn’t matter if the malware can’t get root; spambots and DDOS bots don’t need root, they just need to be able to open an HTTP or SMTP connection.
“””
“””
OK, people! Let’s get those viruses and worms tested, report bugs, and don’t forget to register them in the wine compatibility database!
Edited 2007-10-22 18:43
OK, people! Let’s get those viruses and worms tested, report bugs, and don’t forget to register them in the wine compatibility database!
Well, that has already happened. Not very long ago there was proof-of-concept virus that also targeted GNU/Linux systems. But the virus didn’t work very well and it was later found that it was due to a bug in Linux. So Linus Torvalds fixed it.
Edited 2007-10-22 20:09
That’d be the coolest headline ever.
The coolest headline might be: “Thom Holwerda doesn’t know how wine, viruses and Linux interact, he believes a Linux system with wine can get infected as easy or as worse as in Windows”. LOL
Please Thom, start using your head, there is no way a user will be affected by this trough wine. They won’t be using IE for everyday browsing, and even if they did that would be more secure than in Windows, because you only infect the .wine folder, what a damage? No, no damage at all. Proceed deleting the infected files in that folder or the entire folder, or run clamav on it and your done.
Please Thom you are OSAlert staff, don’t show your inexperience like this in public. if only one can mod you down, you’ll be rock bottom. I love OSAlert by the way.
I wouldn’t say ‘no way’. I can certainly conceive scenarios where a windows virus could infect a linux system via wine, or if wine became standard on most distros, virus writers easily targeting both platforms via wine. And even if it is true that it would just infect your .wine folder it can still do just as much ‘damage’ in the way of spam relaying and DDOSing as it can on windows.
No program in the .wine directory can be started automatically as it can be on real windows.
Anyway, isn’t this winefix a little trivial?
It’s useful, yes, but it’s a small script, why not report about all wine improvements instead? There are tons of them every day.
[Anyway, isn’t this winefix a little trivial?
It’s useful, yes, but it’s a small script, why not report about all wine improvements instead? There are tons of them every day.]
—
Because 99.9% of the daily Wine improvements do nothing to help with desktop integration, ease of use for the end user.
There isn’t much chance a Linux system will ever be compromised by windows viruses or worms – the worst case scenario is a user’s wine configuration going bad.
Either way, i can’t imagine someone using wine so that they can browse the web every day using IE…
>> Either way, i can’t imagine someone using wine so
>> that they can browse the web every day using IE…
Actually for web developers, that’s one of the things keeping them in XP… and we can’t even go to Vista for that matter.
Web developers still test in IE 7 and 6, and occasionally need to test IE 5.x as well. (GOOD developers also test at least three Firefox builds (1.0.x, 1.5, latest 2.x), two Opera builds (8.5 and 9.x), and a version of Safari (in my case 3 beta)
IDEALLY they should also test pages in Safari 2 and IE 5.2, which means having a Mac in the shop.
So running IE every day under *nix is desirable, if for no other reason than to write pages that support 70% or so of the viewing public. (though we ALL hope that number keeps dropping)
Running yes, using no. Checking your own markup is hardly “browsing the web”.
Besides, under GNU/Linux you can run
* IE5, 5.5, 6, 7 with Wine. The excellent IEs4Linux script makes setup a breeze.
* FF1.0, 1.5 or 2.0 or any one of the many other version nativly
* Opera 6.x, 7.x, 8.x, 9.x nativly
* Konqueror 3.5.x with KHTML
* Epiphany 2.20 with Webkit or Gecko.
* many more
All in one workplace! Great, isn’t it?
Yes, we do.
No, we do not. IE6 came out five years ago.
2.x is not exactly bleeding edge, its requirements are indistinguishable from 1.5, and a vast number of extensions no longer support 1.x. There are reasons not to upgrade IE that have to do with your version of Windows; there are no equivalent reasons for not following the upgrade path on FF.
I will admit to being unfamiliar with the major changes between these versions, while I continue to test 9.x.
I test 2 on a G4 laptop and 3 on Windows.
IE5/Mac was a brilliant application in its day. It really was. Steve Jobs was right when he said it was the best browser for any platform. But in the world that passed it by, its CSS model is both incomplete and broken, and its DOM is incompatible with every other browser including IE5/Windows. Supporting IE5/Mac for anything remotely resembling Web 2.0 requires creating your own JavaScript API wrapper code, CSS hacks, and even then it doesn’t handle complex CSS gracefully. Worse, IE5/Mac caches JavaScript. I sincerely wish the source code would become public domain so that the OS community could make it something awesome, but until that happens it is as relevant as Netscape 4. I feel like I’m killing my favorite child, but progress is progress.
I run IE6 on Linux, and sadly I can’t get a JVM to work under it (I need this for a website which combines Java with ActiveX).
Ultimately CSS and DOM have changed radically enough that graceful degradation is not always possible with pre-CSS2 browsers and worse, browsers that partially support CSS2. People who continue to use pre-CSS2 browsers have to be made aware of the ramifications of their choices, and I sincerely, sincerely regret what this means to people who genuinely cannot afford to replace computers they bought before 2000. I work for a university and strive mightily to make our layouts platform agnostic, minibrowser compatible, gracefully degrading, fast loading and ADA compliant.
But for a site with over a hundred pages, supporting every browser released since 2002 means maintaining glue code and hacks guaranteed to generate bit rot. IE6 is a reasonable requirement for a site. IE5/Win is not, given the number of missing properties, box-model errors and other problems.
I was an evangelist once, too.
Edited 2007-10-23 16:41 UTC
Actually an attack on your Wine-installation can wipe out anything everywhere you have write access. Or put differently – an attack on Wine on my system can wipe out all my NTFS-formatted drives effectively removing Win2K3… (perhaps I shouldn’t give my normal user write access to my C-drive).
That’s why things like AppArmour were invented.
Not on gentoo it isn’t :p
But the risk is theoretical since I only use Wine unplugged
Simple. Have options in Wine to seal off network access to all apps but ones you allow.
It would not take much of a sandbox. These stealthy and malicious programs are expecting to run on a real Windows box without any help from the user. Then again, wine apps could be sandboxed to whatever degree desired. It’s not like the user is going to expect close integration with the rest of the OS.
The launcher could automatically scan the binary with Clam before execution, but that would be ugly. The silly “allow by default but blacklist these patterns” strategy that Windows users call a security policy is probably not something that we would want to transplant.
Allow except blacklisted? Isn’t that backwards? You surely mean Block except whitelisted (aahh… third party firewalls are a must on Windows – and remember restricted user accounts).
It has -nothing- to do with root access.
Wine runs in a sandbox and unless you’re stupid enough to map your home directory as a wine disk, wine only seems it’s sendbox and, maybe, a cdrom drive.
Beyond that, Wine doesn’t auto start – it can only start remotely – read: A virus or a DDOS bot needs me to manually start it for it to propagate itself.
Last and not least, the wine binary itself runs from outside the sandbox. a Windows virus can modify system files on your Windows installation – but it cannot modify the “the Windows installation” that being used to execute it under Linux.
In short, a Windows virus may delete/destroy/blow your wine sand box – but unless you’re grossly incompetent, your Linux system itself will not be harmed.
– Gilboa
P.S. You can actually create a different sand box for -each- Windows application you want to run. In such a case, a Windows virus can only damage a single software sandbox.
Edited 2007-10-23 06:27
I read a blog the other day, how some guy tried running different viruses in wine. i think he tested 5, 4 of them didn’t even startup, 1 did, but couldn’t do any harm.
Its a pretty lame joke, can be quite fierce to some not-so-technicaly-savy users
It’s scandalous that distros are not taking a lead with this and with Wine in terms of getting it better integrated, increasing its ability to run many applications and allowing people to use COM components through Wine with a Linux desktop front-end.
Wine is quite important for the many applications that won’t be rewritten or recompiled.
Backwards compatibility is considered catering to “evil legacy” apps when, in truth, all it does is let more programs run. But some people can’t grasp that anything “old” was (or still is) useful.
im sure you DONT want improved integration. because having it launch windows executables automatically, is a security risk.