OSNews

I beg to differ....

I can see at least three valid reasons for ReactOS to keep going (and this is from a Linux-using and occasional BSD-using weenie... )

a) Playing Windows games. At present, if you want to play those but don't want to buy Windows, the options are Wine (running on Linux/*BSD) or ReactOS. Wine has the inside running at present, but ReactOS can still get to a good-enough state to run games.

b) As a security testbed, to see if it is possible to create a Windows-like OS that can be hardened against worms and viruses. If it were possible to port pf to ReactOS then that would be a good start.

c) (Eventually) - as an XP replacement. Ok, I agree that this is likely to be quite a way down the track (I'd guess at least 18 months to 2 years). However, given the progress that the ReactOS devs have made so far, it's possible.
- obsidian

Yup, Linux is currently my default OS, which means Windows XP is my gaming OS. If ReactOS could run games in the future, I might use it.

I, for one, would like very much a Windows compatible OS that I don't have to pay money for. Windows XP will still be relevant 5 years from now, and I think the React OS team will produce something stable in this time frame.

I beg to differ too.

Linux with Reactos in Vmware or Virtualbox so you can run Windows stuff looks like a very promising option.

It easy: because they can! They want to do this, they have time to this, they have skills and most importantly, if they succeed to make something that works well, it will become a big news! I cannot wait this day.

Ridiculous comment. Of course it is a useful project. It *does* take time, but it's a project that many people will use in a few years, because it's a clone of the *most popular* operating system around. What I suggest is take a few Linux developers, have them learn about Win32 and give the Reactos team a hand until it reaches the stable version, then resume work on Linux (if still interested). Now, *that* would be useful, and many more people would benefit from the collaboration and could use a Windows replacement that works for them.

I don't understand the relationship between Linux and Reactos here, why not suggest BSD developers down tools and work on Reactos?

I personally don't use Windows and have no requirement for a Windows clone, so your suggestion seems utter madness to me.

Oh now wait a minute, your were joking in your post right?

Because both people who work on Reactos and Linux are system developers and they can learn any system to work on improving it.



Could be too!



You aren't representative of the majority of people. Most people use Windows, so a Windows clone is useful to more people than a Unix clone.



Nope. Just pragmatic.

The core architecture of the Linux operating system is fundamentally different to that of Reactos, and would take some time to get up to speed.

I agree that any system developer should have no problem learning a new system, but where is the incentive for a Linux system developer to do this?



I never said I was a representative of the majority of people, and like many others you are using the context of a desktop market share.



Nope, you are being pragmatic where it benefits Reactos.

i too have taken a few linux developers and put them to work, chopping trees and mining gold.

i will send them to finish ReactOS, maybe later

I imagine you will be flamed to death for this comment...

Here's a healthy dose of skepticism:

1) Wine has been in development for 16 years. It is useful. It works, but not very well. How much better can we expect ReactOS (which shares a lot of code with Wine anyway) to do? Can ReactOS work better than Linux + Wine? Is kernel compatibility (vs API) the real issue?

2) In my experience, projects either come up with something you can "almost" use within 1-2 years or they never do. Examples: Linux (went from 0.01 to v1.0 within a couple of years), FreeDOS. Contra-examples: Hurd, SkyOS, Haiku etc.

3) ReactOS has been in development for 11 years.

How do you know Haiku will never release a working, usable version 1.0?

The reason operating systems take a long time to reach 1.0 is because operating system development is not magic.

The NT design is very strong and the fundementals haven't changed since the days of cutler.

Unless Microsoft drop the NT architecture, then reactos will always be relevant.

The inner workings of Windows 7 aren't all that different from windows XP. Once reactos has a stable base the extra work to get Vista/win7 only software to work will include adding any new API's (some of which reactos already supports) and adding support for the new driver model.

So, the moving target reactos is chasing isn't moving quite as fast as people believe.

On the contrary, Microsoft dropping NT would make ReactOS more relevant than ever. There will be vital code written for NT running for decades to come. Once ReactOS becomes the only windows 2000/XP compatible OS with drivers for the latest hardware and with regular updates it will take off in a massive way.

