Google Summer of Code 2019 Ideas

[onestop_mid]

Hijacked thread now returning discussions to GSOC 2019 and what we can suggest as possibly interesting technical challenges for new students as well as those we'd like to push for ourselves and our own benefit...

Anything USB.

[Jedi-to-be]

Microsoft Delta Compression API (mspatcha.dll)

good, small and really usefull project for GSOC


https://reactos.org/wiki/Google_Summer_ ... cha.dll.29

[dizt3mp3r]

Microsoft Delta Compression API (mspatcha.dll)

good, small and really usefull project for GSOC


https://reactos.org/wiki/Google_Summer_ ... cha.dll.29

That sounds do-able and useful too. Is it likely to be interesting and suitable as a learning experience for the prospective student to want to take it up?

[ROCKNROLLKID]

I think the kernel test suites and the win32k test suites should be priority. I feel like it is small enough for gsoc students and it will have many future benefits, especially with reducing BSODs.

What about multi-processing support? XP sp3, as far as I know, supported up to 2 cores. This might be a good start for a gsoc and have a more mature developer finish it later to support more then 2.

Anyways, like the developers said before, gsoc should be about trying to gain long-term developers then it is about getting work done. Sure it is a nice way of getting us started somewhere because google pays these students and it encourages them to want to work on more difficult stuff, but if we don't have developers who can finish it afterwards, then it is as useful as just not having it to begin with, like our NTFS driver right now. However, I do feel if we list more selections, it could help us gain more students, so I guess we have to try and balance it.

[ThFabba]

What about multi-processing support? XP sp3, as far as I know, supported up to 2 cores. This might be a good start for a gsoc and have a more mature developer finish it later to support more then 2.

Supporting 2 cores is exactly the same amount of work as supporting 32. Or actually, it may be more work, since you'd have to write code to explicitly limit it to two.

[ROCKNROLLKID]

What about multi-processing support? XP sp3, as far as I know, supported up to 2 cores. This might be a good start for a gsoc and have a more mature developer finish it later to support more then 2.

Supporting 2 cores is exactly the same amount of work as supporting 32. Or actually, it may be more work, since you'd have to write code to explicitly limit it to two.

Ah ok. I am not a developer, so I didn't know. Is the idea good enough for gsoc, though? I would think it would be as challenging as adding multi-monitor support. Actually, according to ReactOS history, ReactOS can initialize multiple processes, but can't use them. So I would think it may even be easier then multi-monitor, am I right? Again, no developer so that's why I didn't include it in the wiki myself (it doesn't look like I can edit it anyways).

[ThFabba]

I don't know how difficult multi-monitor support is. SMP support is definitely too hard for any GSoC student.

[dnordenberg]

Why do you want more network card drivers for virtualisation? Better get virtio drivers working and have a "future proof" solution than "chasing the rabbit" for newer and newer cards... I think that is the future solution for the virtualisation software too and stop making emulated cards completely.

[dizt3mp3r]

Why do you want more network card drivers for virtualisation? Better get virtio drivers working and have a "future proof" solution than "chasing the rabbit" for newer and newer cards... I think that is the future solution for the virtualisation software too and stop making emulated cards completely.

That makes no sense at all, either re-read the purpose of the thread or refrain from commenting please.

[ThFabba]

I think it's on topic, but I don't think I agree with the point.
What _you think_ is the future of virtualization doesn't really matter, unfortunately. VirtualBox, VMware and KVM may very well all support virtio at some point (if they don't already), but Hyper-V and Xen don't really have a reason to, as they have their own paravirtualization interfaces (which, hey, we have another GSoC idea posted for).
That said, this idea is not just about supporting virtual machines better. It will also help hardware support.

[dizt3mp3r]

Extending the NTFS GSOC project I would suggest this : viewtopic.php?f=2&t=18269

Add advanced search using the NTFS index and journalling system. I reckon it is do-able and would result in an advantage of ReactOS over Windows whilst retaining focus on ReactOS recent NTFS development and capability. There is existing open source code that could be adapted.

o NTFS-Search https://sourceforge.net/projects/ntfs-search/
o SwiftSearch https://sourceforge.net/projects/swiftsearch/

[PurpleGurl]

That could be a good idea and something a GSOCer could do. It would have to be done for Windows at this point, as our NTFS support is not complete. Along this line, it seems all 3 strategies have their uses. I liked the "crawling" approach that Windows 9x used. I think 2000 used a hybrid approach between indexing and crawling. Adding an indexing service was intended for multitasking and server environments to reduce the disk activity, as crawling is quite costly in terms of IO. Microsoft learned from Windows 9x that more attention needed to be paid to multitasking (remember "defrag hell?" -- so many would just boot into DOS and run the DOS version of Norton Defrag or something). So adding this could increase search speed for NTFS-formatted drives. Since some code already exists, that would make it even better for a GSOC project.

[Quim]

Extending the NTFS GSOC project I would suggest this : viewtopic.php?f=2&t=18269

Add advanced search using the NTFS index and journalling system. I reckon it is do-able and would result in an advantage of ReactOS over Windows whilst retaining focus on ReactOS recent NTFS development and capability. There is existing open source code that could be adapted.

o NTFS-Search https://sourceforge.net/projects/ntfs-search/
o SwiftSearch https://sourceforge.net/projects/swiftsearch/

What about Trevor´s work? Did ReactOS team contact him to know if he is available to finish his work?
https://reactos.org/blogs/codertrevor
https://reactos.org/blogs/gsoc-ntfs-2017-update-1/

[gonzoMD]

Trevor already participated 2 times,so he is out.

[justincase]

GOOGLE SUMMER OF CODE 2019 PROGRAM RULES

7 Students.
    7.1 Eligibility.
        (b) Ineligible Individuals. A Student may not participate in the Program if:
            (iv) he or she has previously participated as a Student in Google Summer of Code two (2) or more times.

Darn.

CoderTrevor did some good work, and seemed to enjoy it, and also fit in well with the community.
It would be nice if CoderTrevor would come back and work on ReactOS some more (as indicated in his last blog post), even if to a lesser extent than what was done during the GSoC projects he participated in. Heck, it would be nice if he'd even come back to post that final blog post he promised us:

GSoC NTFS 2017 - Work Summary

LOOKING FORWARD
Thank you to my mentor Pierre, ReactOS, and Google for this wonderful opportunity!!

I definitely plan to keep contributing to ReactOS! I will make one more blog post after this one to summarize my experience from a personal standpoint.

Oh well, I guess we can only hope he'll come back eventually.

In the meantime, what's the status of the ReactOS GSoC application for this year? Have we submitted it yet? If not, what needs to happen before we do?