Wine OpenBSD

[Oko]

While I was updating my office desktop to the latest 4.6 snapshot two weeks ago I noticed that Wine port has been updated to the latest stable version 1.21. Due to the 4Gb of RAM I run AMD version on my office desktop so I am not in the position to test the port until I update some of my home desktops. Does anyone actually has any experience with the latest Wine on OpenBSD ? Is it just there for developmental reasons or is it usable?

One unrelated notice. swfdec plugin 0.82 works really beautiful on OpenBSD 4.6 AMD. YouTube, Google video and quite number of other sites full of flush are rendered flawlessly. Actually, one would have a hard time to notice the difference between Windows and OpenBSD. Unfortunately not all flash sites are render correctly. I use Wiley Plus for one of the courses that I teach. Some of the interactive HW assignments use flash and are not completely correctly displayed. It also looks like swfdec development is stale. The new version was supposed to be released in March but it is still not released. Does anyone have any additional information about this issue?

[BSDfan666]

The port was updated to motivate further work, one of the Wine developers is attempting to fix Wine on OpenBSD.

Currently it compiles, runs basic things.. but fails miserably with everything else.

http://wiki.winehq.org/OpenBSD
http://www.openbsd.org/cgi-bin/cvswe...kefile#rev1.33

I can't find the mailing list discussions, but I swear they exist.. either way, it's broken due to the new malloc(3) introduced in 4.5 that Wine doesn't like very much.

As for the Flash stuff, I know nothing.. and want to remain blissfully ignorant.

[Carpetsmoker]

I just installed wine for this:
http://www.thinkwiki.org/wiki/How_to...tsplash_screen

Result:

[~/logo/bios/extract]% wine prepare.exe logo.scr
Segmentation fault (core dumped)
Exit 139

prepare.exe is a simple 90K file, it compresses and converts a bitmap image. All very basic.

[BSDfan666]

Correction; absolutely nothing works.. so.. best not try.

[Carpetsmoker]

I split the discussion to a new thread, it was getting very off-topic. Sorry Oko, didn't want to hijack your thread.

http://www.daemonforums.org/showthread.php?t=3762

[IronForge]

Greetings:

I was looking into the Wine situation a bit too - exchanged emails with one of their developers. He showed me a msg thread he had with the Openports.se Wine maintainer - looked like a bit of a nasty (borrowing his words) problem. I'm no system programmer; but I've done some work with custom built, database, and pkgd apps as Developer, BSA, and as a PM.

The WINE team had been looking for OBSD developers for some help with the malloc problem, so if any C Programmers are available, pls contact the Openports.se maintainer and the Wine Team for further direction.

I know most of you know this; but I'm listing the URL for the casual C hacker who's itching to have a little fun with a Memory Allocation Challenge.
http://openports.se/emulators/wine

On the practical side, not having something that would help people - pardon the pun - cross over from Windows for nearly ten years "just doesn't look good" on the advocacy front, IMHO. Though the OBSD OS/Documentation philosophy is quite straightforward, pragmatic, and logically sound, there appear to be a few apps/features that prevent more people, corporations, etc. to try it out. Given the popularity of Linux and OSX, I'm sure people would enjoy having to work with more reliable alternatives to the Windows OS AND still have access to its apps.

E.g, from the text here at the forum, the search for Flash has read like a "deal-killer" on occassion. Granted, we can live without and work around it; but WINE's currently popular with Gamers (not the worker bees who want their *NIX at the home office) working out their Windows toys on Linux, for crying out loud - kind of reaching a "critical mass" where the interest and increase in the functionality of WINE is self-sustaining. Might as well invest a few Man-hours to enhance the availability of a whole class of apps on OBSD, Should get more users/adopters to try out OBSD - yes, even the corporate Linux fanboys.

It'd be a great "seller" (Your CDpkg and demo opp to co-workers) to others if you can get Wine to get flash and basic M$ Office Apps running. E.g., I'll be working with a Company Packaged App Suite that uses Excel plugins - I know that we have the KQEMU option; but a working WINE would allow us to skip installing the Win* OS altogether and run the "Windoze Apps" a bit faster.

[ocicat]

Originally Posted by IronForge

