ReactOS May Begin Heavily Using Wine Code

[rohcQaH]

Afaik Firefox is much faster in WINE then running native...

That's usually true (~10% faster maybe), but only because the windows builds are built with better optimization.
Make a linux build with PGO enabled and compare again!

[kraftman]

Hahah, yeah, maybe he did. But still is not a very good argument. When you consider that most people have Windows because it came installed with their systems you have to wonder what 'out of the box' means. Sure, a Windows installation CD may have less drivers than a Linux one (I don't know), but how many people actually has to install Windows this way?

If I would say Linux supports more hardware 'out of the box' I would meant a CD. Afaik many people install Windows using this way.

Then, it's funny how the very same people that grab code from git repositories and compile the hell out of their drivers to have basic acceleration then complain about downloading Windows drivers off the manufacturer's site. Go figure : )

While they install drivers using git, have only basic features and complain about downloading Windows drivers off the manufacturer's site this can be little funny. However, if someone uses repositories to install fully featured drivers (like nvidia, fglrx and intel) or if they're already shipped with CD it's a different situation.

On topic:

Does it mean Windows version of Firefox installed in ReactOS will be faster then native one in Linux? Afaik Firefox is much faster in WINE then running native...

[yotambien]

Yes, Linux now supports more hardware than Windows ever will. The problem is that it's never the question how much hardware your OS supports, but whether it supports the particular hardware that you have.

That link made for an interesting reading. Surely Greg sounds very positive and manages to transmit it (I'm not being funny here).

But there is some slippery of logic or perhaps focus going on. I'm going to assume that he is right in his assertion that Linux suports more devices than any other OS (he claims to have an independent source but doesn't cite it). Now, this can only mean one of the following: a) I, and others around me, have had real bad luck with our hardware in Linux, while very good luck with our hardware in Windows; or b) we are talking about different things.

The first option being possible, the easiest explanation is the second one. Notice how Greg quickly jumps to the usual "Linux is 80% of the world's top 500 super computers right now and we're also the number one embedded operating system today". This is good, but it's not what concerns me the most, and it's not what I was talking about, especially in the context of hardware support of an OS like ReactOS. So to be clear, what I have in mind is desktop PC hardware, not supercomputers, mobile phones, wireless routers or electric screwdrivers. Of course, you may not have the same interests, but I'm pretty sure that this forum is full of people whose primary concern is related to the PC desktop market. Thus, that Linux supports a hell of a lot of all types of hardware devices doesn't translate to Linux having better support than Windows for the devices that me and Joe Average are interested in.

Following this line of though:

The thing about drivers is the vast majority, the number doesn't matter. You only care about what you have so it becomes personal. What you have is a very small number of devices.

I don't understand this. Is he saying that some people have a negative perception about Linux HW support because it just happens that their particular hardware is not supported? That what matters is the bigger picture, i.e., that taking into account every single device out there Linux has the broadest support and therefore those perceptions are baseless? I don't know. What I know is that most people that bitch in forums about Linux not supporting their devices are simple PC users, and when you have a sizeable bunch of them there must indeed be a problem with said support. Things don't come out of thin air. The perception that Windows is insecure, although repeated and exaggerated in some circles, is rooted on certain facts. The perception that Linux hardware support is lacking compared to Windows is also based on the experience of users having problems running their kits in Linux. The rest, like comparing 'out of the box' support, number of drivers included in the installation CD, or number of microwaves running the Linux kernel, are pointless issues.

The only thing that matters is the hardware support for what people actually use.

Heh, yes, that's it. And let me add "and when people want to use it". I won't care very much if in 10 years time my webcam doesn't work in Windows10, but I want to see my parents via Skype today.

Having said this, it's clear that Linux hardware support has improved a hell of a lot very quickly. I remember not so long ago an interview with A. Cox (pretty sure it was him) where he stated that Linux wasn't meant for laptops...

[Smorg]

Not everybody likes the way Unix works. ReactOS guys typically like Free software and open source, but don't like Unix. Think of ReactOS attempting to do to Windows that GNU did to Unix.