Agreed. We still have NT4 boxes in production. A working ReactOS would give us another option (one under active development) next time the racks get short or space (or audited).

Fundamentals haven't change - you need to look at where they verred off course in 4.0 for the sake of speed as a prime example of what happens when management start to get involved with things they know nothing about or make decisions that are dogmatically driven based on 'market research' rather than the right course of action based on a long term perspective.

Maybe they do it because they like the idea of having windows drivers installed instead of sitting in linux forums asking all day .
Furthermore i like to add that Linux would kick ass if some cool asm-hacker would remake the mlinux kernel so that it ran all kinds of windows inf/dll drivers and strenghten directx support.
But until that eggheads realize that we'll keep run games on windows or torture ourselves in winex and give linux shit about how some of our hardware don't work.

I imagine it would be useful in a developing country like mine where the vast majority who want to use computers cannot afford even the cheapest Windows license but would like to use Win32 applications. I for one have tried an older beta and will try the latest beta again along with some applcations to see if I can deploy it on retired PCs here.

It's likely something to do with the way Windows handles code signing - the certificates used to sign code have to be issued by a commercial CSA. In order to be compatible with Windows, ReactOS would have to use the same root certificates.

That said, I'm not sure why they'd be implementing that right now. Nor can I work out why they don;t just create their own root certificate, and sign the releases using that.

I don't understand why ReactOS would need code signing for their drivers. Maybe I don't want them? Solution follows

//if (check_driver_is_signed(driver))
//{
enable_driver(driver);
//}


//Am I missed something?

I've -1 Trolled you because of the tone of your post and the following facts you were grossly inaccurate about:

* Linux already has 3D accelleration and network drivers (so it can already run many Windows games better than ReactOS)

* ReactOS already has ethernet network drivers - not tried wireless, but then I find even Windows to be buggy with WiFi with many cards. So I'm really not quite sure what you're on about when you mention ReactOS's lack of "network".

* Ignoring games for a moment: Given ReactOS is BASED on a *nix app (WINE), it's safe to say that Linux/BSD runs not that much less Windows apps (via WINE) than ReactOS does. So there already are workable alternatives to Windows (not that I want to discurrage this project either mind).

* and finally: Millions of people world wide already use Linux/BSD as their desktop OS (including myself). So clearly it is a viable desktop OS.
Sure, Linux/BSD maybe a different way of working to what you're used to (package managers and different software suites as opposed to randomly downloaded untrusted EXEs and running Microsoft branded bloatware), but to argue that these differences make Linux/BSD useless is pure ignorance and trolling.

* Linux already has 3D accelleration and network drivers (so it can already run many Windows games better than ReactOS)

At the moment, yes, but I suspect that when ReactOS gets 3D acceleration working it'll be a better alternative for gaming than Linux. Atleast I get subpar performance with WINE, and usually crashes or other issues. None of the games I want to play are playable under Linux on my machine. Atleast on ReactOS you wouldn't need to translate Direct3D to OpenGL which should lead to better performance and you could use Windows-native graphics drivers which usually support more functionality than the open-source ones.

Sounds good actually, but it'd require modifications to application menus, or an additional panel application to get some integration with virtual OS. It sure would be nice to have a few new menu entries whenever the VM was running: configure, browse disk, copy to/from clip board (even better would be to automatize that), synchronize calendar/mail/address book/etc.

Maybe some of these things could be done with a small TCP/IP server/client between the two OSs? Perhaps the same program code source could run on either OS depending which way you were virtualizing?

Then in the Windows software Add/Remove menu there would be a program called "Ubuntu Integration".

Keep the dream alive people!

Maybe some of these things could be done with a small TCP/IP server/client between the two OSs? Perhaps the same program code source could run on either OS depending which way you were virtualizing?

Then in the Windows software Add/Remove menu there would be a program called "Ubuntu Integration".

Sure, it'd be very easy to implement such functionality, you just need someone to actually do it. We have access to the ReactOS sources and all so there is nothing stopping us from having two-way integration. Too bad I don't know a single thing about Win32 programming, otherwise I'd probably try something myself