The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"79% встроенных в код сторонних библиотек никогда не обновляются"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"79% встроенных в код сторонних библиотек никогда не обновляются"  +/
Сообщение от opennews (ok), 27-Июн-21, 10:48 
Компания Veracode опубликовала результаты исследования проблем с безопасностью, вызванных встраиванием открытых библиотек в приложения (вместо динамического связывания многие компании просто копируют в состав своих проектов нужные библиотеки). В результате сканирования  86 тысяч репозиториев и опроса около двух тысяч разработчиков определено, что 79% перенесённых в код проектов сторонних библиотек в последующем никогда не обновляются...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55396

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от n00by (ok), 27-Июн-21, 10:48 
27% обязательно проверяют лицензию на совместимость
54% не всегда проверяют лицензию на совместимость
19% - ?
Ответить | Правка | Наверх | Cообщить модератору

2. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от OnTheEdgeemail (ok), 27-Июн-21, 10:51 
буратины
Ответить | Правка | Наверх | Cообщить модератору

3. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от proninyaroslavemail (ok), 27-Июн-21, 10:52 
Ну, логично что не проверяют вообще)
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

76. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +12 +/
Сообщение от n00by (ok), 27-Июн-21, 12:30 
Мне не раз предлагали творчески переработать GPL софт и продавать без исходников. На отказ удивлялись и недальновидно заявляли "да тут очередь из исполнителей". :)
Ответить | Правка | Наверх | Cообщить модератору

186. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от rshadow (ok), 27-Июн-21, 20:14 
Он вроде и так без проблем продается. Особенно на таких закрытых платформах как плей и апстор.
Ответить | Правка | Наверх | Cообщить модератору

198. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +6 +/
Сообщение от Аноним (198), 27-Июн-21, 22:29 
И на госзакупках
Ответить | Правка | Наверх | Cообщить модератору

222. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Фотошоп лучше (?), 28-Июн-21, 06:51 
Как ломать нумерацию версий -так у нас нет обратной совместимости, а как "проблемы с безопасность", так у нас все совместимо.
Ответить | Правка | Наверх | Cообщить модератору

228. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 28-Июн-21, 08:05 
Продаётся. А помимо закрытых платформ есть лоббирование и другие способы заменить авторов SJW-активистами. Интересно бы ещё где-то посмотреть %, сколько из апологетов свободы, которые учат как и под какой лицензией правильно писать ПО, что-то сами написали.
Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

261. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Аноним (261), 29-Июн-21, 08:35 
А чего не согласился? Твоего имени там не будет, с деньги за работу бы получил. 👍

Да и на нарушения гпл всем плевать с высокой колокольни, особенно в РФ. Зарабатывай-нехочу.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

265. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от n00by (ok), 29-Июн-21, 10:17 
Что бы Вам осталось на покушать. Главное, в кредиты в расчёте на "деньги за работу бы получил 👍" не влезайте.
Ответить | Правка | Наверх | Cообщить модератору

6. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от ыы (?), 27-Июн-21, 10:57 
определить не удалось.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

11. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –4 +/
Сообщение от Аноним (11), 27-Июн-21, 11:03 
>    19% - ?

прибегает автор нужного и важного патча, поменявшего colour на color в комментарии, и бьет себя пяткой в груть - я, у мамы, разработчик этой библиотеки! Вы украли мою лицензию, немедленно уберите и прекратите!

(можете посмотреть на образцового м-ка подобного типа в ruffle)

Авторам кода не до того - они херачат код, кто бы мог подумать! Да и было ли автору патча убирающего лишние пробелы, чем?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

171. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +5 +/
Сообщение от Аноним (171), 27-Июн-21, 18:40 
В исследовании не раскрыто сколько процентов разработчиков пересчитывают лицензии всех встраиваемых библиотек при их обновлении. Лицензии же могут  поменяться.

Про "отговорки" вообще шизофрения написана. То что в 70% патчи безопасности шли отдельным коммитом не означает, что в проекте больше не было коммитов , в том числе ломающих совместимость. В итоге 30% это не так и мало, грубо, каждое 3 обновление вероятно может что-то сломать, не говоря уже о том, что и патчи безопасности могут что-то сломать и автор может коммитнуть нерабочий код.

Да и разработчики библиотек все такие нарисованы в белом, хотя автотесты не в состоянии написать, а разработчики, что их библиотеки используют прям диверсанты.


Ответить | Правка | Наверх | Cообщить модератору

201. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (201), 27-Июн-21, 22:35 
whitelist на allowlist
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

38. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (38), 27-Июн-21, 11:35 
19% - по.уисты
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

44. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Bx (ok), 27-Июн-21, 11:50 
Они просто не понимают, что делают. Вот такой обращается ко мне, говорит, слева вверху кнопка, на нее нажать нужно. Обращается через моего руководителя, я его рабочий стол смотрю. Нет кнопки. Она из интернета подтягивается.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

68. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –22 +/
Сообщение от Анонимъ (?), 27-Июн-21, 12:19 
19% используют современные ЯП вроде Rust и не задаются такими глупыми вопросами. В конце концов зачем проверять вручную, если при наличии инфраструктуры можно автоматизировать сей скучный процесс проверок и обновлений.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

147. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Anonymoustus (ok), 27-Июн-21, 15:30 
19 % — NaN.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

168. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 27-Июн-21, 18:05 
Это больше бесконечности.)

0x7ff0000000000000 - Infinity

0x7ff0000000000001 - NaN
...
0x7fffffffffffffff

Ответить | Правка | Наверх | Cообщить модератору

196. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Anonymoustus (ok), 27-Июн-21, 22:15 
> Это больше бесконечности.)

А поправка на военное время?

Ответить | Правка | Наверх | Cообщить модератору

235. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 28-Июн-21, 09:17 
В случае применения спецназа или ЯО всё ПО становится свободным?))
Ответить | Правка | Наверх | Cообщить модератору

199. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (198), 27-Июн-21, 22:30 
Долбаный JS
Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

236. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 28-Июн-21, 09:24 
В таком виде сравнить - это надо уметь и постараться.
Ответить | Правка | Наверх | Cообщить модератору

258. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (258), 28-Июн-21, 19:51 
Да я и не считаю JSников глупыми. Там просто доширак в коде, что тока квантовый компьютер разрулит. Мне недавно пришлось касаться фронта, это после бэка и Си. Моск сломался.
Ответить | Правка | Наверх | Cообщить модератору

166. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Козлетто (?), 27-Июн-21, 17:27 
А чему вы удивляетесь? Большинство качают свои сериалы и музыку с торрентов. Уж с софтом как будто кто-то заморачивается?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

172. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (171), 27-Июн-21, 18:42 
Ну раз свои качают, то в чём проблема?
Вот если бы чужие, тогда да, прям мировая проблема была бы.
Ответить | Правка | Наверх | Cообщить модератору

195. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноним (195), 27-Июн-21, 21:59 
Плюю на все лицензии и никогда их не читаю. Публикую свой код под Unlicense/WTFPL/PublicDomain и прописываю это только в COPYING и не засоряю этим файлы с кодом. 19% нас таких?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

204. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (204), 28-Июн-21, 00:05 
Не вас альтернативно одаренных гораздо больше.
Ответить | Правка | Наверх | Cообщить модератору

224. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 28-Июн-21, 07:10 
Порадуйте, пожалуйста, ссылочкой на публикации.
Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

263. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Аноним (261), 29-Июн-21, 08:38 
Молодец! Поклон и уважуха! 😻

Пихать вирусную гпл - не уважать свой код и его пользователей.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

259. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Аноним (259), 29-Июн-21, 07:26 
У нас в корпе (большая, известная, японская, работаю в Токио) обязательная проверка лицензий на любой код со стороны - в том числе ревью юридическим отделом. А если используется какая-то особая интересная математика в своем коде, то надо еще и патентное исследование делать.

Что про GPL- код - его нельзя трогать десятиметровой палкой и точка. Любые BSD/MIT исходники - процедура описанная выше. Большинство используемых либ или полностью свои велосипеды (например, у нас есть аналоги OpenCV, TensorFlow,разнообразных баз данных и прочего) или купленные/лицензированные у других фирм и обязательно с вагонами документов и всяких EULA. Иначе вообще никак.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

260. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (259), 29-Июн-21, 07:27 
Извините за ушлёпищный английский шрифт, в браузере почему-то только полноширинная клавиатура работает.
Ответить | Правка | Наверх | Cообщить модератору

4. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от OnTheEdgeemail (ok), 27-Июн-21, 10:54 
работает -- не трогай ®
Ответить | Правка | Наверх | Cообщить модератору

7. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +17 +/
Сообщение от myhand (ok), 27-Июн-21, 10:57 
Ну да.  Бэкдор же тоже можно рассматривать как часть функционала программы.
Ответить | Правка | Наверх | Cообщить модератору

164. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Твоя совесть (?), 27-Июн-21, 16:54 
После выявления бэкдора состояние программы уже следует характеризовать не как "работает", а как "сломано", поэтому да, принцип сохраняется. "Не сломано - не чини". Сюда же. Обновления ради обновлений не нужны и несут только распухание кода и потерю совместимости.
Ответить | Правка | Наверх | Cообщить модератору

202. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (201), 27-Июн-21, 22:37 
После выявления бэкдора логично срочно запилить невыявленный бэкдор.
Ответить | Правка | Наверх | Cообщить модератору

60. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от vitektm (?), 27-Июн-21, 12:13 
А потом  у тебя базу скачали и на сайте разместили криптомайнер/или редирект .
И потом ой а мы вылетели из выдаче в яндаксе/гугле ой а что делать ??? И реальные убытки каждый день.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

246. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноним (246), 28-Июн-21, 10:43 
А если одновишь либу у тебя сломается обратная совместимость и отвалятся клиенты которые дают деньги. Лучше уж слить базу с точки зрения бизнеса, а потом прислать требование сменить пароль, ибо они все равно хэшированы и задолбаются использовать радужные таблицы.
Ответить | Правка | Наверх | Cообщить модератору

229. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от WE (?), 28-Июн-21, 08:32 
Копируешь из своего репозитория - дыра в безопасности, нет обновлений. Копируешь из стороннего репозитория - дыра в безопасности, неподконтрольный код.
Выбор меньшего из зол.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +15 +/
Сообщение от Аноним (5), 27-Июн-21, 10:54 
Это говорит о том, что большинство программистов - некомпетентные говнокодеры.
Ответить | Правка | Наверх | Cообщить модератору

13. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +7 +/
Сообщение от Dzen Python (ok), 27-Июн-21, 11:03 
Это говорит всего лишь о том, что у большинства разработчиков над душой стоит очень слабо разбирающийся в разработке дедечка/тетенька/комитет, выкатывающие нереальные сроки, режущие по живому бюджет и вообще, всячески мешающих процессу, вместо заявленной им "помощи".

*Летела ракета - упала в болото. Какая оплата (какие условия, какие делайны, etc) - такая работа!*

Ответить | Правка | Наверх | Cообщить модератору

88. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 27-Июн-21, 12:41 
Например, "разработчики" Rosa Tresh хвалились, что у них там полная свобода и демократия. Обещали в прошлом году выпустить версию, которая по плану должна было выйти ещё в 2018-м, потом в 2019-м. До сих пор обещают. Лишь недавно опубликовали какую-то альфу, поскольку прежняя версия 2016  ̶с̶о̶в̶с̶е̶м̶ ̶п̶р̶о̶т̶у̶х̶л̶а̶  в 2021-м выглядит странно.
Ответить | Правка | Наверх | Cообщить модератору

155. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Аноним (155), 27-Июн-21, 16:28 
А вот опять наш поехавший на никому нафиг не сплющившимся дистре. Поаплодируем господа, его тупой настойчивости в повышении индекса цитируемости этой ненужной шняги!
Ответить | Правка | Наверх | Cообщить модератору

156. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от n00by (ok), 27-Июн-21, 16:33 
> А вот опять наш поехавший на никому нафиг не сплющившимся дистре.

Кстати, в прошлый раз Вы так и не представились. Почему? Вы, случаем, не тот фанат Rosa Tresh, который считает, что он одновременно Виндос и Опух? https://www.opennet.ru/~ВыньОпух

> Поаплодируем
> господа, его тупой настойчивости в повышении индекса цитируемости этой ненужной шняги!

Ну, Вы определитесь. Она же Вам не нужна. Но Вы про неё пишете, и меня преследуете заодно.

Ответить | Правка | Наверх | Cообщить модератору

257. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от русский штамм шизовируса (?), 28-Июн-21, 18:17 
Сударь, вам самим не смешна ситуация, в которой вы, приняв изрядно от росы треш, принимаете теперь от альта, а когда его сожрёт астра, то и от астры будете принимать кое-что кое-куда?
Ответить | Правка | Наверх | Cообщить модератору

262. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 29-Июн-21, 08:35 
Не знаю, над чем тут смеяться. Слова вроде знакомые, но в законченную мысль не складываются. Развернёте её?
Ответить | Правка | Наверх | Cообщить модератору

214. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от vitalif (ok), 28-Июн-21, 01:53 
Их же там два калеки осталось, удивительно что вообще выпустили
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

225. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 28-Июн-21, 07:13 
Выпустили - это когда на официальном сайте и в новостях анонсировано, а не когда выкладывают что попало, поскольку пользователи который год просят и уходят. И двое их оставалось после банкротства, когда они клянчили "помогите". Потом выкружили финансы и желающих "помочь" прибавилось.
Ответить | Правка | Наверх | Cообщить модератору

101. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Аноним (101), 27-Июн-21, 13:02 
Я бы еще добавил, что обратная совместимость у большинства библиотек напрочь отсутствует. На примере libgit2 - от версии к версии интерфейсы перелопачиваются, желание переводить проект на новую версию отпадает.
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

126. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Урри (ok), 27-Июн-21, 13:43 
Да что тут говорить, если даже широко рекламируемые ЯП (не буду называть чтобы не провоцировать контекстный срач) таким страдают.
Ответить | Правка | Наверх | Cообщить модератору

231. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (201), 28-Июн-21, 08:37 
Всё правильно делают. Не с недоработангым API же до тепловой смерти вселенной сидеть.
Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

21. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –6 +/
Сообщение от Аноним (21), 27-Июн-21, 11:12 
Это говорит о том что нужно использовать репозиторий, такой как npm, composer и maven, а не копировать исходный код.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

25. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Shshsh (?), 27-Июн-21, 11:16 
Пропадает интернет, вы на объекте без оного и т.п. и вы его не соберете.
Ответить | Правка | Наверх | Cообщить модератору

79. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (79), 27-Июн-21, 12:34 
Почему? Есть кэширующие прокси реестры. Например verdaccio для npm
Ответить | Правка | Наверх | Cообщить модератору

100. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (100), 27-Июн-21, 12:59 
maven и gradle сохраняют в кэш, один на все проекты
npm скачивает в каталог node_modules каждого проекта
в yarn 2 сделан так что позволяет каталог с библиотеками сохранять в git репозиторий и при этом установочные скрипты выполнялись. Даже CI даже не понадобится интернет.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

104. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (100), 27-Июн-21, 13:06 
у maven кэш в HOME/.m2 и у gradle в $HOME/.gradle/caches/
они не выкачивают библиотеки для каждой сборки. Даже если новый проект создать они возьмут библиотеки из кэша
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

211. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Aukamo (ok), 28-Июн-21, 01:08 
Используйте Rust. У пакентого менеджера cargo есть опция --offline которая позволяет не только собрать бинарник, но и документацию по используемым пакетам, если вдруг на некое время прервался доступ к интернету.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

192. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Тфьу (?), 27-Июн-21, 21:08 
> нужно использовать репозиторий, такой как npm, composer и maven, а не копировать исходный код.

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

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

200. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (198), 27-Июн-21, 22:34 
Эти npm бегут впереди головы, делать ради делания. Они только своё перевелосипедируют, а тебе еще всё переперевелосипедировать у себя надо из их велосипедов. Но также немало и умерших проектов, дойдут до версии 1.0.0, в портфолио положат, и досвидося.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

136. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (136), 27-Июн-21, 14:17 
а чо ты хочешь от картизоловых оленяк-работяг
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

276. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (276), 03-Июл-21, 13:40 
Скорее о том, что современные инструментальные средства хреново развиты. Это тольок молодые реализации языков вроде Node, Python, Java моуг похвастаться NPM, PIP, MVN и другими пакетыми менеджерами, а вот что делять сидятлам? Они с трудом собрали свои говноскрипты башевые что бы хоть что-то заработало, а тут надо что-то обновлять.

Пока какой-нибудь meson или conan не дорастет до индустриального стандарта все это будет фактом!!!!

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

277. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Michael Shigorinemail (ok), 03-Июл-21, 14:52 
> а вот что делять сидятлам?

Что вам таким делать (окромя как флудерасить про незнакомые языки, как вот ржавый наброс в теме про neovim рядом Ваш был) -- не знаю, а сишники давно уж изобрели операционные системы и их дистрибутивы.

Рис. 1: "Свинья под Дубом" // по одноименной басне И.А. Крылова

Ответить | Правка | Наверх | Cообщить модератору

8. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –3 +/
Сообщение от Аноним (21), 27-Июн-21, 10:59 
Вот поэтому во всех нормальных языках используют репощитории. frontend можно просто сделать npm update и всё обновиться согласно правилам, а не абы как.
В spring вообще достаточно обновить версию spring boot
Ответить | Правка | Наверх | Cообщить модератору

10. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (21), 27-Июн-21, 11:01 
Npm даже об уязвимостях предупреждает
Ответить | Правка | Наверх | Cообщить модератору

213. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Аноним (213), 28-Июн-21, 01:33 
про leftpad он тоже предупреждал?
Ответить | Правка | Наверх | Cообщить модератору

273. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (273), 30-Июн-21, 23:14 
помнити
Ответить | Правка | Наверх | Cообщить модератору

15. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Аноним (11), 27-Июн-21, 11:06 
> frontend можно просто сделать npm update и всё обновиться

только работать перестанет. Не смотря на заявления о том что "мы только устранили баги, зуб даем, совместимо-совместимо".

См, опять же, репо единственного вроде бы нужного проекта на "нормальном языке" - сколько совершенно нечеловеческих усилий тратится на бессмысленные "bump version ...." - а сколько там реально кода.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

40. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (21), 27-Июн-21, 11:38 
Новость о том что разработчики не тратят время на bump version того что скопипастили. Они молодцы и правильно делают

Typescript в строгом режиме и java при измени api в большинстве случаев просто не скомпилируют это будет видно сразу.

Ответить | Правка | Наверх | Cообщить модератору

78. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (11), 27-Июн-21, 12:34 
> Новость о том что разработчики не тратят время на bump version того что скопипастили. Они
> молодцы и правильно делают

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

> Typescript в строгом режиме и java при измени api в большинстве случаев просто не скомпилируют
> это будет видно сразу.

и? Это как-то поможет разработчику с миллионом не закрытых _собственных_ проблем - заниматься разработкой, а не бессмысленной тратой времени на выяснение что опять поломалось и как теперь снова все переделывать?

А еще в новой улучшенной версии конечно же не бывает ошибок, бэкдоров из-за продолбанных авторами учеток, изменившегося недокументированного поведения в граничных случаях - нет нет, что вы, что вы, нескучные язычки ведь никак не позволяют такого, всегда новая версия - самая наилучшая и безошибочная! (правда потом зачем-то приходится выпускать еще более новую и лучшую, и так каждый раз)

Ответить | Правка | Наверх | Cообщить модератору

93. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:51 
>  с наименьшей потерей своего времени

не своего, а бизнеса. сильно разные вещи. иначе на зп прогерам не хватит

Ответить | Правка | Наверх | Cообщить модератору

165. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (11), 27-Июн-21, 16:59 
Те же самые это вещи. В случае отсутствия какого-либо бизнеса за спиной -  "зп прогеров и их свободного времени, тратимых на хобби-проект, не хватит", чтобы довести его до более-менее законченного состояния. Все усилия уйдут на фуфел - погоню за новыми и новейшими версиями библиотек.

Ответить | Правка | Наверх | Cообщить модератору

16. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Dzen Python (ok), 27-Июн-21, 11:07 
> Разрабочик Larry Hullison продал компании Huei LaoWei Pedul HongKongPong Inc. права на библиотеку SuperHellYeahJSONSmooozyFractalEditor.
> B npm автоматом прилетела свежая версия с трояном от китайцев

Да...

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

37. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –4 +/
Сообщение от Аноним (21), 27-Июн-21, 11:32 
Автоматически она не прилетит потому что npm сохраняет версию и хэш. При каждом npm install будет прилётать одно и тоже, даже если в новой версии появился троян.
А если обнаружется уязвимость то npm о ней будет сообщать.

> Разрабочик Larry Hullison продал компании Huei LaoWei Pedul HongKongPong Inc. права на библиотеку SuperHellYeahJSONSmooozyDzenEditor.
> настоящий разработчик скопировал себе версию с трояном и следующие 20 лет она так и лежала в lib

Ответить | Правка | Наверх | Cообщить модератору

50. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Annoynymous (ok), 27-Июн-21, 12:00 
> Автоматически она не прилетит потому что npm сохраняет версию и хэш.

И чем это тогда отличается от встраивания библиотек?

Логика не очень понятна большинству комментаторов опеннета.

Ответить | Правка | Наверх | Cообщить модератору

84. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –3 +/
Сообщение от anonymous (??), 27-Июн-21, 12:40 
Вероятно тем, что автоматически сообщается об уязвимостях, и исправить их можно одной командой.
Ответить | Правка | Наверх | Cообщить модератору

116. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Анонимemail (93), 27-Июн-21, 13:16 
Одна команда, которая исправляет уязвимости, класс!
Че за команда? Фиксики?

Ответить | Правка | Наверх | Cообщить модератору

121. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (100), 27-Июн-21, 13:33 
npm audit fix
Ответить | Правка | Наверх | Cообщить модератору

209. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (209), 28-Июн-21, 00:21 
Не всегда работает, к сожалению. На моей практике обновляются порядка 5% пакетов. Остальные требуют изменения мажорной версии с возможной потерей совместимости.
Ответить | Правка | Наверх | Cообщить модератору

120. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –5 +/
Сообщение от Аноним (100), 27-Июн-21, 13:33 
тем что библиотеками управляет npm.
Не анонимный комментатор opennet лезет в git непозиторий или неизвестно какую помойку чтобы скачать исходный код чтобы сохранить их себе на флешку с проектом, чтобы через неделю забыть какие библиотеки накачал, какой версии эти библиотеки и откуда они взялись, не говоря о другом разработчике который эту помойку первый раз видит.

npm командой install уставливает те библиотеки которые указаны в package-lock.json. Каждый раз когда новый разработчик или CI вызывает npm install они получают те же самые библиотеки с которыми разрабатывался проект.
Когда разработчик вызывает npm update, менеджер пакетов обновляет библиотеки указанные в package.json на допустимую для обновления версию. Так как версии библиотек задаются на по semver то можно то можно зарание сделать выводы о совместимости с новой версией.
npm outdated покажет какие библиотеки и версии используются, какие доступны для обновления и последнюю версию.
npm audit покажет уязвимости

>И чем это тогда отличается от встраивания библиотек?

всем

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

138. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Annoynymous (ok), 27-Июн-21, 14:27 
Это имеет смысл, если этим пользоваться.

В 79% продуктов этим, разумеется, никто пользоваться не будет — качнул, работает и ладно.

Ответить | Правка | Наверх | Cообщить модератору

232. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (201), 28-Июн-21, 08:39 
Справедливо для любого репозитория и любого пакетного менеджера. Нужно Окончательное Решение этого вопроса средствами language-based security.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

65. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от vitektm (?), 27-Июн-21, 12:15 
с обновлением часто может поломаться сайт, а может оказаться так что для одной библиотеки можно jq  обновить до последней а для другой  нет.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

9. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Dzen Python (ok), 27-Июн-21, 11:00 
146% разработчиков - разработчики.
5% разработанных программ - могут считаться секурными на 100%
80% всего бюджета разработки съедают 20% менеджеров, вставляющих 80% педуль разработчикам.
Ответить | Правка | Наверх | Cообщить модератору

12. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (12), 27-Июн-21, 11:03 
Бандлинг дно, сегодня VCS позволяют указывать конкретные поддерживаемые версии сторонних зависимостей и подгружать их автоматически. Примерно 100% проектов бандлит зависимости просто так, большинство при этом не позволяет цеплять другие версии (скажем, системные) совершенно без причины (хотя поддерживаемые версии могли бы и указывать, это не так сложно обнаружить проблемы при самом минимальном тестировании).
Ответить | Правка | Наверх | Cообщить модератору

17. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Анонимemail (17), 27-Июн-21, 11:09 
> конкретные поддерживаемые версии сторонних зависимостей

Удобно ты придумал.
А что если уязвимость исправлена в версии 2.99.1, а у тебя 1.01?
Кто заплатит программисту за работу с BC при переходе с 1.05 -> 2.99?

Дядя Петя? Тётя Мотя?

Ответить | Правка | Наверх | Cообщить модератору

55. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Michael Shigorinemail (ok), 27-Июн-21, 12:08 
А потом спрашивают -- зачем нужны дистрибутивы, или затягивают сагу про обои...
Ответить | Правка | Наверх | Cообщить модератору

74. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:29 
это то чем занимаются разработчики дистрибутивов? тут мои познания на уровне тумбочки, можешь пояснить свой коммент?
Ответить | Правка | Наверх | Cообщить модератору

94. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 27-Июн-21, 12:52 
Это то, чем они по замыслу должны заниматься.

На деле "разработчик" Rosa Tresh сочинял сегодня рифму:

Арчем деб манжит кубину
Улыбок тебе, дед Макар.

Ответить | Правка | Наверх | Cообщить модератору

135. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +5 +/
Сообщение от Аноним (135), 27-Июн-21, 14:11 
Чел, вот прям жаль тебя даже.
Плюнь ты на эту росу.
Ну кинули, ну да, бывает со всеми.
Живи спокойно дальше, эти сами сдохнут.
Лучше что нибудь полезное сделай или приятное, чем вот так с обидкой няньчиться.
Неужели других достижений в жизни нет, всё роса украла?
Ответить | Правка | Наверх | Cообщить модератору

141. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 27-Июн-21, 14:43 
> Чел, вот прям жаль тебя даже.

Да-да. Где-то я уже это слышал. https://lurkmore.to/Мне_вас_жаль

