Amazing progress!

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
laurflorin
Posts: 86
Joined: Mon Feb 13, 2012 7:39 pm

Amazing progress!

Post by laurflorin » Thu Jun 29, 2017 7:36 pm

Wow... i have to say! :)

I haven't posted in the forums for quite a while.

But i see the regular ReactOS releases now (every few months). I see the heavy progress being made on many components
(such as NTFS, theming, quick launch etc.)

ReactOS has really started to react in its truest sense!

Thank you all contributors and devs for your efforts !! I see real potential for ReactOS in the future.

Once it's stable enough and many people know about it, I belive ReactOS could skyrocket.

The only "downside" of this that I could think of is this: since ReactOS is open source, if other people fork it
and create different "flavors" or "distributions", wouldn't this be at risk of breaking NT compatibility and becoming
fragmented? - What's your view on this?

Thank you.
IT: The only place where a cookie could pose a risk to your privacy.

dizt3mp3r
Posts: 1450
Joined: Mon Jun 14, 2010 5:54 pm

Re: Amazing progress!

Post by dizt3mp3r » Thu Jun 29, 2017 8:38 pm

I will be forking ReactOS immediately it is ready. My own distro. I wanted to call is SteamOS but I think that name is gone.

I don't think you need to worry. ReactOS will always be here I imagine. Something similar to the linux foundation?

verserk
Posts: 35
Joined: Fri May 26, 2017 8:11 pm

Re: Amazing progress!

Post by verserk » Thu Jun 29, 2017 8:41 pm

Forks are almost always good, if something good gets implemented in the fork that ROS can use we can just merge their patch. As for forks that break NT compatibility, they will most likely be irrelevant as they will have less capabilities and stability than they would have had otherwise.
ReactOS: HP pavilion dv6500.

ROCKNROLLKID
Posts: 297
Joined: Mon Oct 17, 2016 3:19 am
Contact:

Re: Amazing progress!

Post by ROCKNROLLKID » Thu Jun 29, 2017 9:58 pm

I don't know. I really don't want to see ReactOS turning into Linux where no one is working together and everyone is just making their own fork then taking credit for it all. I mean 1 or 2 forks wouldn't hurt, but we should try to keep a centralized community, just like Windows and Mac have.

Konata
Posts: 391
Joined: Sun Apr 20, 2014 8:54 pm

Re: Amazing progress!

Post by Konata » Fri Jun 30, 2017 1:05 am

The only fork I plan on making is a Server Core-esque version, and that's only if ReactOS doesn't eventually get that option. Or even better, just no GUI at all, but still retaining GDI unlike Nano Server. I only need it for my dedicated servers for my AI projects.

I really don't think forks will be such a big issue, Windows already has installers that check for software and downloads it if it doesn't exist, or handles multiple versions of the same DLLs with it's DLL cache. if a certain distro is so broken that normal Windows software doesn't work on it, I don't think it'll be adopted very much.

PurpleGurl
Posts: 1778
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Amazing progress!

Post by PurpleGurl » Fri Jun 30, 2017 6:01 am

Branches are what those who want to do their own thing should focus on. And if it fulfills a need that should be filled in trunk, it can be merged. Forks are generally reserved for when there are irreconcilable differences in major things. If you fork over every trivial thing, then that unnecessarily divides the project.

Now, if someone wants to roll out a bunch of enhancements or changes that won't make it into ROS, one way to do that without forking the entire project would be to make an unofficial service pack. Like with the idea I rolled around and probably won't put to use, where I'd want to create files tuned for specific architectures or use certain faster code paths, or even files that require certain hardware, then one way to implement that would be a service pack approach with backups of replaced files, and the option to uninstall the newer files and put the originals back. And the replaced files could be moved to easy to find locations in case one had to manually copy them back (like what if the machine crashes but you replace with hardware that's incompatible with the changes).

Now if you want to bundle with certain replaced files (or an installer to use those instead when appropriate), certain software, certain drivers, themes, etc., then what you'd have would be a distribution. There is no need to do a fork when you can just work on specific parts that are not in the mainstream release that can be tacked on at the end.

Now, for the OP's questions. Distributions are one thing. They change very little if any of the core OS and important files. They are to appeal to a certain user segment. For instance, a gamer's distribution might default to either a "cool" theme, or a minimal one, default to lax security settings, not have as many services enabled (certainly no indexer service), have most logs and performance counters disabled, maybe issue performance commands to the hard drives, etc. And they might throw in some modified drivers for certain devices.

I don't believe distributions would harm the project or compatibility overall. Forks on the other hand are another issue, though even they can sometimes work out for good overall. Let's say that someone decides to rewrite their own memory manager from scratch. Ideally, that could be done as a branch. But let's say they fork it. Then let's suppose it is better than ARM3 and the remnants of the other one. Then that can be merged into mainstream if it truly is better.

Now, if it is a fork because someone wants to use it as a base for their own OS, then that would be of little interest to us. And if the consumer base wants it, then a new platform could emerge. Or, maybe the goal is for a lightweight embedded OS or one that will be used in a high security situation. So yes, they might make it fundamentally incompatible, but they might only need it for specific in-house solutions. Like why not a POS terminal or ATM with forked ROS code on it? They might strip down ROS and remove all but what's essential to run a single, specific application and maybe use their own proprietary, closed-source network stack.

What I said years ago is that forks would likely be less of a problem for us than Linux, assuming the forks are after Windows compatibility. In other words, they follow the same "Bible" (ie., being followers of Windows, etc). It isn't trying to mimic an obsolete mainframe OS that none of the programmers have actually used which was replaced by much better hardware and adding GUI support where it never existed. So there is less room for interpretation when coding a replacement for an active, popular OS.

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Qwantify [Bot], Yandex [Bot] and 2 guests