Slashdot Mirror
Windows Drivers Under Linux?
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?"
nt
I think it's safe to say this opens up a whole new world of compatibility here. I've actually wondered about this before and if it was possible, and it's nice to see that someone wiser than myself followed up on that "wonder." Very cool. I'm sure we'll all want to follow this one.
Yeah, but does it work on Mac OS X?
Most of the BSOD in Windows 2K/XP are caused by unstable drivers. Will using these drivers in these wrappers destabilize Linux as well?
YOU FAIL IT. Props to the GNAA!
PS: the fp was mine, sucka.
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.
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'.
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 )
---- Booth was a patriot ----
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.
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.
..it is incorporated without being buggy. Everybody mentions WINE but nobody mentions mplayer, which is mostly stable. I think it could be a good thing. No one says it has to be used by everyone though. Look how far Linux drvelopment has come so far.
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
Thank you Mario! But our princess is in another castle!
...in linux, except that in kernel 2.7, some wacked out kernel devs would start forcing the need to write code to make the wrapper for windows vxd|dll driver files effectively broken.
I follow the SDK and GDN principles.. Spelling Dont Kount, Grammer Dont Neither
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.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
This is an even worse idea than WINE. The only thing we'll gain from this is even fewer native Linux drivers. Im sure that if this works, many hardware companies won't even consider making native Linux drivers, because users can just use DriverLoader.
Things like DriverLoader and WINE are and will be misused by companies to claim Linux compatability or make quick and low quality Linux solutions. It would be great if it where to be used only as a last resort, not as a permanent solution.
We should kill of Linuxant before they hurt anyone.
Mac OS X is a real operating sytem. Manufacturers provide drivers for us.
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.
---- Booth was a patriot ----
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
--Got Lists? | Top 95 Star Wars Line
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?
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 a standard or is it just too damn big?
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
Cheap UK and US VPS
If this product could solve the problem of 2D hardware acceleration, then it might ease the desktop adoption of Linux and *BDS.
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.
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.
But it probably still wont support my WLAN card. :-(
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.
The Raven
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.
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 "weird" hardware - anothe brand with similar function may not exist.
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?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
just wondering which province CA is?
How about hacking GTK to use the Win32 file dialog. That way we won't have to put up with the monstrositry that it is!
Actually we hardass OSS fanboys refuse to use crippled hardware like Win Modems and Win Printers.
So the whole premise for this kluge software is Moot!
The users that buy winmodems get Windows "free" with their system. They will not try OSS, because it requires thinking outside of the comfortable box. The Linux/*BSD community tends to know enough to build their own boxes or if time constrained, they order them with fully functioning components.
Freedom requires a bit of effort - Slavery just requires apathy.
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 long run. Manufacturers will use it as an excuse not to give
specs to driver developers and users will get less usability out of their hardware. You just need to look at the Linux DVB drivers and compare their features to the Windows one. Linux gets a whole lot more out of the hardware.
***Quis custodiet ipsos custodes***
I am a freshman at a college whose standard issue laptop (Dell D600) has a centrino processor, which Linux does not yet support fully. This means that if I am to use the wireless that blankets the entire campus, I have to boot to windows (They come dual booting XP pro and Redhat 9). I am no Linux ninja, but I would really like to learn. However, if it means carrying around a piece of cat5 while everyone else can walk free... I doubt this would be a great solution for true linux ninjas, but for newbs like me and my classmates, it is a welcome addition. Besides, Olin is so awe inspiring that they are probably already purchasing copies of this for all 75 of us right now.
www.olin.edu
Proprietary drivers are against the GNU philosophy, under which Linux is developed and distributed.
The new 2.6 kernel series goes a step further in this direction, by forcing all proprietary drivers (like nvidia-glx) to run at the lowest priority.
Hardware manufactoreres shuold release their drivers open sourced. If they refuse to do this, I will not buy them. Linuxant had a great idea, but it's in the wrong direction.
Before people start replying that I'm a "linux zealot" or Stallman's biatch, let me state this: I am not paying my money for my software: a linux distro and oss replacements for common applications. The least I can do is respect the authors vision and contribute to it. This means promoting open source software by using it, and refusing to run proprietaru software.
Hack your mind out of its sandbox.
It seems a pity that we need drivers at all. Why can't devices provide java- or other-based interfaces which neatly plug in to a generic OS layer? Admittedly, some types of devices (read: cutting edge) need specifics, but with open standards, I cannot see why network cards, scanners and printers should require OS-specific drivers.
Atheism is a non-prophet organisation
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, and if the problem is severe enough to lock up the hardware under the driver's control then it'll do so regardless of the implementation.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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."
Also expect them to pressure any other driver writers who what their drivers certified by MS and/or included in any MS distribution to require the same. (This is obvious, not insightful.)
Of course, MS can put anything -- legal or not -- into their shrinkwrap and click-through licenses, however it will remain the de facto condition and limitation until your lawyers and lobbiests beat their lawyers and lobbiests in court and Congress.
IIRC MS has successfully scared off attempts to run compiled Foxpro applications under other operating systems, and even prevented printing of benchmarks, with their license terms.
TANJ! (Look it up. Hint: Larry Niven.)
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
After 12 years, the Linux zealot's ancient 386 machine gives up up the ghost! The machine went through alot, going through DOS 5.0, 6.0, Windows 3.11, Windows 95, Windows 98 and Debian gnu/Linux. It even had a Geforce 4 on it using a AGP to ISA converter.
But now the machine was dead. So the Linux zealot decided to go to the local PC world to get a new machine.
He decided to get a Athlon 3500+ Packard Bell, when all of a sudden he heard a giant DUNNNNNNNNNN! And behind him, was the largest cheese greater in the world! Behind him was this fat bearded geek with an Apple logo on his chest. He was an Apple zealot. Suddenly Linux zealot had a weired feeling as a Giant Titatainum X appeared on a huge LCD display.
The titanium X span around a huge smiling blue face, while a cube appeared and rotated towards a desktop. The Apple Zealot started to talk about his Mac affection, and how he was going to buy a G5 to complete his collection, but the price, was almost 5,000 EUR, while the packard bell only costs 2000 EUR, and was noticbly faster. The spinning rainbow ball span for ages while it attempted to copy a 17 Mb mp3 file onto the zealot's iPOD. The Zealot said it was due to the fact that this machine was running the 68k version of OS X, and if you ran the G5 version it would only take two minutes, if that.
[ to be continued ]
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) I guess another layer isn't a big problem.
====
Crudely Drawn Games
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.
Expert in software patents or patent law? Contribute to the ESP wiki!
Not just no, But Hell No!!!
i wont use any Linux drivers that use this technology, i would sooner go buy new hardware after consulting support from a Linux distributer or a Linux hardware database, i want to use a pure Linux so bad and stay far away from that evil M$FT Windoze so much that i would build my computer & perifrials around Linux...
Don't pollute Linux with this crap, plz...
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 because the C128 owners could just use the C64 version.
Of course at the time 64/128 compatibility was all-or-nothing, you couldn't have C64 software running in the C128 environment. Nowadays with multitasking systems the norm and translation layers the lesson from CBM may not hold.
Shh.
I hate nee rrddds and will beat them up any chance I get! Your're next!
Hello,
I'm a great believer in hardware compatibility lists. I've been burned twice where it appeared that a bit of hardware would work, because there was supposed to be a linux driver, but it didn't work properly.
I especially like FreeBSD's attitude. If it is listed, it will surely work. If it isn't listed, you are on your own.
Consequently, I never, ever, buy gear that isn't listed.
Best wishes,
Bob
This is a very small bone. NDIS is the network driver standard. This is nice, as noted, for WiFi card owners, but other than that it doesn't buy us much. Hell finding an NDIS 5 driver for some older cards will be nigh-impossible, so it doesn't buy us much greater compatibility than we already had, except at the bleeding edge.
It does nothing for modems, video, scanners, USB chipsets, etc etc etc etc.
On OS/2 they are emulating printer drivers. I suspect this is easier to do on OS/2 than it would be on Linux given the similarity of the OS/2 printing structure to Microsoft's own setup in Win32.
These are clever hacks but I doubt it is going to go much further, and doesn't alter the landscape all that much. Kudos to the authors, but the struggle to maintain hardware support for non-mainstream OS' continues.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
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 to let others write their own drivers. You are better off buying hardware only from those vendors that actually have the engineering documentation and insight to allow others to write open source drivers.
In different words, if you can't get open source drivers for a piece of hardware, the hardware is usually no good anyway (yes, and in that I include the closed-source-only graphics cards "for Linux").
I got this card and asking other linux owners to hang it on the wall. Like some posters suggested it's better to comply with Open Source spirit than use this dirty compatibility layer.
I am true linux zealot. I smoke the weed, use emacs and don't use half of my hardware because I want to be O.K with myself.
Seriously, people get real and have a drink if you are so stubborn and narrow-minded. Look at the life at least once positively.
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 reading through dozens of message boards bitching about it, I found out that the drivers that ship with it won't work for XP. You'll launch a game and it'll lock up your pc. Well, that's wonderful. After some more digging I found some beta drivers that work (or are supposed to, haven't really tried it in windows fully).
The whole driver situation, particularly for edge peripherals like this, is pretty funny. Mandrake 9.1 supported it out of the box (along with my Microsoft Sidewinder gamepad), while windows needed not only drivers, but SPECIAL drivers.
I'm really starting to feel sorry for XP users.
This isn't really relevant here, but someone has to say it somewhere: is it just me, or has reading slashdot become like swimming through tar in the last few weeks? It frequently seems extremely slow - can it be that slashdot is finally being slashdotted? I think an upgrade is called for.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Given how far back on the technology curve MS seems to be as a whole and Bill Gate's own decrying of 64-bit apps, I wouldn't hold your breath waiting for Win64. I wouldn't count on it working either. High-priority MS items often have a ton of bugs - imagine how many a low-priority MS item is going to have...
Peter M. Dodge,
Chief Executive Officer,
LiquidFire Studios
Platinum Linux - www.
Writing drivers seems to be the real bug in adoption of new operating systems.
,not to far with processor getting faster by the day ,i predict we will have software that can take hardware and chip specs and write drivers on the fly.
Someday in the future
This would be quite interesting for winmodems (and other hardware with seriously broken design and/or drivers). "But", you might ask, "why would anybody want a winmodem?".
The answer is simple: notebooks. In (too) many notebooks, linux-challenged hardware exists, which simply cannot be removed or upgraded. An emulation layer could provide a sufficiently good solution, for situtions where a piece of hardware/a notebook is quite attractive, except for a few driver related issues.
And please don't come with the "it will hurt driver development" - did wine ever hurt linux application development?
With great numbers come great responsibility!
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.
-- Having a Creationist Museum is like having an Atheist place of worship
Aren't we missing the most important reason not to use binary drivers - platform independence. The Linux kernel supports 16 architectures. If you use Windoze drivers you will be restricted to 1 namely i386.
I think that the idea is an interesting way to circumvent the problems with equipment for wich the manufacturer is not willing to supply information under acceptable conditions like CANON on its Scanners.
Maybe that someone from the SANE people will check the feasability?
CU
Does the Win32 device driver architecture actually hold water, or is it junk compared to the way Linux does it? If Win32's model is worth something, it might not be a horrible thing for those drivers to become the standard.
Say if all the hardware developers (or some of the biggest, atleast at first) made a collabarative effort in putting togheter a standard for drivers, that isn`t either windows og linux drivers. This standard could then be implemented in the oses, maybe not as the standard, but at least as an option. Then maybe, over time, linux,windows,bsd and all the other oses out there would improve theyr implementation of these drivers (the buzzword here is "long-term implementation"). so, maybe, in the next 2-3-->10 years, we would have a standard driver interface, which would benefit both the hardware manufactors (more customers), and the consumers (A standard driver that fits all oses). I understand that this won`t be easy, but what great benefits this could lead to, but the gains would absolutely outweigh the downs.
:)
my utopian, wet geek dream
Doolittle :
Bomb no.20 : To explode of course.
So it's not really a fair example. Take a look at the harrowing 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 (or ID Software or Epic Games or
Quack, quack.
"...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?" "
There is nothing more irritating than printing from Linux. I don't mean a Windoze machine printing to a Linux server running Samba. I'm talking about a native Linux app printing directly to a color printer attached via USB, since that appears to be the new standard.
If a universal standard, i.e. Windoze printer drivers, can be used with Linux, the sooner the better. Native printing on Linux is a major weakness. Until this is addressed, most people will continue using M$ Windoze.
Hardware should be documented. Ever heard of data sheets?
The problem is not Linux's "hardware compatibility"... Or any other operating systems so called 'incompatibility' with hardware...
It is the hardware's incompatibility with open systems.
There were ideas to end the tyranny of platform specific hacks (they call them drivers)
There was an initutive around 1996 which called for platform independent drivers for hardware - I2O.
However, it was encouraged to die because companies like Microsoft know that by welding and tying things together is a excellent way to maximize profits.
What is really needed is an OSS approved driver which loads platform-independent drivers (which are permitted to be closed source).
End the lock-in tyranny!
-- The universe began. Life started on a billion worlds...
-- Except on one where stupidity was there first.
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 ...
The Raven
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.
Clear, Dark Skies
Would this make other hardware manufacturers lazy? Instead of porting to native, they might just use the emulation layer? Just wondering whether this is double-edged sword after all.
The most vivid thing I remember of windows was the shitty drivers.
Malike Bamiyi wanted my assistance.
This is only useful if (for some idiotic reason) the NIC manufacturer did not decide to release specs. In that case, though, it might be more appropriate to boycott the luddite.
What? We can have our own drivers! With blackjack and hookers!
-r
Dyslectics of the world, untie!
Bill Gates must be very unhappy with this development
It's really a shame that the potential of JINI never materialized for this same problem.
Think of how nice it would've been to plug a device in and have it automagically make its platform independent driver and configuration software available to the local network. Theoretically, it wouldn't matter if the device was a printer, scanner or toaster or whether the machines on the network were Windows, Linux or eComstation or even a mixture of all of them. No drivers to install, simply plug in the device and it would just work. Although that's, surely an overly rosey view, it sure has a lot of appeal and it's a shame that there wasn't much of a serious effort to even try to make it work.
I was very surprised that there wasn't a huge demand from the user community for the universal adoption of JINI for this sort of application. Even the year after JINI was introduced, there was only ONE demonstration product on the show floor at JavaOne -- a JINI enabled digital camera. Now, JINI seems to be relegated to a specialized web services niche.
Signatures are a waste of bandwi (buffering...)
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 logo one more time I'm going to lose it. Marketing people need something they feel adds value, why not throw them a decent icon?
We have never had some much potential interest as now.
Quack, quack.
ago. I'm not saying the market is big, but its there and any of us who consider ourselves advocate or fans should do our best to support it, and I believe emulation takes away from that.
Quack, quack.
They are slow.
Driver Operation and Comments
The RTL8129 series is a low-cost design, and thus should be considered a "connectivity solution" rather a performance-oriented product.
The RTL8139 series improves on the integration and feature set, adding advanced features such as 802.3x Flow Control and incorporating the transceiver onto a single chip. The data transfer engine remains the same, with much improved PCI burst performance in the B and C versions.
While the chip is a bus master, it's not a descriptor-based bus master. The receive side transfers packets into a single linear ring (compile-time selectable as 8KB, 16KB, 32KB or 64KB) in host memory. The driver immediately copies the packets from the ring to newly-allocated buffers ("skbuffs"). Most other Fast Ethernet designs use a descriptor-based architecture, which allows packets the chip to transfer directly into pre-allocated maximum-sized skbuffs. The driver then optionally copies only tiny packets into smaller-sized skbuffs.
On the transmit side four register sets hold the address and size of the packets to be transmitted. While this results in a rather small, fixed-size transmit queue, four entries is adequate for full performance in most environments.
The transmit performance loss comes from an initially undocumented (yes, that means it took many hours to find) word-alignment requirement of the current chip. Linux cache-aligns the IP header and following payload data when constructing a packet. When the 14 byte Ethernet header is prepended, the complete packet is 2-byte aligned, but not 4-byte aligned. The result is that all IP packets must be copied to an alignment buffer before being queued for transmit.
The state of printing on linux is shite. I bought a Epson C60 for my wife to print out her photos. This printer is reported on linuxprinting.org as "works perfectly". Our Red Hat 7.3 machine drove it just fine. Then after upgrading to Red Hat 9, it couldn't even print the nozzle check (escputil -n) without gaps and the wrong colors.
After spending literally hours reading around on www.linuxprinting.org, trying various things and getting completely confused by gimp-print, ijs, stp, CUPS, ppd, foomatic, uniprint, half of which are never explained, I tried the printer from inside VMWare. Just plugged the printer into the USB, inserted the CD that came with the printer, and was printing photos perfectly within a couple of minutes. Sigh.
Score: VMWare 1, Windows 1, Linux -1.
What happened to printing between RH 7.3 and 9?
How about making a windows wrapper for a linux driver?
.sig
As a driver developer, I'd much rather write the driver once,
then use wrappers for the windows95, windows98, windows2000, windowsME, and windowsXP versions.
Oh and wrappers for the dozen Mac OS versions too.
-- this is not a
I've spent the last 14 months breaking the bond$ of M$ $lavery and I have no intentions of loading any M$ products into any of my Linux boxes. I simply won't do it.
I'm sure that a vast majority of the *nix users here are of the same opinion.
Why downgrade your box??
WxWindows appears to be the solution, yet it is "is a free C++ framework that facilitates cross platform software development, including GUIs, threads, sockets, database, file system access, etc." I remember of a sourceforge-hosted project that dealt specifically with cross-platform driver development, but the memory evades me at the moment. After a quick-search of google, appears Jungo WinDriver, but that wasn't the one I was thinking of.
I know there will be a lot of comments out there about the speed/stability of these drivers. I have a couple of thoughts about that.
I don't know how this wrapper system works but it could be written in a way such that a faulty windows driver being run through a wrapper couldn't take down the kernel. How? Create a kernel modle with a devicenode, use ioctl creatively and make a user-space harness to handle the windows stuff and pass it through to the module through the device. That way all of the nonsense is handled in userspace and a well tested , minimal, "pass-through" module in linux would provide all neccesary services. Neccesarily, only root should have access to this device node but that does without saying.
Also, the ultimate goal for this should not be 'lets replace the linux driver architecture with a windows one', but 'lets find a way to provide immediate compatibility with off-the-shelf hardware before a native driver can be written'.
If your scanner worked 10% slower, would you care? If you're in the industry of course you would, but as an individual? How about transferring pics to and from your digital camera. How's 1:06 as opposed to a minute sound? no big deal. This gives the linux kernel automatic compatibility with devices which is a good thing, even if the compatibility is slower/less stable.
Brian
We want Linux drivers under Linux. Otherwise we'll simply be chasing moving goalposts. Get it?
This is wonderful news. Hardware compatability is Microsoft's edge. With driver compatability layers others operatings systems will break Microsoft's influence on hardware developers and even give an edge to Free OS's as they will be able to wrap drivers from abandoned platforms as well. Performance will NOT be impared that much until wrapers are available for video drivers. A user first wants it to work, then he wants it to perform better. One step at a time. With an emulation layer on linux, OS driver developers will be able to work from their prefered OS to analyze what the drivers are doing. It's easier to spy on hardware from Linux and other open operating systems. The technique will be ported to Freebsd and then to OSX. I would expect analysis tools to be co developed along with wrapper layers eventually. We will finally have a practical way to find out how hardware works and be able to document it. Wrappers are a tool, not the end goal.
Native drivers are obviously the right choice in the long term, but emulation is something that can break the vicious adoption cycle.
Maybe, but how do you revert back to the more ideal situation, where drivers are native _and_ Open Source? (since the windows drivers work just fine).
What you have just done is demonstrate to hardware manufacturers is that binary only drivers are 'ok'. Which they are not. Drivers are the single biggest cause for erratic behaving systems, especially Windows, and without source it will be much harder to track down where things go wrong, let alone correct them.
Regarding this actual emulation layer; this is the worst to choose! NDIS is not a great driver architecture to say the least. (maybe M$'s best, but that says little). To write a network driver for Linux is a lot easier and hence less prone to error. (without prior knowledge of Unix or Linux I wrote a basic Linux driver in what amounted to less than a day, I spent more than a week on an NDIS driver and I really never knew for sure it was 100% stable)
Also, the network hardware support is one of the few areas where Linux is NOT that far behind, if at all. There are (open source) drivers for most network chips/cards, and it seems to be the only area where hardware vendors feel that they have to support Linux. Why reverse this?
I mean, I used to select chips for embedded boards that we made and we were using an in-house OS. This meant that it was important that we could get programming details on the chips that we ued. I've NEVER had problems with network chips (well, except oddly enough some Intel chips). The hardest were usually the graphics chips, especially the MPEG decoding and 3D hardware acceleration parts.
What I'm saying is, if you _really_ want to do this PLEASE don't choose NDIS. A much better choice would be graphics, but I have to admit that with the oogles of layers of drivers for Windows it's practically impossible to do that.
...does this mean my winmodem will work?
Doing this is fine for the x86, but it means that other architectures are shut out. Apple PPC and Sparc-based equipment have the ability to use some of the same hardware, but this solution means that drivers will not be accessible to them. Do we really want all our eggs in the WinIntel basket?
I'd rather see this used as a tool to make reverse engineering easier. Of course, for that to be true, it would probably require that the wrappers be open source.
Sounds like a lose-lose proposition, for short-term gain.
Can You Say Linux? I Knew That You Could.
Umm... wrong. *Very* wrong. Users that buy Winmodems may get Windows with their system... but has it occurred to you that maybe, just maybe, they might want to *try* Linux? That perhaps they're tired of Windows crashes and want to move to something better? If their sole connection to the internet is via a modem, and there isn't a Linux driver available for it, they probably won't buy a new modem just to get it to work in Linux; they'll go back to using Windows. I was an exception- I bought a new modem. Turns out it was a WinModem, too. The frustration led me to abandon Linux for two years.
Had this project been around, I might not have left Linux behind. I might have relegated my WinXP partition to games.
Yes, the Linux/*BSD community tends to know enough to avoid WinModems. However, if Linux is to gain a foothold on the desktop, hardware compatibility is a must. Linux won't be free if you have to buy new hardware for it, now will it?
Great idea. Also, I want a magical pony that shits native open source drivers and sings the GPL. I think that this is good news overall. Some driver support is better than none (in the desktop space, that is).
"My God, this must be a truly remarkable corn chip, to be so widely and confidently touted."
Think DMCA. Think thrustworthy computing. Think Palladium. Now think that Microsoft won't like it a bit and they will do anything to destroy this wrapping technique.
I don't speak (proper) English, you insensitive clod!
P.S. Can I lick your weiner?
P.S.S. I believe the comma is supposed to go INSIDE the trailing quotation mark.
That's what.
If you have a graphical app you want portable between Linux, Windows, then you use WxWindows, which will compile on both with the right userland build setup.
What that has to do with drivers is beyond me. It also appears to be beyond you.
Fuck Beta. Fuck Dice
it won't be a problem.
The logic being that it's no "excuse" for hardware manufacturers if their linux userbase has to pay for driver support from a 3rd party before they can use their Windows driver.
It will limit acceptance, so to reach a wider audience the hardware maker will still have to consider opening enough documentation to get a localized implementation (or do it themselves).
Or they are ignoring the linux end-user, in which case they don't know either way, and a driver will never exist. And those who choose to pay will get to use their hardware anyway. How is that problematic?
Linux doesn't have enough marketshare to create a boycott situation to certain vendors: emulation helps to fill in the gaps until cross-OS support becomes trendy.
And hopefully, as more devices start to attach to systems across platform neutral interconnects (i.e. USB, IEEE1394, etc.) it will be possible to have true cross-platform drivers that run in userspace with a consistent API for the hardware type. At least attempting to implement a binary-compatibility API is a step in that direction (even if this particular case is not a good example).
Fuck Beta. Fuck Dice
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!
Less is more !
I disagree. If hardware manufacturers are able to cop out on the Linux drivers by using emulation, they will. If they don't have to produce specs so that other people can create decent drivers, they won't.
If they can't cop out, they'll be forced to actually listen to their customers and port the dam thing over -- or provide specs so that someone else can do it.
In the end, forcing them to do the right thing will result in faster drivers.
In the short term, it may mean that there are fewer drivers, but those are better quality.
Think of what will happen if you settle for the cop-out. Linux starts to become unstable and slow because of faulty emulated drivers. As a result, Linux's growth decreases because the stability advantage of Linux over Window is reduced. Since Linux isn't growing as fast, there's less pressure to create a native port and as a result, they will continue cop out. Worse than that, Linux will always be playing catchup to Microsoft driver standards. While Microsoft doesn't obsolete it's driver support, they have a way of creating new driver layers that leave the old ones in the dust. Emulation, like the emulation in WINE, would always be a little flaky, so Linux would start be be more flaky than Windows.
It's a viscous cycle that works both ways.
If Linux continues to be stable and high performing, it will attract more market share and force hardware developers to port their drivers or provide specs.
Windows does this itself internally. Win16 code is still valid for use on the Win32 environment. The way this accomplished is via the thunking layer. Writing direct calls for this can and does provide improved performance for emulators. Of course this is just a case of writing a better emulator than microsofts.
No being dependant on other operating systems native drivers is not a good thing. Wrappers for network or modem drivers will be a very very bad thing. Winmodems by themselves are pretty crappy for windows. Doing them worse on linux will only put linux one behind on another issue.
Maybe if you stopped oogling over girly pictures, you would recognize that I expressed I could not remember the name of the sourceforge project and thus I provided one "WxWindows" and one "Jungo WinDrive" that I remember well. Stop being a baby over it, pr0ntab.
I'm not sure how you could go about doing this, but wouldn't it be more useful make a wrapper for Linux drivers on Windows?
Now while the short term bennifit of this is next to nothing (with the exception of philosophical benifits), in the long run it would encourage vendors to develop for Linux. Linux would be the lowest common denominator, and developing for it would save money.
I think thats the way to get hardware vendor support for linux.
It's already happened once. With Word Perfect. Corel put out version 8 of Word Perfect, and by all counts it was/is one of the best word processors ever put out for Linux. But, the next version they didn't bother porting to Linux, they used some wierd setup with WINE and as a result version 9 sucked eggs on Linux.
The WINE people and now these Linuxant people have laudible goals, but if everything works fine through the compatibility layers then eventually nothing will be written natively. Only now it's drivers instead of applications.
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
But the lawyers went ape shit over it. You'll notice that the Windows SDKs and DDKs specifically mention that you'll not use them to develop drivers that can run on other operating systems.
Plus as we learned on OS/2 with the Win32s emulation, Microsoft will rev the spec once a month to keep the emulation broken.
--Rob
Sounds like the architecture. of the Hurd.
I did some small work on Project UDI, the Uniform Driver Interface. It attempts to make a consistent DDI across all platforms. It aims to make device drivers source compatible across all platforms, and binary compatible across architectures with the same C ABI. Pretty slick, you don't need to worry about synchronization primitives, the environment handles all that for you, giving you ways of handling interupts, getting memory... etc.
Caldera was one of the big supporters actually, back in the "lets, Idunno, actually ENGINEER something that people would want to buy" instead of getting the lawyers involved. Never really went anywhere unfortunately. The big OSes don't need it because people already make drivers for them. The smaller ones tended to have philosophical differences (RMS hated it for Linux, made it easier for binary only drivers he thought). I'ts been pretty much dead since 2001, being in the odd place of having drivers but no OSes.
Just what I want, Windows drivers on my Linux box. Just what I need, the very things which Microsoft tends to blame for the majority of its software hiccups to be on my Linux box, making it as crash-worthy, slow, and crappy as can be.
Personally, I think that the best solution may be to crete a sort of universal spec. for drivers, where everybody would write drivers to that spec, and then, after a bit of testing, the drivers could be impletmented into any OS which implements that spec, like BSD, Linux, Plan9, even the proprietary Unices. Personally, I think that this may be better in the long run, because then the hardware companies only have to write one driver, and then it'll work with every system.
And of course, the best are open-sourced drivers, like the vast majority of Linux and BSD's drivers today (except for a few *cough*nVidia*cough*). That way everybody can have a look at the source code, see where any problems may lie, and then fix them themselves. I'm sure that any well-used drivers will quickly have virtually all bugs stomped out of them, making everybody's overall experience much better.
Efforts like this are dangerous for the same reason that OS/2's Windows compatibility layer killed OS/2: it removes any incentive for vendors to support you natively. They'll just develop for Windows alone and assume you come along for the ride. (but judging from the quality of MS's kernel APIs and most third-party Windows drivers, we don't WANT them...)
This is a trojan horse that will have two 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.
Pragmatism as an ideology is not particularly pragmatic in the long term. Keep it in mind when you dismiss Free Software
Linux already has pretty damn good network drivers - I'm not sure what would be the advantage of instead using drivers written for a windows pc - I certainly can't think of any, and in fact I can see several downsides, not the least of which is the idea of carrying along this legacy windows baggage for no reason, in addition to the peformance penalities which such a kludge would incur. The last thing we would want is for driver writers to all write drivers for windows pcs and then consider their job done, that would be a giant step backwards.
From the article:
"Both come from small developers outside Silicon Valley, which makes one wonder why nobody inside the billion-dollar labs of "innovative" mega-corporations like Carly Fiorina's or Palmisano's thoughts about this."
Uh, I think she already laid those folks off. Companies that have taken the short cut of only supplying Windows drivers for their hardware have tied their fortunes and futures directly to Microsoft. The good news is that former giants such as HP don't actually design or manufacture any of their own hardware any more, nor do they have any control over what drivers come supplied with them. That means that no matter how buddy buddy they are with Microsoft there will probably be drivers for these products produced in the country of origin for the international market.
"Can OSes like Unix and Linux gain market share by "piggy-backing" on win32 driver development in an ironic twist of "embrace and extend" that this time takes advantage of Microsoft's driver market share to hurt them and let users move to other platforms?"
yep yep, however I don't think such measures will be necessary for long. The vast majority of PCs in the future will be small ready to go configurations and the notion that you would buy a network, video, or sound card will be largely a thing of the past (based on the prices in Microcenter for these items I'd say it already is). Fewer players means less for Linux hackers to reverse engineer and the companies that differentiate themselves by supplying Linux drivers out of the box will do very well in some areas. Restrictive technologies that have nothing to recommend them other than (perhaps) the force of US laws (DRM) will ultimately fail with devastating consequences to those companies that embrace them.
If Microsoft wants to continue the fight against Open Source (somehow Brare Fox and the Tar baby come to mind) then they had better merge with a hardware company and start coming out with the driver of the week that only they support. I can't see this being a winning strategy for long either for Microsoft or for any duopoly they want to construct. They'll go down the tubes together or separately, makes no difference to me.
No thanks, keep the lawyers out of my Linux box please.
Taking Windows drivers and loading them on a Linux box will open a Intellectual Property Rights can O worms, which is not worth it.
The reason to even write a new OS instead of using Windows, is to have the source code to fix things.
Now you are telling me you are going to binary my drivers?
Why not just use Windows?
Really OPEN means OPEN. I do not want a closed OS. I want the source code for my drivers, so I can fix problems, or others can fix it for me.
I do not want to wait after 15 or 20 reboots a day for the next 3 months till a company gets around to fixing its crappy software.
If you want to do compatibility with Windows at the user or application layer, fine, I do not care.
But don't SCREW WITH MY OPEN SOURCE OS KERNEL GUYS.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
WxWindows = GUI (which is why you thought of it, parent mentioned it)
WinDrive = userland drivers
pr0ntab = jaded. Forgive his cold nature.
Fuck Beta. Fuck Dice
Linuxant explains why they're charing money for their drivers here: https://www.linuxant.com/store/faq.php
----
Not to be confused with Col.
Nothing like this will ever work for very long. The minute support for this type of emulation becomes usable, M$ will release an improved or upgraded driver framework.
One of the reasons many people are afraid of linux is driver availability. M$ has a vested interest in ensuring it stays that way.
Apart fromt the part that most of the Windows BSODs are caused by drivers, there might be other issues such as performance.
About my subject line, I said it is a double-edged sword, because this could be a way to accelerate making-a-lot-of-hardware-work-with-linux programme, but on the other hand, it could possibly stifle the development of native drivers (both by vendors and independent developers).
I am actually more worried about the independent developers losing interest in writing native drives, because the very same drivers from vendors that crashed windows ran without any problem with the Linux kernel, but were written by independent developers.
The drivers developed for the Linux kernel also seems to be devoid of all the superfluous system tray utilities that are required to use many of the hardware that comes with PCs these days.
I thougt drivers were supposed to sit quitely under the OS and be used ;-), but in the Windows world, installing drivers seem to insist on having some utilities running and constantly nagging about contacting its company via the net. And if you switch off these nasty programs the hardware stops to function. The same hardware, runs without any complaint or running any daemons or stuff with the Linux kernel.
I am quite cofused, here so anyone who can confirm/correct my assumptions would be nice.
Thanks
asdfsadfasdfasdfasdfasdf
This drops the cost to almost nothing, and shifts the hard work to the OS.
The problem is, DSP isn't easy. It's not a hobby effort. things like OSes and compilers and GUIs have been worked on since the 60s. There are plenty of books that discuss them, and plenty of reference code, so college dropouts and pimple-faced teenagers can work on without a problem. In 20 years, DSP might be just as pedestrian.
For now, at least, the DSP needed for a dumb-modem requires a masters degree and a lot of time to devote to it. A couple years ago, someone offered $50,000 for a GPL DSP that would work with winmodems. That money has gone unclaimed.
Win printers are a lot easier. Instead of using a printer language like VT100, postscript, or HPL, the printer driver renders a graphic of the page in memory, compresses it, and then dumps it to the printer. It's time consuming to reverse engineer, but not terribly difficult.
Sure Win2K is far more stable than Win9x. And the NTFS reliability seems much better than NT4 SP4.
P ollard/FGA/c srss-backspace-bug.html
But anyone who implies no nonhardware related BSOD "since W2K" probably has little experience with W2K.
Example:
http://homepages.tesco.net/~J.deBoyne
Only fixed in W2K service pack 3.
I've managed to reproduce the bug on a default install W2K. Bug gone with service pack 3. Fixed in service pack 4 too.
i won't go into the design flaws in this "product", but let's just say it's shoddy at best. anyway, i downloaded the free trial and got my free license key (a license to use a driver i already have on hardware i already paid for? Thanks.) and set it up on my lappy. i wanted to get my new Buffalo Wireless Notebook Adapter-G (which was listed as a working product on their page) working. the damn thing did not work. first the shitty from-scratch CGI app kept fucking up. then when it did "upload" the driver to the closed-source kernel module, the thing just wouldn't work. i worked all night on it and finally gave up out of frustration. no WAY i'm paying $15 for this piece of shit. open source it or let broadcom create closed-source drivers, but i'm not dealing with this wrapper BULLSHIT. i'll just return the card and order an Orinoco Gold (no, i won't get the 802.11g, but at least it actually has working drivers and a slot for an antenna pigtail - not to mention monitor mode).
Yawn, been there, done that:
Right after Novell acquired Unix from AT&T (think pre-UnixWare 2.1 days) they needed to improve the dismal hardware support since the stock SVR4 ES/MP kernel was hardly "productized", particularly NIC driver support (and graphics, but I won't go there). Netware had a bunch of stable NLM NIC drivers so they threw a bunch of talented engineers at the problem and soon the ODI driver was born. The Novell UNIX engineer simply fed the NLM as input to the transmogrifier (seriously, that was its name!) and out popped an ELF Driver.o file which could be turned into a dynamically loadable module with idbuild -M and subsequently dynamically loaded into the kernel via UnixWare's modadmin command. There was some glue layers in the kernel that handled locking, interrupts, and function pointer games but it worked amazingly well for its time and instantly gave UnixWare 2.x a bunch of NIC drivers that otherwise wouldn't exist from the respective IHV.
The other oft-forgotten Novell technology in Unixware 2.x and early UnixWare 7 is NDS. Novell licensed the technology to SCO and a few other UNIX vendors at the time and their directory services offerings were the best around (in their day, of course).
But I digress...
For the curious, go google on unixware and "niccfg", "ndcfg", or "bcfg"
There is no such thing as Win32 drivers.
What about a comprehensive, cross platform, FREE (as in LGPL or some license that allows proprietary drivers), driver SDK? Rather than porting drivers to various kernels, can't we write to a driver SDK?
Telling a vendor to recompile on Linux is easier than getting them to rewrite the driver entirely.
I wonder how many points in the GPL this breaks. I would think quite a few. Last I looked, "few" windows drivers were OpenSourced, much less GPL'd.
I'll let the rest of slashdot argue (mostly uselessly in the first 262 posts!) about whether its the right future direction or not... I'll try to do something more constructive like seeing if the darn thing actually works or not!!
</rant>
That out of my system...
Executive Summary: Yeah it works... I'm writing this over a fairly fast (2.6 mbps) 802.11g+cable connection. One big gotcha as of right now (version 1.05 of the driver) -- no WPA support. I had to drop my router to 128 bit WEP instead.
My setup:
Steps:
- Get the Windows driver from Dell [ http://www.linuxant.com/drivers_bcmwl/compatibili
t y.php ] and extract it under winxp. Copy the TMSetup subdirectory to a partition that is accessible to redhat (or at least the two files bcmwl5.inf and bcmwl5.sys)
- Get the rpm (follow the instructions [ http://www.linuxant.com/drivers_bcmwl/bcmwl5/inst
a ll.php ] on the Linuxant drivers page to make sure you get the right iX86 rpm -- mine was i686)
- Install the rpm -- notice it says you need to connect to http://localhost:18020 to finish the install. When I tried it it was asking for my root password... I'm not a fan of providing my root pwd to strange apps so here's what I did:
- Went as root in a terminal and killed the process titled bcmwl5webconfd.
- cd to
/usr/lib/bcmwl5driverloader and edited the file bcmwl5driverloader.conf and changed $UseAuth=0 (it was 1).
- Restarted bcmwl5webconfd again and followed the instructions to point it to the
.inf and the .sys file. Followed the instructions on the lunxiant site to get the driver license (30 days... yeah I know THAT sucks... especially now that I know it works!). Plug in the license key and email address you use (use a real one... you need to confirm receipt of email and confirmation key) into the setup and you are all set as far the install is concerned.
- Kill the bcmwl5webconfd daemon now.
- Start->System Tools->Network Device Control and add the device. I added it as eth1. My setting in the wireless settings tab are
- Mode is Auto
- I specified my SSID (its not broadcast on my network)
- Fixed the channel
- Entered the WEP hex key (stupid note: when it says hex keys should be prefixed by 0x -- please do it!)
- That was pretty much it... Activated the driver and it worked just fine. Checked stats using ipconfig -a... tested it by disabling (and removing the cable from) my lan connection. Tested the speeds for just the wireless and then with both interfaces up...
- Enjoy Wireless 802.11g freedom!
:)
Its up two hours and counting...The intelligent approach to this (given many other comments to this story about how manufacturers will now drop Linux drivers and use DriverLoader, etc) is that what this company should be doing is:
(a) developing a common driver interface (CDI) that is portable for both Windows, Linux, BSD, etc;
(b) _then_ producing the wrappers that allow existing Windows drivers to adapt to this new driver interface;
(c) _then_ convincing manufacturers that they produce to the CDI, and once a CDI driver is creaed, it will work on all platfoms by way of a small harness;
This would be good way to go about it: as it would please all stakeholders and have more of a chance of gaining adoption.
I really wish those people who complain about hardware compatability stopped and thought for a second. It isn't the Linux hackers' fault that your hardware is not supported. It isn't like they have the specs to your hardware sat around, and they just can't be assed to write a driver.
While hardware manufacturers continue to create cheap "Windows Only" hardware, without any publicly available specs, and refuse to support Linux, this problem will always exist. It is no ones fault but the hardware manufacturers, and complaining about "Linux" isn't going to solve anything.
Of course I do demand full access to the source code.
You completely missed the whole point here but I don't blame you since I used the broad term "system" which you misunderstood. I was talking about the operating system (OS). I was sure it was obvious from the context, but then again it apparently wasn't. But I am probably wasting my time as from your irrational anger it looks like you are one of those people who feel obligated to point out to vegetarians that they are eating plankton while they are swimming, for no reason other that the miserable need to prove they are full of sh*t.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
In other words you are in the open source camp (see OSI) -- pragmatical and practical imperatives, in the oposition to purely ideological and political ones of free software movement (see FSF). This is exactly what I was talking about.
As for making the system "usable" I have really no idea how having pure free software system (in The Church of Emacs sense) renders it somhow "unusable." I don't need Windows drivers, since I don't buy crappy hardware without support in my kernel. I don't need win32 codecs for MPlayer, since I don't pirate movies. I don't need patent-violating MP3 players since I don't pirate music, which means I can have all of my CDs ripped to superior in every way Xiph Ogg Vorbis format.
I also don't care about more users -- only about more developers and with my Debian those are completely orthogonal (I don't use commercial GNU distroes, with which I admit that the user base is indeed important).
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Unfortunately (from your perspective anyway) 64bit versions of windows are in the final phases of beta testing, and it seems to be working rather well from every report I've read ...
...to "winmodem"
Either that, or it reinforces the existing meaning.
tasks(723) drafts(105) languages(484) examples(29106)
Windows Server 2003 doesn't support the PXE binaries that all prior versions of Windows (for x86) do.
It's kinda sad, really. I expect they're still going to get bit by all the companies that rely on custom software to handle their operations.
On the other hand, portions of their Office suite have become sophisticated enough to serve as custom applications. Think of Access. And, to a lesser extent, Excel.
tasks(723) drafts(105) languages(484) examples(29106)
I've been thinking for some time now that it should not be very difficult to have linux use the windows modem drivers at least for
hardware modems, because those are only files with AT commands and responses.
I know them quite intimately, because of my current job, but don't know where to put the result of parsing the files. One should need something a little more sophisticated as wvdial.conf or something like that.
Anybody knows if something like this is already happening?
Adriaan
RogerWilco the Adventurous Janitor
I say make it like a kernel wrapper.
would run using a kernel module or patch, and would work like binfmt_misc or something along thosel ines..
it would access the module for hardware and kernel access, then use the wrapper to use the drivers, which would support the hardware..
so you could use the drivers almost like kernel modules, except they would load through one driver, and it would provide functionality to the kernel, etc.
that would be a decent idea for compatibility with windows drivers, (and a lot of future linux users would be please with the fact that their scanner will work, or their camera, or joystick or whatever until an official linux driver is written or a individual creates his own driver that (often) works better than the official driver.
Back in '94 Windows NT reportedly supported a POSIX interface (I've never seen anyone use it in all these years). However the implementation routed thru the WIN32 interface, which pretty much guaranteed that Windows apps under NT would be more effecient than Unix apps using the POSIX subsystem.
Can someone seriously propose doing the same with device drivers? Perhaps if they did I could use my ATI 9700 PRO under FreeBSD running X, but why bother? It would make using such a graphics card redundant.
I think we're entering dangerous territory here. Management like to think in terms of these layers of compatibility, but in the long run they produce unsupportable solutions. When it breaks where do you begin to look and how much will it cost to find the problem and sort it?
Emulating printer drivers on linux wouldn't be that big a deal. I've considered it myself, all you need is a filter to ghostscript that outputs to a Windows GDI device, and then a wine type (wine doesn't deal with this level last I checked, but it would help getting there) layer to get to the printer. The ghostscript output wouldn't be easy, but if you want to cheat that, there are windows programs that read postscript that you could run through wine, and use them to print.
A lot of extra layers so it is expensive CPU wise, but CPU cycles are cheap nowadays.
I'm with you 99%.
Leaving the issue of your use of the word "pirate" aside, there are many legitimate music sources which distribute things in MP3 format only, or worse, RealAudio. Want to listen to some of the new Los Amigos Invisibles tracks before the album hits the U.S.? Of course you do; who doesn't like sexually explicit Spanish disco? But they're in RealAudio format. Fortunately, Real has a player available, or you can use their codecs with MPlayer.
You should also not forget about services such as Emusic.com, or the fact that many people (like myself) have hardware MP3 players, and so have an incentive to rip everything to MP3 instead. A cheap, portable MP3 discman was worth using an encoder of dubious legal status. I'm not going to spend several hundred dollars on a less flexible player, while my old one works fine, just to be able to use Ogg.
Don't get me wrong; I also use Debian, and I use as little proprietary software as possible. But I already had an nVidia card, and they are the best supported under Linux anyway. I want to watch fan-subtitled anime sometimes (which is legally grey, but responsible fansub distribution is tolerated by copyright holders, as they understand it will generate interest in a commercial release. Plus, some anime NEVER has a commercial release).
I am generally much more happy with Free software, but sometimes you need a tiny chunk of not-entirely-Free-as-in-Holy code to make things much easier on you. The goal is to eventually make these go away.
Technically, according to RMS, Vim and djbdns are non-free, but I'm not going to stop using them.
WMBC freeform/independent online radio.
Why hasn't a smart engineer come up with a way for HW cards to be self descripting to the OS? That way the OS can apply the resources needed automatically?
Say you buy NETO card which happens to be the latest greatest. You plug the card into an available slot, and boot your system.
The system sees the new card and querries its description. The NETO card dumps the description to the OS, provides a list of HW API's and other resources it is expecting, the OS installs those resources and makes sure the HW APIs are installed for that OS.
If done properly, the OS wouldn't have to know WHAT the NETO card does, just how to interface with it.
I am sure that it would take a new HW platform entirely, perhaps just a new NETO bus. Just have the card provide enough info so that the OS could build a driver set on the fly for the new NETO cards.
Plug the NETO card in, Windows builds the drivers and installs them. No vendor code required.
Plug the NETO card in, Linux builds the drivers, and installs them. No vendor code required.
This idea is to be considered PRIOR ART for any and all technologies the behave is a similar manner. The technical requirement aside. Any use of these idea must be FREE and OPEN standards.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Can I get the nift BSODs in linux now? I wondered when they were going to add that feature.
+-+-+-The folowing statement is true. The previous statement is false.-+-+-+
This argument has been used many times against WINE. However, the existance of WINE for the last 10 years hasn't slowed the growth of native Linux applications. If anything it has helped.
In the case of drivers, very few hardware manufacturers provide native Linux drivers. I could probably count the chipsets on my fingers and toes. Most native drivers were written by enthusiasts, either with tacit approval of manufacturers, limited support (e.g. documentation), or reverse engineering.
Yes, companies may claim Linux compatibility where they had none before (and without lifting a finger to help). But that's better than the previous absense of support from that company. Companies don't make money on drivers, so there's no reason for them to add Linux support, unless they have Linux users. Once they gain users, they may consider making native drivers for the next generation of their hardware (to make the users happier). But unless they have some users, they won't bother.
Life's a lot like money-- you spend it, then it's gone. Spend wisely.
Emulation doesn't have to take away from the native market. Buy native if it is available, but leave us with the choice of emulation for when it isn't.
Choice is a good thing.
Life's a lot like money-- you spend it, then it's gone. Spend wisely.
Press Release:
http://www.linuxant.com/company/press_dldr.php
Download:
http://www.linuxant.com/driverloader/