Only 1 student this year?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

binarymaster
Posts: 285
Joined: Sun Nov 16, 2014 7:05 pm
Location: Russia, Moscow
Contact:

Re: Only 1 student this year?

Post by binarymaster » Sun Apr 29, 2018 9:06 pm

knowmad wrote:Well if i'ts only one student that's gonna make almost zero difference to ReactOS progress :(
I don't think so.

knowmad
Posts: 17
Joined: Mon Oct 20, 2014 11:04 pm

Re: Only 1 student this year?

Post by knowmad » Sun Apr 29, 2018 10:27 pm

Keep in mind the word "almost" does not make anything a definitive statement. Certainly the student's efforts will provide yet more functionality to ReactOS and we can all be fully confident that the senior dev's are fully and accurately correct about a student's abilities now as well and what is possible in the future.
However, any developer can only spend as much time on a project as circumstances permit and many many components require a not only quite a bit of time but a high level of coding skills as well.
Seems that "real life" thing usually takes precendence over coding huh?

Murmur
Posts: 140
Joined: Fri Nov 20, 2009 8:16 pm

Re: Only 1 student this year?

Post by Murmur » Tue May 01, 2018 5:06 pm

I don't want to sound rude or ungrateful but to me it doesn't seem like booting from BRTFS is high on the priority list for things ROS currently needs at the moment.

ThFabba
Developer
Posts: 265
Joined: Sun Jul 11, 2010 11:39 am

Re: Only 1 student this year?

Post by ThFabba » Tue May 01, 2018 6:32 pm

Murmur wrote:I don't want to sound rude or ungrateful but to me it doesn't seem like booting from BRTFS is high on the priority list for things ROS currently needs at the moment.
Again, we're not aiming for "get the most/most useful work done during the summer". We're looking to gain a new long-term contributor.

Also, things high on the priority list tend to be extremely hard. That's usually why they're not fixed yet.

Heis Spiter
Posts: 183
Joined: Sun Sep 03, 2006 11:39 am
Location: Paris, France
Contact:

Re: Only 1 student this year?

Post by Heis Spiter » Tue May 01, 2018 11:25 pm

I often read on boards people having strong opinions about file systems situation in ReactOS. About current situation, about ideal situation, about future situation.

So, let me try to clarify once for all current file systems situation, current goals, what are the under going works. In short: WHY is it that way and not another way. You'll understand better why this GSoC project makes sense, not only to (attempt to) gain a new ReactOS developer, but also to improve our project.

Historically, from users point of view, ReactOS had two file systems: CDFS & vFAT. Both having their dedicated drivers. These drivers have been developed in ReactOS, against the ReactOS kernel and our libs. These drivers weren't working in Windows and Windows drivers were not working in ReactOS. Both ReactOS drivers and ReactOS kernel have been made to work together. Our drivers need our kernel, and our kernel needs our drivers. This is clearly not the best way to improve ReactOS compatibility nor to make it progress.
There has been an attempt a few years ago (or perhaps a decade ago?) to develop a new FAT driver, in W2K3, using an external lib, and to fix ReactOS around so that we would be closer to what Windows kernel does. Unfortunately, because ReactOS is a FOSS project, the developer attention got drawn elsewhere and this driver got abandoned and then dropped. Our kernel didn't benefit from the attempt.
In parallel, several developers were doing their best to improve our vFAT driver (which even became a FastFAT driver in the process ;-)), but still against ReactOS, which didn't help regarding compatibility.

Some did the test, and just took the drivers from Windows 2003 and put them in ReactOS, it just BSOD and didn't work.

So, how to improve compatibility ? Make our drivers work in Windows 2003, or make drivers that work in W2K3 work in ReactOS. First option is no go for me. I have no way to instrument a W2K3 (reminder, I develop on Linux ;-)) to have proper debug, so, only remains the second option.
We could have used MS drivers for this. As FSD implementation samples, MS provides CDFS and FastFAT driver. But two problems raise: first one is a half driver (only RO), and second is really complex. Hence, they are good examples, but not that easy to debug.
Then comes 3rd party drivers: ext2fsd, winbtrfs, and so on. These work on Windows 2003 (or nearly ;-)) and can provide good test case. And this is the choice I made. Getting these in ReactOS. It has two benefits: providing live test cases for our kernel and bringing in new features. Sounds great, isn't it? And it worked. We brought support for these FS, but we also squashed a number of bugs in our kernel at each release of these drivers breaking in ReactOS. Our kernel started working better. For the record, Trevor Thompson, a GSoC student, even helped on a part.

Thanks to these efforts, we came to the point where we could drop our own CDFS implementation in favor of the Microsoft one. It just works out of the box (or nearly ;-)) in ReactOS.
Nowadays, our kernel isn't still ready to handle setup with MS FastFAT, but could work once installed with it. At some point, ext2fsd and MS FastFAT seem to expose the same issues when it comes to setup. Fixing one should help the second one. BtrFS could be already used to install ReactOS. It requires less fixing, and less complicated fixing, no on-disk corruption, no broken behavior in the kernel. It is then more interesting for a student to work on it and bring ReactOS on it; while being less frustrating for the student, and more relevant for the community as regular progress can be shown. It will pave the way for fixing the other FSDs. Every single bit added in the right direction is a plus for any FSD. It's definitely not wasted time. And it will also help ReactOS in general: there are software, features, APIs we cannot test because FAT is a too limited file system (for instance, no hard links). Having BtrFS setup will allow testing these code paths without requiring second hard drive and so on.