> Плюнь ты на эту росу.

Я и плюю, как Вы просите. Одновременно отвечаю человеку на его вопрос. Они служат примером. Все довольны. Кроме Вас.

> Ну кинули, ну да, бывает со всеми.

Точно, кинули своего работничка Алзима. https://www.opennet.ru/openforum/vsluhforumID3/124359.html#204

> Живи спокойно дальше, эти сами сдохнут.
> Лучше что нибудь полезное сделай или приятное, чем вот так с обидкой
> няньчиться.
> Неужели других достижений в жизни нет, всё роса украла?

Я и делаю. Вас то что так волнует?

Ответить | Правка | Наверх | Cообщить модератору

280. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Michael Shigorinemail (ok), 03-Июл-21, 15:57 
> это то чем занимаются разработчики дистрибутивов?

В том числе...

Однодневок и единороллингов не касается -- там или забивают на вопрос в целом, или решают его исключительно текущими апстримными версиями (последнее само по себе бывает хорошо, только вот имеет свою цену и свои побочки в зависимости от повадок конкретного апстрима).

У кого есть поддерживаемые ветки -- все так или иначе сталкиваются и так или иначе занимаются и поддержкой совместимости того, что в них.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

210. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (210), 28-Июн-21, 00:51 
А зачем нужны бинарные дристрибутивы кроме чесания ЧСВ их разрабов? К примеру, во всех испробованных за последние полтора года (включая альт) имелась одна и та же проблема с неполной русификацией VLC - часть пунктов по-русски, часть на английском. Понятно, что я сам могу взять соответствующий файл из виндовой версии, где с этим вопросом все в порядке и подсунуть в линупcячью, но это - брать на себя работу майнтайнера. Или другой пример из практики: есть такой epub-редактор, называется Sigil (понятно что рядом с Adobe Indesign поделка по функционалу и близко не лежала, но на халяву и линупc готов для десктопа). Если используемый дристрибутив не роллинг, то этот самый sigil при запуске будет постоянно задалбывать сообщениями что у тебя стоит древняя версия и надо бы обновиться, ага (по умолчанию обновы проверяются каждые 6 часов и в самой софтине это дело неотключаемо). Простейший способ исправить это дело - прописать #define DISABLE_UPDATE_CHECK в src/main.cpp и в таком виде собрать, но для рук и интеллекта майнтайнера это абсолютно непосильный труд, а потому снова сам собирай из сорцов как оно тебе надо. Или, к примеру, неимоверно доставила последняя opensuse, в которой wine из их собственной репы не видел без доработки напильником wine-mono, поставленный по зависимостям вместе с этим же wine из той же репы. А потому неизбежно возникает вопрос: а нужны ли вообще эти майнтайнеры если половину их работы потом переделывать приходится, нужны ли кучи пакетов в разных форматах если все равно качаешь сорцы и собираешь сам, и нужны ли эти 100500 сортов кocтылинупca вообще или надо по уму (то есть как в бсдшках): есть base system, а все остальное - в портах и пакетах?
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

218. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –4 +/
Сообщение от Аноньимъ (ok), 28-Июн-21, 05:29 
В ФрииБСД свой отдельный ад.
Например бинарные пакеты оказываются с отличными от портов опциями сборки.

Таки вся эта клоунада спакетами нужна для системного софта.

Прикладное ПО должно быть самодостаточным в рамках системы.
Флетпак и АппИмаже поняли прикладное ПО верно.

С вайном отдельная история, работает он через не известное проктологам место.
Зачем-то требует предоставлять вин приложениям доступ к корню и вообще страшно костыльный.

Ответить | Правка | Наверх | Cообщить модератору

227. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 28-Июн-21, 07:34 
Я когда-то установил FreeBSD из сорцов, тупо нажимая пол часа continue в конфигураторах. Потом ставил приложения и так, и эдак. Через год прочёл, что оно работать не должно в теории. Решил, что наконец я готов для Линукс. Наткнулся рекламу на Rosa Tresh. Протухший DKMS, который не понимает актуальные сборочные сценарии и который никто не собирается обновлять; какие-то левые файлы возникают в корне после обновления системы (разработчики, само собой, не могли их заметить). Wi-Fi не работает в инсталляторе -- ну и что? это не критичный баг, подключат провод, можно релизить! Зато масса видосиков, насколько это здорово и лучше Венды с Убунтой, потому что когда-то было Мандривой.
Ответить | Правка | Наверх | Cообщить модератору

267. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноньимъ (ok), 29-Июн-21, 12:03 
Ну, Фре нужно отдать должное, она практически разумна и без мусора. Практически нее делает того, о чём её не просят.

Дистрибутивы линукса же в большинстве, это набор костылей делающих удобно. Даже самые минимальные сегодня идут с систеемой-Д. Положительная сторона в том, что оно само обладает разумными дефолтами для выполнения широкого круга задач. Отрицательная - добавочная сложность, в том числе в возникающих проблемах и их решении.

Ответить | Правка | Наверх | Cообщить модератору

249. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (-), 28-Июн-21, 12:56 
> В ФрииБСД свой отдельный ад.
> Например бинарные пакеты оказываются с отличными от портов опциями сборки.

И в чем ад-то?
Бинарные пакеты - это порты, собранные с определенным набором опций.
Вместе с возможностью простого редактирования мейкфайла (ну или использования своего оверлея) и такой же простой возможности добавления своих патчей  - получается достаточно гибкий инструмент, вполне "дружащий" (на практике) с установкой пакетов из репы.

Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

266. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноньимъ (ok), 29-Июн-21, 11:57 
В том что опции по умолчанию в портах должны совпадать с опциями сборки бинарных пакетов.
В противном случае появляется системная неоднородность.

Никаких разумных причин для которой нет. Единственное объяснение которое приходит в голову - по*** мейнтейнеров и прочих участников проекта.

Кроме всего прочего, большая часть прикладного ПО в FreeBSD банально не тестируется перед выкладыванием пакетов или добавлением изменений в порты.
Частая ситуация - порт не собирается.
Вторая частая ситуация - программа при запуске крашится, или крашится при попытке использования (открыть файл например).

Ответить | Правка | Наверх | Cообщить модератору

268. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (-), 29-Июн-21, 14:14 
> В том что опции по умолчанию в портах должны совпадать с опциями
> сборки бинарных пакетов. В противном случае появляется системная неоднородность.
> Никаких разумных причин для которой нет. Единственное объяснение которое приходит в голову
> - по*** мейнтейнеров и прочих участников проекта.

Никуя не понял.
Дефолтные опции портов == опции с которыми из них собирают пакеты. Естественно, что не все возможные комбинации совместимы (или тестируются) - при нестандартных хотелках уже желательно немного подключать голову и иметь какое-то представление, что делаешь и зачем.

Я почти два года спокойно сидел в репе "latest" (которая по актуальности и обновляемости софта переплевывает AUR c Федорой: https://repology.org/) c замороженным harfbuzz-2.1.3 кастомной сборки.
До сих пор спокойно использую (принцип "... или ишак или падишах", как c harfbuzz)
freetype2 2.9.1
Installed on   : Fri Nov 23 15:19:19 2018 CET
(актуальная версия в репе - freetype2-2.10.4)

Это самые "интересноые" (т.к. имеют большие обратные зависимости) - а так, из 1595 установленных пакетов только 54 "самосбор", в основном из-за отличных от дефолта опций сборки или кастомных патчей или убирания "лишних" зависимостей.
Куда уж тут еще "неоднороднее" ...

> Кроме всего прочего, большая часть прикладного ПО в FreeBSD банально не тестируется
> перед выкладыванием пакетов или добавлением изменений в порты.
> Частая ситуация - порт не собирается.

Это частая байка опеннета, разве что.
Еще раз, медленно и по буквам: бинарные пакеты - это собранные в эти самые пакеты порты.
cd /usr/ports/foo
make package clean
соберет пакет foo.txz в /usr/ports/packages
pkg repo /usr/ports/packages/ - сделает (или обновит) из этого "настоящую" репу, из которой pkg update/upgrade/install сможет брать пакеты.

Далее, сборка оф. пакетов из портов предельно автоматизированна, пакеты _никем_ не выкладываются, а собираются билдсервером из среза портов. И весь смысл портов в том, что их сборка юзверем - это штатная операция, а не ритаул одинокого мейнтейнера раз в полгода, с танцами и бубном как-то чудом собрать бинарный пакет.

При сборке оф. репы, не собирающиеся порты автоматом помечаются как "broken" (и со временем, если их не фиксят, удалаются).
Сейчас таких в портах аж 87
https://www.freshports.org/


Calculated hourly:
Port count    44153
Broken    87
Deprecated    169
Ignore    320

Остальное - проблемы окружения сборки (обычно - излишних наворотов и опций компилятора в make.conf). Не можешь/хочешь/умеешь определить причину - тупо собирай в чистом джейле/poudriere.
А собираемость во всех возиожных 100500 вариациях окружения и комбинаций никто не обещал.

> Вторая частая ситуация - программа при запуске крашится,

Угу-угу. Частота (и причины) - примерно как с первым пунктом. Но мне лень комментировать очередные "предания опеннета о бздах".

Ответить | Правка | Наверх | Cообщить модератору

270. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –3 +/
Сообщение от Аноньимъ (ok), 30-Июн-21, 11:04 
Я так же как и вы юзаю фрю и описывают свой опыт.
Ваши щёконадувания выглядят жалко. Попробуйте в следующий раз вести добросовестный диалог и слушать собеседника.
Ответить | Правка | Наверх | Cообщить модератору

271. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (-), 30-Июн-21, 14:14 
> Я так же как и вы юзаю фрю и описывают свой опыт.

Да-да-да, только вас таких "опытных пользователей" - как обычно, пол опеннета.
> Ваши щёконадувания выглядят жалко.
> Попробуйте в следующий раз вести добросовестный диалог и слушать собеседника.

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

Ответить | Правка | Наверх | Cообщить модератору

274. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –3 +/
Сообщение от Аноньимъ (ok), 01-Июл-21, 11:05 
Вы бы хоть чем-то читали бы, уже был бы прогресс.

Ещё раз, опции сборки бинарных пакетов отличаются от дефолтных опций портов.

Перечитывать пока не прийдёт просветление.

Ответить | Правка | Наверх | Cообщить модератору

275. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (-), 01-Июл-21, 12:27 
> Ещё раз, опции сборки бинарных пакетов отличаются от дефолтных опций портов.

Еще раз, опции сборки бинарных пакетов и есть дефолтные опции портов.
> Перечитывать пока не прийдёт просветление.

Прекратить нести чепуху пока не придет просветление.

Ответить | Правка | Наверх | Cообщить модератору

281. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Michael Shigorinemail (ok), 03-Июл-21, 16:10 
> А зачем нужны бинарные дристрибутивы кроме чесания ЧСВ их разрабов?

Ну вот чтоб Вы своё могли почесать.

> К примеру, во всех испробованных за последние полтора года (включая
> альт) имелась одна и та же проблема с неполной русификацией VLC -
> часть пунктов по-русски, часть на английском. Понятно, что я сам могу
> взять соответствующий файл из виндовой версии, где с этим вопросом
> все в порядке

Если всё же почесать затылок, а не ЧСВ, то может оказаться, что переводы-то в обоих случаях или апстримные (и различие для конкретного языка тогда может быть только в версии, которые Вы не потрудились привести), или добавленные создателем сборки (и тогда включаются все плюсы и минусы любого форка).

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

http://altlinux.org/BugTracking/BugzillaMiniHowto в помощь, если вдруг отважитесь :-)

> и подсунуть в линупcячью, но это - брать на себя работу майнтайнера

Вообще-то нет, это "работа" пресловутого Дениса Попова и прочих зверьсиделателей.  Сам как майнтейнер порой брал и дорабатывал переводы (того же recoll, да много чего), отправляя их и разработчику.

>. Или другой пример из практики: есть такой epub-редактор, называется
> Sigil [...] Простейший способ исправить это дело - прописать
> #define DISABLE_UPDATE_CHECK в src/main.cpp и в таком виде собрать,
> но для рук и интеллекта майнтайнера это абсолютно непосильный труд

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

Но самым коварным было бы взяться поддерживать пакет в подходящем виде в том дистрибутиве, который меньше всего Вас достал своими выбрыками и косяками.

> Или, к примеру, неимоверно доставила последняя opensuse, в которой
> wine из их собственной репы не видел без доработки напильником
> wine-mono, поставленный по зависимостям вместе с этим же wine из той
> же репы.

Ну попробуйте туда WINE@Etersoft поставить, в альте-то его Виталик в репозитории и поддерживает (и несколько лет назад конкретно с wine-mono всё завелось вообще без пинков).

> А потому неизбежно возникает вопрос: а нужны ли вообще эти
> майнтайнеры если половину их работы потом переделывать приходится

Без них приходится переделать те 99,9% работы, которые Вы принимаете за данность и попросту не замечаете.  Посмотрите, что ли, инструкции по установке третьей слаквари какой и подумайте, "половину" ли.

> нужны ли кучи пакетов в разных форматах если все равно качаешь сорцы
> и собираешь сам

Вот как думаете -- как я стал майнтейнером? :)

> и нужны ли эти 100500 сортов кocтылинупca вообще или надо по уму
> (то есть как в бсдшках): есть base system, а все остальное -
> в портах и пакетах?

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