On the practical side, not having something that would help people - pardon the pun - cross over from Windows for nearly ten years "just doesn't look good" on the advocacy front, IMHO. Though the OBSD OS/Documentation philosophy is quite straightforward, pragmatic, and logically sound, there appear to be a few apps/features that prevent more people, corporations, etc. to try it out. Given the popularity of Linux and OSX, I'm sure people would enjoy having to work with more reliable alternatives to the Windows OS AND still have access to its apps.

In general, you have a point, & if the OpenBSD Project's goal was to treat itself as a product to sell, if it wanted to show marketplace growth, or a dominant position among conmmercial alternatives, then your point would be quite sound & grounded. However, these aren't the goals of the OpenBSD Project.

The target audience of the OpenBSD Project is the OpenBSD developers themselves. The project just happens to make its work available to the public. I am sure that the developers are aware its shortcomings, but developers have to champion causes. If one of the developers feels passionate enough about any particular feature, in time it will happen.

While the Project does ask for donations & does ask users to help support its work, its goals & target audience remains firm. The OpenBSD Project will likely always remain small, but this seems fine by the developers. Is this odd or contradictory? Maybe, maybe not. The model has been able to sustain itself for nearly fifteen years. OpenBSD is an engineering project for engineers by engineers. Nothing more; nothing less.

[IronForge]

Ocicat:

Per your post on
http://www.daemonforums.org/showpost...1&postcount=55

Originally Posted by ocicat

Not immediately, but I will in time. Mainly for three reasons:

• Corporate America, & especially large corporations typically standardize on Windows. Enough said.
  
  As subpoints, it also doesn't hurt to stay abreast of what Redmond is doing. Maybe I'm not addicted to their wares, but many people are, & some of those people might pay my bills. Knowing the terrain is a good thing -- just like knowing a bit of OS X.
  
  Diversity also breeds tolerance. Although I prefer OpenBSD, all operating systems have their place & function. Neither is any one operating system perfect -- even OpenBSD.
• Some laptop vendors (Lenovo...) only provide BIOS updates via Windows applications. For these situations, I prefer dual-booting because I don't need to boot into Windows often, & the overhead of virtualization merely for this one reason isn't justified. I just need the disk space.
• The Open Source Unix-like operating systems still pales in comparison to the support of Flash & other youtube-like venues. Like it or not, there is salient information in these formats.

I'm not trying to change your model or convince you to convert your OS Project to being run by Marketing Majors....we've (at least I've) seen that too often. You're already selling your CD Sets and asking for donations; and as you claimed your userbase consists mostly of Developers. My $0.02 has been that Open Source advocacy and adoption by Computer Users and IT Departments have been done by "show and tell" and "word of mouth". "User Friendliness" and "Ease of transition from 'Legacy' (IMHO) has always been a factor affecting a System's Learning Curve.

If obsolete/decrepit ports are fixed/updated by aiding a team of engineers looking to have their project work on yours (I'm sure they changed their tune from wanting to support Linux only by now), make access to multimedia apps a bit more convenient for your engineers, contribute to advancing multimedia capabilities on your platform, and indirectly results in more adoptions and increases in the sale of your CDs (obviously by System and App Programmers for the most part - mebbe IT Dept Heads), isn't it still within the parameters of your model, albeit with the potential for more $$ for Hardware and Operation Capital for your projects?

IMO, having a working WINE can contribute to smoothing out the OBSD Learning Curve for Developers, SysAdmins, and Desktop Users. In addition to trying out jiggmi's LiveCDs/DVDs or having a VirtualBox hosting an OBSD Session, a workable WINE may most likely be beneficial in providing a workable solution on your 3 points listed in your quote, by:

a) Complementing an IT Department's Virtualization efforts with WINE;
b) Get several "windows only" apps like your Laptop Vendors' to work on Wine (and if it doesn't, use that opportunity to begin a dialog with them). E.g., I recall contacting the tech support at Brother concerning Linux support (and offering to look for OpenSource Coders, contacting SourceForge) for their "All-in-One" print drivers a few years back. Because of user advocacy and increased corporate adoption, Brother rolled out lpr and CUPS wrappers for a good number of models months later;
c) No need to reject people (including Developers) who "want" flash or games. With your systems' emphasis on Security and Open Source Encryption, perhaps more Flash, swfdec, and game developers may sign up and start using OBSD for their workstations/dev environments. I would - had my share of BSOD and Dr. Norton calling my Packaged Apps and OS instance's "Time of Death and Reason".

