Доступны результаты опроса разработчиков открытого ПО, проведённого компанией Intel. На вопрос об основных проблемах открытого ПО 45% участников отметили выгорание сопровождающих, 41% - обратили внимание на проблемы с качеством и наличием документации, 37% - выделили поддержание устойчивого развития, 32% - организацию взаимодействия с сообществом, 31% - недостаточное финансирование, 30% - накапливание технического долга (участники не доводят работу до конца), 27% - контроль качества...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60634
Хорошо что в закрытом ПО такой проблемы нет. Нет документации - нет проблемы
У проприетарщиков: "Нет исходников - нет проблемы".
> У проприетарщиков: "Нет исходников - нет проблемы".YOLO! Учись как надо было: нет багтрекера - нет проблем! Ни с документацией, ни с программой, ни с хоть там чем - вот, маркетинговый буклетик почитайте, там написано как все ЗБС! :)
>Нет документацииhttps://learn.microsoft.com/ru-ru/docs/
https://developer.apple.com/documentation/
Документация Microsoft на русском это ужаснейший автоперевод. Кстати, Гугл туда же подался. Разленились в край.
https://learn.microsoft.com/en-us/docs/
Читайте в оригинале.
Программист без знания английского - инвалид.
И радуйтесь, что не приходится читать оригиналы на китайском, которые что с автопереводом, что после курсов китайского для начинающих, в любом случае читаются как ребусы.И кстати, может автоперевод и не очень, но это больше сказывается на эстетических чувсвах, а на запрошенный вопрос ответ они дают.
С радостью. Только вот оно путается под ногами в поиске. А если всё-таки поиск выдаст оригинал, то особо умные автоматом переключат на язык браузера.
Вы не волнуйтесь, оригиналы на китайском и для того, кто неплохо знает китайский, читаются как ребусы.Как говорил Линус Торвальдс "что рождалось с трудом, пониматься тоже должно с трудом".
Текст от автопереводчиков не понятен на тонком уровне,я когда читаю - много смысла могу пропускать мимо. Если что-то сложное.
А ещё я потом в жизни могу использовать термины и конструкции придуманные автопереводчиком.
Сепир и Уорф тихонько курят возле пустой цистерны с бензином, а нативных спикеров взрывает лингвистический термин "лакуна".
А вот вы ж не пользовались этой документацией) Индусские примеры кода на C# которые никто не проверял на валидность, которые не скопированы из рабочего экземпла, а накиданы из головы, с опечатками и выдумками прекрасны. И надцать раз переехавшие ссылки, из-за чего иногда поиском приходишь на статью - а её нет давно
Естественно, используют оригинал, а не машинный перевод. До Platform SDK и DDK документации по любимому всеми здешними экспертами XCB (угадайте, что это) как до Луны пешком.
Кстати был случай. Начинающие програмисты аномально долго отлаживали почти дидактическую програмку.
В переводах документаци на STM32 были обнаружены ляпы перевода, дающие заведомо ошибочное понимание.
После впадантя начинающих программистов в ступор, по вине такокой документации, горе-переводы были безжалостно удалены с локальных серверов.
Есть и куда эпичнее случай с переводами: "низкоуровневое программирование". С точки зрения нормального человека, "программировать на низком уровне" - это тяп-ляп. :)
А где ж вам померещилось "перевод"? Там в коде, на английской странице, примеры не валидные
А может мне померещилась ссылка на страницу? В Platform SDK и DDK, о которых я писал, такого нет.
Назвать это документацией сложно, скорее декларация
Сколько встречал проприетарного ПО — всегда документация была, ещё начиная с MS-DOS (книжкой от Windows 3.11 вообще можно было телесные повреждения нанести).
А разгадка одна:
1) писать документацию — это трудоёмко;
2) держать документацию в актуальном состоянии — это трудоёмко;
3) писать документацию надо уметь, это совсем другой навык по сравнению с программированием;
4) самое главное: писать документацию СКУЧНО И НЕИНТЕРЕСНО, по сравнению с кодингом. В проприетарщине такой проблемы нет, там для этого специально обученные люди на зарплате сидят.
> там для этого специально обученные люди на зарплате сидятахахахахахааххахахахахахахаха. Первый день в вайтишке? Так же смешно, как утверждение, что документация всегда была. Далеко не к каждому продукту вы ей даже интересовались.
Приведите пример.
(впрочем, я и не утверждаю, что она всегда есть, но лично с такой проблемой не сталкивался.)
Ты просто не читал документацию к продуктам IBM, а уж их IBM Redbooks - это вообще академический уровень написания документации, лучший образец.
>академический уровень написания документацииКак и у Cisco например.
И в судах выиграли:
https://www.cisco.com/web/RU/news/releases/txt/0297.html
В средних и крупных компаниях целые отделы технических писателей создаются. Поинтересуйся, кто это такие.
>документация была, ещё начиная с MS-DOSИ ею же заканчивая.
Толщина документации отнюдь не означает ее практическую пригодность.
У тех же M$ можно постоянно продираться сквозь разжевывание очевидных вещей с придумыванием собственной, ни на что не похожей терминологии - а как все это обложенное жеваной бумагой работает на практике и может быть приложено к конкретным задачам, только эмпирическим путем и выяснишь...
Ну этим троллям всегда "там" хорошо.
Что ж, пользуйтесь продуктами M$, если они Вам так милы.
Впаривайте их своему работодателю / нанимателю втридорога, с конскими наценками. Завязывайтесь на них по самое нехочу, тем самым создавая вендорлок.
Это эволюция, тупиковые ветви тоже ведь зачем-то нужны.
Старые книжки у MS были отличнейшие.
MSDN — тоже пример документации.
> писать документацию — это трудоёмко;
> В проприетарщине такой проблемы нет, там для этого специально обученные люди на зарплате сидят.У нас она генерировалась из исходного кода и писалась программистом сразу вместе с сервисом.
Но даже при этом в конце в стандарт пришлось добавить требований для реализации пустяковых фич, но ооочень сильно упрошающих от невозможного к возможному диагностику у эксплутационщиков.
При этом горе начальник должен быть без просчётов с забытым временем на реализацию того, сего, когда уже обещал дату релиза и уже взял ипотеку. И если был просчёт, то время на документацию может быть использовано на халтур-кодинг.
И всё становится печально у такой проприетарщины.
> У нас она генерировалась из исходного кодаЭто сопроводиловка, а не документация. Без человеческого описания, что это и зачем (а не как реализовано) - можно считать, что ее нет. Показать аргументы функции и IDE умеет.
Вот в этом и беда - что программисты "в эксплуатацию" не умеют, и собственно "документации" как правило в глаза не видели. А видели... кто "language reference", кто арчевики, а кто и вовсе - стековерфлоу...
> У нас она генерировалась из исходного кода и писалась программистом сразу вместе с сервисом.Сгенерьте мне таким образом документацию к фотошопу, пожалуйста.
К слову, у Adobe, кроме онлайн-справки, на сайте лежит талмуд в PDF на 1000+ страниц.
У Adobe с документацией хорошо, да.
https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf - документация по языку PostScript, позволяющая его освоить и пользоваться, не прибегая ни к каким другим материалам.
>Сколько встречал проприетарного ПО — всегда документация была, ещё начиная с MS-DOSПокажите мне документацию для Microsoft Word. Мне _очень_ нужна прямо вчера.
Если сами не смогли найти, обратитесь в поддержку. Вы ведь его купили, правда?
> Хорошо что в закрытом ПО такой проблемы нет. Нет документации - нет проблемыТам выгорание 4 из 5 в старших должностях.
Документация бывает плохая или совсем нет, но гораздо хуже, что попытка экономить и делать minimum viable/valuable product заканчивается сохранением недоделки.
Как в у мелкомягких: талантлив? - или сюда талантливо халтурить!
Я как человек, который пишет документацию для закрытого продукта, смотрю на тебя с недоумением.
фух! проблемы открытого ПО на десктопе решены!
Опрос показал, что возможность для решения отсутствует: некому (существенная часть выгоревших в опросе не участвовала) и нет условий (документации).
>существенная часть выгоревших в опросе не участвовалаих в первую очередь и нужно было опрашивать
Это от целей опроса зависит. Если требуется оставить всё как есть (фанаты якобы борются за свободу и против корпораций, продающих вечную поддержку), то наоборот следует их исключить.
В принципе согласен с участниками опроса. У меня схожие ощущения.
PyTorch'ки всё также PyTorch'ат...
> 45% участников отметили выгорание сопровождающихУгадайте слово из шести букв, означающее "полный крах всех надежд", вторая "и" (правильный ответ: фиаско). Статистика не учитывает систематическую ошибку выжившего.
Ни разу не сталкивались с заброшенными проектами? По той простой причине, что автору надоело.
Нет, не сталкивался. Мне пришлось "забросить" an estimated 51 years of effort (COCOMO model) поскольку цель СПО в России согласно ГОСТ - удаление программистов с рынка.
рынок? О_ои какое определение по ГОСТ-у у "рынка"?
ГОСТ Р 54593-2011. Информационные технологии. Свободное программное обеспечение. Общие положения.Скачай и почитай сам (в сообщении выше отсылка к п. 4.1.1), вместо вот этих попыток потроллить.
И какой толк от этих стандартов?
Каждому свой. Одним даёт основания говорить, что они делают хорошие дела. Другим он объясняет, чем на самом деле заняты первые.
там нет определения, ток упоминание в 4.1.1 в стиле "продаем клоны (форки) дешево".> вместо вот этих попыток потроллить
там где речь заходить про СПО, последнее о чем можно говорить в этом контексте, это о "рынке".
Там и слова "программист" нет.
и чем вам модель "цап-царап" не нра?
Попользуйся современным мелкософтом, это их модель.- Когда для близоруких интерфейс разъезжается у их вебни,
- когда почтовые фильтры невозможно админить,
- когда управления конфигурациями без систем версионирования (типа Svn/Git нет и не будет; хотя - пакетиование на их месте, но тут админы в свою очередь не догадываются),
- в мультифакторке "морковь-чё" в интерфейсах и сбоит переодически,
- с чатиками 15 лет хоть раз в неделю, но работает именно через пень колоду,
- код страны в номере телефона может быть перпереставлен на стороне сервиса 007 и 077, а это система без-ти и аутен-ции.Тухло, душно как-то при цап-царап. В опенсорсе свободней дышится: не смог - таким себя сам сделал, никто не неволил, но зато есть возможность делать для людей.
А ты отлично разбирашься в продуктах мелкософта, что аж подозрительно (≖_≖ )
Возможно все то что ты написал правда, проверить я все равно не смогу.
Но по какой-то причине юзерам оно удобно.
А вот декстопный линукс - нет.> В опенсорсе свободней дышится: не смог - таким себя сам сделал, никто не неволил, но зато есть возможность делать для людей.
Угу тонны УГ, тысячи васяно дистров, форки-форов и тд.
А еще селые секты поехавших на щвоßодке которые не признают друг-друга и спорят кто посвободестее (libroboot'ы и прочие)
Юзера и пальмовое масло едят, и руки моют анионными мылами, вместо катионных.
Миллион мух не может ошибаться. :)Проблема не удобстве, а духоте халтуры отдельных проприетарщиков. Не всех.
Но и у тех, у кого качество высокое, душно от искуственности и надуманности ограничений.
> что аж подозрительно
P.S. Да просто наши винадмины на работе находятся в пяти метрах. Волей неволей будешь в курсе какое г. MS с изнанки.
> но зато есть возможность делать для людей.где-то я это уже слышал - "земля крестьянам!", ага.
Наоборот, с другого континента: бери, делай, покажешь результат.
Не можешь? - Извини, давай досвидания.Основное в исходной _возможности_ взять и начать делать без запрещения кем-то, без чужих правил.
Но многие не смогли. Их назвали васянами, у них же MS Teams получился сбойно-забагованный даже во второй версии New.
Вам не кажется, что проект может быть "заброшенным" потому, что он уже почти совершенен и в него ничего добавлять и убавлять не надо?
Проект может быть заброшен по совершенно разным причинам. От автор умер, протерял доступы, нашёл готовое решение которое его устраивает больше, до в сотни раз большего заброшенных коммерческих проектов о которых, в отличие от открытых, может никто никогда и не узнает потому что бизнес не оправдался.
О да, он на убунточке 14.04 автора совершенен. А если у кого на современной оси не компилируется — ну вам же никто ничего не должен.
Само слово "заброшен" говорит о том, что причины не известны и выдуманы. Если проект "совершенен", то он завершён. Если проект коммерческий не целесообразно развивать далее -- то он "свёрнут". Даже если сам автор говорит "я забросил" -- это всего лишь значит, что он не хочет углубляться в детали.
> 45% участников отметили выгорание сопровождающихИ это был опрос среди еще не выгоревших))
А сколько таких проигнорило опрос - одному Патрику известно.Вообще это не удивительно. Сейчас не 80-90е, новизны стало совсем мало, ты не можешь слабать за два вечера супер-пупер не имеющую аналогов (в прямом смысле) программу.
Зато появилось много рутины, много взаимодействия с другими проектами, куча неочевидных легаси решений, которые были приняты годы назад по хз каким причинам.
Для поправки на ошибку выжившего в первом приближении умножаем на 2, получается 90%. Теперь смотрим на кривую Гаусса. Выгорание является "нормой". Естественно, что ему не подвержены не занятые производством: идеологи, коммитеры в CoC, сборщики из исходников и прочие плохо понимающие, чем они на самом деле заняты. Вот они остаются и привлекает новое "мясо", что обеспечивает кажущуюся устойчивость системы.
> ты не можешь слабать за два вечера супер-пупер не имеющую аналогов (в прямом смысле) программуПочему же мне постоянно приходится добавлять в опенсорс чего-то не хватающего? Причём даже за пару дней.
Вон, в один только Nushell сколько всего нужно добавить нужного, причём это несложно (если знаешь что-то кроме Си в 2024 году).
>> ты не можешь слабать за два вечера супер-пупер не имеющую аналогов (в прямом смысле) программу
> Почему же мне постоянно приходится добавлять в опенсорс чего-то не хватающего? Причём
> даже за пару дней.Очевидно, потому что программа, куда приходится что-то _добавить_, писалась куда больше двух дней, и даже этого времени оказалось мало.
каким боком интел к открытому ПО? это как спрашивать проститутку о мнении по религиозным вопросам
Так обычно так и поступают на практике, только аналогия не совсем верная.
Аналогия неверная, да. Реальная жизнь гораздо сложнее. Как и причины выгорания экосистем.
Смотрим какое-то открытое ПО.
Например Х.ОРГ people.freedesktop.org/~vignatti/xdevelopment/xorg_19_xserver-SHOWING-WHEREIS-CANONICAL.txtTop changeset contributors by employer
Intel 87 (17.2%)
jamey@minilop.net 75 (14.9%)
Red Hat 67 (13.3%)
Nokia 62 (12.3%)Вспоминаем что иксы это просто кусок ала в котором не хочет копаться.
Сопоставляем полученную информацию со статьей.
Жалеем сотрудников интел))
Интеловский драйвер для видях был лучшим открытым драйвером для видях долгое время.
Об этом примерно 15 лет назад написали, ЛОЛ:https://itvision.altervista.org/why.linux.is.not.ready.for.t...
Выгорание, по причине отсутсвия документации, из-за отсутствия обратной связи разработчика с пользователями, по частой причине безпочвеной вони, о том, что кто-то сделал бы лучше.82% за ии? Ну-ну...
из этих сказочников половина "ну точно в следующем году начнут учить хруст, ведь им интересно" (спойлер - нет)
Основная проблема опенсорса - это дизлайки и теневые баны. Человек тратит время, деньги, кодит, что то получается. А его нет чтоб поддержать, минусуют банят. Всем подавай высокое качество бесплатно.
Не, проблема опенсорса в том, что каждый васян наовнячивший какой-то кусок кода, считает "не раз оно запустилось - значит оно идеально! его же создал такой гений как я!!"А потом, когда в этом выпрограмише начинаю находить узявимости, то чел начинает агриться.
Типа "вы что хотели высокое качество!?"И ладно если это какой-то лефтпад, а когда ребята из OpenSSL, берущие денежки у корпов, выкатывают HeartBleed, а потом такие "нужно больше денег!".
Казалось бы, причём здесь open source? Эта проблема (уязвимости и/или другие баги) везде есть. И куда обидней, когда она проявляется в платном ПО с платной техподдержкой при том, что эта техподдержка вначале все соки из тебя выпьет, прежде чем признает проблему.
>При выборе наиболее интересных открытых проектов 80% упомянули ядро Linux, 42% - язык Rust, 38% - LLVM/Clang, 35% - GCC, 24% - Kubernetes, 17% - PyTorch, 15% - eBPF.Наверное интерес там не в разработке их, а в использовании. Вкатиться в их разработку почти нереально — их-то и просто собирать несколько часов со всеми оптимизациями.
ИМХО главный бич СПО — это безразличие апстримов. Ты сделал фичу, послал PR, и он 5—10 лет висит и апстрим его даже не интегрирует. Апстрим активен, но на твою лично фичу ему по фигу. Ты её периодически перебазируешь на master, апстриму от этого прилетает уведомление, но ему всё равно пофиг.Ещё бывает PRы просты закрывают из-за тараканов в голове апстрима "а я вот хочу так, и **** я хотел на всё остальное, я тут главный".
> Ты сделал фичу, послал PR, и он 5—10 лет висит и апстрим его даже не интегрирует.Возможно фич слишком много, и мейнтейнеры не успевают (хотя речь не про 10 лет)))
> Ещё бывает PRы просты закрывают из-за тараканов в голове апстрима "а я вот хочу так, и **** я хотел на всё остальное, я тут главный".
Ну... объективно твои предложения могут действительно проиворечить видень авторов.
Тут конечно хорошо, если вежливо ответят и пояснят почему они не принимают фичи (у меня такое біло несколько раз, я совершенно не обидился).С другой стороны, иногда приходят с реально бредовыми идеями.
Например вот bugzilla.freedesktop.org/show_bug.cgi?id=865
Пришли с просьбой нарушить XKB specification, потому что "It's a very annoying bug, a lot of Emacs shortcuts don't work because of it."
На ответ "есть стандарт" начали ныть, что нужно бы "make everyone happy".Ну и, как кучка (не шоколада) сверху на этом торте из нытья, куча комментов вида
"Five years the problem remains not solved."
"This bug is now 7 years old and it's still not fixed?"
"It will be a real shame if this issue, that is actively discussed by the community for 10 years now and is hurting a lot of users, will be ignored for another 10 years."
>Возможно фич слишком много, и мейнтейнеры не успевают (хотя речь не про 10 лет)))1. часто проект авторский, автор на него клянчит донаты, и ему часто важно демонстрировать, что вот он автор. А нужна фича в апстриме — ну заплатите автору, он реализует. У некоторых проектов такая модель.
2. Часто автору лично эта фича не нужна. Была бы нужна — сам бы и реализовал. Логично?>Ну... объективно твои предложения могут действительно проиворечить видень авторов.
Да, могут. Бывают фанатики контейнеров, статической линковки и вообще перекомпиляции a la Bazel, но на подмодулях и CMake. Впиливаешь детектирование и использование либ из дистра — закрывают с формулировкой, что они не могут доверять дистру, а на несовместимость такого пакета с пакетированием для дистра — "компилируйте сами", "флэтпак юзайте", вообще "мы вас не обязываем нашу программу юзать" — вот такого рода аргументы. У некоторых сносит крышу от осознавания собственной важности и новообретённой власти, когда они делают уникальную (из числа "швaбодных") программу, когда ближайшие аналоги с коммерческой лицензией стоят сотни баксов за лицензию.
> А нужна фича в апстриме — ну заплатите автору, он реализует.А интересно, вот это хоть раз в современной истории работало? Регулярно такое про опенсорс слышу, а видеть никогда не видел.
SQLite — пример из палаты мер и весов: известный и значимый проект с явно прописанной такой политикой. Ты, конечно, при желании сможешь сделать свой форк. Но и сопровождать его будешь тогда ты, а в пакеты дистров он никогда не попадёт и на него всегда будут смотреть как на васянозависимость. Другое дело, что согласно докам SQLite основные его спонсоры — это ... автомобильная индустрия. Такие пакетами из дистров не пользуются.
>> А нужна фича в апстриме — ну заплатите автору, он реализует.
> А интересно, вот это хоть раз в современной истории работало? Регулярно такое
> про опенсорс слышу, а видеть никогда не видел.Это работает как раз в опенсорсе (потому что есть нюанс - в апстрим для всех остальных могут и не опубликовать). Про GPL не слышал, обычно все хотят нахаляву.
>>Ну... объективно твои предложения могут действительно проиворечить видень авторов.
> Да, могут. Бывают фанатики контейнеров, статической линковки и вообще перекомпиляции a
> la Bazel, но на подмодулях и CMake. Впиливаешь детектирование и использование
> либ из дистра — закрывают с формулировкой, что они не могут
> доверять дистру, а на несовместимость такого пакета с пакетированием для дистра
> — "компилируйте сами", "флэтпак юзайте", вообще "мы вас не обязываем нашу
> программу юзать" — вот такого рода аргументы.Совершенно верные аргументы, обусловленные нежеланием тратить время на тех, у кого свобода ПО трактуется исключительно как личная выгода. Если ты научишься писать программы, поймёшь их точку зрения.
> У некоторых сносит крышу
> от осознавания собственной важности и новообретённой власти, когда они делают уникальную
> (из числа "швaбодных") программу, когда ближайшие аналоги с коммерческой лицензией стоят
> сотни баксов за лицензию.Так в чём проблема? Покупай по сотне баксов копию и включай в свой нескучный дистрибутив.
Выбирайте проекты с меньшим числом звездочек и с более дружным комьюнити, там и работать приятнее, и фичи влетают в тот же день после ревью.
Я как бы не выбираю проекты. Я выбираю фичи, а еслр фичи есть в одном проекте, то приходится выбирать его.
Выбираешь фичи, чтоб потом впилить недостающие фичи, и поныть на трудность принятия твоих фич.
Отличный план.
Предлагаешь просто с нуля свой незалежны1 луна-парк сделать? Или сделать хардфорк и самому его и поддерживать и развивать?
Предлагаю изначально выбирать софт/сообщество правильно. Из серии: emacs/vim, screen/tmux, irssi/weechat, ratpoison/stumpwm, lighttpd, suckless, etc. Большая часть из них даже не требует запиливания фич, так как фичу уже запилили и нужно лишь кастомизировать для себя. А если требуется - кодовая база стабильна, и позволяет твоему патчу жить без переделки годами. Сам же софт стабильный, баги известны, патчи от разных энтузиастов написаны, и сами софтины работают 24/7 без проблем на тысячах машин по всему миру.Впрочем, ты не привел пример, может тебе жизненно необходим какой-нибудь патч в контролируемый красношляпой или интелом софт. Так учти, там выгорание у людей. :-D
> главный бич СПО — это безразличие апстримов. Ты сделал фичу, послал PR, и он 5—10 лет висит и апстрим его даже не интегрируетЭто не имеет отношения к СПО. Если я сделаю для чужого проекта что-то, что владельцу не нужно или не нравится или без согласования - оно даже в коммерческой конторе может быть отвергнуто.
Результаты опроса, кстати, вполне коррелируют со старой новостью про "Сокращение срока поддержки LTS-ядер Linux" (opennet.ru/opennews/art.shtml?num=59791)
Так тоже плач, что все сложнее искать немамонтов, которые будут бесплатно работать.
А денег у ЛинуупсФаундейшена 60 лярдов, но на зарплаты нет))
Скудная документация это фича современного СПО. Решение способа оплаты труда программиста. Не хочешь бесплатно разбираться в трех строках мануала, купи консультацию у авторов.
в qt и archlinux шикарная документация, лучше просто нет
Второе просто гомерически смешно, да.
А первое ложно. Qt - проприетарь с двойной лицензией. На то он и эксперт.
Ну да, а вместо трех строк мануала получишь целый лист.
> Скудная документация это фича современного СПО. Решение способа оплаты труда программиста.
> Не хочешь бесплатно разбираться в трех строках мануала, купи консультацию у
> авторов.Практически у всего более менее значимого GNU софта отличная документация.
42% - Rust. Немыслимо, комментаторы опеннета возмущены
Идеалом считаю документацию от Borland на С++. К сожалению, устаревшая, но иногда пользуюсь и печатным, и электронным вариантом.
Можно подумать, ты когда-либо пользовался другой документацией.
> На вопрос о наиболее значимом аспекте открытого ПО, 46% выделило лицензии на кодЯ давно подозревал, что «открытое ПО» где-то в конце девяностых/начале двухтысячных превратилось в ритуал вроде религии или ансамблей «народных» песен и плясок. Теперь видно, что это не просто подозрение.
> Я давно подозревал, что «открытое ПО» где-то в конце девяностых/начале двухтысячных
> превратилось в ритуал вроде религии или ансамблей «народных» песен и плясок.Не соглашусь.
Открытое ПО это отличный инструмент для
- поиска немамонтов, которые будут тебе бесплатно писать код
- поиска таких же, только для тестирования
- крайне редко, но можно еще какой-то грантик урватьГлавное не продолбаться с лицензией, лучше сразу брать такую, чтобы можно было в бизнесе использовать.
Ну и желательно Copyright Assignment, но это надо находить уж совсем непуганных немамонтов
> немамонтов
> будут _тебе_ бесплатно
> поиска таких же
> грантик урвать
> главное не продолбаться
> непуганныхO tempora, o mores. Я думал вы вымерли в 90х, как вообще в ойти попали?
> наиболее интересных .. 42% - Rust, 38% - LLVM/Clang, 35% - GCC, 24% - Kubernetes, 17% - PyTorch, 15% - eBPFЧивоо?! Кто все эти люди??
Или правильные пацаны из корпорации Intel нарисовали правильный рейтинг?
Добро пожаловать в реальный мир, юный падаван.
А как же мои любимые PHP, Java, Go и JavaScript они куда-то вошли?
У BSD систем шикарная документация, гораздо лучше, чем у любых проприетарных продуктов. Тут дело не в опенсорс, а тупо в бабках. Всё дело в том, что такие компании, как, например, Ред Хат зарабатывают деньги на поддержке и им просто невыгодно писать документацию к их намеренно раздутым и переусложнённым продуктам, ведь они будут терять гешефт.
Маны это не документация.
Маны и хэндбук это документация. Самая что ни на есть исчерпывающая для использования и администрирования системы. Покрывает полностью спектр задач.А если уже охота лезть в код а по природе овощ овощем, то бери книги от разработчиков, из серии The Design and Implementation of the xyzBSD. Плати или качай бесплатно.
Нет. Маны — это user's manual. Инструкция по использованию. Это часть документации, но само понятие намного шире.
Условно, man — это «для того, чтобы сделать так, сделайте вот так». А что можно сделать, зачем и почему — они не описывают.
>Нет. Маны — это user's manualman 1 man.
>Это часть документации, но само понятие намного шире.
Шире. Как небо. И даже аллах.
Расширяется хэндбуком и книгами.
>Условно, man — это «для того, чтобы сделать так, сделайте вот так».
очень условно. man 1 man, чтоб не быть таким "неоднозначным".
> А что можно сделать, зачем и почему — они не описывают.
описывают. Краткость покрывается хэндбуком и книгами.
> Расширяется хэндбуком и книгами.Ха! А их создание — дело сугубо добровольное.
>> Расширяется хэндбуком и книгами.
> Ха! А их создание — дело сугубо добровольное.И маны дело добровольное. И само программирование. Ты скучаешь по кнуту, или в чем претензия? Все равно ж лучше документации BSD ничего нет (в соотношении объема/качества).
Вы качество OSS софта Intel видели?
Про выгорание, так они же сами создают ситуацию когда у тебя пять менеджеров и каждый говорит не слушай того этого делай что я говорю. И вот ты такой успешный сидишь и делаешь ... а потом бац выгорание из-зща переключения между 5 контекстками
А тебя к клавиатуре приковали цепью и паспорт отобрали? Это совершенно аномальная ситуация, когда пять менеджеров с разным требованиями тянут одеяло на себя. Вассал моего вассала не мой вассал. Этот принцип соблюдается (должен соблюдаться для эффективной работы) и в корпоративной структуре, поэтому смело посылай тех четверых к одному и пусть они с ним выясняют приоритеты до посинения. Я рекомендую емейлы форвардить своему менеджеру, не отвечая на них. А все устные распоряжения записывать и посылать с копией своему непосредственному начальнику:Дорогой Главный Решалович по результатам сегодняшнего обсуждения было решено:
1. Грести сюда
2. Туда не грестиПрошу Менее Главного Решаловича указать приоритеты данных указаний в контексте моих текущих обязанностей.
С уважением, Гребец Сеньорович.
Худшее, что с тобой сделают — снимут цепь и вернут паспорт. И судя по твоей фрустрации, тебе там и так не особо нравится.
Подгорание, документация... главное - хвост!Пишите код и документируйте одновременно - хрен ли. Код надо писать так, чтобы он сам был хорошей документацией.
И кто тут говорил что доки писать скучно?? Нормально вполне. Даже картинки рисую иногда. Только читает ли кто? Судить по каментам нельзя - их пишут только те, кто доков не читал )А вот всякие коммунистические енгейджменты - это да. Комунисты то в дискорде, то в телехраме, то в почтамте сидят. Крч, там, куда даже в химзащите заходить противно.
> Код надо писать так, чтобы он сам был хорошей документацией.Так и представил, как черпаю знания о каком-нибудь GIMP из исходников.
Все вышеперчисленные проблемы решаются в процессе разработки типа "водопад". Что-то не замечается проблем ни с выгоранием, ни с документацией у таких проектов, как ПО для воздушного транспорта, медицинского ПО, а только у того, котороое готовится по принципу "понос". Банально выгоняте нахер эджайлщиков, вместо них на работу берете нормоконтролеров, берете в руки стандарты -- у каждой страны есть на сей счет такие, и жестко им следуете. И документация будетв порядке и никто не выгорит.
Заодно всех дизайнеров тоже нахер -- нет никакой необходимости постоянно "обновлять" внешний вид приложений, достаточно один раз разработать их интерфейс, согласовать с физиологами, хирургами, окулистами, психиатрами и все будут рады.