И вишенка на торте -- нужны ли эти 100500 сортов бздей, почему одной-то не хватило?..

(если вместо риторики посмотреть трезво, то получится всё то же неизбывное: люди разные, цели разные, средства -- как ни странно, тоже оказываются тем ещё разноязычием; а что-то общее вырастает там, где люди находят смысл и возможность ради него объединиться и найти в чём-то компромиссы, которые неизбывно вылезают другими боками порой)

Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

123. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (100), 27-Июн-21, 13:41 
>А что если уязвимость исправлена в версии 2.99.1, а у тебя 1.01?

надо было об этом думать десять лет назад.

тот же кто оплатил появление в проекте версии 1.01, очевидно же.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

18. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Аноним (11), 27-Июн-21, 11:09 
Причина - что умному достаточно один раз получить по лбу граблями от очередного улучшизма.

Чтобы указать "поддерживаемые версии" - надо для начала потратить время на проверку, какие же версии работают - а потом еще и разгребать багрепорты от тех кто подсунул-таки "поддерживаемую", а она, ну надо же - что-то поломала.

Очевидно, что нах никому не вперлось этим заниматься.

Нет, "самым минимальным" не отделаешься. Тестировать надо весь апи, включая неиспользуемые части - сегодня не используешь, завтра что-то по мелочи изменил в коде - и уже используешь, даже сам этого не зная (потому что при другом параметре той же функции оно внутри библиотеки начинает использоваться).

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

22. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –6 +/
Сообщение от Аноним (12), 27-Июн-21, 11:14 
Разработку нужно вести на самом актуальном окружении, тестировать мохнатые версии заявленные поддерживаемыми только по остаточному принципу. Собственно, многие так и делают. Другие действуют по принципу "нас и версия 50 летней давности устраивает, в что там нового мы не знаем". Что-то ломается конечно и внезапно, но такие низкокачественные зависимости вещь нечастая.
Ответить | Правка | Наверх | Cообщить модератору

29. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –3 +/
Сообщение от Анонимemail (17), 27-Июн-21, 11:20 
Когда актуальность окружения сведётся к месяцам, а доллар будет по 300 рублей - запоёшь
Ответить | Правка | Наверх | Cообщить модератору

36. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (12), 27-Июн-21, 11:32 
> Когда актуальность окружения сведётся к месяцам, а доллар будет по 300 рублей
> - запоёшь

Можно пример где так часто ломают совместимость между версиями? Когда ты используешь новый функционал, ты понимаешь, в какой версии он появился (и что он может быть сыроват). Если ты пользуешься кодом, объявленным устаревшим 10 лет назад, ты тоже понимаешь, к чему это приведёт.

Ответить | Правка | Наверх | Cообщить модератору

39. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от ыы (?), 27-Июн-21, 11:35 
1С например :)

Причем оплачивать совместимость конфигурации с последней версией вы будете из собственного кармана.
Или можно присылать счета вам?

Ответить | Правка | Наверх | Cообщить модератору

48. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (12), 27-Июн-21, 11:55 
Куда лучше на годы завязываться на неподдерживаемые версии? Мигрировать всё равно придётся, и чем быстрее, тем меньше проблем это вызовет.
Ответить | Правка | Наверх | Cообщить модератору

49. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:00 
Вот и обновляй железо каждый месяц. Все равно придётся, че
Ответить | Правка | Наверх | Cообщить модератору

51. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от ыы (?), 27-Июн-21, 12:00 
Вот прямо сейчас и начнем.
Счете вам присылать?
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

54. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноним (12), 27-Июн-21, 12:06 
> Вот прямо сейчас и начнем.
> Счете вам присылать?

Т.е. я должен отвечать за опрометчиво принятые вами решения? Нет, спасибо, это ваш бизнес прогорит и отвечать тоже вам.

Ответить | Правка | Наверх | Cообщить модератору

56. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от ыы (?), 27-Июн-21, 12:09 
Вы поняли что сейчас написали?
Вы сейчас назвали опрометчивым решением свою сентенцию "Мигрировать всё равно придётся, и чем быстрее, тем меньше проблем это вызовет."

И эта ситуация совершенно типична-  философы и экспреты призывающие к обновлению  как-то сразу сдуваются когда им напоминаешь что то к чему они призывают- вообще говоря не бесплатно... и часто СИЛЬНО НЕБЕСПЛАТНО.

Ответить | Правка | Наверх | Cообщить модератору

64. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноним (12), 27-Июн-21, 12:15 
Что, это я вас подписал взять агрессивно-монетизируемые проприетарные решения?
Ответить | Правка | Наверх | Cообщить модератору

72. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от ыы (?), 27-Июн-21, 12:27 
Когда вам пишут код на заказ- не имеет значения проприетарный код или нет. Он кастомный. И его любое изменение - стоит денег. а использовать не кастомный код- не получится. Есть универсальные варианты конфигурации, но они настолько универсальны- что нигде кроме угла под вывеской "кофе на вынос" применятся по сути не могут. Тоесть код будет кастомный. И это значит платный.  В простых случаях вам его поправит ваш программист. В чуть более сложных- только разработчик конфигурации. Ибо СЛОЖНО СИЛЬНО. И за каждое изменение - плата отдельная. Ну или вы будете оплачивать тысячи разработчиков как Сбербанк :)

Ответить | Правка | Наверх | Cообщить модератору

86. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноним (12), 27-Июн-21, 12:40 
Это всё ещё последствия принятой модели. А значит, бюджет на подобную миграцию заложен (зато сэкономили на разработке собственного поддерживаемого решения, правда?). Если не устраивает регулярность, с которой разработчики ломают совместимость и монетизируются, задавайте вопросы им. При этом, конкурирующие решения могут и не доить, но вам очевидно интереснее, чтобы вас доили.
Ответить | Правка | Наверх | Cообщить модератору

90. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от ыы (?), 27-Июн-21, 12:46 
>зато сэкономили на разработке собственного поддерживаемого решения, правда?

То есть вы утверждаете что существует некий вариант кода,  который будет совместим с любыми изменениями любых зависимостей в будущем? Вы забавный человек :)

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

99. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноним (12), 27-Июн-21, 12:59 
Нет, я утверждаю только то, что нагло доить клиентов это очень неприлично, и что клиенты эти сами согласились на это, а значит, это только их проблема. Это какого же низкого уровня должен быть код, чтобы он регулярно рассыпался? Компоненты могут и обновляться, но совместимость в них сохраняется.
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

91. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:48 
Давайте смоделируем по предлагаемой вами модели "код пишется для актуального на момент времени окружения".

После очередного обновления windows поддерживает только актуальное железо, браузер поддерживает только актуальные версии дров, вебсайт только актуальную версию jquery, jquery только актуальную версию браузера. Остальное по остаточному принципу/желанию левой пятки.

Сколько понадобится времени, чтобы всё рухнуло?

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

96. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от ыы (?), 27-Июн-21, 12:53 
Вы меня не поняли. Я только за , чтобы обновлять парк железа сразу же после выхода нового... Я только говорю что это не бесплатно.
Счета вам на какой счет присылать? В этом месяце миллиарда на два обновим...
Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

97. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от ыы (?), 27-Июн-21, 12:55 
А, я не тому ответил похоже. Сорри..
Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

98. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:56 
вас то я как раз-таки понимаю, в отличие от нашего собеседника, предлагающего поддерживать только актуальное :)
Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

129. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Урри (ok), 27-Июн-21, 13:47 
Rust, например.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

58. Скрыто модератором  –2 +/
Сообщение от Michael Shigorinemail (ok), 27-Июн-21, 12:09 
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

62. Скрыто модератором  +3 +/
Сообщение от ыы (?), 27-Июн-21, 12:14 
Ответить | Правка | Наверх | Cообщить модератору

108. Скрыто модератором  +1 +/
Сообщение от Аноним (108), 27-Июн-21, 13:10 
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

130. Скрыто модератором  +3 +/
Сообщение от Урри (ok), 27-Июн-21, 13:49 
Ответить | Правка | Наверх | Cообщить модератору

252. Скрыто модератором  +/
Сообщение от свидетель яхве (?), 28-Июн-21, 14:10 
Ответить | Правка | Наверх | Cообщить модератору

279. Скрыто модератором  +/
Сообщение от Michael Shigorinemail (ok), 03-Июл-21, 15:53 
Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

95. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:53 
Давайте смоделируем мир по предлагаемой вами модели.

После очередного обновления windows поддерживает только актуальное железо, браузер поддерживает только актуальные версии дров, вебсайт только актуальную версию jquery, jquery только актуальную версию браузера. Остальное по остаточному принципу/желанию левой пятки.

Сколько понадобится времени, чтобы всё рухнуло?

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

103. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –3 +/
Сообщение от Аноним (12), 27-Июн-21, 13:03 
Это может означать провал новой версии окна. Если ей никто не сможет пользоваться, она уйдёт в минус, тут всё просто. На некоторое время. Новое железо будет поставляться с новой версией окна, и потеряют опять же те, кто завязывался на неподдерживаемые проприетарные решения. Зато сэкономили (и тут).
Ответить | Правка | Наверх | Cообщить модератору

107. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Анонимemail (93), 27-Июн-21, 13:09 
Вот и я говорю: хорошую модель предлагаете. Простую, и, что самое главное, надежную.
Ответить | Правка | Наверх | Cообщить модератору

119. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (12), 27-Июн-21, 13:30 
> Вот и я говорю: хорошую модель предлагаете. Простую, и, что самое главное,
> надежную.

Кстати по поводу железа. Посмотрите на игровые приставки например, или на телефоны, там ведь всё так и происходит: новая версия ПО для нового железа. Это маленькое развитие привычной модели продажи проприетарного ПО, в данном случае ещё и железо проприетарное. Скорее всего, не будь IBM PC, мы до сих пор жили бы в обществе, где за все обновления надо платить.

Ответить | Правка | Наверх | Cообщить модератору

122. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Анонимemail (17), 27-Июн-21, 13:36 
Я пользуюсь свежими версиями приложений на смартфоне 18 года, и пишу это сообщение в свежей версии дистра и браузера на лэтпопе 13 года
Ответить | Правка | Наверх | Cообщить модератору

128. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (12), 27-Июн-21, 13:47 
В том и дело, что по завязывается на новые версии железа только искусственно и практически новый софт будет работать и со старым оборудованием, только намного хуже. Не понимаю, почему тут некоторые пытаются прировнять циклы обновления (проприетарного) аппаратного обеспечения к развитию (проприетарных) программ.
Ответить | Правка | Наверх | Cообщить модератору

113. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от ыы (?), 27-Июн-21, 13:14 
А пользователи не провалятся, у которых доступ к Госуслугам или к Ютубу  только с новым браузером который только на новой ОС которая только на новом железе?
Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

118. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –3 +/
Сообщение от Аноним (12), 27-Июн-21, 13:26 
К госуслугам закрывать доступ старых систем это правильно, может поменьше историй будет в духе "у меня украли 3 квартиры". Но не старых, а более старых чем официально принятый на общегосударственном уровне стандарт минимальной версии. Обновляться надо. И стандарт этот тоже обновлять надо -- дырявые версии прикрытые бумажкой это не выход. С ютубом же так и происходит, причём, всё больше 1 специальный браузер новой версии, или будут разнообразные проблемы.
Ответить | Правка | Наверх | Cообщить модератору

144. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Котофалк (?), 27-Июн-21, 15:24 
> Причина - что умному достаточно один раз получить по лбу граблями от очередного улучшизма.

И он же готов регулярно получать по лбу граблями от древних багов. Может, дело не в уме?

> Чтобы указать "поддерживаемые версии" - надо для начала потратить время на проверку

CI, тесты, да. Тут вот какое дело. Либо ты пишешь код и сам с ним брачуешься, либо ты берёшь чужой и экономишь время на разработке. Вся проблема в том, что когда код весь твой, ты можешь забить на его проблемы (или даже не знать о них до поры-до времени) и даже на развитие, а вот когда код чужой тебя ткнут носом. Т.е. если в первом случае экономия понятна всем и признаётся желаемой, по второму варианту есть разночтения.

> Очевидно, что нах никому не вперлось этим заниматься.

Только тем, кто проблемы своего кода склонен заметать под коврик с криками "мне за это не платят".

> Тестировать надо весь апи, включая неиспользуемые части

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

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

14. Скрыто модератором  –6 +/
Сообщение от ИмяХ (?), 27-Июн-21, 11:05 
Ответить | Правка | Наверх | Cообщить модератору

19. Скрыто модератором  +3 +/
Сообщение от Dzen Python (ok), 27-Июн-21, 11:09 
Ответить | Правка | Наверх | Cообщить модератору

24. Скрыто модератором  –1 +/
Сообщение от Анонимemail (17), 27-Июн-21, 11:16 
Ответить | Правка | Наверх | Cообщить модератору

111. Скрыто модератором  +6 +/
Сообщение от Dzen Python (ok), 27-Июн-21, 13:12 
Ответить | Правка | Наверх | Cообщить модератору

131. Скрыто модератором  +2 +/
Сообщение от Урри (ok), 27-Июн-21, 13:53 
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

205. Скрыто модератором  +/
Сообщение от msgod (ok), 28-Июн-21, 00:06 
Ответить | Правка | Наверх | Cообщить модератору

215. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 28-Июн-21, 02:02 
Ответить | Правка | Наверх | Cообщить модератору

