Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Software Operating Systems Windows Linux

Windows Drivers Under Linux? 474

Posted by michael from the last-resort dept.
sniggly writes "The Inquirer has an article about how Montreal, CA based Linuxant has created a 'compatibility wrapper' allowing standard Windows NDIS 5.0 drivers to work on linux. After pointing to another project allowing windows printer drivers to work on OS/2 the author asks 'Are printer and network card drivers going to become, over time, a commodity with Win32 drivers one day the 'de-facto standard' run via wrappers?"
This discussion has been archived. No new comments can be posted.

Windows Drivers Under Linux? More

Windows Drivers Under Linux?

Comments Filter:

  • Instability (Score:5, Interesting)

    by Anonymous Coward on Sunday October 19, 2003 @01:24PM (#7254998)
    Most of the BSOD in Windows 2K/XP are caused by unstable drivers. Will using these drivers in these wrappers destabilize Linux as well?
    • As long as these wrappers don't have a good and secure "separation" layer - yes, it will.
      I imagine this wrapper as a kernel module (i.e. it gets part of the kernel) which itself loads the windows drivers. I.e. the windows driver it more or less part of the kernel and as such can bring the kernel down if it acts stupid.

    • Re:Instability (Score:3, Interesting)

      by cymen ( 8178 )
      Think of the opposite -- using these drivers on Linux could finally clear up which drivers are responsible for the crashing the system and absolve Microsoft from blame (in these specific cases). Free driver stability testing, apply within. Kernel compilation experience required.

    • Re:Instability (Score:4, Interesting)

      by mausmalone ( 594185 ) on Sunday October 19, 2003 @02:47PM (#7255503) Homepage Journal
      If there's one thing you can definitely hand to the Linux development community, its error handling. I bet if the driver dies, the wrapper will tell you something like "______________ Win32 driver has crashed. Restarting driver in 5..4..3..2..1"

    • Re:Instability (Score:4, Informative)

      by AKnightCowboy ( 608632 ) on Sunday October 19, 2003 @03:12PM (#7255645)
      Most of the BSOD in Windows 2K/XP are caused by unstable drivers.

      That's true. Unstable drivers and faulty hardware. People always complain about BSOD under Windows, but since Win2k you should never get a BSOD anymore unless your hardware is broken somehow. For example, I kept getting lockups and blue screens but I traced it down to faulty memory. Another time it was an overheating video card because the fan on it died. Win2k is actually one of the most stable operating systems I've ever run.

      • Re:Instability (Score:3, Informative)

        by Lothsahn ( 221388 )
        Erm, sorta.

        You shouldn't get a BSOD often unless:

        a) Your hardware is broken
        b) Your hardware's drivers have bugs in them

        I have also had windows BSOD once or twice in my usage because of actual bugs in windows.

        I did get BSOD's fairly often, which traced to a memory controller. That of course was fixed with a replacement board, but I still get them.

        For instance, until 44.03, Nvidia's drivers had some funky bugs in them for the Geforce DDR and the Geforce FX 4600... on both cards my systems would crash w
      • I've got myself BSOD on Win2K just after installing update patches. The hardware worked fine before, and it works fine after reinstalling the system. The booting Linux for testing also did not find anything wrong with hardware.

        Another several lockups with BSOD were caused by unstable NTFS. I wonder how many more decades Microsoft will deliver that must-already-be-dead filesystem?

        Somebody, fix the moderation of the parent properly!

      • Re:Instability (Score:3, Informative)

        by pi_rules ( 123171 ) *

        That's true. Unstable drivers and faulty hardware. People always complain about BSOD under Windows, but since Win2k you should never get a BSOD anymore unless your hardware is broken somehow. For example, I kept getting lockups and blue screens but I traced it down to faulty memory. Another time it was an overheating video card because the fan on it died. Win2k is actually one of the most stable operating systems I've ever run.

        Never? Really....

        Run 'RhymBox' on your system for a while... then start up Net

    • Given that BSODs are caused not because the system is in its final death bed, but rather because the driver violated some very very abstract conditions such as running at a higher DIRQL mainly, or throwing an exception, I suspect the incidence of BSOD causing events should decrease, not increase, since Linux kernel is not pre-emtible/interruptible as Windows' is, because the kernel is not pageable as Windows' is, and also because throwing an exception in kernel mode linux, AFAIK doesn't panic the kernel.

  • Cool (Score:3, Interesting)

    by gilesjuk ( 604902 ) <giles@jones.zen@co@uk> on Sunday October 19, 2003 @01:25PM (#7255008)
    I mentioned ages ago that this would solve a lot of driver shortages. Now if this layer can snoop and aid the development of Linux drivers then even better. Of course laws can be broken with this approach.
    • I'll be honest - and this is NOT a flame or a troll - I don't care whether it is against the law or not. When I buy a printer, I'll use it with whatever OS I want, regardless of the license to which I have tacitly (or otherwise) agreed.

      My own rights of possession supercede any contracts that I might sign, any EULA, or the letter of any law. If I have to be an outlaw to fully use something that I own, c'est la vie.

      Of course, the definition of "ownership" can be problematic for some people, but if I paid
    • or perhaps lead to some driver API that would allow easy creation of cross platform drivers for certain device classes. If a good enough api layer would allow simple recompiles to target linux or windows, THEN we would see many more native drivers (plus some resistance to kernel revision changes). Laziness is the most powerful force in human nature.

      the current "kernel driver modules that break or have to be recompiled for every kernel update or option change" totally sucks. the GPL ideology hasn't worked f

  • Funny windows drivers (Score:5, Insightful)

    by bobthemuse ( 574400 ) on Sunday October 19, 2003 @01:25PM (#7255009)
    What about all the windows drivers which have a 'light' NDIS layer solely to establish a communications channel with the hardware and assignment of resources. They then rely on more complex programs to do what should happen in the driver.

    I'm thinking of several printers, including the new MFDs, not to mention the separate mess called 'WinModems'.

  • Native Drivers, Please (Score:5, Insightful)

    by nurb432 ( 527695 ) on Sunday October 19, 2003 @01:26PM (#7255011) Homepage Journal
    No thanks, id rather have native drivers for my hardware. Not some sort of kludgy hack to make windows drivers work..

    Even if it worked well, there is no guarantee that Microsoft wouldn't make it impossible to keep doing this, leaving us out in the cold.

    + you cant honestly think performance and stability would be the same as a true, well written, native driver for your chosen OS ( regardless of what that OS is )
    • You do realize, that some memory resident program that interprets drivers on behalf of the user.. is like a JVM (or Parrot) which interprets specially formated byte code programs?

      Parrot and the JVM are of course, more current. Your OS runs your programs on your behalf too.

      All this thing is, is a consistent layer that interprets something. Hardly a cludge.
      • I agree this does take place all the time, but i dont want low level drivers to be ran 'virtually'.

        Application virtualization is bad enough as far as im concerned, but its hard to avoid 100%.

        Actally, I prefer to compile even my java and python, when possible, and dump the VM layer.
        • Why not? Some linux programs run faster under Freebsd linux emulation, but on the whole, they run about the same speed. Same with WINE programs. Yes, native is all nice and neat, but with emulation in place to emulate proven drivers, a proven emulator will give many more drivers and many more linux driver writers w/o them knowing it.
      • You do realize, that some memory resident program that interprets drivers on behalf of the user.. is like a JVM (or Parrot) which interprets specially formated byte code programs?

        Well, if you are saying that the driver-wrapper actually reads the x86 binary, and interprets that, then you really have a marvel of engineering.

        But what makes sense, and would probably be possible to do is to just create a wrapper. The driver expects certain "hooks" to be able to talk to Windows. The wrapper provides them, and

    • Re:Native Drivers, Please (Score:4, Insightful)

      by loucura! ( 247834 ) on Sunday October 19, 2003 @01:33PM (#7255056)
      Even if it worked well, there is no guarantee that Microsoft wouldn't make it impossible to keep doing this, leaving us out in the cold.

      The thing is, though, that Microsoft's driver APIs have to remain stable if they're going to get hardware manufacturers to write drivers for them. If they start making changes that break this driver compatibility layer, then they also break current drivers. There's no way to make the layer break without breaking backwards compatibility, and that still won't prevent you from using pre-break drivers.

      • Re:Native Drivers, Please (Score:3, Interesting)

        by PCM2 ( 4486 )

        The thing is, though, that Microsoft's driver APIs have to remain stable if they're going to get hardware manufacturers to write drivers for them. If they start making changes that break this driver compatibility layer, then they also break current drivers.

        Well, Apple has done this regularly, so I don't see why Microsoft wouldn't. I think it was the release of Mac OS X 10.2 ("Jaguar") that broke everybody's printer drivers ... printers that used to work with the earlier versions. Apple works with the ma

        • Since they've alienated Brother, I would assume that Brother won't be supporting OSX with their printers for a while. Apple can afford to be picky, because Apple users expect to get the shaft when it comes to hardware. Windows users don't, so if Microsoft makes its driver API a moving target, it will only hurt them in the long run.
    • You missed the point. There ARE NO native drivers available for some things. This will be a big step if this works well, as this will be perfect for many companies (and end users) that don't go to linux because a piece of hardware will not work. I'm one of them and am looking forward to this...
    • No thanks, id rather have native drivers for my hardware. Not some sort of kludgy hack to make windows drivers work.

      Are you going to write those native drivers? Many of them do not exist today.

      I'd rather have a kludgy hack then no drivers.
    • By relying on Windows' binary drivers wouldn't we also lose our ability to run on alternate architectures ? This sort of thing might be great for OS/2, which is already pretty much dead, but it could only weaken Linux.

      Now, on the other hand, if hardware manufacturers want to do this, write a common binary and provide wrappers for various platforms, I'm all for it. After all, it's better than nothing.
    • The reliability aspects of this are indeed dreadful, but could possibly be overcome if each driver ran in its own individual MMU-protected virtual machine. User-space module and driver mechanisms already exist, so this wouldn't be such a huge leap.

      That could ensure that diver code never tramples on any other code and only communicates with the rest of the O/S via fixed interfaces. It could still hang of course, but dealing with that would be no different to dealing with other misbehaving user processes,
    • No thanks, id rather have native drivers for my hardware.

      This remind me I2O. If I remember corectly, I2O idea is to have OS-indepedent drivers supplied and connected to real OS via think I2O layer. This idea seems dead, althrough.

  • Not likely. (Score:2, Insightful)

    by Anonymous Coward
    Are printer and network card drivers going to become, over time, a commodity with Win32 drivers one day the 'de-facto standard' run via wrappers?

    Not a snowball's chance in Hell. A large part of Microsoft's power rests in limited device support for other OS's. They will keep the OS-specific requirements alive. This whole thing is a cool trick, but it's in the "why bother" class, along with NetBEUI for Linux.

  • Ultimate Lock In (Score:5, Insightful)

    by Crashmarik ( 635988 ) on Sunday October 19, 2003 @01:26PM (#7255015)
    Not a good thing. If Drivers are written for windows and then emulated to other OS's it will give Windows a permanent performance advantage.

    • Re:Ultimate Lock In (Score:5, Insightful)

      by Hard_Code ( 49548 ) on Sunday October 19, 2003 @02:34PM (#7255415)
      "If Drivers are written for windows and then emulated to other OS's it will give Windows a permanent performance advantage."

      If drivers are written for windows and then "emulated" (not really emulated, just run through an abstraction API), it will render windows IRRELEVANT. Slow drivers run infinitely faster than NO DRIVERS. Once the drivers become commoditized a HUGE reason is eliminated for keeping Windows around (the current main reasons being ubiquity of 1) applications 2) drivers; we have already achieved #1).

      Drivers are only really a performance concern (as far as an abstraction layer is concerned) for things like graphics card drivers, which are already woefully absent in Linux (and of course they change frequently as the technology is updated). I'd wager most "desktop" users of Linux don't even have kernels recompiled for their specific CPU, so I think an abstraction layer isn't going to make much of a difference.
      • To follow up, once the compatibility is there, regardless of whether it is slow, there will suddenly be inertia to improve it, and a target for some of the big players to throw money at to improve (it's always easier to improve a good thing that already exists, than to be the one to invest in it to begin with). It will also provide a migration path for current driver writers. Rewriting drivers entirely (especially for an operating system with such a low market at this point) is not a feasible migration pa
      • Drivers are only really a performance concern (as far as an abstraction layer is concerned) for things like graphics card drivers

        Graphics cards
        Storage Devices
        Network Cards
        Data Acquisition Devices
        Serial Ports
        Manufacturing Equipment

        Oh well just off the top of my head. The above are all things where people get very upset about performance hits. Believe me when you have 64 serial ports serving terminals on a system you feel the pain of interrupt latency.

        Rendering Windows Irrelevant are you ev

  • Intel should sponsor this (Score:3, Insightful)

    by chevybowtie ( 96127 ) * on Sunday October 19, 2003 @01:28PM (#7255021)
    The way I see it, all of these layers of software are what are going to require faster processors. What exactly will you not be able to do next year with the 3Ghz processor you bought this year? Then again, are these layers going to cause bugs that can never be found?
  • It costs $15 to use the modem driver which is more money than I paid for my network card and modem combined.

    Unless of course you only need to access your modem for 30 days.

    The store can be found Here [linuxant.com]
  • It's kind of like MPlayer's win32 codecs -- very practical and a great way to pollute your system with proprietary crap. In other words it's great for open source advocates and evil for free software advocates (myself included). Actually, this Windows drivers, codecs, formats, APIs (Office, Wine, .Net, etc.) it is a very interesting issue where free software differs from open source. Great article.
    • very practical and a great way to pollute your system with proprietary crap. In other words it's great for open source advocates and evil for free software advocates (myself included).

      If the 1% of proprietary crap on your system makes it usable, with the option being a 100% proprietary environment, I'm all for the little bit of proprietary crap. If proprietary stuff brings more users, more and better Free Software will be developed.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Sunday October 19, 2003 @01:32PM (#7255053)
    Comment removed based on user account deletion
    • I agree.

      OS/2 advocates often point the fact that OS/2 being a "better Windows than Windows" strangled the OS/2 application development industry in it's cradle.

      Who would write applications for OS/2 when you could just write them for Windows and they would run on OS/2 without problems?

      Similarly, who would want to develop drivers for Linux when Linux runs Windows drivers without problems? Devices on Linux would always be subjected to extra layers that may or may not allow access to all of the device featur

    • I don't have a problem with third-party companies trying to sell Linux drivers for hardware. Those of us who actually do research will buy hardware for which Linux drivers already exist, or can be made with relative ease (well, for those versed with Linux driver programming, I am not).

      The main thing to consider is that very few companies make native Linux drivers for their products (well, consumer products anyway). So in that aspect, we're already getting zero support from them. I don't see any reason f

    • Re:Bad idea (Score:4, Interesting)

      by IamTheRealMike ( 537420 ) on Sunday October 19, 2003 @01:50PM (#7255158)
      I don't think you can draw comparisons.

      Firstly, writing a new driver for Linux is several orders of magnitude easier than rewriting an entire application for portability. A program like MS Office will never, ever be a "native" app, say that uses GTK, Qt, whatever - it's far too huge to ever rewrite in that way.

      A driver, on the other hand, is not so complex, and can be more easily developed independantly, especially by the community.

      Really, Wine is useful primarily for apps that will never, ever be ported. I've seen little evidence that it discourages companies from doing native ports. I've seen quite a few companies do native ports even when their programs worked just fine in Wine. Only time will tell if this has bad effects or not.

    • On the other hand, this can make Linux work with more hardware which will make Linux more popular (e.g. with more government agencies considering using Linux, Linuxant can make the lack of device drivers one less excuse to avoid adoption). The increased popularity in turn will compel companies to write native Linux drivers.

      We should kill of Linuxant before they hurt anyone.

      I hope this was written in jest. Otherwise, we'd be stooping to some of the same tactics that made Microsoft so infamous. Let people
    • Wait. How many native linux drivers are out there? How many *bsd ones? Ones that are written by the companies, not by some random guy who figures out how to get the NCR53c875 card to work.

      Yes.. that is an actual card.. may have gotten the first two digits wrong :)
    • We should kill of Linuxant before they hurt anyone.

      But, they are also making native Linux drivers for Conexant Win-modems. This is a good thing for those who are unfortunate enough to be stuck with one.

  • Cross Platform Driver Standards (Score:5, Interesting)

    by hillct ( 230132 ) on Sunday October 19, 2003 @01:42PM (#7255095) Homepage Journal
    While on one level it's great to see this sort of standardization, one has to ask whether standardization on the WIndows driver architecture is the best choice. This is what standards organizations are for. While I like OSS as much as the next guy, and things like Wine, or other compatibility layers such as those mentioned in the article are certainly valuable in their own right, They shouldn't be seen as a mechanism for promoting standards. This just promotes adoption of proprietary mechanisms as de-facto standards, which is seldom a good thing.

    I'm just waiting for Microsoft alter their EULA to disallow software written using their (presumably patented) driver architecture and copyrighted APIs on competing platforms, in a bid to deter hardware manufacturers from providing linux support by increasing the development costs for linux support through preventing unified cross-platform driver development.

    --CTH

  • That's nice, but ... (Score:3, Insightful)

    by Kourino ( 206616 ) on Sunday October 19, 2003 @01:45PM (#7255119) Homepage
    Great, now Linux can be Windows compatible and crash just as much as Windows does! The most common cause for Windows crashes these days, I'm told, is bad drivers, not Windows itself. Do we really want to use such drivers?
    • Yes, but that would be bad drivers within the Windows enviroment.

      The bad drivers may trigger the crash, but the crash itself is still due to a flaw in the OS. In Windows everything is tightly tied to everything else making the whole structure brittle.

      In UNIX and Unix alikes things are more modular with every function keeping its own place and continuing to chug along when something else goes screwy.

      It's the prime reason that DARPA ended up giving Unix favored status for internet infrastructure. The core
  • This is so cool. Turn the whole MSDN / Win32 API into an ISO standard. Once this happens, Linux just absorbs the millions of existing programs, and hardware out there. If they could get this working for 3D Video cards I would gladly pay for it.

    If only Microsoft could be so smart. I have an old sound card that still works, but the company went under so there are no new drivers for XP and it won't work.

    Now should we use ECMA, ISO or some other standards body? Is it possible for windows to be defined as

  • WinPrinters/WinModems (Score:3, Interesting)

    by rf0 ( 159958 ) <rghf@fsck.me.uk> on Sunday October 19, 2003 @01:45PM (#7255127) Homepage
    Would this driver help WinPrinters/WinModems work under linux as with there bgin so many driver types as WinModems being such a 1/2 way house.

    Rus
  • Well, I think it's a good idea at least for the short term. I'm on the freedesktop.org mailing list, which gets a lot of debate about things like "Why is X so darn slow?" Alan Cox and other have opined that X seems to be slow because there is little to no 2D hardware accelleration in most Linux video drivers. I'm talking about things like moving the mouse cursor in hardware, or fast hardware blits to copy rectangles (eg windows) around on the screen.

    If this product could solve the problem of 2D hardwar

  • performance and stability (Score:3, Insightful)

    by updog ( 608318 ) on Sunday October 19, 2003 @01:48PM (#7255144) Homepage
    These are the most important aspects of a device driver - if you have a buggy app, it will just crash; but a buggy driver can take down your entire system.

    Also, a driver might typically be running 24/7 on a server, managing hundreds of packets per seconds, so stability and performance are of utmost importance.

    A wrapper is a nice idea, but definitely adds overhead, and probably makes the system less stable.

    • I'm going out on a limb here, but if I were setting up another server running linux, I'd at least make sure that all the hardware I'm using is properly supported under linux. There aren't going to be many servers requiring this, I'm guessing. Sure, you can mention print servers, but most schools and companies are now willing to spring for a ps or ip available printer.

      P

  • Do we need this? No today, less tomorrow... (Score:3, Insightful)

    by jurgen ( 14843 ) on Sunday October 19, 2003 @01:49PM (#7255152)
    Are printer and network card drivers going to become, over time, a commodity with Win32 drivers one day the 'de-facto standard' run via wrappers?
    First off as we all know from painful experience, a lot of windows drivers quite buggy. Since we have zero chance at fixing them (closed source), the only time anyone will use them is if they absolutely have to. Even with Windows drivers available and sort-of-linux-compatible, most people will continue to buy hardware that's directly supported under Linux... they will rightly expect it to work better.

    Secondly, this is becoming less and less of an issue. More and more add-on hardware is built on standardized models of hardware interaction, such as the USB driver classes, and thus works with the generic drivers in the Linux kernel. Of the remainder, more and more hardware companies are seeing the value in cooperating with Open Source and opening up their specs. The probability that a random piece of peripheral hardware you bought at CompUSA or some such will work with Linux out of the box has been steadily increasing and is now quite high.

    In short, this is a non-issue.

    • I agree with your point about drivers under linux. I recently bought a playstation controller adapter to use with ePSXe, a playstation emulator. It's made by Soyo and connects via usb. Well, guess what? I plugged it in and usbview showed a 'psx-usb pad'. So I plugged a playstation controller into it, configured Omnijoy in ePSXe, and I was ready to get my game on. I couldn't believe everything worked so well.

      On the other hand, I tried it on my evil twin pc running XP (it's for my wife and roommate). After

  • RE: native drivers (Score:4, Insightful)

    by vlad_petric ( 94134 ) on Sunday October 19, 2003 @01:51PM (#7255160) Homepage
    Native drivers are obviously the right choice in the long term, but emulation is something that can break the vicious adoption cycle (hardware manufacturers aren't going to provide drivers until there is enough demand, while demand is small because of lack of drivers).

    Take a look at the linux games area - Loki is dead, Transgaming is alive and well ... Loki's approach was technically superior (very stable ports as opposed to games which play ok, but only ok), but the economics were not.

    Emulation is good for creating a market; when the market is big enough, native ports and drivers will arrive as well.

    • Emulation is good for creating a market; when the market is big enough, native ports and drivers will arrive as well.
      Commodore Business Machines tried this with the Commodore 128. It was completely backward compatible with the Commodore 64, You would hold down a key on boot and it would boot into C64 mode. This actually kept the C128 from catching on - every C128 sold was just another C64 in the market so network effects simply strengthened the C64 software base and little C128 software was written beca
      • Well, there are two companies that understood compatibility (Intel and MS), and look where they are now ... Now how long did it take for 32 bit to truly replace 16 bit ? About a decade. If it takes Linux a decade to replace Windows (with compatibility tricks, if necessary) I'll personally be very happy about it.

        PS2 runs PS1 games, but you also get so much more from a PS2 game.

    • So it's not really a fair example. Take a look at the harrowing [linuxandmain.com] tale. It would be a shame if we collectively forgot this early part of Linux (in business) history and wrote if off as an example of why Linux isn't ready for business. Loki, or more specifically, Scott Draeker wasn't ready for business.

      Besides, lets not write off companies like Linux Game Publishing [linuxgamepublishing.com] (or ID Software [idsoftware.com] or Epic Games [epicgames.com] or ..).
      • ... since it was precisely Carmack who said (2y ago I believe) that "All linux games combined didn't sell more copies than an average windows one" (very aprox. quote)

        Neither of these 2 companies actually make money with Linux sales (I believe that they do cover porting costs, but nothing more than that)

        Yes, LGP is great - my heart is with them. When a good game (that I also like) comes from them, my money will be with them, too ...

  • All of us with 54G laptops with broadcom drivers now have some hope to use our wireless cards in our laptops. It also may spur Broadcom to provide drivers for Linux.

  • usb hardware? (Score:2, Insightful)

    by Richard_J_N ( 631241 )
    Actually, network cards, modems and printers aren't really that interesting. There are usually choices (except if it's a laptop), and so you can always just buy something compatible. The real place this would be useful is in the case of "weird" hardware where it would be wonderful to be able to have WINE work with the driver. For example, the Psion Wavefinder (USB Digital radio receiver) which at the time was $60, and the only way to get digital radio for less than $450. There is often no alternative to "w
    • It's *very* interesting in the case of Broadcom's programmable wireless chipsets -- Broadcom has been pressured by the gubmint to avoid giving out programming specs as their networking cards are in fact fully programmable software radios (and could be used to break all kinds of FCC regulations); for that reason, the likelihood of open source drivers being forthcoming is quite low.
    • No need to bother with emulation. Just learn a bit of C, read some of the official USB specification, and write your own driver program (using USB Snoopy on windows to see what gets sent to the hardware). It took me a weekend to write a driver with libusb, and that's with virtually zero prior knowledge. Now granted, it isn't a proper driver per se, but it works.
  • Win32 drivers one day the 'de-facto standard'

    If this is done, I'd hope it would be for Win64 drivers. Why spend good effort on what (we hope) will soon be an obsolete standard?

  • Since the windows drivers are x86 only and even the module is closed source, this will only work for Linux on x86 architecture.
    A native Linux driver would be much more preferable since you could use it on all platforms supported by Linux.This would also be an advantage for the hardware manufacturers because they would get instantly (maybe not instantly but soon) support for those platforms and increase their customer base.
    Working with an adaptation layer seems great in the short run, but hurts a lot in the
  • I'm glad that I'm going to get WiFi hardware very soon, so I won't have to use my modem for my laptop anymore. I won't pay; I'll just hold on to the old beta drivers which, despite what Linuxant says, are of good quality. Hell, I'd rather keep a 2.4 kernel around and boot that to use the modem.

    Of course, we mustn't blame Linuxant for being forced to "play the money game."
  • Microsoft doesn't want to do anything to aid the compeititon. For certain MS would not allow any drivers they write to be used for free in other OS's, and can clearly be expected to add to any shrinkwrap license (if it's not already there) that even purchasing a legal copy of Windows does not entitle you to use any part of it under any other OS. Even the act of decompiling a Windows distribution might run afoul of the (truely awful) DMCA.

    Also expect them to pressure any other driver writers who what the

  • I never really have any trouble finding linux support for hardware that I use. I used to, back when I started with linux (about 4 or 5 years ago). I imagine this would help some with more obscure hardware, but even then it would be limited by the fact that the drivers will no doubt be slower than native ones. For example, I can't imagine using this with a high quality sound card without getting audio artifacts from buffer underruns. For non-real time kinds of communications (umm... digital cameras, i guess)
  • In a monolith such as Linux, drivers run in kernel mode. This gives them the highest level of permissions available.

    We verify the stability of such drivers?
    And if bugs are found, we cannot do anything about them until our driver providers decides to fix them.
    How could we check what else it might be doing?
    If we grow to depend on these proprietary additions, how will we fight overactive-DRM?

    I think it is short-sighted to see this as a solution.
  • Comment removed based on user account deletion
  • Windows drivers have a hard time working even between different releases of Windows. Furthermore, they usually come with complicated GUIs for setting parameters in driver-specific ways.

    And why would you want to? I have generally found Windows drivers to be junk; they usually look like they are produced by minimum wage programmers. Most vendors probably don't produce open source drivers because they are too embarrassed to share their code and because they don't have the engineering documentation to share
  • I think this is a great step forward for Linux. Hardware compatibility is one of linux's weaknesses. The only problem I see with this is a problem that exists in windows. I have a stack of hardware that doesn't have drivers for win2k or XP. From companies that are still in business. Yeah, I probably should spend the money for more expensive stuff, but oh well.

    This would be GREAT for the linmodem project.
  • I can see where this would work for miniport drivers (drivers that use a restricted API, like network drivers and SCSI drivers) but for full drivers? I can't believe it.
  • The most vivid thing I remember of windows was the shitty drivers.
  • Compatability layer? How about just pushing Linux compatability? How about making it something hardware marketing cronies will notice: a better Logo! If I see the original Tux [linuxbase.org] logo [linuxtested.com] one more time I'm going to lose it. Marketing people need something they feel adds value, why not throw them a decent icon [everaldo.com]?

    We have never had some much potential interest as now.

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close