The latest ReactOS newsletter is out. “Reactions have varied in regard to 0.3.1, though one response was consistent. The difficulty in getting it to work on real hardware. As mentioned many times, 0.3.1 was branched in the middle of a kernel rewrite.”
While I appreciate the fact that they are in the middle of a kernel re-write, I can’t see why they would release something that just does not work.
OK sure, ReactOS is getting to the stage that major jumps have to be done to go to the next stage of it’s evolution (for lack of a better word) and many of other OS’s have had to go though the same thing, but why not hang back for a few more weeks until this was sorted before committing?
Enough of me moaning, well done all ReactOS devs out there, for not only keeping this going but looking far into the future. Vista compatibility may be a few years off yet but at least your roadmap looks very good and everyone has a common goal.
Just one question to anyone out there who might know: Is there a general rule that nothing can be taken from the Linux / BSD code base? The reason I ask is that with the Audio issue it seems to me that you could take one of the well tested and mature sound engines from Linux and integrate that to give you sound support. You could then just put in wrappers around it to make it compatible with ReactX and DirectSound (or your take on that standard). Just a thought.
>OK sure, ReactOS is getting to the stage that major >jumps have to be done to go to the next stage of >it’s evolution (for lack of a better word) and many >of other OS’s have had to go though the same thing, >but why not hang back for a few more weeks until >this was sorted before committing?
The release was already about two months late, and most critical bugs had been fixed. The 0.3.1 branch was also getting old in relation to trunk, so further delays would have caused even more merging issues between the two.
>Just one question to anyone out there who might >know: Is there a general rule that nothing can be >taken from the Linux / BSD code base?
Absolutely not. From what I understand, ReactOS’ (and windows’ as well) TCP/IP implementation is borrowed from FreeBSD. Basically, ReactOS’s audio architecture has to be compatible with windows’s, which linux or BSD is not.
(Anyone care to correct the numerous technical errors I’ve no doubt made? :p)
Edited 2007-03-19 01:34
NT’s TCP/IP stack is not borrowed from FreeBSD’s. It had at one point a BSD-derived stack, and still ships with some BSD-derived tools, but the stack was rewritten for NT 3.5.
EDIT: Linky – http://www.kuro5hin.org/?op=displaystory;sid=2001/6/19/05641/7357
Edited 2007-03-19 02:44
The TCP/IP stack may have been rewritten for NT3.5; however the NT4 stack was problematic for heavy network use and the Windows 2000 TCP/IP stack fingerprinted as a BSD stack….
Times have changed.
Personally I think it would be great if a shared driver model allowed well written drivers to be shared across the range of open source operating systems.
I agree. uKernel will be of great help.
> I can’t see why they would release something that just
> does not work.
I’m sure they test as much as they can, but mistakes happen. Remember, even in the tightly controlled
Linux kernel process, Linux has made “brown paper bag” releases to fix obvious critical bugs. ReactOS
isn’t used on any production system, so although I’m guessing it did work on the hardware/test cases
they tested on before the release, I’d imagine that things fall through the cracks since the tests
aren’t as thorough as a production system. They don’t need to be (yet at least).
I think ROS is GPL source, but they strive for compatibility with Windows interfaces and drivers. They’d have to implement the upper half of the KS API for apps and the lower half for drivers, so they might as well implement the whole thing rather than grabbing OSS or ALSA.
On another note, I read that Alex Ionescu is going to take a job with one of the Big Three soon (Apple, Google, Microsoft). I wonder how this will affect the development of the kernel. Given his experience, I’d bet that Microsoft would be aching to hire him and I have no confidence in their allowing him to continue as a ROS developer if he also has access to the Windows Source.
may not be that microsoft do not allow it, but that he have to walk away in fear of contaminating the reactos code with ms code.
if so happens, the sco vs linux clown show will be a flea on the back of a elephant in comparison…
if so happens, the sco vs linux clown show will be a flea on the back of a elephant in comparison…
I dunno. In the case of SCO vs IBM, SCO has been able to show the SCO-owned code that was released verbatim by IBM under the GPL without SCO’s permission, and they still haven’t been able to recieve damages.
Copyleft software has been amazingly successful in the courtroom, even when the facts of the case are To Kill A Mockingbird-obvious. ReactOS probably doesn’t have anything to worry about.
Copyleft software has been amazingly successful in the courtroom, even when the facts of the case are To Kill A Mockingbird-obvious. ReactOS probably doesn’t have anything to worry about.
SCO’s claim to date has amounted to 349 lines of code they claim was copied, with the majority of them consisting of comments and declarations; it’s questionable whether those portions would even be covered by copyright law even if IBM admitted to copy-and-paste tactics.
Copyleft is successful specifically because of many of the practices behind it, such as clean-room reverse engineering or the absence of direct contact with copyright protected code. This can’t be overlooked.
It would be a mistake for a paid proprietary developer to contribute work to a similar OSS project, or even if that developer has access to proprietary code and information as part of their daily job. Most high profile projects will tend to reject work under those circumstances, and even IBM and HP compartmentalize their OSS and proprietary software developers.
Remember that you can’t copy something you don’t have access to. With a project like ReactOS where the software is written from scratch or based on existing OSS code, it would be difficult for Microsoft to claim code was copied from or directly influenced by their own source code since they would have difficulty proving the developers ever saw Microsoft source code, which reduces their opposition tactics to the usual claims of baseless IP copying. That premise works because none of the developers actually has contact with Microsoft source code; if one of them does then the entire argument shifts potentially in Microsoft’s favor.
Could you please point out specific examples to which code SCO (arguably, see the Novell vs. SCO case) has the copyright for, that has been dumped verbatim into the Linux kernel (by IBM or whoever)?
Hint: The code examples presented at the SCO forum some years ago have been shot down within days (IIRC, BSD code and therefore legally transferable to Linux, please correct me if I’m wrong).
The SCO legal team has used a very fancy theory concerning “methods and concepts” and a very adventurous interpretation of how the copyright system works in order to dance around the “verbatim copying of code” issue lately and has went to great lengths to turn this into a contract related issue (Linux on Power, Project Montery).
If you know of any specific examples of source code with a (at least somehow verify able) non-clean provenance, please do the right thing:
– point it out to the (Linux/BSD/ReactOs/…) devs directly
– provide specific information why this code is problematic (e.g. infringes upon library xyz of OS version a.b) (and in the case of SCO)
– tell it also the SCO legal team, they look as if they could need some help in finding infringing code in the linux base
EDIT: As elsewhere pointed out correctly in the comment above mine, not every instance of “verbatim identiy” is automatically a copyright infringement, for example in the case of header files (where it is pretty much impossible to deviate from existing implementations, when compability is an issue) or implementations of trivial (sub)routines, copyright is almost likely not infringed.
Edited 2007-03-19 18:20
Microsoft could easily hinder reactos already very very very slow development. All they have to do is “hire” reactos developers (whom for the most part love microsoft) Which will mean they can no longer work on reactos. At the current pace of development reactos will have a windows xp equivilent 32 bit os in at 1.0 in about
4 or 5 years…. so even without microsofts interference you will have a free open source xp in that amount of time think how much the world will change by then…
Andif they DO interfere how long will it take…
And the audit they had to do who wants to bet billy boy had his hands or money in that hmmmmmmm
SHHHH!!!
Don’t give ’em any ideas!!
–bornagainpenguin
I can’t get the LiveCD to boot natively or in VPC2K7 either. It has the same problem either way; it pauses at the splash screen. I suppose I’ll just get the install image.
I’m astounded by the amount of advances made, however. I decided to read the changes log, and I just couldn’t keep going about five minutes into it. Wow.
Great work, team!
And, viator, you could stand to be a bit more accepting. I trust this team to deliver the goods in a reasonable amount of time.