Now that's said, what about NTFS? NTFS support in ReactOS is a complex topic. It was the first thing I worked on when I joined ReactOS (remember, in 2007 ;-)), then I moved to other topics. I later came back to it, and brought it to a level were it could read from any NTFS partition (or nearly ;-)). We had the chance to have a student working on it for two GSoCs: Trevor Thompson. He even brought in initial write support. Unfortunately, our NTFS driver development started along with vFAT and CDFS drivers and suffers from the same issues. It is really ReactOS specific. I understand NTFS is important for ReactOS, but it requires hard work to complete, and waiting for it to fix our kernel compatibility would be a mistake that would make the project stay behind. So, it will come, one day. It just needs more time to mature. And no, NTFS-3G is no use here (nearly ;-)). It is a usermode implementation for FUSE that cannot be just translated in our kernel. And no, you don't want to install ReactOS on our NTFS driver, it would be slow as hell, it doesn't support any caching, yet.

I hope you understand better what's going on regarding file systems in ReactOS and will be less prone to say this GSoC slot is misused ;-).

Roma blabla.
Pierre Schweitzer (aka Heis Spiter)
ReactOS kernel developer.
ReactOS systems administrator.

middings
Posts: 1008
Joined: Tue May 07, 2013 9:18 pm
Location: California, USA

Re: Only 1 student this year?

Post by middings » Tue May 01, 2018 11:46 pm

Thank you, Pierre Schweitzer (Heis Spiter), for describing the current status of ReactOS storage drivers and file systems. I learned a lot.

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

Re: Only 1 student this year?

Post by ROCKNROLLKID » Wed May 02, 2018 10:22 pm

Just for the record, the only reason I brought this topic up was because I thought we only got 1 student because that is all who applied for ReactOS. I wasn't trying to insult anyone. If the ReactOS team thinks that only doing 1 student at a time and giving him extra help will help him stay with ReactOS, then it is worth a shot because obviously this didn't work in all the past years when we had 3-4 students. Sure, maybe they could have gotten a 2nd student to do something else, but they decided to start low and work up. If it makes anyone feel better, Wine got 4 students this year (one working on finishing dx9 implementation which will surely help ReactOS for dx9 apps) and Freetype got 3 students (one working on finishing the fuzzing part which will surely help with fixing fonts in ReactOS), so we will surely be benefiting from that.

Anyways, if I can add to what Pierre said, just try to remember that part of the reason we have ext2fsd and Winbtrfs is because there already was a driver for these, so this was much easier than doing NTFS. There is no open-source driver for NTFS that anyone has made, so the ReactOS team had to make their own and use code samples and documentation from MS. Besides, have Winbtrfs over Fat32 is a plus itself, considering Fat32 is very limited on what it can do. My only concern about Winbtrfs is that the main developer of it doesn't really seem to be working on it anymore, now that it is completed, so the ReactOS team might have to fork it and work on it themselves.

Now, with all that said, I am just curious as to what Victor will be doing if he finishes his work before GSOC ends. Will he continue to improve the bootloader for other filesystems or will he move onto something else? I am not sure how much he has to do to get Winbtrfs bootable.

binarymaster
Posts: 285
Joined: Sun Nov 16, 2014 7:05 pm
Location: Russia, Moscow
Contact:

Re: Only 1 student this year?

Post by binarymaster » Wed May 02, 2018 10:53 pm

ROCKNROLLKID wrote:Now, with all that said, I am just curious as to what Victor will be doing if he finishes his work before GSOC ends. Will he continue to improve the bootloader for other filesystems or will he move onto something else? I am not sure how much he has to do to get Winbtrfs bootable.
As you can see, he's interested in many different things :)

https://jira.reactos.org/secure/ViewPro ... xtravert34

Rosh
Posts: 97
Joined: Thu May 03, 2018 12:44 am

Re: Only 1 student this year?

Post by Rosh » Fri Jun 01, 2018 1:36 am

Zombiedeth wrote:Do you suppose getting Btrfs working could could help making other filesystems bootable?
like using it as a template or something.
Ext2 for example?
And ext3 and ext4 later...

dark
Posts: 275
Joined: Wed Apr 06, 2005 9:40 pm

Re: Only 1 student this year?

Post by dark » Sun Jun 03, 2018 5:15 pm

ThFabba wrote:The goal of GSoC is not necessarily to make progress during the summer, it is for the students to become long-term contributors to open source. Having only one student means the student will have more support and the project can focus better, so they're more likely to stick around.
That's one of the reasons we decided one slot was the right way to go (in addition to the fact that none of the other proposals were as good... for example no other students met the contribution requirement).
Why specifically btrfs though instead of ext2/3/4?

edit: nevermind, didn't see the second page of posts on a phone browser.

erkinalp
Posts: 839
Joined: Sat Dec 20, 2008 5:55 pm

Re: Only 1 student this year?

Post by erkinalp » Sun Jun 03, 2018 10:33 pm

Thanks to these efforts, we came to the point where we could drop our own CDFS implementation in favor of the Microsoft one.
Microsoft's driver does not support ISO9660 fully.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2

EmuandCo
Developer
Posts: 4334
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: Only 1 student this year?

Post by EmuandCo » Mon Jun 04, 2018 8:42 am

More than ours does.
Image
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 4 guests