26. Скрыто модератором  –3 +/
Сообщение от Аноним (26), 27-Июн-21, 11:17 
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

112. Скрыто модератором  +3 +/
Сообщение от Dzen Python (ok), 27-Июн-21, 13:14 
Ответить | Правка | Наверх | Cообщить модератору

157. Скрыто модератором  +/
Сообщение от Аноним (26), 27-Июн-21, 16:36 
Ответить | Правка | Наверх | Cообщить модератору

158. Скрыто модератором  +/
Сообщение от Аноним (155), 27-Июн-21, 16:36 
Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

212. Скрыто модератором  +/
Сообщение от Aukamo (ok), 28-Июн-21, 01:14 
Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

241. Скрыто модератором  +/
Сообщение от n00by (ok), 28-Июн-21, 09:48 
Ответить | Правка | Наверх | Cообщить модератору

30. Скрыто модератором  –1 +/
Сообщение от ыы (?), 27-Июн-21, 11:22 
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

114. Скрыто модератором  +1 +/
Сообщение от Dzen Python (ok), 27-Июн-21, 13:15 
Ответить | Правка | Наверх | Cообщить модератору

206. Скрыто модератором  –1 +/
Сообщение от msgod (ok), 28-Июн-21, 00:08 
Ответить | Правка | Наверх | Cообщить модератору

216. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 28-Июн-21, 02:14 
Ответить | Правка | Наверх | Cообщить модератору

189. Скрыто модератором  –1 +/
Сообщение от Аноним (189), 27-Июн-21, 20:29 
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

20. Скрыто модератором  +3 +/
Сообщение от корпорация зла (?), 27-Июн-21, 11:10 
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

28. Скрыто модератором  +/
Сообщение от Аноним (28), 27-Июн-21, 11:19 
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

33. Скрыто модератором  +1 +/
Сообщение от iZENemail (ok), 27-Июн-21, 11:26 
Ответить | Правка | Наверх | Cообщить модератору

41. Скрыто модератором  –2 +/
Сообщение от Аноним (38), 27-Июн-21, 11:41 
Ответить | Правка | Наверх | Cообщить модератору

45. Скрыто модератором  +/
Сообщение от Аноним (45), 27-Июн-21, 11:52 
Ответить | Правка | Наверх | Cообщить модератору

61. Скрыто модератором  –1 +/
Сообщение от Аноним (38), 27-Июн-21, 12:14 
Ответить | Правка | Наверх | Cообщить модератору

59. Скрыто модератором  –1 +/
Сообщение от Michael Shigorinemail (ok), 27-Июн-21, 12:11 
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

66. Скрыто модератором  +3 +/
Сообщение от ыы (?), 27-Июн-21, 12:16 
Ответить | Правка | Наверх | Cообщить модератору

278. Скрыто модератором  +/
Сообщение от Michael Shigorinemail (ok), 03-Июл-21, 15:51 
Ответить | Правка | Наверх | Cообщить модератору

67. Скрыто модератором  +4 +/
Сообщение от Аноним (38), 27-Июн-21, 12:18 
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

145. Скрыто модератором  +/
Сообщение от Котофалк (?), 27-Июн-21, 15:27 
Ответить | Правка | Наверх | Cообщить модератору

169. Скрыто модератором  +1 +/
Сообщение от iLex (ok), 27-Июн-21, 18:08 
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

219. Скрыто модератором  +/
Сообщение от Аноньимъ (ok), 28-Июн-21, 05:42 
Ответить | Правка | Наверх | Cообщить модератору

27. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Ананоним (?), 27-Июн-21, 11:17 
О какие плохие и неправильные пользователи библиотек! Ату их! О какие хорошие и правильные разработчики бублиотек! Хвала им!

Реальность несколько иная - нет дыма без огня.

Ответить | Правка | Наверх | Cообщить модератору

31. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноним (31), 27-Июн-21, 11:22 
Причём тут динамическое связывание? Ну вот лежит у меня в папке с автокадом миллиард ДЛЛ файлов. Допустим некоторые это динамические библиотеки с уязвимостью. Они предлагают мне пойти скачать откуда-то свежие ДЛЛ и перезаписать их у себя? Или они предлагают разрабам вместо копирования их в папку с приложением класть их в system32 порождая dll hell?
Ответить | Правка | Наверх | Cообщить модератору

32. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от ыы (?), 27-Июн-21, 11:24 
Они предлагают отслеживать лицензию, и обновлчть вам автокад автоматически на каждый пук автора длл...
Ответить | Правка | Наверх | Cообщить модератору

146. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Котофалк (?), 27-Июн-21, 15:29 
Упаси аллах, пусть валяется кривое тухлое. Пользователь деньги уже занёс, к чему лишние хлопоты?
Ответить | Правка | Наверх | Cообщить модератору

150. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от ыы (?), 27-Июн-21, 15:38 
То есть вы признаете что продали недоброкачественный продукт и знали об этом заранее...
А ведь это сокрытие существенной информации при сделке...
Ответить | Правка | Наверх | Cообщить модератору

179. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от библия (?), 27-Июн-21, 19:38 
в еуле все это прописано, что покупаете гомнецо. так что никаких претензий.
Ответить | Правка | Наверх | Cообщить модератору

221. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Котофалк (?), 28-Июн-21, 06:16 
> То есть вы признаете что продали недоброкачественный продукт и знали об этом заранее...

Тебя ждёт unbundle libsarcasm и обновление зависимостей.

> А ведь это сокрытие существенной информации при сделке...

На языке маркетологов это может быть заботой о стабильности софта. Или что-то ещё. Да и покупателей это может вообще не парить.

Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

34. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от iZENemail (ok), 27-Июн-21, 11:27 
> Причём тут динамическое связывание? Ну вот лежит у меня в папке с
> автокадом миллиард ДЛЛ файлов. Допустим некоторые это динамические библиотеки с уязвимостью.
> Они предлагают мне пойти скачать откуда-то свежие ДЛЛ и перезаписать их
> у себя? Или они предлагают разрабам вместо копирования их в папку
> с приложением класть их в system32 порождая dll hell?

Они ничего не предлагают, а лишь констатируют печальный факт.


Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

35. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –4 +/
Сообщение от Аноним (35), 27-Июн-21, 11:29 
А вот в Huawei не 79%, они там для KPI могут  стилевые правки делать
Ответить | Правка | Наверх | Cообщить модератору

42. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Zenitur (ok), 27-Июн-21, 11:45 
Разве для борьбы со Spectre v2 не нужно пересобрать все бинарники?
Ответить | Правка | Наверх | Cообщить модератору

53. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (38), 27-Июн-21, 12:05 
Не все же подряд программы работают с чувствительными к утечкам данными.
Ответить | Правка | Наверх | Cообщить модератору

177. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Аноним (177), 27-Июн-21, 19:30 
Photoshop сольет АНБ твои мемасы с обамой и российскими подьездами
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

43. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от боня (?), 27-Июн-21, 11:45 
> Отговорки, что обновление библиотек не производится из-за возможного нарушения совместимости, в большинстве случаев беспочвенны

Это про проекты на c++ где берут указатели на произвольные участки памяти и выполняют их?

У нас наоборот, запрещено зависимости обновлять потому что проект на дотнете и 100% кода - безопасный код.

Просто не пишите на дырявом решете

Ответить | Правка | Наверх | Cообщить модератору

47. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Аноним (45), 27-Июн-21, 11:54 
Я пришлю Вам счёт за услуги проф.химчистки - весь монитор жиром залило.
Ответить | Правка | Наверх | Cообщить модератору

92. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от боня (?), 27-Июн-21, 12:50 
> Я пришлю Вам счёт за услуги проф.химчистки - весь монитор жиром залило.

спасибо. Жирнвато - да. Но автор статьи совсем не учёл специфику различных проектов и технологий разработки.

Например, нашей библиотеке, которая взаимодействует с сериализацией сетевых сообщений более пяти лет. И только человек, который желает получить в печень может попытаться обновить её.

С другой стороны, в том же джаваскрипте обновления - это вечная погоня за своими пятками. В условиях дикого запада люди обновляют обновляют обновляют обновляют... и зачем? Лучше и безопаснее не становится

Ответить | Правка | Наверх | Cообщить модератору

57. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (38), 27-Июн-21, 12:09 
Вот так вот прямо на произвольный? А если там окажется середина машинной команды? Машинные коды они далеко не всегда однобайтовые.
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

106. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 27-Июн-21, 13:07 
> Вот так вот прямо на произвольный? А если там окажется середина машинной
> команды?

Будет обработана процессором как другая команда.

Ответить | Правка | Наверх | Cообщить модератору

139. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Маняним (?), 27-Июн-21, 14:27 
> Просто не пишите на дырявом решете

Вот поэтому ты и пишешь всю жизнь обёртки к софту на "на дырявом *ешете". Дай тебе "дырявое *ешето" и мы будем свидетелями удивительных вещей.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

160. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от боня (?), 27-Июн-21, 16:40 
> Дай тебе "дырявое *ешето" и мы будем свидетелями удивительных вещей.

Спасибо, не надо. Выжигали это архитектурное недоразумение годами

Ответить | Правка | Наверх | Cообщить модератору

148. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Котофалк (?), 27-Июн-21, 15:31 
> У нас наоборот, запрещено зависимости обновлять потому что проект на дотнете и 100% кода - безопасный код.

(помечает в блокнотике)
...разработчики на дотнете напрочь оторваны от реальности, придумали 100% безопасный код.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

46. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Аноним (46), 27-Июн-21, 11:52 
Veracode - шарлатаны. Продают воздух за килобаксы
Ответить | Правка | Наверх | Cообщить модератору

52. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (52), 27-Июн-21, 12:05 
"простым" обновлением кода библиотеки
но на C/C++ что-ли обновление простое?))
Ответить | Правка | Наверх | Cообщить модератору

69. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от CPP (??), 27-Июн-21, 12:20 
Если после исправления бага нужно повторно проходить сертификацию продукта, то руководство предпочтёт подождать ещё лет пять.
Ответить | Правка | Наверх | Cообщить модератору

70. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +4 +/
Сообщение от Аноним (70), 27-Июн-21, 12:20 
Мистер Cargo к нам придёт и порядок наведёт, Мистер Cargo.
Ответить | Правка | Наверх | Cообщить модератору

71. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от ip1982 (ok), 27-Июн-21, 12:26 
В психологическую ловушку попадаете вы. Новое не означает более лучше.
Ответить | Правка | Наверх | Cообщить модератору

75. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от ыы (?), 27-Июн-21, 12:30 
Так старые дыры позакрывали... как новые то подсовывать? Обновляться надоть...
Ответить | Правка | Наверх | Cообщить модератору

80. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:34 
истину магистр говорите вы
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

73. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от ip1982 (ok), 27-Июн-21, 12:28 
Я думаю отчасти виноваты авторы библиотек, которые срать хотели на  пользователей и мчатся впереди паровоза не думая ни о чём: ни о проектировании, ни об обратной совместимости, ни о переносимости.
Ответить | Правка | Наверх | Cообщить модератору

149. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Котофалк (?), 27-Июн-21, 15:38 
Авторы библиотек бывают разные. Некоторые всё ломают, некоторые - нет. Некоторые некоторое время тянут две версии - старую, до радикальной смены API и новую.

И разработчики бывают разные. Некоторые забивают на развитие библиотек (которые кстати сами выбрали) и стонут по форумам "слоооожно", некоторые не забивают.

Очевидно авторов библиотек, которые делают нехорошо, можно и нужно критиковать. Но ровно то же и про разработчиков. В головной новости даже не критикуют, просто указывают на проблему. И тут уже вой от любителей прибитых гвоздями версий библиотек.  

Ответить | Правка | Наверх | Cообщить модератору

77. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от x3who (?), 27-Июн-21, 12:33 
Ну ладно уязвимости - это ещё фигня, их и пофиксить можно. Но ведь не секрет что многие разработчики до сих пор не проверяют проекты, из которых наследуют функционал, на инклузивность! А что если в разработке по поучаствовало ни одного содомита!? Я понимаю что такое теперь редко встречается, но опасность всё равно пока остаётся. Репозитории должны уделять больше внимания этому вопросу и помечать неинклузивные проекты предостерегающим значком.
Ответить | Правка | Наверх | Cообщить модератору

81. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:37 
Тут еще вот ведь какая опасность: унаследовавшись от master автоматически получаешь white privilege
Ответить | Правка | Наверх | Cообщить модератору

85. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от ыы (?), 27-Июн-21, 12:40 
Вот! Нашелся человек который поставил вопрос остро и по существу! Необходим общедоступный фреймворк от уважаемой компании, который мог бы проводить анализ автоматически и исключать из дерева зависимостей неблагонадежные коды.
И кстати еще не закончена борьба с master, slave и подобным. Репозитории должны блокировать исходный код, инклюзивность которого сомнительна. А те разработчики которые присылают патчи повышающие KPI - должны изгоняться из сообщества, и патчи от них приниматься не должны.


А еще встроенный на этом сайте спелчекер в редакторе не знает слова "инклюзивность". На опасную тропинку вступаете Максим... Ой опасную...

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

102. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Анонимemail (93), 27-Июн-21, 13:03 
> Необходим общедоступный фреймворк от уважаемой компании

