[opensuse] The new revolutionary concept of Windows (Wined) packages !
hi all ! I'm going to describe a new concept. A very controversial one. Usage Scenario: We (the OSS community) have a great website copier, named "httrack", with 4 versions of it: 1. httrack - this is the engine + text-mode (console) menu-based frontend. Stable. 2. WinHTTrack - desktop version of the above with Windows GUI. Stable and mature. But we can't use it without an emulator. (read: Wine) 3. WebHTTrack - Linux version with Web-based GUI - buggy version - not recommended. 4. KHTTrack - a KDE frontend to httrack. unmaintained & alpha. The problem: 1. httrack is stable, but it works only in console mode. 3 and 4 are both unstable, so I would vote against including them in the distro. 2. This looks interesting.... Do you remember "Google Picasa" ? They have built a Windows-only package, optimized it for wine, and pooof ! it works on Linux ! In case of WinHTTrack, The main advantage of doing this, is that we receive both stable and mature product. I think there *can* be a new class of Linux applications, that follow the "Google Picasa" storyline, Namely: Windows applications, that are tested and developed for Wine ! They could get packaged for openSUSE distro, as all the components are Open-Source, and in their rpm dependency database, there could be only one thing: "wine" ! The main problem with Wine, is that not all Windows software works on it, but this problem is resolved, when Windows software is targetted at "Wine". With such an approach wine makes it for a stable platform. Both Wine and applications, such as WinHTTrack are open-source, and if that application gets running stable on wine, we could really create such a package. That package could even modify some of wine's parameters to work better, and integrate into openSUSE better. What do you think of this new, revolutionary, concept ? This is a real usage scenario, link: (Please discuss here, not in Bugzilla.) https://bugzilla.novell.com/show_bug.cgi?id=264686 P.S. The Wine team think they are: " Wine is not emulator " while I think that wine is the: " WINdows Emulator" -- -Alexey Eremenko "Technologov" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 4/16/07, Alexey Eremenko
hi all !
I'm going to describe a new concept. A very controversial one.
Usage Scenario: We (the OSS community) have a great website copier, named "httrack", with 4 versions of it:
1. httrack - this is the engine + text-mode (console) menu-based frontend. Stable. 2. WinHTTrack - desktop version of the above with Windows GUI. Stable and mature. But we can't use it without an emulator. (read: Wine) 3. WebHTTrack - Linux version with Web-based GUI - buggy version - not recommended. 4. KHTTrack - a KDE frontend to httrack. unmaintained & alpha.
The problem: 1. httrack is stable, but it works only in console mode. 3 and 4 are both unstable, so I would vote against including them in the distro. 2. This looks interesting.... Do you remember "Google Picasa" ?
They have built a Windows-only package, optimized it for wine, and pooof ! it works on Linux !
In case of WinHTTrack, The main advantage of doing this, is that we receive both stable and mature product. I think there *can* be a new class of Linux applications, that follow the "Google Picasa" storyline, Namely: Windows applications, that are tested and developed for Wine ! They could get packaged for openSUSE distro, as all the components are Open-Source, and in their rpm dependency database, there could be only one thing: "wine" !
The main problem with Wine, is that not all Windows software works on it, but this problem is resolved, when Windows software is targetted at "Wine". With such an approach wine makes it for a stable platform. Both Wine and applications, such as WinHTTrack are open-source, and if that application gets running stable on wine, we could really create such a package. That package could even modify some of wine's parameters to work better, and integrate into openSUSE better.
What do you think of this new, revolutionary, concept ?
This is a real usage scenario, link: (Please discuss here, not in Bugzilla.) https://bugzilla.novell.com/show_bug.cgi?id=264686
P.S. The Wine team think they are: " Wine is not emulator " while I think that wine is the: " WINdows Emulator"
I've never used Wine, or any other windows compatibility tool. (Not sure what that says.) Anyway I use cygwin all the time to let me run Linux code specifically compiled (or ported) for cygwin on a windows box. It is an extremely popular and successful solution but as I gather for wine, it sometimes takes a little tweaking to the source code to get things to work. I definitely think it would be logical to have a Windows Compatibility tool that allowed Windows source code to easily be ported to Linux. If Wine fits that goal, fantastic. FYI: For good or bad cygwin requires the use of a dll. That dll is licensed as pure GPL, not LGPL. That means all programs that use the cygwin dll are covered by the GPL. I don't know enough about Wine to know if there is an equivalent issue or not. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I definitely think it would be logical to have a Windows Compatibility tool that allowed Windows source code to easily be ported to Linux. If Wine fits that goal, fantastic. The problem of making wine work consistently is one of licensing for one
On Monday 16 April 2007 15:41, Greg Freemyer wrote: thing. Technically, I can move any of the windoze dlls over to my wine setup an make just about any windoze application work... I did that back at IBM where I was able to make Lotus Notes run in wine... but the problem is that those windoze components require a windoze license also, and when you're done, you're still using closed software. Now, as a stop-gap, [ believe this or not guys ] I am not apposed to doing that for the short term if an app is absolutely critical until a replacement can be built. Running a win app on linux and porting a win app to linux are two different things. The cite above uses the word "ported" which in fact wine does not do. Wine does allow a win app to run on linux until such time as the app can be "ported," that is, rewritten for native linux. The bottom line is that there are many apps that *must* be written soon... an industrial strength CAD program for instance, Logos Research logos software, and maybe on my mind right now because its April--- a tax processing program complete with electronic filing for both Fed and State... -- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
M Harris wrote:
On Monday 16 April 2007 15:41, Greg Freemyer wrote:
I definitely think it would be logical to have a Windows Compatibility tool that allowed Windows source code to easily be ported to Linux. If Wine fits that goal, fantastic.
The problem of making wine work consistently is one of licensing for one thing. Technically, I can move any of the windoze dlls over to my wine setup an make just about any windoze application work... I did that back at IBM where I was able to make Lotus Notes run in wine... but the problem is that those windoze components require a windoze license also, and when you're done, you're still using closed software. I don't think that's what Greg is talking about. He means FOSS apps targeted at windows. Picassa is a poor example because it's closed source.
The problem with this is that it gives MS control of the APIs. Some are stable, yes, but when it comes to adding features, this means that /by definition/ MS apps will have the advantage. Whereas if apps are targeted at FOSS APIs, the developers of the APIs will be able to add new features much more quickly and innovatively (not having to ape MS or wait for them to add a feature).
Now, as a stop-gap, [ believe this or not guys ] I am not apposed to doing that for the short term if an app is absolutely critical until a replacement can be built.
This is a reasonable approach, IMO.
Running a win app on linux and porting a win app to linux are two different things. The cite above uses the word "ported" which in fact wine does not do. Wine does allow a win app to run on linux until such time as the app can be "ported," that is, rewritten for native linux.
What he meant was that the Wine APIs are restricted relative to the Windows APIs, which means some apps don't work. But if one deliberately restricts the app to those APIs implemented under Wine, possibly modifying it in the process, I think it's fair to describe it as being ported to Wine.
The bottom line is that there are many apps that *must* be written soon... I'd think a lot are under development. an industrial strength CAD program for instance, qcad? http://www.ribbonsoft.com/*qcad*.html Or do you mean 3d? Logos Research logos software,
Sword? http://www.crosswire.org/sword/index.jsp
and maybe on my mind right now because its April--- a tax processing program complete with electronic filing for both Fed and State...
http://www.grisbi.org/ Grisbi might be a good starting point. I know very little/nothing about US tax law. Wouldn't you require 50 odd modules for state tax requirements? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
M Harris wrote:
a tax processing program complete with electronic filing for both Fed and State...
This looks more relevant than Grisbi: http://taxgeek.sourceforge.net/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Alexey Eremenko -
Greg Freemyer -
M Harris -
Russell Jones