Unix has the advantage for implementors that it is a real standard. There exist free implementations, and Gnu/Linix even of course gives itself the freedom to diverge from that standard where necessary.

With Windows all you have is a proprietary reference implementation, and the implementation must prioritize compatibility over function, at least initially.

For these reasons you both shouldn't, and couldn't do to Windows what Gnu did to Unix. Its more reverse engineering than implementing. If you don't like Unix, You'd be far better off starting from scratch with your own concept, unless of course you think Windows is the most ideal of possible operating systems...

[deanjo]

Oh there are certainly a lot of companies that do driver maintenance right. NVIDIA and ATI for example. But many companies will at some point just stop porting over their drivers to the new system. The new products will work fine, but the old ones are not important anymore. I have had a scanner, a USB-LAN bridge, and even a LAN card turn into a brick because the vendor couldn't be bothered to support it right.

Sure but given the longevity of past windows releases this isn't a big issue usually. I've had products in pretty much every OS out there eventually hit a limit. My Umax scanner for example that was purchased in 1996 ran finally couldn't be used anymore eventually in any OS as SCSI card that came with it was ISA, a PCI mpeg decoder card that did not work with newer revisions of PCI slots, etc etc. Sure I could have bought a new PCI SCSI card and got the scanner going again but at that point it's just cheaper to buy a new scanner which in all but one way far exceeds the capabilities of that old scanner. Fortunately things have gotten better over the last couple of decades and most common items now follow set standards and the days of proprietary interfaces are coming to a close.

[benmoran]

You can be sure that many vendors stop supporting old hardware just to force consumers to buy new models.

[Remco]

That really is an over exaggeration, I don't think I've come across a piece of hardware in windows that has had just one driver release. While yes there maybe after a while few and far in between driver releases but as mentioned it's because of it's relatively stable ABI. The drivers usually for such devices are, as I mentioned before, far more feature rich then their free counterparts and with it usually goes another layer of complexity.

Oh there are certainly a lot of companies that do driver maintenance right. NVIDIA and ATI for example. But many companies will at some point just stop porting over their drivers to the new system. The new products will work fine, but the old ones are not important anymore. I have had a scanner, a USB-LAN bridge, and even a LAN card turn into a brick because the vendor couldn't be bothered to support it right.

[deanjo]

Well, not like Windows. Windows is a very peculiar system, where most drivers are out of tree. Basically those drivers are written once and then promptly forgotten about.

That really is an over exaggeration, I don't think I've come across a piece of hardware in windows that has had just one driver release. While yes there maybe after a while few and far in between driver releases but as mentioned it's because of it's relatively stable ABI. The drivers usually for such devices are, as I mentioned before, far more feature rich then their free counterparts and with it usually goes another layer of complexity.

[Remco]

Which is pretty much like any other OS out there. Closed or open somebody has to step forward to maintain a working solution.

Well, not like Windows. Windows is a very peculiar system, where most drivers are out of tree. Basically those drivers are written once and then promptly forgotten about. The stable ABI makes this work somewhat, but as said, it's not that stable in practice.

Of course -- to get back on topic -- ReactOS does not have to suffer from this third party driver hell. ReactOS being free software can just port drivers from Linux and maintain them in tree.

[deanjo]

Once they get into the mainline kernel, they will have a maintainer, and that maintainer will have to support it indefinitely.

Some drivers are dropped from mainline. Those are old drivers that nobody uses anymore. If nobody uses a driver, it doesn't get tested, and it will break.

Which is pretty much like any other OS out there. Closed or open somebody has to step forward to maintain a working solution. In linux there is a crapload of drivers that probably aren't even really used anymore (such as ISA devices, long dead video cards, radio cards, long obsolete networking protocols, bus mice, etc). I would actually like to see the kernel developers 'prune' some of that really old, obsolete, device support and have the developers worry about devices that people actually use now days. There really is no practical reason for the developers to be patching 18 year old soundcard (gravis ultrasound for example) drivers to maintain them with the kernel changes.