У которого тоже есть версии :(

Ответить | Правка | Наверх | Cообщить модератору

105. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от ыы (?), 27-Июн-21, 13:07 
А мы не будем их менять :)
Ответить | Правка | Наверх | Cообщить модератору

110. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Анонимemail (93), 27-Июн-21, 13:11 
Так вот как это делается!
Ответить | Правка | Наверх | Cообщить модератору

117. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Dzen Python (ok), 27-Июн-21, 13:25 
Фу! Это прошлый век. Проверять коды, помечать их....

Нужно сделать полицию инклюзивности. Вот ты выложил свой хеллуворлд в паблик, и к тебе прихал сквад из трех жирных феминисток, гея-п**ора-латиноса, зеленоволосого вонючего ОНО в мешковатой одежде, трех укуренных ниггеров-исламистов, экосектанта-вегана индейца и затравленного белого куколдиста в очочках без права голоса в ошейнике.

И он будет долго и вдумчиво изучать тебя и твой код. А еще дело заведут - как ты посмел, белый умный гетераст написать в одно рыло код аж в три юнита и не привлечь к разработке меньшинства! Почему у тебя в семье нет квот на ниггеров, даунов, жиробасов и инвалидов? Ты что, угнетатель тут дох***я, а? Ты вообще с какой гендерной идентичности, пацанчик? Почему ты тут пердишь и твой углеродный след тут всю планету парниковым эффектом затянул, а? Вообще не по масти живешь тут, черт христианский! А ну быстро отдал нас все свои деньги, мужло!

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

125. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от боня (?), 27-Июн-21, 13:42 
Просто говорите что вы инклюзивно угнетённый, еще больше чем все остальные. Проблем то?
Ответить | Правка | Наверх | Cообщить модератору

159. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от ыы (?), 27-Июн-21, 16:39 
"
- А ты Мариос - ты всегда на стороне девок, ты зло.бучий, подлый, х.есо.ущий верблюдов .бущий нацист-уголовник!
- Во первых - я не принимаю сторону девушек, и во вторых- я совершенно точно не .бу верблюдов
" (С) Освободите Джимми. Гоблин
Ответить | Правка | Наверх | Cообщить модератору

161. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (155), 27-Июн-21, 16:46 
Так у них там русские к цветным приравнены уже, ибо тоже угнетались в этой их Америке не меньше прочих. Так что сиди спокойно, а лучше присоединяйся к описанной тобогй весёлой команде. Заодно недотрах вылечишь.
Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

82. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 27-Июн-21, 12:38 
а все навсего надо не заниматься этой дурью и просто динамически связываться с библиотекой, не встраивая её в проект
Ответить | Правка | Наверх | Cообщить модератору

83. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Анонимemail (93), 27-Июн-21, 12:40 
это как?
Ответить | Правка | Наверх | Cообщить модератору

89. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 27-Июн-21, 12:41 
> это как?

не засовывать исхи библиотеки в свой проект, а просто использовать её системную версию

Ответить | Правка | Наверх | Cообщить модератору

87. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от ip1982 (ok), 27-Июн-21, 12:40 
Как правило, связываются динамически :)
Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

109. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от n00by (ok), 27-Июн-21, 13:11 
Существуют header-only библиотеки.
Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

115. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 27-Июн-21, 13:16 
> Существуют header-only библиотеки.

и? хидеры тоже обычно системные при сборки используются.

бывают конечно случае исключительные, где это обоснованно (видел проект где используются хидеры boost, но не сам boost, там это было обоснованно, чтоб буст в систему не ставить). Однако в основном включение библиотек в код не имеет смысла

хуже всего когда даже опцию при сборе для использования системноой версии не делают

Ответить | Правка | Наверх | Cообщить модератору

127. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 27-Июн-21, 13:44 
>> Существуют header-only библиотеки.
> и? хидеры тоже обычно системные при сборки используются.

Осталось понять, как это обеспечит "просто динамически связываться с библиотекой".

> бывают конечно случае исключительные, где это обоснованно (видел проект где используются
> хидеры boost, но не сам boost, там это было обоснованно, чтоб
> буст в систему не ставить). Однако в основном включение библиотек в
> код не имеет смысла

Буст - это набор библиотек, часть из них header-only. Что-то из них даже принимают в стандартную.

> хуже всего когда даже опцию при сборе для использования системноой версии не
> делают

Не спрашивали разработчиков, почему они так поступают?

Ответить | Правка | Наверх | Cообщить модератору

133. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 27-Июн-21, 13:55 
я имел ввиду использовать системные версии библиотек.

буст в любом случае это один тарбол и собирать его придеться полностью

и зачем писать 2 раза сообщение, есть кнопка "правка"

Ответить | Правка | Наверх | Cообщить модератору

137. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 27-Июн-21, 14:19 
> я имел ввиду использовать системные версии библиотек.

Вы смотрите на вопрос с точки зрения сборки Линукс, Вам так удобнее. У разработчиков свои критерии, и не всегда "удобнее" в приоритете.

> буст в любом случае это один тарбол и собирать его придеться полностью

Не в любом. Можно извлечь только требуемые библиотеки при помощи bcp https://www.boost.org/doc/libs/1_75_0/tools/bcp/doc/html/ind...
Особенно header-only.

> и зачем писать 2 раза сообщение, есть кнопка "правка"

Спасибо, отправил жалобу на первое. Криво его отредактировал.

Ответить | Правка | Наверх | Cообщить модератору

134. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 27-Июн-21, 13:56 
имел ввиду использовать системную версию библиотек
Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

151. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Котофалк (?), 27-Июн-21, 15:41 
Ты всё проспал. Разработчики прибитых гвоздями версий ненавидят системные библиотеки. Им нужна среда, в которой всё как они захотят.
Ответить | Правка | Наверх | Cообщить модератору

162. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (26), 27-Июн-21, 16:51 
И чтобы было меньше вопросов к системным либам пихают многие разработчики свое творчество в снапы, флатпаки, а то и в докеры и почему то случается, что и это не помогает. Кто же все-таки виноват и что делать?
Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

170. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Ordu (ok), 27-Июн-21, 18:20 
Подскажи мне, в какой версии какой системной библиотеки можно найти реализацию perfect hash table? Да такую, чтобы она в качестве ключей принимала бы строку заданную указателем на кусок памяти + длина строки, не полагаясь бы на наличие терминатора \0. И чтобы с C'шным API, без всех этих няшностей сиплюсплюса.

А ещё, что-нибудь маааленькое, C'шное, для парсинга url'ов в подстроки совместимые с perfect hash table выше?

А ещё, да, что-нибудь такое, для генерации выборок случайных чисел, подчиняющихся заданному распределению. Чтобы там было бы распределение Гаусса, распределение Пуассона, может ещё парочку каких. И да, неплохо было бы, если бы оно умело пару десятков статистических методов сравнения выборок. В смысле, вот те стандартные которые включают любой курс статистических методов, типа хи-квадрат, anova, T-вилкоксона, t-Стьюдента, U-манна-уитни, и тп. Желательно при этом, чтобы я тупо туда скармливал семпл за семплом, потом вызывал бы что-то типа finish, и получал бы результат -- значение параметра, p-значимость, и тп.

Ещё было бы неплохо иметь всяких библиотечек для извлечения данных из /proc. Там блин синтаксисы простейшие, но так задалбывает с ними разбираться, обрабатывая на ходу всевозможные ошибки ввода-вывода, что прям ппц. Причём, местами -- это не просто синтаксис, это надо взять открыть директорию, перечислить там все поддиректории с именами определённого вида, залезть в эти поддиректории, найти файлы с определённым именем, распарсить их в соответствии с определённым синтаксисом, и собрать всё это в одну сводную табличку. Ипааать. И это же на фоне того, что любой вызов open или read может вернуть ошибку, которую либо надо заигнорить и повторить операцию, либо вернуть её как ошибку наверх. Начинаешь задумываться, почему бы ядру не освоить sql в качестве языка запросов, да?