The fun part is, WINE's cranking out a new set of "releases" every 6-8 weeks. Getting an Windows app to work long enough to allow the WINE Debugger to capture "what's wrong" - generally speaking - should do the trick.

Helping the OBSD Maintainer and the WINE Dev Team overcome the "malloc conformance issue" (could be just an general edit/overview of their code, highlighting the problematic sections/practices, and providing/posting guidance and/or sample working code) would be beneficial, if not operationally convenient.

Pardon the editing - late night.

Regards

[ocicat]

As clarification:

• I am not an official Project developer associated with the OpenBSD Project. I am a user just like everyone else on this site (although a few Project developers do lurk here from time to time...).
• Any contradiction seen in my diatribes found in responses #7 & #8 of this thread is overlooking the fact that in one I am espousing how I deal with my own personal equipment in comparison to explaining the Project's mindset in the other. The two aren't the same.

Originally Posted by IronForge

IMO, having a working WINE can contribute to smoothing out the OBSD Learning Curve for Developers, SysAdmins, and Desktop Users.

This may very well be, but easing the learning curve for the masses isn't a paramount priority of the Project. What appears to be acutely important to the Project developers is adherence & support of fundamental standards & protocols. Interoperability is important only so far as it relates to the above issues (which is also seen in the "free, functional, & secure" mantra...).

Until a Project developer champions a cause (ie. WINE compatibility), users like you or I have no say in the direction taken by the developers. This may be seen as a serious flaw, or as remaining unfettered from commercial pressures. Either way, it is as it is -- a project run by engineers who enjoy enhancing a 30-year-old code base remaining mindful of its own goals.

Lastly, if there is anything that has born itself time & again from reading the official misc@ mailing list for several years: one will only be wasting time when attempting to steer or persuade the project to be something it is not. If OpenBSD does not meet people's needs, there are other alternatives & the Project developers are well aware of this fact.

[jggimi]

I will second Ocicat's reply. Users do not steer the Project. Ever. The developers do. We users are along for the ride. And in no sense does a) interoperable functionality with Windows, b) ease of use for the new-to-BSD Windows or Linux user, or c) advocacy of OpenBSD at all ... have anything to do with the Project's goals.

Users who wish to contribute can contribute to the ports tree, or may contribute patches to the OS. All may be rejected. I've had patches completely rejected, or partially accepted. I've had a couple of ports added to the tree, after much work, and several rejections.

Any other contributions -- monetary, or hardware -- are accepted only when without any preconditions. At best -- at best, mind you -- a user might arrange to make a donation of specific hardware, hoping for its support, or might fund a specific research activity, hoping it may bear fruit. The likelihood of success will depend on the time, interest levels, and support of the specific developer(s) involved.

At no time will a non-contributory request for a feature be accepted unless there is a developer already intending to add it, no matter how politely worded. And I have never seen a suggestion for a shift in Project direction, no matter how small, be accepted.

[jggimi]

Let me flesh out my remarks, above, as they relate to WINE:

WINE is in the ports tree. As such, it is a 3rd party program, and therefore, non-core to the project.

WINE has an active maintainer, who is also an OpenBSD developer. (Maintainers often are, though that is not a requirement.) The CVS logs show multiple developers committing changes in the last year.

It is my assumption, therefore, that the OpenBSD Project has developers who are interested in updating and improving the WINE port, though it is not, by definition, their core function.

If you wish to initiate and guide a discussion between those working on the OpenBSD port of WINE, and the WINE project, I would start by contacting the port maintainer. You will find her name and e-mail address in the port's Makefile.

[ocicat]

Originally Posted by ocicat

What appears to be acutely important to the Project developers is adherence & support of fundamental standards & protocols. Interoperability is important only so far as it relates to the above issues (which is also seen in the "free, functional, & secure" mantra...).

For more context on WINE compatibility, see the following thread from misc@:

http://marc.info/?t=125729297000001&r=1&w=2

...as this gets into some undesirable side effects of plunging too quickly into appeasing the masses.