Thread: Wine OpenBSD
View Single Post
  #8   (View Single Post)  
Old 8th October 2009
IronForge IronForge is offline
Fdisk Soldier
 
Join Date: Jul 2009
Location: SoCal - "have skills, will travel for projects"
Posts: 55
Default A case for Open Source Logrolling...

Ocicat:

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

Quote:
Originally Posted by ocicat View Post
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
Reply With Quote