Или, скажем, библиотечку для рисования табличек в терминале. В смысле, чтобы не мухой на стекле выёживаться с printf("| %03.7d | %.25s |"... , ох блин, надо ж не фиксированные размеры полей, а подобрать их по содержимому таблички и под ширину терминала... А с переносами по словам в ячейке что делать? Есть ли какие алгоритмы, позволяющие легко и быстро получить достаточно хороший результат в 99% случаев? Ух ты ёкарный бабай, хрен с ними с няшной псевдографикой типа
    ╔═════════════════════════╗
    ║ НЯШНАЯ ПСЕВДОГРАФИКА ║
    ╚═════════════════════════╝

(сорри, не ипу как тут в комментах получить fixed-width шрифт, чтобы действительно няшно вышло, в маркдаун форум не хочет, а все эти bb-коды, насколько я вижу, не работают).

Не, действительно, хрен с ним, и можно ведь и обычными ASCII +-| обойтись. Или даже на них забить, чтобы не создавать себе проблем на несколько вечеров кодинга кряду на няшность, которая не добавляет ни йоту функциональности. Вообще вывести всё в виде записей вида:

row1: value1,
row2: value2,
...
rowN: valueN.

кстати так парсить проще будет, если чо.

Но с другой стороны, можно ведь взять что-нибудь типа [1], что в достаточно простых случаях позволяет получать достаточно хороший результат, а потом просто озаботиться тем, чтобы не создавать слишком сложных случаев? М? Но есть ли что-нибудь такое среди "системных библиотек"?

[1] https://crates.io/crates/term-table

Нет. Среди системных библиотек есть только старпёрство 80 уровня. Никакой няшности. Никаких послаблений. Если библиотека не была предложена в 80-х годах лично Керниганом, то это ересь, а не библиотека. За такие библиотеки надо сжигать на костре. Либо, альтернативы вида "gnome в депендансах". Которые тоже не решают всех проблем, потому что туда тоже не так то и просто включить свою библиотечку, которая няшно рисует таблички в терминале, или реализует H-краскала-уоллеса, делая сомнительные и неоднозначные допущения о том, в каком формате данные будут загружаться туда.

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

173. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 27-Июн-21, 19:04 
системные библиотеки = установленные в систему то есть в /usr/lib или еще куда нибудь

установить туда можно что угодно

Ответить | Правка | Наверх | Cообщить модератору

178. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Ordu (ok), 27-Июн-21, 19:34 
> системные библиотеки = установленные в систему то есть в /usr/lib или еще
> куда нибудь
> установить туда можно что угодно

Хаха. Ты пробовал?

Не, ну ты вот сам подумай. Вот, допустим, ты пишешь софтину, которая не под Debian заточена, не под RedHat, не под Arch и не под Gentoo, ты пишешь софтину, задумывая её как кроссплатформенную промежь unix'ов. И теперь вопрос: как ты будешь при инсталляции своей софтины убеждаться, что в системе уже установлена libsomething-I-need-a-lot.so, причём достаточной версии?

configure? Эмм... ну это в принципе вариант, да. Если твой configure выдаст диагноз системе вида "здесь не установлена libsomething-I-need-a-lot.so.3.12" то это сработает: если человек снизошёл до запуска configure, то можно надеятся, что такое заявление подтолкнёт его у установки something-I-need-a-lot. Гарантировать этого нельзя, но если он не может, то это его проблемы.

A если не configure, то что? pkg-config? Это тоже вариант, но того же уровня.

rpm? apt-get? emerge? pacman? Но они не позволяют описать депенданс, которого нет в репах. В смысле, ты не сможешь проверить свой build/install-скрипт, не занеся предварительно в репы эту библиотеку. Но разработчик этой библиотеки считает, что возня с репами тысячи дистров -- это не та деятельность, которую он готов выполнять в качестве хобби. На самом деле, скорее всего, он не готов даже для одного репа поддерживать пакет: ему, в качестве хобби, интересно писать алгоритмы, реализовывать структуры данных, парсить синтаксисы, сериализовывать данные, но ему не интересно писать шелл-скрипты, под разные версии дистров, которые там что-то сделают. Ему не интересно связываться с бюрократией, которая требует десятка справок в трёх экземплярах, только для включения пакета в репы.

В результате, ты не имеешь никакой библиотеки в репах, которая решит твою проблему. Я поэтому выше и задавал конкретные вопросы, типа "подскажи мне библиотеку, которая делает X". Я надеялся, что это будет хорошо демонстрировать точку зрения. Нет такой библиотеки. И либо ты начинаешь атаковать лбом кирпичную стену, в надежде протолкнуть такую библиотеку в репы, которую можно подключить, либо ты забиваешь на всё это, и включаешь библиотеку в виде сорцов.

Покажи мне как можно установить в систему библиотеку, которая реализует для C строки вида struct {size_t len; size_t *bytes}. Которая реализует url_encode/url_decode. Которая позволяет легко получать выборки из различных распределений вероятностей. Которая позволяет легко форматировать данные в таблички, используя наилучшее возможное представление для терминала. Как это сделать? Так, чтобы часик повозиться единожды, и установить.

Нет такого способа. Linux-дистры не заточены под такое. Они распространяют лишь достаточно "серьёзные" библиотеки, которые достаточно часто используются. Если они попытаются двинутся хоть на полкарасика ниже, если они попытаются предоставлять больше библиотек, то их накроет dll-hell'ом, и мейнтейнеры linux'ов взвоют, и выкинут свои рабочие компьютеры от бессилия. dll-hell -- это фундаментальная проблема, есть разные способы справляться с ней, но ни один из них не является серебряной пулей. Подход linux-дистров не решает её, лишь снижает её влияние: по сравнению с вендой, он (за счёт трудов мейнтейнеров дистра) даёт возможность для ограниченного списка софта и депендансов иметь наилучшее решение проблемы. Всё что выходит за пределы ограниченного списка софта/депендансов, будет решать проблемы dll-hell так, как сможет. Причём дистры не предоставляют _ваабще_никаких_инструментов_ для этого. Программист вынужден костылить свои решения.

Тут могут помочь всякие решения, типа maven, gridle, cargo, npm, gem, pip, ..., но даже с ними возникают ОГРОМНЫЕ проблемы, если их пользовать через apt-get, emerge и тп. В том смысле, что все эти apt-get лишь добавляют больше проблем. Когда я игрался с ruby, я быстро забил на "emerge dev-ruby/something-i-need" и перешёл к использованию gem напрямую, устанавливая всё что нужно в $HOME. Потому что репы больше создают проблем в этом случае, чем решают. Они не могут найти решение для dll-hell в столь мелком разрешении: dll-hell -- это фундаментальная проблема со сложность O(exp(N)), под её решение не хватит никаких вычислительных ресурсов, и никаких человеческих ресурсов.

Самый простой способ для разработчика: оставить эти проблемы "кому-нибудь-ещё". Вот кому будет не лень с ними возиться, кому будет интересно или очень нужно, вот пускай он и возится.

Ответить | Правка | Наверх | Cообщить модератору

182. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 27-Июн-21, 19:50 
configure проверяет либы через pkg-config. Всегда нормально работало это и никаких проблем подобных не было. потом линкеру идет -lsome-lib и он уже решает so.3.12 или so.3.13 и тд

если же ты про бинарники (их распространяют только дистры и виндузятники) то
1. их кстати принято распространять ввиде пакетов для дистрибутивов (а значет зависимости решаются дистрибутивным ПМ)
2. просто сказать что требуются установить определенные библиотеки нельзя
3. ld.so если что сам скажет что какаято либа не найдена


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

Ответить | Правка | Наверх | Cообщить модератору

185. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Ordu (ok), 27-Июн-21, 20:09 
> Ну а если вы используете какието странные васяноподелки которых даже в репах
> дистров нету то в случае бинарников прилинкуйте статически. При нормальной установке
> пользователю не составит труда собрать также и эту зависимость

Дык они и делают именно это: они включают статически, вместе с сорцами.

А насчёт сваливать на потенциального пользователя обязанность скачать сорцы и собрать их, я расскажу тебе байку. [в качестве оправдания] Я был молодой и глупый, я два месяца назад впервые поставил linux, за три дня убил XFree86, пытаясь его отконфигурировать, провёл полтора месяца в ядерной консоле, и смог-таки скомпилять XFree86, до состояния когда у меня запустился xterm. [/в качестве оправдания] И вот я думаю: теперь надо собрать gnome. Я залез на сайт gnome, и там ипааать в рот сколько всяких разных тарболлов. Я скачал все. В смысле, закинул в список закачки, и wget выкачивал метров по сто за ночь, через dialup, который по ночам был по дешёвке ваще -- там были карточки Web-Plus, которые на неделю ночей за какие-то копейки продавались. И вот у меня лежит хренова туча тарболлов, и я такой: а в каком порядке их собирать? Хз, думаю. Я тогда выкрутился посредством создания шелл-скрипта, который брал первый тарболл, распаковывал, пытался собрать, и если это не работало, то брал второй тарболл, пытался собрать... и так далее. И если какой-то тарболл собрался в процессе, то просто убираем его из списка, и начинаем сначала. Именно тогда я возненавидел autootols.

Но я к тому, что тебе видимо не приходилось сталкиваться с ситуацией, когда софтина для сборки требует какого-то очень специфического окружения, и хрен его знает что именно надо. Причём, я отмечу, что мой пример с гномом -- это ещё цветочки, потому что эти примеры чётко знали, что им нужно. В более общей ситуации, программисту сложно понять, что именно нужно его софтине, чтобы собраться. Он может принимать за данность какое-то свойство системы, а оно на самом деле не является данностью в FreeBSD. Или может у него просто установлена библиотека, и он её использует, не замечая того. А может не библиотека, а расположение файлов в etc важно. Или может наличие какого-то файла в /proc (что накладывает ограничения на версию ядра и/или на его конфигурацию). А может быть это работает только в локали en_US.C, и нихрена не работает в локали ru_RU.KOI8-R? А разработчик не замечает, потому что единственная установленная у него локаль -- это en_US.C.

Ответить | Правка | Наверх | Cообщить модератору

187. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 27-Июн-21, 20:18 
обычно на эту тему есть документация. В том случае проблема была совсем в другом, т.к. одна программы была кучей тарболов и ты не нашел документации. Если что https://www.linuxfromscratch.org/blfs/

для пользователя юзающего бинарники лучше всего использовать ПМ дистра

> Дык они и делают именно это: они включают статически, вместе с сорцами.

дык  я про установку в систему для сборки статической версии если ты очень хочешь бины распространять без ПМ. Но опять же - так делают только виндузятники. А обычно либо дистро ПМ либо сорцы

А если ты хочешь дополнительно собрать tar.*z пакет для любого дистра - линкуй системные либы статически или засунь внутрь тарбола динамические. А тут речь идет о включении их  в код и сборки по дефолту вместе с прогой

Ответить | Правка | Наверх | Cообщить модератору

190. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Ordu (ok), 27-Июн-21, 20:30 
Ты сейчас излагаешь точку зрения энд-юзверя. Точку зрения "зделайте так, чтобы мне было хорошо".

> А если ты хочешь дополнительно собрать tar.*z пакет для любого дистра - линкуй системные либы статически или засунь внутрь тарбола динамические. А тут речь идет о включении их  в код и сборки по дефолту вместе с прогой

Естественно: это самый простой способ избежать бюрократии дистромейнтейренов. Подумай как программист, ну вот хотя бы попытайся. Тебе нужна функция, которой нет ни в одной из системных либ. Что делать? Скопипастить её в код со stackoverflow? Проигнорить stackoverflow и написать заново? Или подключить несистемную библиотеку, которая реализует эту функцию?

Ответить | Правка | Наверх | Cообщить модератору

244. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 28-Июн-21, 10:04 
обычно linux разработчики вообще не распространяют бинарники. в конечном итоге - почти все пакеты LFS и большая часть пакетов BLFS встроеных копий либ не имеют и нормально живут. И собственно библиотеки нельзя разделить на "системные и несистемные" - системные = установленные в систему, а туда может быть установлена любая библиотека.

К счастью для большей части либ есть --with-system-somelib и т.д.

> Подумай как программист, ну вот хотя бы попытайся. Тебе нужна функция, которой нет ни в одной из системных либ. Что делать? Скопипастить её в код со stackoverflow? Проигнорить stackoverflow и написать заново? Или подключить несистемную библиотеку, которая реализует эту функцию?

ну я бы скорее всего использовал первый вариант т.к. второй лень, а подключать доп либы когда это не нужно т.к. есть 1 и 2 вариант - так себе

Ответить | Правка | Наверх | Cообщить модератору

247. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Ordu (ok), 28-Июн-21, 11:26 
Вот чего ты мне пытаешься доказать? Что программисты так не делают? Но ведь в новости написано, что они так делают. Ты пытаешься логикой опровергнуть реальность сейчас, или что?

>> Подумай как программист, ну вот хотя бы попытайся. Тебе нужна функция, которой нет ни в одной из системных либ. Что делать? Скопипастить её в код со stackoverflow? Проигнорить stackoverflow и написать заново? Или подключить несистемную библиотеку, которая реализует эту функцию?
> ну я бы скорее всего использовал первый вариант

Это и есть встраивание открытого кода в свой проект. Только хуже, чем с библиотекой, потому что обновлений точно не будет. Не только простых обновлений, которые не ломают совместимость, но и ломающих совместимость обновлений не будет. И на stackoverflow при этом достаточно дырявого кода, эпизодически в новостях всплывает очередной пример. Кроме того, stackoverflow работает только пока функция укладывается в несколько десятков строк. Если тебе нужна, скажем, библиотека для вменяемой работы со строками в C, то это уже сотни строк, и на стековерфлоу не будет такого. Придётся копипастить с github'а. Что уже и есть встраивание открытой библиотеки в свой проект.

Ответить | Правка | Наверх | Cообщить модератору

248. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от макпыф (ok), 28-Июн-21, 11:44 
то что значительная часть проектов отлично без этого обходится.

>  Если тебе нужна, скажем, библиотека для вменяемой работы со строками в C, то это уже сотни строк, и на стековерфлоу не будет такого. Придётся копипастить с github'а. Что уже и есть встраивание открытой библиотеки в свой проект.

В таком случае как раз стоит подключить библиотеку. Ну а ради 10 строк не стоит.

Ответить | Правка | Наверх | Cообщить модератору

250. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Ordu (ok), 28-Июн-21, 12:58 
> то что значительная часть проектов отлично без этого обходится.

Да, очень часто посредством выпиливания лобзиком велосипедов. Или использования не тех алгоритмов, которые подходят лучше, а тем что есть. Скажем, конструкции вида
if(strcmp(s, "hello") == 0)
{ ... }
else if(stdcmp(s, "world") = 0)
{ ... }
else ...

И так пара десятков else-if'ов. Хотя сложив все эти строчки в хештабличку, можно обойтись подсчётом хеша s, и использования этого хеша как индекса в хештабличке, с дальнейшим switch'ом. Но для этого нужна perfect hash-табличка, желательно такая, которая собирается в compile-time. Хрен ты найдёшь такое в репах. Поэтому костыли if-else'ов, или, скажем, libc'овой реализации хеш-таблички (которая вовсе не perfect, и как её собрать в compile-time я даже не представляю). Или велосипеды выпиленные лобзиком ad hoc.

Бывают люди, кто ценит своё время, и понимает что весь код в мире не напишешь сам, но C и C++ в этом смысле очень недружелюбны к тем, кто пытается код заимствовать со стороны и ещё потом отслеживать эти заимствования, обновляя их по возможности. Поэтому таких людей относительно немного.

>>  Если тебе нужна, скажем, библиотека для вменяемой работы со строками в C, то это уже сотни строк, и на стековерфлоу не будет такого. Придётся копипастить с github'а. Что уже и есть встраивание открытой библиотеки в свой проект.
> В таком случае как раз стоит подключить библиотеку. Ну а ради 10
> строк не стоит.

А они не подключают, они включают код библиотеки в код программы. И это работает даже для 10 строк. Ну, в смысле, почти работает. Потому что хоть задумка и хороша (если в этих 10 строках найдётся баг, то на них прилетит багфикс), на практике этот багфикс часто оказывается невостребованным.

Ответить | Правка | Наверх | Cообщить модератору

272. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от n00by (ok), 30-Июн-21, 17:01 
> if(strcmp(s, "hello") == 0)
> { ... }
> else if(stdcmp(s, "world") = 0)
> { ... }
> else ...

+
> И так пара десятков else-if'ов. Хотя сложив все эти строчки в хештабличку,
> можно обойтись подсчётом хеша s, и использования этого хеша как индекса
> в хештабличке, с дальнейшим switch'ом. Но для этого нужна perfect hash-табличка,
> желательно такая, которая собирается в compile-time. Хрен ты найдёшь такое в
> репах. Поэтому костыли if-else'ов, или, скажем, libc'овой реализации хеш-таблички (которая
> вовсе не perfect, и как её собрать в compile-time я даже
> не представляю). Или велосипеды выпиленные лобзиком ad hoc.

Идеальный хеш на этапе трансляции подразумевает, что определено конечное множество строк, верно? Не ясно, зачем тогда при ветвлении оперировать со строками, а не с их индексами в массиве (в какой задаче такое может понадобиться).

Кроме того, else намекает, что s возможно указывает на произвольное значение, значит вероятна коллизия. В таком случае на этапе трансляции следует генерировать пефиксное дерево (оно может оказаться быстрее, поскольку не требует сканирования всей строки). Но если транслятор произведёт подстановку (inline) strcmp() и оптимизирует, то результирующий код окажется гомоморфен поиску по дереву.

Ответить | Правка | К родителю #250 | Наверх | Cообщить модератору

174. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Аноним (26), 27-Июн-21, 19:23 
Надеюсь это не мне написано было, а то для меня тут темный лес.
Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

181. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (26), 27-Июн-21, 19:46 
ldd
Ответить | Правка | Наверх | Cообщить модератору

183. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от макпыф (ok), 27-Июн-21, 19:53 
> Надеюсь это не мне написано было, а то для меня тут темный
> лес.

разуметься тебе, ну кому же еще это может быть написанно. Ведь точно не тому на чье сообщение это ответ

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

188. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (26), 27-Июн-21, 20:25 
В начале не понятно кому, потом было конкретно не мне, но я кажется понял о чем разговор идет и себе же ответил.)
Ответить | Правка | Наверх | Cообщить модератору

194. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от тоже Аноним (ok), 27-Июн-21, 21:52 
>  а все навсего надо не заниматься этой дурью и просто динамически связываться с библиотекой, не встраивая её в проект

