“DriverLoader”, created by Linuxant Inc, is a revolutionary “compatibility wrapper” allowing standard Windows NDIS 5.0 drivers (the network driver standard used by Windows and on an earlier spec revision by OS/2 too) as shipped by hardware vendors for windows users to be used as-is on Linux x86.Driverloader immediately gives Linux users the ability to use network cards “for which no adequate native open source drivers are available” -the company claims. The company has currently released a technology “demo” that allows owners of 802.11g 54mbps Wireless LAN devices (CardBus and PCI) based on Broadcom chipsets to use their devices under Linux.
The full news is :here.
finally someone did the most obvious thing to face missing linux drivers – can’t wait for a wdm wrapper for soundcards etc…
Although this might help somewhat short-term, I can’t but think that this is another reason for HW firms not to develop native drivers…..
To name a few:
one more layer (why not?)
less native free (as in speech) support for new hardware
what about drivers API changes in Linux kernel?
what about Windows drivers API changes?
compatibility issues (read bugs in the “compatibility wrapper”) uneasy to locate
And so on…
I must say that I am not that happy with that kind of “magic” :o7
Just my own personal opinion, of course :o)
Smart or not, i welcome any project for Linux.
If it will work we will see in the future.
If you dont like it – dont use it.
This is only as good as the wine project; which means, not nearly good enough. For the long term, Linux needs to stand on its own. Given what people have had to work with, I would say the hardware support has been nothing short of amazing, and I would like to see it continue.
I AM happy with this thing, even though it’s still in a very early stage– it would make things for Windows users migrating to Linux a whole lot easier, which, in the end means more marketshare for Linux.
A personal note: how about doing this to Ati’s Cataclyst (or is it catalyst? I don’t even know…) drivers? I would finally be able to use the full potential of my Radeon 9000 w/ 128 mbram in MDK! (native linux drivers by ati/xfree don’t work)
Using this technology, it would almost resemble running
the driver in userland. My first guess would be that
this is a great way to get around the Linux driver IP
issues that always arise.. OTOH, loadable Linux Kernel
drivers seem to be exempt from the GPL anyways so I guess
this argument is a wash? Anyone else have comments on this
method and the GPL?
This is a trojan horse that will have to immediate consequences:
1) Manufacturers will just tell users and Linux kernel driver developers that they do not need drivers or specs. Just use the wrapper.
2) A new host of difficult to debug problems will creep in putting a blemish on the wonderful stability provided by Linux.
Say no to this nonsense and demand native drivers.
I agree we need Linux native drivers. This will only hurt Linux in the long run. I want native drivers that work and give me access full access to my hardware. I do not need some slow ass buggy driver running in emulation mode.
This doesn’t say it works with everything. I don’t see how this can hurt Linux users. They didn’t have access to drivers, now they do, sorta. Until the manufacturers get off their ass and start providing native drivers to their customers.
It would be wiser to write a wrapper for drivers really missing in Linux – printers, graphic cards, etc.
Most NICs are supported under Linux, and NICs are one of the few devices where specs are almost always available.
The problem is that they will not do so if you have something like this around. Why ? They’ll just to users to use this crappy wrapper instead of providing native wrappers. Native software like native drivers are just plain better and do not hurt Linux. EMulation of driver or software via a 3rd party app hurts Linux because then programmers and hardware companies do not feel the need to port of software or drivers to support Linux natively.
This will probably be plagued by incompatabilities whenever there’s a new version of Windows, much less by anyone who tries to use it on a development kernel. It may occasionally retard the creation of an oss driver. It may sometimes threaten stability – some windows drivers are awful.
Despite that, I think it’s a good thing – it gives *choice*, and supports at least one thing which is not otherwise supported. Linux will never support every piece of hardware, despite getting closer and closer to that goal. If this lets someone use linux who otherwise couldn’t, I think it’s a good thing; I personally have no plans to let it near my computers at present.
I can finally use my wireless (Dell 1180) card. I can get rid of Windows….
In the meantime we do need to keep the pressure on HW makers.
This solution might suck but if tape and glue allow me to get my car moving I’ll use them…
>“OTOH, loadable Linux Kernel drivers seem to be exempt from the GPL anyways so I guess this argument is a wash? Anyone else have comments on this method and the GPL?”
Maybe so, but unless you have a stable kernel ABI it doesn’t really matter because binary drives would lose binary compatibility each time the ABI changes.
Hmmm. A bit strong wording.
I know of an example which means no native games are developed for certain games: WineX. Besides it beeing non-free which is a huge pain, on Icculus.org i’ve readed some companies already chosen not to (provide information to) port native to Linux. OTOH, WineX has a bright side. Some companies won’t port to Linux, ever. Take the Halo game for example…
I think this project has both such a positive and a negative as well since it deals with essentialy the same problem.
Binary drivers wouldn’t lose binary compatability as the ABI changes, because – there’s a wrapper. It’s the wrapper which would need to be reworked. Compared to the differences in the Windows and Linux driver models, Linux ABI changes are fairly minor.
First they were using Windows apps and now Windows drivers. So, what next? Will people just say f**k it, decide that Linux is too much trouble, and reinstall Windows?
i agree with all the other replys above that are against this idea, i refuse to use it in my computers, and when it comes time to buy new hardware i will check with distribution websites and Linux hardware databases extensively before making purchases…
Keep Doze out of Linux!!!
I have to agree with an earlier anonymous poster on this one. This project is a true trojan horse because it sounds so good but in the end, it will only hinder the development of native Linux drivers. Manufacturers could then begin to argue “hey, we have windows drivers, and this thing can run in Linux, so why bother with native Linux drivers.”
I commend those for thinking up something like this, but in the end, it will hinder Linux, not help it.
Good or bad ?
When you need drivers for some hardware thing, and you can’t find them anyware, you’ll be glad to have this.
It may not be the best solution for Linux, but is not using the hardware any better ?
Industry is looking at one thing only: money. If one day they find a market in Linux, they’ll develop the drivers. It’s therefore great to see so much support lately from hardware companies like HP (Compaq).
We need their support to get things moving. We’ll have native drivers (for Linux), the day companies see how much users there are using it.
Couldn’t agree more.
Back in the days of Windows 3.x and OS/2 one of the problemas of having native programs on OS/2 was because OS/2 could run Windows programs as good as in Windows.
This may seem like advance for the Linux community, but it’s really a step back. Next printer drivers will be used with wrappers.
This is not a as good as the real thing. Linux and other open source operating systems deserve a better solution.
I was going to say that linux has good support for NIC’s. But i was only thinking about wired NIC’s. This is good news for laptop modems and WiFi. Though my Orinoco card works fine.
1. As much as we would like otherwise, most hardware manufacturers will only develop native drivers for Linux if they have an economic incentive to – if there is enough demand to warrant their expenditure on coding and maintaining them.
2. Demand will only come from a lot more people using Linux and asking for native drivers, either because they cant get them or because the ones that other people have coded arent up to scratch.
3. A compatability layer like this will either be *so* good that there will be no need for native drivers, or (more likely) will be somewhat inefficient. But either way it will enable more people to readily migrate to using Linux as their primary OS. If it’s brilliant, then there’s no need for a native driver (why would a manufacturer want two separate codebases to maintain?). If not then eventually there will be enough demand for them to consider making a native driver.
Perhaps the Linux community could learn a trick or two from Microsoft? They came from well behind in the spreadsheet market to dominate it with Excel by removing the barriers for people to move both back *and* forth between 123 and Excel: http://www.joelonsoftware.com/articles/fog0000000052.html
Hardware is a big barrier for Linux and a lot of people like me dual boot still, so any technology that allows more of us to flick over permanently to Linux can only be healthy.
This is one instance where I hope an open source version gets done ASAP. Normally I’d be against undercutting a commercial app, but in this case an open source spec wrapper could be used to help get drivers for many more OSes even if it means making OS driver ABI looking like Linux, whatever gets the job done.
As for the trojan issue, if a HW comp cans any Linux driver version suggesting using the wrappper when it doesn’t work, well thats a shame and their HW will just get less sales.
It wasn’t clear to me if this wrapper was strictly limited to certain class of drivers (NICs etc) or the whole gamut.
The DriverLoader folks have “sue me” written on their forehead.
It’s one thing to reimplement the Win32 core APIs, it is pretty much public. Anti-trust laws prevent MS from suing.
The NDIS wrapper interface is another thing. The DDK licence that documents it forbids using DDK technology on non-MS systems. Furthermore, they would have to reverse engineer certain MS SYS files, forbidden by the Win NT licence.
I have been waiting ages for someone to take this kind of thing on. There isn’t too much reason why drivers have to be so different for every platform – a single spec would be great – and in absence of that, a wrapper around the MS method is very cool.
If this is true, ReactOS would have the same problem…
1) Most drivers are based on sample source from Microsoft. This source is not licensed for use on anything but Windows.
2) DDK license forbids it
3) MS has patented some of their driver APIs.
4) Driver binaries distributed for Windows are licensed only for use with Windows. Each vendor would need to release under a different license. Copying the driver out of a Windows release is a license violation.
I’ve known how to do this for ten years but I don’t want the lawsuit that is sure to come.
1) Wrappers will enable more people who want to move to linux, but can’t because they absolutely *HAVE* to have …
(By the same logic WINE is NOT a Bad Thing)
2) More users will move to linux (depending o nhow they rank the other merits of the OS, not by HW availability)
3) Hardware companies will see an increased market share in linux, realize that writing a native driver will increase speed/reliability/features
they will therefore produce said native drivers in order to compete with rival hardware companies for the linux marketshare. (same holds true for apps, at least in markets where competition exists)
While it is true that some companies will use the “use the wrapper” excuse for a while, the real key to defeating this attitude is obtaining a critical mass of linux users. You can see this already — five years ago it was rather rare to see linux compatibility listed on a hardware box, and while it is still not quite common, it IS getting better due to the increase in usebase size.
This is great news, those guys at Linuxant are real champs for doing this. Lets see how this software does. I hope that the HW vendors do decide to support this project instead of trying to find ways of locking these guys out.
I would love to see native drivers, however, when you have the kernel each path release, that is, 2.4.21 to 2.4.22, compatibility is broken. Is it really necessary to break compatibility?
Sure, I can understand the need to break compatibility between major releases; things change, bugs are found and compatibility has to be put behind quality, however, I do find it rather rediculous that one cannot run a driver compiled against 2.4.21 on 2.4.22. Sure, I *COULD* forcefully insmod it, however, the end result is that compatibility is done at the risk of instability, which is unacceptable.
Now Linus has claimed that *HE* shouldn’t need to provide backwards compatibility and instead, driver manufacturers should opensource their drivers and work within the kernel source tree. I would love that to happen, I am a strong believer in opensource drivers, however, one has to be a realist and realise that not all people share that same belief. Some companies are paranoid whilst others are cheapskates who don’t want their customers to know that the wizz-bang video card is just one big software driven plastic board.
“I would love to see native drivers, however, when you have the kernel each path release, that is, 2.4.21 to 2.4.22, compatibility is broken. Is it really necessary to break compatibility?”
What exactly are you referring to? Examples?
It’s not outside the realm of possibility that wrapped Windows drivers will work better than a half-hearted native driver.
As far as the notion that the wrapper will discourage the manufacturers from writing drivers, they already have that. It seems many take the attitude that some volunteer will write drivers for them.
I think the main issue is how well it works. If it works well, then it’s good for Linux. If not, it’s not.
“I would love to see native drivers, however, when you have the kernel each path release, that is, 2.4.21 to 2.4.22, compatibility is broken. Is it really necessary to break compatibility?”
Grab a binary module from an older version of Linux, lets hypothetically say 2.4.19, and try to load it on 2.4.22. It won’t run. There are alot of modules out there that are only supplied in binary form, meaning, unless you run the the kernel which the driver was compiled against, you’re stuffed.
“Grab a binary module from an older version of Linux”
Why would one want to do that? I see little use of it.
Btw check CONFIG_MODVERSIONS in your kernel (at least in 2.4.21/2.6.0-test8). It says: […] makes it sometimes possible […].
Have you got this enabled?
Doesn`t NViDIA own a patent on the recompilable “wrapper” interface for a binary module ? i`m sure i`ve read something along those lines in a kernel mailing list discussion on binary modules.
Also why not make a seperate “driver language” and run it on a mini virtual machine of sorts ?
Simmilar in principle to java but not as bloated, fully featured, no GC etc etc
The thought of write once run on anything is kind of addictive isn`t it :p
Have you tried it yet? I just spent two days trying to get it to work on my Dell with Truemobile 1300. Gave up and ordered $42 modem that is compatible with Linux.
Btw check CONFIG_MODVERSIONS in your kernel (at least in 2.4.21/2.6.0-test8). It says: […] makes it sometimes possible […].
Have you got this enabled?
It might work, but don’t expect support from the kernel team if something goes wrong.
Let me say that I agree with the folks who say that this is a bad idea. First of all people let’s remember how and why we even have ATI drivers in the first place for ATI Radeon cards. If it were not for Nvidia providing native driver support for Linux and succeeding in drawing in a large Linux user crowd toward their cards, ATI would of never of put out Linux drivers. It’s a simple fact that once one hardware manufacture of any device starts putting out drivers for Linux others in that same area, be it video cards, sound cards, modems, ethernet cards, etc… will and shall become scared at the thought of being left behind. Now how does this happen ? Well it happens because once you get enough people to start buying hardware components with Linux in mind, this is when you start seeing a shift in the mind’s of most OEM’s. Once one OEM sees that there is a large demand for their product via mass email request or the simple fact that people start hacking native Linux drivers for their hardware they will more then likely jump in to gain an edge and brand name recognition in a new virgin market place.
The problem with these attempts of bringing in non-native drivers ( especially from windows ) or software applications is that companies are never put in a position in that they can jump in and claim the Linux market for their goods ahead of others. If a mp3 player manufacture has to compete with other mp3 manufactures because Linux users have access to windows drivers via emulation then why put any effort in making Linux native drivers ? Companies need to feel that they are gaining an edge over their rivals. This project basically takes away the edge of a company being the “Linux **insert name of generic hardware here** savior” and thus is not able to gain any advantage whatsoever by providing drivers since their own and that of their competitors are now available via emulation.
Not to mention the fact that the average user will look at this and say to him/herself “Why should I switich if I am going to use stuff in emulation mode and have my hardware work twice as hard inorder to use windows drivers ?” The truth of the matter is that they should not switch if they can get better preformance from their hardware in windows rather then in Linux. I would rather have the native preformance of windows drivers or software in windows then use it in a half-arse’d way that is slower preformance wise in Linux. Or better yet I’d rather replace that piece of hardware or shop with Linux in mind when building a PC or buying parts for my PC.
why did beos die?
drivers. lack of hardware support.
now if linux can use the same drivers as windows xp, then hardware compatibility would be assured.
even if performance is lower than native drivers, keep in mind that with multi-ghz cpus, the hit in performance would not be noticeable.
personally, i’d like to c an open-source win XP clone, that can run xp apps, xp drivers, xp hardware, but be free.
why did beos die? drivers. lack of hardware support.
Well, also the available software “sucked” as well. Here we are, around 2 years after OpenOffice source was made available and we’ve yet to see it being made available for the unwashed masses to use.
Unlike BeOS, Linux/FreeBSD both have strong hardware support. Sure, you won’t be able to run the latest wizz-bang piece of hardware from Widgets Incorporated but you’re atleast able to access zip drivers, cd-writers, flash keyrings and a decent amount of sound card support. The only thing that lets down the side is not the fact that hardware isn’t supported but the fact that not all the features are supported.
I certainly don’t blame the kernel coders, they can only reverse engineer and hack hardware so much, it is about time hardware companies came to the table and started producing drivers. If there was ever good punishment for Microsoft, it would be for hardware companies to make the source for their driver software available.
I don’t think a specific binary wrapper is the answer. If thier is ever developed a “write once, run anywhere” layer for devices than a driver VM specification should be created that is well-desigend and completely open standard. Then FreeBSD, Linux, whatever could share drivers under the same, open structure.
Of course this would add some bloat and increase latency. But also this would create a consistent framework that could improve over time and lend immediate benefit to *any* operating system that uses it. Of course any such specification would have to be carefully developed to ensure that it would remain scalable and stand the test of time.
If such a framework were in place, vendors could code their drivers *once* and constantly evolve and improve their driver code because they are only writing code for one specification. Further their could be a number of compile time code optimizations that could occur at run time, a JIT for device drivers (during initialization.) Plus this would allow devices to load and unload seamlessly and the same support would be around on any platform that supports the framework. It is just a matter of super-optimizing the framework code so that it is extremely efficient. Couple that with very mature and optimized driver code and the device layer may actually improve performance. Also consider that any improvements to either the driver or the framework could yield immediate benefits for any platform that uses it.
Sounds like a pipe dream, I know … But then again, software can do anything we tell it to do. Just a thought.
To find the good hardware manufacturers and the bad ones… the good ones will provide native drivers… BECAUSE they care on how their hardware runs!
Bad manufacturerers are of no consequence… as always…
😉
I did not like the half backed driver for conexant chip they produce, that now are priced for end user about the same price the hardware ($ 14.95)…
I won’t support in ANY way any other crap they are supposed to sell to anyone.
Their approach is stupid, drivers cannot/should not be done that way, considering that linux isn’t just x86, and that overall win32 drivers aren’t that stable…
If Linux did not provide “stable APIs”, then some other way would definately be invented.
For long time, Linux developers supported the idea “if we change the APIs often, hardware firms will have to release source code to their drivers, since they will not be able to catch up”.
But the idea backfired. Look at the RedHat-Linux-NTFS driver page for example:
http://linux-ntfs.sourceforge.net/info/redhat.html
There is a FOUR DIMENSINAL matrix, with probably around 100 differrent kernel drivers to choose from. (Mine is not listed by the way).
On good old DOS days, there was only one driver for each hardware (if we do not consiver “sound” and “video” ones).
Windows currently has only 3 different APIs: Win9x, WinNT 4.0, Windows XP
I guess everbody got the idea.
Buy hardware that is supported, either open source or the NVidia way. Steer clear of the rest.
Note that to date, I don’t know a good linux hardware reference site…. Is there one ?
Or, you could use a distro that supports NTFS.
From the Linux NTFS page…..
“6.1 Which distributions support NTFS out of the box?
The Linux Distributions that are known to support NTFS are: Mandrake, Debian, SuSE, Gentoo, Lindows and Caldera
In fact, the pattern is, that if the name isn’t RedHat, then they will support NTFS. ”
Red Hat don’t support NTFS for their own unknown reasons. (Possibly because write support is not totally safe).
The developers of the Linux kernel do not intentionally break APIs, they get enough flak from their own oss community when something changes that requires modifications to a modules code.
The problem with the Windows method and binary drivers is that your hardware becomes defunct once they move to a new API. I have around £3000 worth of specialist audio hardware that is now useless because my sequencer requires one version of Windows, and the hardware requires an older one. I could run another computer with the older windows dedicated to just that hardware I guess, but that’s such an ugly workaround for a 520k driver.
“1) Manufacturers will just tell users and Linux kernel driver developers that they do not need drivers or specs. Just use the wrapper. “
Your argument is a Trojan horse. The point is a number driver manufacturers AREN’T going to develop for Linux and have no intention to. The ones that want good support on their hardware will bother to make it work.
People say the same about Wine but the software companies that want Linux ports HAVE bothered to port. Companies that haven’t at least can now run on Linux.
Take MS Office, Dreamweaver MX and Photoshop. I doubt MS, Macromedia and Adobe have any plans to develop Linux versions in the next few years (or at all) but thanks to WINE you CAN run these programs in Linux.
I’d rather have that scenario than welcome your Trojan horse.
I do disagree with this approach, like others have so diligently pointed out. Hardware vendors have no incentive to create native drivers now. Also, Linuxant has decided to start charging for their modem drivers and limit their free version to 14.4kps which in turn cripples the users hardware. I see now for x86 I will be going with External modems for all my fax needs and they are totally supported by Linux.
Take the lindows distribution, use the XPDE desktop environment, use wineX to run applications like Internet Explorer and Microsoft Office(TM) instead of the bloated mozilla and the OpenOffice which is fine, but use by default a non-standard file format, and finally use this emulation to launch every windows hardware, and …
That´s it !
We´ve catch up, Linux beats Windows
“Take the lindows distribution, use the XPDE desktop environment, use wineX to run applications like Internet Explorer and Microsoft Office(TM) instead of the bloated mozilla and the OpenOffice which is fine, but use by default a non-standard file format, and finally use this emulation to launch every windows hardware, and …
That´s it !
We´ve catch up, Linux beats Windows”
1) As someone else earlier mentioned. You mean GNU/Linux x86.
2) WineX is not free. You don’t even need WineX to run 3/4.
3) Internet Explorer is not free.
4) Microsoft Office is not free.
5) 3 and 4 are both ”a part” of MS and Windows. How does it beat that?
6) This is not true autonomy. Microsoft can break this any time.
7) IE isn’t going to be devved anytime soon and is unsecure as hell. Mozilla and offsprings have a lot cool features IE doesn’t have. And _are_ free.
8) What’s wrong with OOo?
Is sorely needed for Linux. I think many non-critical drivers do not have to be part of the kernel. If you want them there, you can put them there. Like for example, network drivers for home computers. Performance is not really an issue. For a webserver it probably is, so those who have specialist requirements can recompile and those with very general requirements can just use HAL abstracted drivers, which hopefully will be binary compatible with many kernel releases. could even end up sharing drivers with other Unix type OSes like the BSDs and so on.
I agree this is a huge mistake. Of course i am not a fan of emulation short of old arcade ROMS.
On the one hand, anything that gets more hardware running on Linux ( or BSD ) makes me happy. But, at the same time, let’s not forget the lesson of OS/2’s excellent Win 3.1 emulation – they did it so well that hardly anyone choose to write for OS/2; they wrote for Win 3.1 and said, “Hey, it runs just fine on OS/2; less work, more sales!!”.
I’ve argued on several occasions on different forums for a more stable Linux ABI. I’ve been told that there are good reasons so far for not doing it – I confess the reasons given
went over my head – but it gives little incentive to those who simply won’t open up their source to support Linux, except for
specific kernel versions.
Will someone who is kernel-savvy explain why the ABI can’t be fixed to a major version or why it can’t be held stable for a reasonable timeframe, say 6mths to 1 year?
A few people have mentioned OS/2’s Win3.1 emulation as being a bad thing. If Wine was perfect(and integrated better) and had an active development and this thing could run all windows drivers perfectly… What’s the problem? You would still have a unix like OS. Who cares if there aren’t any “native” drivers for it as long as it gets the job done. I believe as long as a OS works at a good speed and runs the apps I want to run then it’s a good OS.
Finally, linux will support drivers written for Windows! How is this is a great thing for linux? Now linux can crash just like Windows. Instead of the blue screen of death, we can watch linux kernel panic. In the early days of Windows 90 percent of crashes were due to driver problems. Does the linux community really want to use Windows drivers in their precious OS?
This is hard to believe.
> Finally, linux will support drivers written for Windows! How is this is a great thing for linux? Now linux can crash just like Windows. Instead of the blue screen of death, we can watch linux kernel panic. In the early days of Windows 90 percent of crashes were due to driver problems. Does the linux community really want to use Windows drivers in their precious OS?
This is hard to believe.
If it allows hardware to work, go for it. Something is better then nothing!!!
“In the early days of Windows 90 percent of crashes were due to driver problems.”
No, 90% of crashes were caused by applications in the early days of windows as it had insufficient memory protection. So pretty much any app misbehaving could take down the entire OS. (I was there in the Win’95 days, and still have the scars to prove it
It would also leak memory like a sieve.
Now, since the NT derived versions (2000,XP) have become popular, windows is quite stable, but like Linux, it can still be a pig if you have dodgy drivers.
Hmm, I think SciTech SNAP solves the binary driver issue already and has been proven on millions of machines;)
>>> The NDIS wrapper interface is another thing. The DDK licence that documents it forbids using DDK technology on non-MS systems. Furthermore, they would have to reverse engineer certain MS SYS files, forbidden by the Win NT licence. <<<
Not necessarily; this is a hairy legal area. Explicit provisions in TRIPS and national implementations of copyright law typically allow for reverse engineering IFF the purpose is to determine interface behaviour to produce interoperable software, and only IFF the manufacturer does not provide documentation of the interface behaviour. This is for various reasons, including competition law.
Also, end user restrictions that prohibit competition (i.e. EULA that specify that software can “only run” on a certain type of system) are very very dubious and would probably not stand up in court.
I think that these people probably have nothing to worry about. Any reverse engineering they’ve carried out seems entirely for the end goal of producing an interoperable implementation. If any EULA provisions are prohibiting this, I’m thinking that those provisions probably wouldn’t stand up in a court of law. I don’t think that anyone will sue them.
Of course, using your hardware with a “wrapped” driver on such a system will probably void your warranty – which is fair enough IMHO.
Perhaps this is a new crowd or perhaps I have failed to get this point across earlier…. Binary compatibility is the key fundamental behind SciTech SNAP! SciTech SNAP provides both a stable and fully tested API as well as a very formalized HW abstraction layer.
To date we have successfully supported Linux, QNX, DOS, OS/2, SMX, Qt/Embedded, Windows, and more with the SciTech SNAP API, and SciTech SNAP Graphics binaries. In addition to this wide sweeping support we are often times able to out perform the OEM/OS specific drivers and typically prove to be more stable.
To date we have certified 150+ SciTech SNAP Graphics binaries for use with XFree 4.0.2 – 4.3 and are shipping these same SciTech certified binaries for use on other OS’es for customers such as HP, ATI, IBM, and more.
Have you used Windows drivers? Blech, and the same for the crappy software which you must install at the same time. E.g. HP Winprinters and Winmodems. Saving $5 to end up pulling my hair out over hardware not working later is not my idea of a good time or a solution.
We will end up losing any performance gained by having a faster processor.
Can I get FULL 3d hardware support for my Radeon 9700 Pro ? If not then you are wasting my time.
“1) As someone else earlier mentioned. You mean GNU/Linux x86.”
Do we still have people out there if that are offended if the GNU is dropped and the OS is simply referred to as ‘Linux’?
I’m using these drivers fine with my TrueMobile 1300.