image


Привет, Хабр!


Спешим сообщить, что операционная система ReactOS уже третий год подряд получает слот на Google Summer of Code!


В случае успешной сдачи работы участник Google Summer of Code получит 3 600 евро.


Кто может участвовать?


Участвовать могут любые студенты и аспиранты (т.к. в юрисдикции США аспиранты считаются PhD Students).


Что надо сделать, чтобы участвовать?


  1. Зарегистрироваться на https://summerofcode.withgoogle.com/;
  2. Выбрать вариант участия как студент;
  3. Выбрать ReactOS как проект участия;
  4. Описать в свободной форме то, что вы хотите сделать для проекта;
  5. Подписаться на почтовую рассылку разработчиков и продублировать туда текст из пункта 4;
  6. Обговорить в IRC свое участие;
  7. Взять в вашем учебном заведении Proof of Enrollment – бумагу, которая подтверждает, что вы являетесь студентом (или аспирантом) этого учебного заведения на срок Google Summer of Code.

Поторопитесь! Подача заявок закончится 27 марта!


Возможные идеи для участия – под катом.


Возможные идеи для участия


В этом году в качестве идей предлагаются следующие варианты (взято из Wiki ReactOS и свободно переведено с добавлением справочной информации):


  1. Ваша идея. Если вы уже немного разбираетесь в инфраструктуре ReactOS, то вы можете предложить свою идею для реализации в рамках GSoC.
  2. NDIS-драйверы для распространённых современных версий виртуальных машин. Это упростит установку ReactOS на последних версиях виртуальных машин, на которых уже не используются сетевые карты, для которых в проекте уже есть драйверы (такие, как AMD PCnet, Realtek RTL8139 и NE2000).
  3. Разработка фундаментальных компонентов для поддержки Wi-Fi. Сейчас в проекте есть поддержка открытых сетей Wi-Fi и сетей с шифрованием WEP, однако отсутствует поддержка большинства API, необходимых для работы с защищенными сетями. Для улучшения поддержки таких сетей предлагается реализовать API из Windows Vista+, также добавленное в Windows XP SP3, про которое можно почитать по этой ссылке.
  4. Поддержка технологии Plug-and-Play для стека устройств хранения. Это улучшит поддержку SCSI- и SATA-устройств. Предлагается начать задачу с улучшения драйвера scsiport, а потом улучшить поддержку PnP в драйвере UniATA.
  5. Стек поддержки протокола Bluetooth. Сейчас в ReactOS нет поддержки протокола Bluetooth. Предлагается начать задачу с менеджера устройств и поддержки профиля Bluetooth для поддержки передачи файлов (OBEX-FTP).
  6. Драйвер для шины Intel High Definition Audio. В ReactOS уже есть начальная поддержка этой спецификации для звуковых карт, и надо ее доработать, чтобы такой драйвер мог работать и на Windows, и на ReactOS. Подробнее про интерфейс шины – по ссылке.
  7. Драйвер для Wine Audio. В контексте проекта Wine драйвер – это модуль, реализующий некоторый набор COM-интерфейсов поверх различных Linux-библиотек (в контексте звука таких, как ALSA, OSS или PulseAudio). Наличие такого модуля позволит использовать последние библиотеки Wine, связанные со звуковым API, позволит локализовать весь интерфейс в одном месте и сделать совместимый с Vista и более новыми Windows звуковой стек.
  8. Аудиомикшер – позволит улучшить поддержку аудиодрайверов, которым мешает отсутствие этого компонента. По завершению этого проекта должна появиться возможность воспроизведения множества звуковых потоков в одно и то же время. Об аудиомикшере Windows можно почитать тут.
  9. Автонастройка прокси, используя файлы PAC (Proxy Auto-Configuration) и протокол WPAD (Web Proxy Auto-Discovery Protocol), что позволит системе проще подключаться к локальным сетям, где используются прокси-серверы.
  10. Удаленное управление Windows (Windows Remote Management, WinRM) – используется для удаленного администрирования систем под управлением Windows, концептуально немного похож на SSH.
  11. Дальнейшая интеграция поддержки протокола SMB (Server Message Block, в народе известно как "Сетевое окружение"). Несмотря на то, что уже существует Samba, ее код в некоторых местах специфичен для Unix-подобных операционных систем. Эта возможность очень востребована среди новых пользователей ReactOS (к примеру, передача файлов из хоста в гостевую ОС в VirtualBox завязана на поддержке сетевого окружения), и ее реализация приведет к общему улучшению поддержки сетевого окружения Windows. В качестве стартовой точки участнику предлагается начать с проекта Samba-TNG. Спецификация протокола SMB доступна по ссылке.
  12. Службы терминалов (Terminal Services). Один из ключевых компонентов для работы протокола для подключений к удаленному рабочему столу RDP. Необходимо доработать имеющуюся реализацию (об имеющейся функциональности см. вики), дополнив ее поддержкой входящих подключений удаленного рабочего стола.
  13. Расширение наборов тестов ядра ReactOS – покрытие тестами некоторых частей ядра, таких как менеджер кэша ядра, Plug and Play и другие. Основная цель – в экстенсивном тестировании Native API (немного подробнее о нём можно посмотреть тут: http://hex.pp.ua/native-api.php). В качестве эталонных результатов необходимо рассматривать поведение ядра Windows.
  14. Написание тестов для подсистемы Win32. Ядро NT поддерживает различные интерфейсы между User-mode-программами и функциями ядра. Такие интерфейсы называются подсистемами, и в теории (и на практике) можно написать такую подсистему, которая может реализовать набор API другой операционной системы. В рамках этой задачи вам надо будет написать различные тесты для взаимодействия ядра и подсистемы Win32. В качестве эталонной реализации необходимо рассматривать поведение ядра и подсистемы Win32 самой Windows. Необязательным заданием может быть запуск другой подсистемы (такой, как OS/2, или Interix) внутри ReactOS. Подробнее об подсистемах ядра NT можно посмотреть на английской википедии и в книжке Марка Руссиновича "Windows Internals".
  15. API автоматизации UI, связанное со специальными возможностями (Accessibility) Windows. Сейчас этот программный интерфейс не реализован в ReactOS, хотя он является важной частью ОС Windows, т.к. на нем основаны различные инструменты для людей с ограниченными возможностями (такие, как экранный диктор, к примеру). После реализации этого API участнику предлагается проверить его работу с помощью открытой утилиты NVDA (Non Video Desktop Access), помогающей слепым людям или людям с нарушениями зрения пользоваться компьютером. Также после реализации этого API оно будет предложено для слияния в проект Wine.
  16. Расширение оболочки для поиска. В рамках этой задачи необходимо написать Shell Extension для Проводника ReactOS, которое будет искать файлы, т.к. сейчас пока такое расширение еще не реализовано. Также это расширение должно предоставлять совместимые API для других поставщиков поиска, как это делает Windows. О расширениях оболочки можно почитать здесь, о расширениях, которые расширяют поиск – здесь.
  17. Поддержка паравиртуализации. Для улучшения опыта взаимодействия с ReactOS и повышения производительности предлагается реализовать некоторый набор API для поддержки различных гипервизоворов. В рамках GSoC предлагается выбрать одно из возможных направлений паравиртуализации:
    • Заставить работать открытые драйверы гипервизора Xen;
    • Реализовать набор драйверов, реализующих подмножество API гипервизора HyperV (такие улучшения также называются "Enlightenments";
    • Улучшить ядро, чтобы использовать VMI (virtual machine interface), интерфейс паравиртуализации, предложенный компанией VMWare;
    • Тестировать и интегрировать драйвера VirtIO, или гостевые дополнения VirtualBox, или open-vm-tools в ReactOS.
  18. Поддержка возможностей корзины из Windows Vista (NT v6.0+). В Windows Vista расширение оболочки, отвечающее за корзину, было расширено, и его внутренний интерфейс изменился. Предлагается в рамках проекта задокументировать изменения API и реализовать его в ReactOS. По оболочке Windows можно почитать здесь.
  19. Реализация компонента MSHTML поверх WebKit. В рамках этого проекта необходимо сделать адаптер между API WebKit, и API компонента MSHTML, который позволяет отображать HTML-страницы. Об интерфейсе MSHTML можно почитать тут, об интерфейсе WebKit – тут.
  20. Улучшить реализацию реестра. Для улучшения реализации предлагаются два возможных направления:
    • Улучшить отказоустойчивость реализации, чтобы при сбое реестр не повреждался;
    • Улучшить бинарную совместимость с реестром Windows. Сейчас в реализации реестра не реализованы до конца дескрипторы безопасности. Их реализация поможет интероперабельности с Windows и улучшит общую надежность системы;
      Детали внутреннего строения реестра можно найти по этой ссылке.
  21. Куст реестра, связанный с данными счетчиков производительности. Немногие знают, что в реестре Windows есть специальный куст, называемый HKEY_PERFORMANCE_DATA. Этот куст содержит множество различных счетчиков производительности, но работать с ними бывает довольно неудобно. В ReactOS пока отсутствует этот куст, и его реализация поможет многим приложениям (в том числе и от Microsoft) запускаться. Подробнее о том, как использовать счетчики производительности можно здесь.
  22. Консоль управления. Именно через неё работают почти все графические утилиты администрирования в Windows. В ReactOS есть зачаточная поддержка оснасток консоли управления, и в рамках этой задачи необходимо улучшить эту поддержку. Подробнее о консоли управления можно почитать тут.
  23. Поддержка файлов PDB в реализации библиотеки dbghelp. Эти файлы содержат отладочную информацию для приложения, а dbghelp содержит в себе API для работы с такими файлами. Поддержка этих файлов в ReactOS позволит отлаживать компоненты режима пользователя в таких утилитах, как WinDBG, Process Explorer, и других. О dbghelp можно почитать подробнее тут.
  24. Кроссплатформенная реализация отладчика уровня ядра (Kernel Debugger, KD). Утилиты для отладки Windows (и ReactOS также) от Microsoft являются проприетарными и работают только под Windows. Реализация таких кроссплатформенных утилит позволит отлаживать ReactOS в режиме ядра под другой хостовой ОС, а также позволит отказаться от более простого отладочного протокола KDBG, который поддерживается в сборках от компилятора GCC.
  25. Поддержка других портов для отладки ReactOS. Сейчас ReactOS поддерживает отладку через последовательный порт (COM-порт, RS-232), хотя многие компьютеры уже не имеют такого порта. Поддержка современных портов (типа 1394, Ethernet или USB) поможет отлаживать ReactOS на новых компьютерах, не используя на них режим режим отладки Screen, при котором все выводится на монитор компьютера с ReactOS. Также в рамках этой задачи в качестве альтернативы предлагается исследовать и реализовать недокументированный протокол отладки KDVM, поддерживаемый Hyper-V и другими гипервизорами.
  26. Поддержка отчетов об ошибках. Когда Windows падает, она записывает свое состояние в дамп памяти, и потом такой дамп можно проанализировать в отладчике. Поддержка дампов памяти в ReactOS упростит отладку и отправку отчетов об ошибках разработчикам. Подробнее о дампах памяти можно почитать тут.
  27. Поддержка нескольких мониторов. Сейчас в ReactOS есть поддержка перечисления мониторов, благодаря реализованному API HwVidGetVideoChildDescriptor в драйвере videoprt.sys. Этот драйвер дальше передает информацию драйверу подсистемы Win32 (win32k.sys), и уже именно win32k.sys решает, как необходимо отображать картинку на втором мониторе – дублировать, или расширить рабочий стол, или не использовать монитор. Реализация такого API позволит использовать ReactOS на нескольких мониторах, что бывает очень полезно для разработчиков, дизайнеров и простых пользователей. Подробнее можно почитать на MSDN.
  28. Поддержка драйверов печати режима пользователя. В рамках архитектуры Windows существует множество интерфейсов для драйверов принтера (PostScript, Plotter, GDI/win32k). В рамках этой задачи необходимо реализовать базовую поддержку для драйверов печати пользовательского режима, использующих интерфейсы GDI. Подробнее о таких интерфейсах можно почитать тут.
  29. Многопользовательская поддержка нескольких сессий. В современной Windows эта служба называется "Служба удаленного рабочего стола" (Remote Desktop Services) и реализация поддержки множественных сессий позволит каждому пользователю работать в своём изолированном окружении, запуск от другого пользователя (с созданием отдельной сессии) и улучшит совместимость с возможностями удаленной работы с Windows. Почитать про службу терминалов можно тут.
  30. Web-интерфейс для разработчиков. После перехода на git некоторые старые утилиты непрерывной интергации (такие, как buildbot, testman) стали хуже работать друг с другом. Поэтому предлагается реализовать улучшенную версию Web-интерфейса для разработчиков, который позволит показывать коммиты, билды, пулл-реквесты и пр. и сможет связывать их друг с другом, в том числе с использованием фильтров поиска. Это поможет ориентироваться в кодовой базе новым и старым разработчикам. Идеи по Web-интерфейсу детально расписаны в соответствующем разделе ReactOS wiki.

Как видите, идей для Google Summer of Code полно. Не упустите свой шанс поработать в интересном проекте с первоклассными наставниками и менторами в самых разных областях. Выбирайте любую вам понравившуюся идею (или предложите свою), регистрируйтесь на сайте и отправляйте свою заявку!


P.S. Спасибо всем, кто дочитал до этого момента. Огромная просьба писать об ошибках (грамматических, пунктуационных, синтаксических, речевых, и, что самое главное, – фактических) в личку мне, или в наш Telegram-чат.

Комментарии (31)


  1. alan008
    17.03.2018 20:48

    Подача заявок закончится 27 марта!

    Странно, что предложение поучаствовать появилось за 10 дней до окончания подачи заявок. Создается впечатление, что хотели сначала придержать места, но желающих нашлось мало и пришлось их искать уже везде


    1. Fails Автор
      17.03.2018 20:51
      +2

      "Не стоит искать злой умысел там, где это можно объяснить глупостью" – подача заявок от студентов (если верить таймлайну ) началась 12 марта, а я эту публикацию слишком долго писал (3 дня примерно). В следующий раз надо оперативнее, соглашусь.


      1. SaturnTeam
        18.03.2018 07:23

        Честно говоря у меня тоже такая нехорошая мысль возникла из-за этой рекомендации.

        5. Пишем пропозал.

        После выбора проекта вы должны написать пропозал. Официально вы должны запостить свое предложения в начале апреля. Не официально — к этой дате организация уже имеет черновой список принятых студентов.


      1. Mugik
        18.03.2018 13:24

        «Проект стартовал в 1998»
        И бета-версия так толком ещё и не вышла, как я понял.
        «ReactOS уже третий год подряд получает слот»

        слишком долго писал

        Я смеюсь :) Простите, не умаляю важности и супер необходимости этого всего, что вы делаете, наверно…, но это реально очень смешно.


        1. sumanai
          18.03.2018 15:39

          Активно писать начали года четыре назад, до этого баклуши пинали.


    1. Jeditobe
      19.03.2018 00:52

      Объявление на Моем Круге висит уже достадочно давно.


  1. saboteur_kiev
    17.03.2018 23:41

    Удаленное управление Windows (Windows Remote Management, WinRM) – используется для удаленного администрирования систем под управлением Windows, концептуально немного похож на SSH.


    Кстати, а почему бы не встроить натуральный ssh в ядро, чтобы по дефолту сразу вызывал cmd, точнее сделать возможность выбирать shell на будущее?


    1. Fails Автор
      17.03.2018 23:48

      Звучит интересно; можете попробовать предложить в IRC


      Концептуально, конечно, это надо просто добавить пакет с SSH, но вам там подробнее расскажут


    1. x86corez
      17.03.2018 23:53

      Это конечно интересная идея, но она не продвинет развитие проекта в сторону лучшей совместимости с Windows (а это есть исходная цель).


      1. Fails Автор
        17.03.2018 23:54

        Ну, только если с Windows 10 :)


      1. saboteur_kiev
        18.03.2018 04:33

        Зато это то, что категорически не хватало в Windows всегда, когда нужно было администрировать. Удаленное выполнение консольных команд в винде было ужасным.


        1. x86corez
          18.03.2018 14:20

          Что ужасного в использовании утилиты PSExec?


          1. saboteur_kiev
            19.03.2018 02:38

            Отсутствие кроссплатформенности.
            Тот же putty — не знает что такое bash, он знает что такое ssh и все.
            Зато насколько ssh протокол более защищенный, устойчивый и нетребовательный к линии связи, по сравнению с telnet или RPC


            1. x86corez
              19.03.2018 14:16

              В принципе, в качестве GSoC проекта было бы интересно увидеть реализацию Telnet сервера для ReactOS, с возможностью работать не только по стандартному небезопасному соединению, но и по SSH.


              1. saboteur_kiev
                19.03.2018 17:01

                Телнет сервер с возможностью работать по ssh? Это как?

                Сразу не ssh сервер. Или отдельно телнет, отдельно ssh. Это же протоколы.


                1. x86corez
                  19.03.2018 17:10

                  Поскольку ssh это универсальное средство (не только лишь терминал), то скорее всего он должен быть отдельной службой, которая будет связываться напрямую с Telnet сервером (в частности) в случае запроса терминала.

                  Просто чтобы начать делать SSH сервер, придётся его с чем-то связать для работоспособности.


                  1. saboteur_kiev
                    20.03.2018 02:42

                    телнет — это протокол. ssh — это протокол.
                    И то и то можно подключить к консоли напрямую.

                    Зачем же тогда делать ssh через telnet?


                    1. sumanai
                      20.03.2018 04:07

                      telnet фигня без шифрования, ssh годнота с шифрованием и аутентификацией по ключевым файлам.
                      Правда что там писать не пойму, обычный тоннель и проксирование.


  1. Fails Автор
    17.03.2018 23:54

    Да, также можете откликнуться на вакансию в Моем Круге. Она у нас где-то с середины февраля висит


    1. SaturnTeam
      18.03.2018 07:26

      От 3 000 до 6 600 eur.Неполный рабочий день

      Это получается надбавка к $3200 от гугла?


      1. Jeditobe
        19.03.2018 00:51

        Все вознаграждение от Гугла, объем зависит от страны нахождения.


  1. Kluev
    17.03.2018 23:55

    Какие требования к студентам?


    1. Fails Автор
      17.03.2018 23:57

      Для работы с исходным кодом необходимо, конечно же, знать языки C/C++. Для Web-сайта – any, что может быть использовано. Но по вебу надо опять же писать в IRC.
      Также надо уметь работать с Git, уметь собирать проект из командной строки (там есть вспомогательные скрипты). Вроде бы всё. Конечно, есть еще детали, но, думаю, что эти пункты основные.


    1. x86corez
      18.03.2018 00:01
      +1

      Требования разные в зависимости от того, за какую задачу возьмётесь.

      В основном конечно акцент на программирование — а это написание программ на C/C++, умение читать исходники, разбираться в принципе их работы.

      Плюсом будет опыт написания программ под Win32 API и умение работать в среде Visual Studio или с набором утилит MinGW (в том числе с отладчиками).


  1. novikovag
    18.03.2018 13:40
    -1

    ReactOS закопали уже много лет назад, как ос лютое г… но, лучше бы свои усилия на вайн напрвили.


    1. x86corez
      18.03.2018 14:30
      -1

      Кто закопал и куда?

      Проект живёт активной жизнью, коммиты пушат, регрессии фиксят, тесты прогоняют, и с вайном обмениваются патчами в двустороннем порядке.


    1. domix32
      18.03.2018 16:43

      Вижу ровно обратную ситуацию


  1. decomeron
    18.03.2018 14:41

    А что с защитой?


    1. x86corez
      18.03.2018 15:01

      Лучшая защита — нападение в BSOD. :)

      Ну а если серьёзно, то с элементарными базовыми вещами, такими как ACL и защитой памяти ядра сейчас не гладко.

      Буквально на днях один из разработчиков Timo Kreuzer (кстати, бывший студент GSoC) начал реализацию функции защиты памяти ядра MiSetSystemCodeProtection. Сейчас он активно занимается AMD64 портом системы.


      1. decomeron
        18.03.2018 17:07

        В списке нет этого


        1. x86corez
          18.03.2018 17:30

          Вряд ли может быть GSoC проект с темой «реализация системы защиты ReactOS», поскольку это звучит размыто — нельзя чётко определить границы, когда его можно будет считать полностью выполненным.

          Даже если кто-то возьмётся, это будет колоссальный труд, на несколько уровней выше типичного проекта в рамках GSoC.