Организация Linux Foundation совместно с Гарвардской лаборатории инноваций в науке подготовила новую редакцию исследования Census III, нацеленного на выявление наиболее широко используемых открытых проектов, нуждающихся в первоочередном аудите безопасности. В ходе исследования проведён анализ совместно используемого открытого кода, неявно применяемого в различных корпоративных проектах в форме зависимостей, загружаемых из внешних репозиториев. Всего было изучено более 12 млн открытых библиотек, задействованных в приложениях, используемых в 10 тысячах различных компаний...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62347
Вот вот весь мир держится на желаниях и компетенции одного васяна, но копики даже не чешутся на счёт создать что-нибудь свое защищённое и возможно платное. Единственно правильный вывод это форкнуть популярные Либы и либо включить их как часть языка с соответствующей поддержкой либо поддерживать на коммерческой основе.
*корпики
*коприки
Благодарю за лайки. Очень взбодрили. )
> либо включить их как часть языка с соответствующей поддержкойКакого языка?
"Пока не начался срач, никто не хочет выйти? (с)"> либо поддерживать на коммерческой основе.
А кто это будет оплачивать?
Пользователи? Точно нет.
Корпы? Так их и так все устраивает.То что ты описываешь это хорошо.
Но корень проблемы - это то самое AS IS.
Программист пишет код и не отвечает за его качество, даже если это платный продукт.Есть попытки заставить бракоделов давать какие-то гарантии, но боюсь они провалятся, тк никто не заинтересован отвечать за качество.
Включение в основу языка или его стдлиб оплачивает тот кто финансирует язык. Все остальное оплачивает клиент как и все в этой жизни. Программист допустим на будет отвечать а вот Юридическая организация будет. Создай в РФ такую национальную компанию которая будет нести ответственность за этот бардак и все сначала ты в реестре потом золотые горы. Бесплатная идея для стартапа на опеннете.
> Включение в основу языка или его стдлиб оплачивает тот кто финансирует язык.Ок, я пишу на С++, кто профинасирует добавление либы (и главное поддержку в актуальном состоянии)?
А есть языки, которые настолько низкоуровневые, что там даже нет нормальных функций сплита строки - приходится велосипедить.
(Возможно дело не в низкоуровневости, а просто в отстойности языка который придумывали ногами, но это не относится к теме).> Все остальное оплачивает клиент как и все в этой жизни. Программист допустим на будет отвечать а вот Юридическая организация будет.
Хм... И как я оплачиваю мою кУбунту? Я даже денег им не могу перекинуть последние пару лет.
А если лицензия либы, какой-то рак ЖоПЛи? То кто-то будет править баги и проводить тесты, а остальные просто станут в очереди за халявой.> Создай в РФ такую национальную компанию которая будет нести ответственность за этот бардак и все сначала ты в реестре потом золотые горы. Бесплатная идея для стартапа на опеннете.
К сожалению моя фамилия не совпадает с фамилиями отечественных олигархов - тк что успех предприятия очень сомнительный.
Во-вторых, это нужно иметь существенные компетенции в каждой либе. По ходу проще нанять разработчика на фуллтайм, но захочет ли он.А в третих, я уже представляю как создается какой-то Fоundation из гугла, амазона, фейсбука, ИБМ и мелкомягких - которые делают проверенные либы.
И тысячи васянов воняют на форумах что корпы лезут в опенсорс и подминают его, тк у них есть тресурсы искать баги, а у нущуков - нет.
В корпах никого не волнуют тех скилы, кроме как на собесе. Главное правило успеха в корпе - это быть удобным и быстро давать результат, если недоделанная либа от нищего васяна решила проблему - сотрудник получит бонус а васян ничего не получит. Делать же свою более лучшую либу чревато неуспехом, да и ответсвенность придётся нести.
> Делать же свою более лучшую либу чревато неуспехом, да и ответсвенность придётся нести.А типа васян несет какую-то ответственность за то что наомнокодил?
Его вообще-то никто не заставлял выкладывать либу в опенсорс.При этом если либа будет не правильно работать, то дручить будут сотрудника.
И манагеру будет пофиг откуда он стянул код - "ты главное сделай чтобы работало как нужно. и побыстрее"
Сотрудник уволится, а позор на компании останется навечно. Кому нужен такой головняк?
Ну создают так-то
В любимом всеми расте, даже форкнуть не поможет если библиотека скомпроментирована. Cargo в раст проверяет контрольные суммы библиотек и отказывается компилировать, если исходники пропатчены, т.е. пока автор не пофисит, ты ничего не можешь сделать, но дальше еще веселее, библиотеки тянутся рекурсивно зависисмости и привязаны к конкретной версии, т.е. пока они тоже не пофиксят и не поменяют версию в манифесте, ты так будешь тянуть скомпроментированную библиотеку, или не сможешь скомпилировать исходный код. В том же npm ты привязан к только к версии библиотеки, а в Cargo кроме версии еще к контрольной сумме, что ломает все. Якобы так "безопаснее", а по факту наоборот... Двойные стандарты на лицо. Нахлебался я с этим растом в свое время при сборке Firefox и js78, постоянно что-то ломают в языке и библиотеках, а ты ничего не можешь сделать.
> В том же npm ты привязан к только к версии библиотеки, а в Cargo кроме версии еще к контрольной сумме, что ломает все. Якобы так "безопаснее", а по факту наоборот...Дополнительная проверка контрольной суммы уменьшает безопасность?
>> В том же npm ты привязан к только к версии библиотеки, а в Cargo кроме версии еще к контрольной сумме, что ломает все. Якобы так "безопаснее", а по факту наоборот...
> Дополнительная проверка контрольной суммы уменьшает безопасность?Да, это замедляет фикс! Контрольную сумму архива я без них могу проверить, так делают все сборочные системы, да и исходники лежат все с файлом подписи, проверять не проверять твое дело. Но вот Cargo скачивает рекурсивно зависимости и сразу несколько версий одной и той же либы, потому что кроме твоих зависимостей еще есть зависимости твоих зависимостей, свой манифест ты можешь поправить, а чужой вот нет. Отсюда фикс может затянутся на долго, просто рай для бекдоров! Тот же файерфокс при сборке обычно собирается на конкретной версии раста, системный раст обновляется файерфокс перестает собираться, или тебе надо воротить портянку из rustup и иметь несколько компиляторов в системе для каждой версии раста. Сплошная растомания. В С и C++ нет такого. Представь у тебя уже есть rpmbuild или PKGBUILD, сборка происходит в контейнере или chroot, чтобы к примеру пофиксить баг, тебе надо чтобы cargo скачал зависимости и распаковал их в общее дерево исходников, и ты можешь пропатчить код и поменять все нужные манифесты, но cargo не дает этого делать, он сразу скачивает, распаковывает и собирает, локальный кэш пакетов ты тоже не можешь пропатчить - нарушишь контрольные суммы. Из-за всего этого мне приходилось в свое время городить кучу костылей, чтобы собирать Firefox и js78.
Если тебя это утешит, то скажу что я понимаю тебя и эту проблему. Ребята просто не сталкивались с такими проблемами, да и сравнивать веб или что-то незначительное с десктопными/системными приложениями как-то не корректно.
В карго из коробки есть способ указать зависимости из гита [1] или даже ФС [2] (ну и свою регистри, если нужно).
Более того, есть целый механизм переопределения зависимостей [3] который именно транзитивно работаетНе, ну если васянить и руками редактировать файлы в локальном кеше, то, о чудо, это не будет работать. Что совершенно логично, потому что такие костыли:
1. Не нужны (когда из коробки есть фича для решения описанной проблемы).
2. Это совершенно хрупкая история (была бы, если бы чексумма не проверялась).[1]: https://doc.rust-lang.org/cargo/reference/specifying-depende...
[2]: https://doc.rust-lang.org/cargo/reference/specifying-depende...
[3]: https://doc.rust-lang.org/cargo/reference/overriding-depende...
спасибо кэп, как это я раньше не смог догадаться?
> спасибо кэп, как это я раньше не смог догадаться?Skill issues, видимо, потому что как иначе объяснить, почему Ваше описание ((решения)) подходит именно под васяноподход, а не тот, который доступен из коробки и решает ровно описанную проблему?
>> спасибо кэп, как это я раньше не смог догадаться?
> Skill issues, видимо, потому что как иначе объяснить, почему Ваше описание ((решения))
> подходит именно под васяноподход, а не тот, который доступен из коробки
> и решает ровно описанную проблему?Ну да, на опеннет полно "экспертов". Чего только стоит поставновка диагнозов через интернет по переписке...
Скажу по другому, например я нашел в своем дистрибутиве Linux в какой-то библиотеке баг, я ее могу быстро обновить, пропатчить, скомпилировать и затем обновить зависящие от нее пакеты, написать патчи для них, если например разработчик сломал API в новой версии. В свой системе я могу иметь пакеты, какие сам захочу с нужными мне патчами, а cargo же не дает мне иметь свою библиотеку и линковаться с ней, она заставляет использовать cargo и скачивать зависимость каждый раз, ты можешь обновить свой пакет и обновить зависимость на новую версию, но какая-то зависимость этого же пакета может зависеть от старой версии rust и старого API, и ты уже ее не можешь пропатчить и скомпилировать, и тебя надо ждать разработчика этой зависимости, а он может забить болт или забухать на пару месяцев. Или тебе нужно форкать библиотеку и прописывать ее... В линуксе не редко обновление одной библиотеки, требует патчинга или обновления других библиотек. Идеально совпадающего API для всех пакетов не существует. Сборка того же chromium с кучей зависимостей и своей сборочной системой в разы проще была, чем сборка Firefox, которая ломалась при каждом обновлении rust.
> Более того, есть целый механизм переопределения зависимостей [3] который именно транзитивно
> работаетТы не понял. Ты можешь обновить, но какая-то зависимость-зависимости зависит от конкретной версии зависимости, ты переопределяешь зависимость, делаешь патчи для основного пакета, что бы он собирался с новой версией зависимости, но какая-то твоя зависимость требует старой версии этой же зависимости, которая была обновлена, и еще старый раст. Пакет который ломался каждый раз в Firefox это что-то там "simd", там часто api менялся и еще он ломался при обновления rust. Ты патчишь Firefox, а по итогу у тебя зависимость просит старую версию simd, и сборка ломается на ее сборке. Вы надеюсь понимаете, что ваши зависимости зависят он конкретной версии API?
>> Возросла актуальность защиты учётных записей разработчиков. Многие из наиболее востребованных пакетов размещены под учётными записями конкретных разработчиков, менее защищённых чем учётные записи созданных под проект организаций.
> весь мир держится на желаниях и компетенции одного васяна, но копики даже не чешутся на счёт создать что-нибудь своеБезопасность это очень дорого. Большая ошибка обеспечение безопасности минутой мозготраха. Безопасность можно повысить только многолетним системным, кропотливым трудом, который стоит много денег. Кто имеет деньги и желание могут сделать первый шаг в повышении безопасности библиотеки Васи:
https://www.nitrokey.com/news/2018/nitrokey-partners-linux-f...
https://www.nitrokey.com/news/2019/nitrokey-partners-gentoo-...
https://www.nitrokey.com/news/2021/nitrokey-equips-arch-linu...
Купите Васи хотя бы Nitrokey 3A Mini:
https://shop.nitrokey.com/shop/nk3am-nitrokey-3a-mini-149#attr=
https://www.nitrokey.com/news/2024/nitrokey-3a-mini-receives...
Второй шаг, купите Васи относительно безопасное железо:
https://shop.nitrokey.com/shop/nitropad-v56-684?search=nitro...,1480,1414,1420,1448,1454,1456,1458,1462,1466,1467,1472,1475
https://www.nitrokey.com/news/2024/now-available-nitropads-v...
Это не всегда так. Есть корпики которые берут код, форкают и сами допиливают, порой если умные - сливают обратно или как свой продукт рекламируют. А есть действительно которые держатся на неизвестном Васяне
Какая из перечисленных библиотек поддерживается одним Васяном, а не корпиками?
Так-то вся разработка на таких линусах и держится :)
А ведь можно всё писать с нуля на паскале со стандартными библиотеками.
Ничего в этом зазорного не вижу, если пишете для себя, а не для дяди.
Турбо Паскаль, Бейсик... Что еще предложишь?
А чем плохо-то? Что эти языки не выполняют своих задач? А в некоторых случаях похоже эффективнее некоторых современных языков...
Что плохого в перечисленных языках? Вы, пожалуй, удивитесь, но есть немало коммерческих игр, которые до сих пор выпускаются энтузиастами на этих языках для любителей играть на аутентичном ретро-железе. Да и не игр. Вон тут в прошлых темах аноним бросал ссылку на свой гит, где он написал весьма годный, судя по скриншотам, клиент для телеграма под Windows 3.11 на Delphi 1.x.
Фигня в том, что ты написал для себя, вылодил в опенсорс (мы же про него говорим), а потом узнаешь что 100500 компаний, опенсорс проектов и корпораций завязаны на твой код.
Они просто пришли и взяли то, что им подходит.
Значит они стали товаром и можно их хорошенько протроянить или устроить им Жиа Тана.
> Значит они стали товаром и можно их хорошенько протроянить или устроить им Жиа Тана.Начнем с того что это подло, даже по отношению к корпоративным проектам.
Более того не все корповские проекты будут закрытыми, а нагадить в опенсорсный это низко.Плюс это явно испортит не только карму, но и репутацию.
Сомневаюсь что такого человека возьмут куда-то на должность выше дворника.И последний, но тем не менее важный пункт - как бы не вышло что тебя потом задержат в каком-то аэропорту и посадят н̶а̶ ̶б̶у̶т̶ы̶л̶к̶у̶ в тюрьму.
> Фигня в том, что ты написал для себя, вылодил в опенсорс (мы же про него говорим), а потом узнаешь что 100500 компаний, опенсорс проектов и корпораций завязаны на твой код.А я так никогда не делаю. Все свои проекты выпускаю под собственной лицензией, где код открыт, ты можешь его изучать сколько угодно и даже участвовать в разработке, но тебе запрещено делать форки и без моего согласия использовать этот код в своих проектах.
Ты молодец всем надо быть такими как ты.
Ну и как? Коммьюнити сформировался вокруг твоих проектов? Шлют ли пулл-реквесты? Сколько человек попросило твоего Соизволения™ на использование твоего Драгоценного™ кода?
Ну так не все железо программируют. Для веб-разработки я бы тогда С выбрал. Чисто из-за скорости, если не смотреть на платформы. Или Go из-за удобства программирования. Golang пишут что вдохновлялся разными языками и что-то от Pascal он взял. Ну или Rust - популяризируют его, да и вроде такой же быстрый как С.
Для домашних проектов С в этом плане всех переигрывает - на нем много чего поддерживается. Правда нет времени на домашние проекты.
А вообще тут больше о библиотеках JavaScript. Некоторые для браузера, некоторые для сервера. Конечно, я так понимаю речь идёт о серверной стороне
Хм.. раз уже Linux Foundation говорит, что
> Возросла актуальность защиты учётных записей разработчиков.то фанатики анонимности все так же будут верещать "нас заставляют использовать OpenID!!1111" ?
Будут ли обвинения LF в продажности ?
В данном случае обвинений быть не может, поскольку. Linux изначально боролся против анонимных разработчиков. В ядро Linux анонимных матчей не принимали никогда. Пример патчи безопасности PAX. Споры о приеме анонимных патчей не стихают, но Линус аргументировано отказывает.> OpenID
ОперID не нужное зло.
Нужно подписывать пакеты PGP: https://www.opennet.dev/openforum/vsluhforumID3/135499.html#97
Python и JavaScript, опять нужно тратить кучу времени на гадюку и жабу.
Из них получится разве что хороший китайский суп.
Достаточно просто гадюшник запускать в контейнере или любой другой безопасной зоне.
Контейнерофобы все-равно найдут оправдание тому, чтобы бинари голым задом торчащим в интернет запускать нативно в системе. Только лишь бы не в контейнере.Знаю не мало людей, которые Прод сервисы так и запускают, ещё и под рутом.
Да, что там говорить, даже вендоры пакетов известного ПО так делают. Их systemd службы настроены на использование root.
> Контейнерофобы все-равно найдут оправдание тому, чтобы бинари голым задом торчащим в интернет запускать нативно в системе. Только лишь бы не в контейнере.С одной стороны я с тобой согласен, что контенеры это круто.
А с другой - они расслабляют и подталкивают программера овнокодить - типа "пиши абы как, а там все завернем в контейнеры"
> А с другой - они расслабляют и подталкивают программера овнокодить - типа
> "пиши абы как, а там все завернем в контейнеры"это зависит от разработчиков, некоторые даже межсервисные соединения в пределах внутренней подсети шифруют через SSL, а некоторые говорят - "так есть же SSL на балансировщике, зачем нам этим заморачиваться" и заказчику тоже так это объясняют. А потом сниффер-троян делает своё дело и происходит та самая утечка персональных данных, за которую последнее время ужесточают законы.
>межсервисные соединения в пределах одного сервера шифруют через SSLДостаточно нелепо, как мне кажется
Для начала - для выпуска и корректной работы валидного сертификата SSL\TLS требуется дырка в интернет (при установлении соединения необходимо к примеру проверять валидность церта, не отозван ли он, подключаться можно только по валидному внешнему имени и т.п.).
Что уже само по себе интересно для "межсервисные соединения в пределах внутренней подсети".
Если же мы говорим про самоподписанные сертификаты, то это уровень настроек админа локалхоста.
Если смогли поднять свой удостоверяющий центр, то на моей практике я еще не видел ни одного корпа, с собственным УЦ, выписывающим на свои сервера церты меньше чем на 10 лет сразу. Что тоже как бы "Хм...".>сниффер-троян делает своё дело
это что же за архитектура сети такая, позволяющая сниферу брать пакеты ото всех устройств сети?
его сразу на контрольные точки ставили, типа шлюза, сервера БД, сервера приложений, или на маршрутизаторы сразу?Ну а про утечку персональных данных - вон в прошлом году, майлру заплатил целых 60 тысяч рублей, за утечку миллионов данных пользователей.
яндекс за аналогичное, тоже был оштрафован на такую же катастрофическую для их бизнеса сумму.
> Достаточно нелепо, как мне кажется
> Для начала - для выпуска и корректной работы валидного сертификата SSL\TLS требуется дырка в интернетТут вообще, достаточно нелепо использовать публичный CA для этой цели, это даже снизит безопасность, поскольку они генерируют сертификаты на длительный срок действия. Автоматическую генерацию, автоматическое продление и автоматическое обновление текущих самоподписных сертификатов с коротким сроком дейстсвия можно автоматизировать, через тот же HashiCorp Vault или через другие инструменты.
> это что же за архитектура сети такая, позволяющая сниферу брать пакеты ото всех устройств сети?
Когда у злоумышленника есть root, перевести NIC на хосте в promiscuous режим это одна команда. После этого троян может логировать весь незашифрованный сетевой трафик от всех машин в доступных подсетях, включая пересылаемые пароли и токены. Есть снифферы, которые по заголовкам пакетов разпознают конкретное ПО, и аккуратно складывают в таблице в виде CSV файлика, который пушат curl'ом себе на временную страницу pastebin (чтобы не палить себя). Имел дело с такими, через дыры в устаревшем ПО проникли, помогло только обновление ПО, удалять их было бесполезно, злоумышленник или его бот создавали новые. Контейнеризация для ПО не использовалось, состояло из systemd служб.
> Когда у злоумышленника есть root, перевести NIC на хосте в promiscuous режим это одна командаС рутом на системе можно не заниматься ерундой, а просто взять из памяти ключ и читать вообще любой трафик. mTLS в пределах одного хоста бесполезен полностью. Между хостами — обязателен. Если у вас не так, то это либо что-то очень специфическое, либо обычный подкроватный локалхост.
> С рутом на системе можно не заниматься ерундой, а просто взять из памяти ключ и читать вообще любой трафик.Без promiscuous режима, NIC на хардварном уровне будет дропать пакеты не предназначенные данному MAC'у поэтому операционка их не увидит вовсе.
> mTLS в пределах одного хоста бесполезен полностью. Между хостами — обязателен.
Это минимальная норма безопасности, да. Но если мы имеем дело с сервисами, которые потом потенциально могут разнести по разным нодам, но лучше заранее перестраховаться и шифрование сделать обязательным всегда. К примеру сегодня Postgres у нас на машине с сервисами, завтра мы его вынесли. В Postgres то TLS включить опытному админу не составит труда, а вот приложение-клиент адаптировать под SSL задача сложней и дольше.
> сегодня Postgres у нас на машине с сервисами, завтра мы его вынеслиТы сейчас локалхост весьма точно описал. В проде так бывает разве что в стартапах, да и то очень недолго.
> включить опытному админу не составит труда, а вот приложение-клиент адаптировать под SSL задача сложней и дольше
Опять какой-то локалхост описываешь. Клиент коннектится туда и так, как ему через переменные окружения сказали. Любая более-менее популярная библиотека для работы с БД это умеет, и любой нелокалхостный программист знает, что не нужно ломать это поведение. А что там кодеры в своих хэллоу ворлдах делают никому не интересно, даже их бабушкам.
Ты помешался на своих на локалхостах и хелло-ворлдах :) Не нужно равнять всех по себе.
Про вертикальное масштабирование что-нибудь слышал?Корень твоих наездов, в том, что я задел твои контейнерофобские чувства, признайся :)
нет, не задел.
например меня смутило, что ты на знаешь, что маршрутизирующее оборудование может посылать пакеты на порт, только тому хосту, на который направлен.
и ты хоть обвключайся promiscuous режимом, но поймаешь только то, что тебе предназначено, т.е. только свои пакеты.
То что ты описал, было реальностью ну скажем в начале 2000-ых, когда в офисах были сетки 10\100 мб сотворенные на хабах, "потому что так дешевле".(Я даже видел одну контору, которая экономила на жестких дисках и буталась исключительно по 10 мб сетке, в 9 утра у них был полный цирк)Так вот, о чем я, строить серверный сегмент на оборудовании, которое массово рассылает всем зарегистрированным портам весь траффик на 10 гигабитной сетке - ну, моветон с моей точки зрения.
Ну или ты админ локалхоста с развернутым например nodejs, с таким подходом, и просто основ не знаешь.Ты даже не понимаешь, где у тебя может произойти взлом, и просто говоришь "Когда у злоумышленника есть root", ты что несешь, глядь?
> и просто говоришь "Когда у злоумышленника есть root", ты что несешь, глядь?Что в этой фразе не ясного? :)
> рассылает всем зарегистрированным портам весь траффик на 10 гигабитной сетке -
> ну, моветон с моей точки зрения.Есть ещё виртуальные сети, построенные на гипервизорах и облачных платформах. Там может ограничиваться не весь тип трафика, а например, только unicast. Всегда важно не подходить к безопасности расхлябанно, даже если в теории шанс такого взлома не велик. Ты же предлагаешь не шифровать межсервисную коммуникацию, в пределах одного хоста, это и есть расхлябанность.
Когда-то, давным-давно, свичами называли маршрутизаторы без мозгов, которые перекладывали задачи анализа пакетов на сетевые карты хостов.
Сейчас даже самые тупые свичи маршрутизируют ровно туда, где приемник и без вариантов. Если не настроить на свиче соответствующее группы для снифинга.
Поэтому проблема может быть лишь дальше маршрутизатора локалки, но там шифрованный трафик уже будет.
А так, контейнеры этой проблеме индифферентны.
Ну и если маршрутизатор в локалке под контролем злоумышленника, то тут уже мало что спасёт.
И зачем в межсервисных соединениях текстовые протоколы?
> И зачем в межсервисных соединениях текстовые протоколы?Разработчикам виднее, обычно это всякие API, отдающие JSON
Но если работать в коммерческой разработке, то таки придётся вникать в этот серпентарий. У меня на прошлой В работе, даже будучи embedded-разрабом, пришлось учить Python и пару васянских либ.
JavaScript и Python считаются более безопасными, чем, например PHP
https://tproger.ru/news/nazvany-glavnye-problemy-v-bezopasno...
Express кстати русская разработка. И весьма удачная, она повлияла на многие проекты.
> Express кстати русская разработка. И весьма удачная, она повлияла на многие проекты.Ты уверен?
Там главный разраб из London, UK, а остальные Douglas Wilson, Jonathan Ong (Orange County, CA)
На русских не сильно похожи)
Там по классике жанра оформлено всё на левое юр. лицо для легализации за пределами pФ.
Уверен, ранее он даже не был иностранным. Тихий проект русского энтузиаста. У моих разработок тоже кирпичная американская морда, и что? Ну кроме одной, но там утилита и мы не об этом.
> Express кстати русская разработкаТи Джей сейчас подавился своим соевым латтэ. Канадо-британский хипстер стал русским?
А зачем Ти Джей информацию о библиотеке делал на русском и английском? Он наверно сильно любит Россию в отличии от некоторых других английских проектов, которые так не делают.
> А зачем Ти Джей информацию о библиотеке делал на русском и английском?Это где? Ссылка есть?
https://expressjs.com/ru/
Сейчас написано что перевод автоматический. Найти то просто. Машину времени правда не сделаешь.
> Сейчас написано что перевод автоматическийТы точно внимательно читал свою ссылку? Какой-то интернациональный у тебя разработчик, столько языков знает:
Documentation translations provided by StrongLoop/IBM: French, German, Spanish, Italian, Japanese, Russian, Chinese, Traditional Chinese, Korean, Portuguese.
Community translation available for: Slovak, Ukrainian, Uzbek, Turkish, Thai and Indonesian.Кстати, еще несколько лет назад Russian входил в список "Community translation" с вечным отставанием от оригинального сайта.
Хотя я может что-то путаю, но мне кажется что это раньше была разработка русского разработчика.
Ти Джей никогда не был русским, что какбы даже имя нам намекает на это...
Ну-ну, верь и дальше что то его Ти-Джей написал.
Да в общем, какая разница? Есть более удобные библиотеки. Тот же Nest выиграет по удобству, а Fastify по скорости. Я только глянул - 5 версию выпустили, там всё-равно не сидят на месте. Тот код который был изначально - переписан наверняка.
Это также как сказать что Skype или Telegram русские разработки.
>формированы списки из 500 наиболее часто используемых библиотек, безопасность и качество сопровождения которых требует особого внимания,никто не подскажет, почему они занимаются только NPM?
например лично я бы для начал с линуксового ядра, системных библиотек, потом, в зависимости от дистрибутива - софтом в прилагаемом репозитарии.
А это перцы сразу за помоечную nodejs решили взяться?
Занимаются тем, что нужно индустрии и имеет максимальный импакт. А не то, о чём мечтают обыватели с опеннета. До ядра и системных библиотек ещё добраться надо, а фронт на js — вот он, прямо в интернете доступен без этой вашей гибсонщины.
> никто не подскажет, почему они занимаются только NPM?
> например лично я бы для начал с линуксового ядра, системных библиотек, потом, в зависимости от дистрибутива - софтом в прилагаемом репозитарии.Это очень сложно.
Вот придешь ты в ядро и скажешь "библиотека шерето!", а там какой-то вредный дед "я не буду исправлять ошибки и так сойдет".> А это перцы сразу за помоечную nodejs решили взяться?
Потому что пользователей веббраузеров на порядок больше чем линукса.
> на порядокЭто в 10 раз. Маловато. Я думаю минимум в 1000 раз (не считая всяких стим и прочих серверов).
У айтишников "порядки" это степени двойки, а не десятки.
Сишных библиотек в top 20 нет?
А много ли вообще на NPM сишных или даже не JavaScript проектов? Кстати на C в общем-то там есть. А на многих других языках - нет.
> 17% из 50 наиболее популярных проектов, не представленных в репозитории NPM, имеют только одного разработчика, а 40% - одного или двух разработчиков, совершивших 80% коммитов.Скорее всего это ментейнеры, а не разработчики. Им могут присылать патчи по почте и т.д. Слабо верю, что у Open Source мало участников. А вот одного ментейнера обычно достаточно.
17% от 50 это 8 с половиной проектов.
Плохо что нет libc или упоминания того что это рейтинг для "особенных" языков. Зря только читал вот это всё...