Есть у меня программка, собранная под Ubuntu 16.04. Использует системные библиотеки, в т.ч. libpng12.so.
Знаешь, почему она перестала запускаться под Ubuntu 18.04? Да потому, что системная библиотека PNG исправила уязвимости, стала лучше и вообще обновилась. И стала по этому поводу называться libpng16.so.
Всего-навсего.
P.S. Причем, ЧСХ, этой программе были глубоко до пуговицы любые уязвимости в этой библиотеке, потому что НИ ОДНОГО внешнего PNG-файла в программе НИКОГДА не открывается.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

242. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от макпыф (ok), 28-Июн-21, 09:51 
>>  а все навсего надо не заниматься этой дурью и просто динамически связываться с библиотекой, не встраивая её в проект

libpng.so.12 или .16 определяеться во время сборки

и если программа не работает с PNG то зачем ей libpng?

Ответить | Правка | Наверх | Cообщить модератору

243. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от тоже Анонимemail (ok), 28-Июн-21, 10:02 
> libpng.so.12 или .16 определяеться во время сборки

Да, поэтому программу "достаточно" было пересобрать под 18.04. Или тупо создать симлинк на либу, потому что больше никаких проблем у этой программы под обновленной системой не было.

> и если программа не работает с PNG то зачем ей libpng?

Читаем медленно и внимательно: она не работает с PNG, приходящими со стороны. Так что сценарий "злоумышленник прислал специально сформированный файл, эксплуатирующий уязвимость в библиотеке" отсекается, а больше ничем уязвимости в этой библиотеке и не грозят.

Ответить | Правка | Наверх | Cообщить модератору

132. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от commiethebeastie (ok), 27-Июн-21, 13:55 
Даже jquery даёт ссылку на релизы вместо роллинга.
Ответить | Правка | Наверх | Cообщить модератору

140. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Аноним (140), 27-Июн-21, 14:29 
Когда основные доработки библиотек сводятся к имитации бурной деятельности и постоянному ломанию обратной совместипости, потому что "надо выпустить новую версию", встроить и никогда больше не трогать единственная альтернатива варианту написать самому только то, что тебе требуется. А в плане временных затрат, в которых разработчики урезаны до невозможно, потому что пипл требует вчера и со всистелками и на халяву, то и единственная.
Что просили, то и получили. Чё ныть то теперь?
Ответить | Правка | Наверх | Cообщить модератору

142. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Маняним (?), 27-Июн-21, 14:46 
Непонятно о каком софте речь. Для серьёзного софта существуют регрессион тесты. Заменил либвер1.0 на либвер1.1, прогнал регтесты. Прошли тесты заменяешь на новую версию, нет - досвидос. Либо разбираешься где сломалось, если изменения нужные, либо забиваешь. При этом добавить новую  зависимость в такой софт, как кстати и новый регрессион тест - это такой квест, что предпринимается только действительно в обоснованных случаях.

Ну а если они имеют ввиду говнософт от васи пупкина, то там конечно всё так как они описали.

Ответить | Правка | Наверх | Cообщить модератору

152. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Котофалк (?), 27-Июн-21, 15:50 
Есть два варианта развития серьёзного софта. Первый - как ты описал. Второй - как мы встречаем на каждом шагу: всё прибито гвоздями, предложение не прибивать встречается заунывными песнями "а кто будет тестить", "а кто мне за это заплатит" и прочими. Лично у меня велик соблазн сказать "потому что в бывшем они виндузятники, у них так принято", но это неправда. Я видел софт который пишется чистыми виндузятниками, но так, что хочется некоторых привести за ухо и показать, как надо. Ещё приятно видеть когда некая контора, которая пишет опенсорс, на основании багрепортов меняется. Unbundle либ, свитч на другую билд-систему, обновление зависимостей. И никаких визгов "кто будет платить?", "это всё ж надо проверять!".  Ну речь как вы догадываетесь о европейских компаниях. Российские например вообще крайне не любят писать инструмент для себя и выкладывать в опенсорс. Про остальное и речи нет.
Ответить | Правка | Наверх | Cообщить модератору

191. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (189), 27-Июн-21, 20:38 
Ну ты сравнил. Европейцы за деньги пишут.
Ответить | Правка | Наверх | Cообщить модератору

220. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Котофалк (?), 28-Июн-21, 06:12 
> Ну ты сравнил. Европейцы за деньги пишут.

вот это вообще не оправдание в данном случае. напротив - чем больше бюджет на российский софт "для себя", тем меньше шансов его увидеть в опенсорсе. исключений - единицы. Ну типа яндекс с кликхаусом.

Ответить | Правка | Наверх | Cообщить модератору

154. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от НяшМяш (ok), 27-Июн-21, 16:09 
Только вот в жизни наличие или отсутствие регрессионных тестов никак не зависит от серьёзности софта. Может быть ынтырпрайз продукт, который тестируется только вручную обезьянками за еду, а может быть утилита от васи пупкина, который для себя эти тесты написал.
Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

163. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от ыы (?), 27-Июн-21, 16:52 
>нет - досвидос

Первый раз досвидос...
Второй раз досвидос...(хотя могли бы понять что будет как в первый)
А третий раз даже тест запускать ненадо- сразу сообразили ясно что досвидос гарантирован...

А делать то что? Непонятно как это вообще меняет проблему или показывает ее под другим угол? Вы вообще о чем сейчас?

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

143. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +2 +/
Сообщение от Михрютка (ok), 27-Июн-21, 14:53 
>>>без предоставления сведений - устранения уязвимости приходилось ждать 7 и более месяцев.

естебственно.

- У нас дыра в безопасности!
- Ну слава богу, хоть что-то у нас в безопасности...

Ответить | Правка | Наверх | Cообщить модератору

167. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от acroobat (??), 27-Июн-21, 17:56 
Это всё из-за пиратсва. Школьники-то на каникулах.
Ответить | Правка | Наверх | Cообщить модератору

175. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (177), 27-Июн-21, 19:23 
Британские ученые видимо пилили эту статью(((
А ниче что у тех самых пресловутых библиотек нет стабильного API и ни одна нормальная программа не будет рисковать динамически подрубать непротестированную либу?
Ответить | Правка | Наверх | Cообщить модератору

176. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Аноним (177), 27-Июн-21, 19:27 
Для большей наглядности можно привести Qt и его лицензию LGPL для коммерсов, которую те обходят десятой дорогой и покупают лицензию Qt, потому что софтоделам не нужен гемморой с угадыванием, та ли версия Qt что нужно стоит у пользователя и есть ли Qt у юзера вообще
Блджад!
Ответить | Правка | Наверх | Cообщить модератору

184. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (184), 27-Июн-21, 20:04 
>>в 69% случаев уязвимости были устранены в корректирующих выпусках

Т е в 31% случаев программа бы сломалась из-за потери совместимости? Много этих разработчиков либ поддерживают отдельные ветки в плане безопасности?

Ответить | Правка | Наверх | Cообщить модератору

193. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от And (??), 27-Июн-21, 21:15 
Сначала обновляют, а потом ломают, отбирают функционал, не тестируют. Не. Обновления - зло, зло и зло.
Ответить | Правка | Наверх | Cообщить модератору

197. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от anonymous (??), 27-Июн-21, 22:24 
> так как в 69% случаев уязвимости были устранены в корректирующих выпусках, не связанных с изменением функциональности.

Ага. Только уязвимость внесли года три назад и пару мажорных версий. И толку от корректирующих вупысков для новых версий, когда ты всё равно их использовать не можешь.

А если кто и поддерживает старые версии - то только за деньги.

Ответить | Правка | Наверх | Cообщить модератору

203. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (177), 27-Июн-21, 23:56 
69% процентов багфиков не ломают API))) почти половина))) подгружать такое чудо это как монетку подбрасывать повезет не повезет
Ответить | Правка | Наверх | Cообщить модератору

226. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от www2 (??), 28-Июн-21, 07:22 
Для двух библиотек вероятность не сломанного API = 0.69 ^ 2 = 0.48

Для трёх - 0.33, 4 - 0.23, 5 - 0.16, 6 - 0.11, 7 - 0.07, 8 - 0.05, 9 - 0.04, 10 - 0.02...

Ответить | Правка | Наверх | Cообщить модератору

234. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –2 +/
Сообщение от Ыы (?), 28-Июн-21, 09:00 
К чему это казино? Давай считай, какая вероятность сломанного хотя бы одного из двух и более.
Ответить | Правка | Наверх | Cообщить модератору

237. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от ыы (?), 28-Июн-21, 09:33 
Вероятность появления хотя бы одного из событий (А1, А2,…,Аn), независимых в совокупности, равна разности между единицей и произведением вероятностей противоположных событий.

для 2: 1- 0.69*0.69 = 1 - 0.48   = 0.52
для 3: 1- 0.69*0.69*0.69 = 1 - 0.33   = 0.67
для 4: 1- 0.69*0.69*0.69*0.69 = 1 - 0.23   = 0.77
и так далее...

Ответить | Правка | Наверх | Cообщить модератору

217. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от Gogi (??), 28-Июн-21, 03:12 
Чушь всё полная! Бизопасность, бизопазность.... как курица тупая бегает!
Не надо нам внушать мысль, будто мы перманентно должны быть онлайн и мониторить свежие либы.
Есть "релиз" либы - это более-менее проверенное состояние, в котором можно держать либу достаточно долго. Если всё обновлять как параноики, есть риск сломать систему или даже ВНЕСТИ ошибки безопасности.
Не надо впадать в паникёрство и бесконечную "боязнь дыр", просто РАБОТАЙТЕ! Пока вы делаете свою работу, разрабы либы делают свою. Так и движется прогресс.
Ответить | Правка | Наверх | Cообщить модератору

223. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (223), 28-Июн-21, 06:57 
У нас на работе не только нужно ждать разрешения от  юриста и исследования безопастности на внедрение любой версии библиотеки, даже если это просто апдейт. Но они ещё и репозиторий переодически сканят на предмет «заимствования» кода, что постоянно дает фалспазетив. Хотя все равно где-то кто-то умыкнёт куски кода, которые не заметили во время рецензированиях. Связи с чем у нас интернет блочат на работе… чтобы всякие плебы переставали копировать строчки кода  с гитхаб или стаковерфлов
Ответить | Правка | Наверх | Cообщить модератору

230. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (201), 28-Июн-21, 08:33 
Работодателя назовёте?
Ответить | Правка | Наверх | Cообщить модератору

233. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от ыы (?), 28-Июн-21, 08:40 
Обычный нормальный работодатель. Те у кого не так- просто еще не осознали...
Ответить | Правка | Наверх | Cообщить модератору

253. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (223), 28-Июн-21, 14:49 
Honeywell
Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

239. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +1 +/
Сообщение от Аноним (239), 28-Июн-21, 09:38 
Твоя фирма производит велосипеды?
Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

254. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (223), 28-Июн-21, 14:51 
Это в точку… Много велосипедов… плоть до 2017 или 18го был свой компилятор…
Ответить | Правка | Наверх | Cообщить модератору

240. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (239), 28-Июн-21, 09:45 
Вы пишите уникальные строчки кода которые не могут никогда нигде и никак походить на другие. И алгоритмы придумываете новые уникальные нигде не повторяемые.
А вы там выкалываете глаза и в лагерях содержите людей чтобы дизайн не своровали?
Менеджерам руки отрубают за воровство идей бизнеса.
Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

255. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (223), 28-Июн-21, 15:01 
Нет, раз в пару месяцев заводят одну и туже пластинку про «заимствование» кода из других источников, на что отвечаем  это сложившиеся общепринятая практика или общий алгоритм… для обработки сигналов используется куча всяких функций которые построены на преобразование фурье… там уже мало что уникального напишешь… но начальству с образованием юриста или инженера из другой области это не очень в голове укладывается
Ответить | Правка | Наверх | Cообщить модератору

238. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от Аноним (239), 28-Июн-21, 09:36 
Надо C++ проверить на совместимость со старыми библиотеками и удалить все новые не совместимые со старыми
Ответить | Правка | Наверх | Cообщить модератору

245. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +/
Сообщение от InuYasha (??), 28-Июн-21, 10:32 
"Линкуй статически" - говорили они.
"Поставляй флатпаки" - говорили они.
И я их не слушал.
И где их советы сейчас? )
Ответить | Правка | Наверх | Cообщить модератору

251. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от n00by (ok), 28-Июн-21, 13:02 
$ ./AoW3Launcher
./AoW3Launcher: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

Зато через Proton -- работает!

Ответить | Правка | Наверх | Cообщить модератору

256. "79% встроенных в код сторонних библиотек никогда не обновляю..."  +3 +/
Сообщение от Аноним (256), 28-Июн-21, 16:49 
Ну так это изветная виндузятская болезнь. Ну теперь ещё и всех этих флатошлаков.
Ответить | Правка | Наверх | Cообщить модератору

269. "79% встроенных в код сторонних библиотек никогда не обновляю..."  –1 +/
Сообщение от adolfus (ok), 30-Июн-21, 01:08 
> Компания Veracode опубликовала результаты исследования проблем с
> безопасностью, вызванных встраиванием открытых библиотек в приложения
> (вместо динамического связывания многие компании просто копируют в
> состав своих проектов нужные библиотеки).

Что они имеют ввиду? Cтатическое связывание или использование библиотек в виде исходного кода? А ведь эти два способа позволяют сократить размер загружаемого кода, а второй -- обаспечиитть глобальную оптимизацию и вынос инвариантов из циклов.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру