Здравствуйте, Sheridan, Вы писали:
P>>А такого в нормальных проектах я не встречал. S>Ты конечно крут, но создаётся впечатление что тебе удалось каким то чудом работать исключительно в тепличных условиях.
Ты это называешь чудом. Мы это называем хорошей работой. Наш код работает в production. А условия production далеки от тепличных.
Кстати интересно, с помощью каких умозаключений ты пришел к выводу о тепличных условиях, исходя из факта неприменения нами open source без документации.
S>Учу читать. Дорого.
S>А вот когда нет документации — тогда либо лапу сосать, либо исходники читать. S>Предпочитаю исходники.
Ты на второй круг пошел? Я писал: голые исходники без документации практически бесполезны. Иди учись читать.
S>Не, ты не понял. Не "как написать чтобы заработало", а "как именно оно работает. Как реализовано и что происходит."
Именно это и выясняется написанием примеров и тестов. Чтение исходников — крайний случай.
S>Работал. Всем вышеописанным рулит заказчик, разговаривая с манагером. А манагер потом разговаривает с тобой. И хоть вывернись наизнанку — "я уже договорился с заказчиком, тебе придётся сделать так как я говорю".
И эта твоя фраза говорит, что не работал. Я не про этих, как ты говоришь, манагеров. Такое встречается в небольших проектах. Я о другом. А нормальных проектах график известен разработчикам. В непредвиденных случаях они извещают свое непосредственное начальство, дальше начинается разбор. Мы нарвались однажды на веселую штуку: из БД возвращались только первые 4000 байт строковых данных. Деталей не помню, и это неважно. Оказалось, баг подтвержден и надо обновить некий драйвер. Для нас такое поведение было полной неожиданностью. И толку мне тут с open source драйвера без документации?
S>Так как?
Учу читать. Дорого. Я писал раньше, как. Повторять не буду. Отключи бота, потом возвращайся. Оставлю цитату из себя ниже. Попробуй осилить. Но выключи бота.
S>>>И как ты к этому относишся? Опенсорц всё еще плохой?
P>>Он не плохой и не хороший. Он существует. Он — реальность, данная нам в ощущениях. Кстати, напомни, где я писал про плохой open source? С цитатами и ссылками. Или снова про гиперболы загнешь?
S>Ну тогда пиши понятнее. А то пока что из твоих слов можно понять только то, что опенсорц — не для людей и брать его нужно только от безысходности. Клозет сорц рулит, можно писать в техподдержку, спихивая на них проблемы.
Объясни логическую цепочку. Я пока вижу L — лоГика. Да, и на вопрос ответь, который я там же задал. Ну про плохой open source.
P>>Давай тогда сразу про гиперболический параболоид. S>С Гариным не знаком.
Я тоже не знаком. а кто это и причем он здесь? Он впервые построил гиперболический параболоид?
S>Всмысле "бросил писать"? Оно пару лет отработало в проде, возможно и сейчас работает, я хз, ущел оттуда.
То есть что, работал в соответствии с техзаданнем, по календарному плану? Успел к deadline в срок?
S>Впрочем вряд ли работает, тамошний контингент предпочитает таски по телефону ставить. Почта? Что это? Скайп? долго. Заткнись и записывай что надо сделать.
Лично я предпочитаю Интернет. Телефон — резервный вариант. Сервисные центры, кстати, сейчас чаты на своих сайтах делают. Очень удобно. И ждать меньше, чем по телефону.
Здравствуйте, Mamut, Вы писали:
M> AB>Ты вменяемый человек, ты не можешь не признать, что в приведенном фрагменте как минимум 2 очень серьезных проблемы. А виноватым окажется потом конечно же Linux, а не те идиоты, которые так делали. M> Я знаю, что такой способ потенциально опасен.
И понимая риски считаешь его использование нормальным/приемлемым?
M> AB>Такой способ установки появился из за лени обыкновенной и культа "я dev-ops як-як-продакшин". M> Лень — двигатель прогресса. Такой способ появился по той же причине, по которой появились nvm'ы и pyenv'ы.
Прогресс двигает лень, но не любая лень двигает прогресс. Здесь вторая.
Здравствуйте, Sheridan, Вы писали:
S>Только после того как ты расскажешь как ты смог придумать такую юзерстори в контексте "у нас тут есть продукт со своими исходниками, надо разобраться как работает некая его часть".
Но сначала тебе придется объяснить, где ты откопал такой контекст.
S>Если есть мониторинг и логи — брать их и читать.
Я ведь задал совершенно конкретный use case. В ответ на твое предложение использовать cout. А ты опять сочинять начал. Gentoo в больших дозах вреден для здоровья.
AB>И понимая риски считаешь его использование нормальным/приемлемым?
В определенных ситуациях — да.
M>> AB>Такой способ установки появился из за лени обыкновенной и культа "я dev-ops як-як-продакшин". M>> Лень — двигатель прогресса. Такой способ появился по той же причине, по которой появились nvm'ы и pyenv'ы.
AB>Прогресс двигает лень, но не любая лень двигает прогресс. Здесь вторая.
Здравствуйте, Mamut, Вы писали:
M>Когда 60-80% поправок в ядро Линукса приходит от корпораций, это не называется «помогать». Это называется «разрабатывать». А вот «сообщество» именно и делает, что помогает разрабатывать. Более того, это пресловутое сообщество не способно обеспечить даже прожиточный минимум людям, которые не работают на корпорации, а занимаются разработкой опенсорса индивидуально.
У тебя очень хорошо получается мечтать
Здравствуйте, Privalov, Вы писали:
P>>>А такого в нормальных проектах я не встречал. S>>Ты конечно крут, но создаётся впечатление что тебе удалось каким то чудом работать исключительно в тепличных условиях. P>Ты это называешь чудом. Мы это называем хорошей работой. Наш код работает в production. А условия production далеки от тепличных. P>Кстати интересно, с помощью каких умозаключений ты пришел к выводу о тепличных условиях, исходя из факта неприменения нами open source без документации.
Нет, исходя твоих слов можно сделать вывод что у вас всегда документация есть, сроки соблюдаются, заказчики согласны на озвученные сроки за озвученные деньги, разработчики зависимостей всегда в кратчайшие сроки выполняют таски и так далее.
S>>Учу читать. Дорого. S>>А вот когда нет документации — тогда либо лапу сосать, либо исходники читать. S>>Предпочитаю исходники. P>Ты на второй круг пошел? Я писал: голые исходники без документации практически бесполезны. Иди учись читать.
То есть ты предпочтёшь лапу сосать?
S>>Не, ты не понял. Не "как написать чтобы заработало", а "как именно оно работает. Как реализовано и что происходит." P>Именно это и выясняется написанием примеров и тестов. Чтение исходников — крайний случай.
Сначала читаем, потом пишем.
S>>Работал. Всем вышеописанным рулит заказчик, разговаривая с манагером. А манагер потом разговаривает с тобой. И хоть вывернись наизнанку — "я уже договорился с заказчиком, тебе придётся сделать так как я говорю". P>И эта твоя фраза говорит, что не работал. Я не про этих, как ты говоришь, манагеров. Такое встречается в небольших проектах.
Ну хз. Один проект где я так участвовал помогает медикам рак выяснять, второй почти в каждом городе запущен и хитро синхронизирует гигабайты контента.
P>Я о другом. А нормальных проектах график известен разработчикам. В непредвиденных случаях они извещают свое непосредственное начальство, дальше начинается разбор. Мы нарвались однажды на веселую штуку: из БД возвращались только первые 4000 байт строковых данных. Деталей не помню, и это неважно. Оказалось, баг подтвержден и надо обновить некий драйвер. Для нас такое поведение было полной неожиданностью. И толку мне тут с open source драйвера без документации?
Как выясняли?
P>Объясни логическую цепочку. Я пока вижу L — лоГика. Да, и на вопрос ответь, который я там же задал. Ну про плохой open source.
Я уже неоднократно отвечал. У тебя пренебрежительное отношение к опенсорцу. Это видно без очков даже.
S>>Всмысле "бросил писать"? Оно пару лет отработало в проде, возможно и сейчас работает, я хз, ущел оттуда. P>То есть что, работал в соответствии с техзаданнем, по календарному плану? Успел к deadline в срок?
да
Здравствуйте, Privalov, Вы писали:
S>>Только после того как ты расскажешь как ты смог придумать такую юзерстори в контексте "у нас тут есть продукт со своими исходниками, надо разобраться как работает некая его часть". P>Но сначала тебе придется объяснить, где ты откопал такой контекст.
Можешь начать читать отсюда: https://rsdn.org/forum/flame.comp/7524897.1
Ни в одном из моих сообщений данного подтреда нет упоминания никаких третьих лиц у которых крутится какойтотам код
S>>Если есть мониторинг и логи — брать их и читать. P>Я ведь задал совершенно конкретный use case. В ответ на твое предложение использовать cout. А ты опять сочинять начал. Gentoo в больших дозах вреден для здоровья.
Потому что почему нет?
Не могу понять, чем тебе так не нравится использование cout в ситуации "что у нас тут происходит"?
А, ну да, ты ж в "нормальной конторе" с "хорошей командой" привык работать. То есть два дня на изучение, неделю на написание специального логгера, три дня на встраивание, сутки на сбор логов и две недели на их изучение.
Или нет? Если нет, то в чём проблема? Больше придрацца не к чему?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
M>>Когда 60-80% поправок в ядро Линукса приходит от корпораций, это не называется «помогать». Это называется «разрабатывать». А вот «сообщество» именно и делает, что помогает разрабатывать. Более того, это пресловутое сообщество не способно обеспечить даже прожиточный минимум людям, которые не работают на корпорации, а занимаются разработкой опенсорса индивидуально. S>У тебя очень хорошо получается мечтать
Since the beginning of the git era
(the 2.6.11 release in 2005), a
total of 15,637 developers have contributed to the Linux kernel; those
developers worked for a minimum of 1,513 companies.
...
Top companies
contributing to the Linux
kernel, 4.8– 4.13
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Privalov, Вы писали:
S>Не могу понять, чем тебе так не нравится использование cout в ситуации "что у нас тут происходит"? S>А, ну да, ты ж в "нормальной конторе" с "хорошей командой" привык работать. То есть два дня на изучение, неделю на написание специального логгера, три дня на встраивание, сутки на сбор логов и две недели на их изучение. S>Или нет? Если нет, то в чём проблема? Больше придрацца не к чему?
Вероятность появления ситуация, когда надо понять, "что у нас тут происходит", всегда больше нуля. Поэтому, о логировании или других средствах диагностики поведения программы на этапе эксплуатации, стоит подумать заранее и использовать их с начала разработки проекта.
Здравствуйте, Ops, Вы писали:
C>>Ну а что сделать, если (официальный!) драйвер NVidia в репозитории и обновляется в тот же день, что и на сайте NVidia? Ops>Это где так? Разве что в arch, возможно, но у него свои тараканы, которые нивелируют все плюсы свежих пакетов.
RedHat/CentOS, о котором тут шла речь. 100500 разных компаний, которые занимаются AI, используют NVidia для расчётов на GPU. Так что есть потребность в нормальной поддержке.
Здравствуйте, Sheridan, Вы писали:
P>>Кстати интересно, с помощью каких умозаключений ты пришел к выводу о тепличных условиях, исходя из факта неприменения нами open source без документации. S>Нет, исходя твоих слов можно сделать вывод что у вас всегда документация есть, сроки соблюдаются, заказчики согласны на озвученные сроки за озвученные деньги, разработчики зависимостей всегда в кратчайшие сроки выполняют таски и так далее.
Документация есть. Возможно, для некоторых однофайловых скриптов ее нет. Но сисадмины заказчика в курсе, что это такое. Они получили инструкции, что это и зачем нужно.
Сроки — это, как всегда. Бывает всякое. Реальность — штука суровая, иногда подбрасывает сюрпризы. Но мы справляемся.
Заказчик обычно согласен за озвученные деньги на озвученные сроки. Консенсус достигается в результате переговоров, иногда жарких. Как и везде. Таски выполняются не в кратчайшие сроки, а в заданные. По степерт важности и срочности.
S>То есть ты предпочтёшь лапу сосать?
Читай ветку. Я четко озвучил предпочтения. Если не умеешь читать, признайся. Впрочем, оно и так заметно.
S>Сначала читаем, потом пишем.
Для написания примера использования нужно читать исходник? А зачем? Достаточно в доке посмотреть, что функция принимает и что возвращает. Как результат, у меня получается нормально использовать и закрытые библиотеки. А вот что ты делать будешь, если в открытой библиотеке нужного функционала нет, а выбор простой: использовать закрытую библиотеку или писать самому. И, разумеется, сроки и бюджет влияют.
S>Ну хз. Один проект где я так участвовал помогает медикам рак выяснять, второй почти в каждом городе запущен и хитро синхронизирует гигабайты контента.
В качестве кого работал? Я, можно сказать, тоже участвовал в нескольких немаленьких проектах. Но если копнуть, в одном случае я просто где-то куда-то сетевые кабели подсоединил. Буквально пару дней там покрутился. А в другом несколько сервисов сделал да еще самопальный протокол поверх TCP/IP сочинил. Так что участие — понятие весьма растяжимое.
S>Как выясняли?
Тестами, разумеется. Есть другой способ?
S>Я уже неоднократно отвечал. У тебя пренебрежительное отношение к опенсорцу. Это видно без очков даже.
Тебя уже неоднократно тыкали в этот твой ответ.
P>>То есть что, работал в соответствии с техзаданнем, по календарному плану? Успел к deadline в срок? S>да
Здравствуйте, Sheridan, Вы писали:
M>>Кхм, но это тоже не так. К примеру кряки пишут и без исходников S>Не такая большая проблема для опытного человека — найти место "проверить_ключ_лицензии и если ок — продолжить" и поменять сразу на "продолжить". IDA творит чудеса в опытных руках.
S>Тоже не такая большая проблема — поснимать хеши с участков кода и сравнить их с хешами вирусов из БД плюс определить набор признаков, по которым можно предположить наличие в коде деструктивных частей.
Так вот кто шароварщикам и тем, кто проверяет лицензию, спать спокойно не дает! Вот, оказывается, кто пачками проверки лицензий отключает и крякнутый софт на торренты и варезники выкладывает!
Я, помнится, зачем-то заменил версию 2.08 своего любимого текстового редактора qEdit на 4.0. А в ней два экрана рекламы при запуске показывалось. Я эту рекламу отключил. И не скажу, что жто было так уж тривиально. В конечном итоге поправил в бинарнике только пару команд, но там ни хитрого шифрования, ни хэшей, ни противоотладочных приемов не было. Просто хорошо оптимизированный код.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Privalov, Вы писали:
P>>>>Про "полчаса на архитектуру" озвучил ты, а не я. При этом ты ссылаешься на свой опыт. S>>>Да, именно так. За полчаса многое можно понять и даже что нибудь сделать. P>>Здесь ты тоже ссылаешься на свой опыт? Тогда вопрос, как мне кажется, вполне логичный. Архитектуру каких софтин ты изучил за полчаса? S>Мне их поимённо надо помнить? Я во многих лазил. От ядра до прикладнух. Гдето понять как именно опция применяется, гдето чтото поправить или отрезать временно. В кутэ ковырялся, в компизе, в иксах, в постгресе, в mc, в ceph, в urho3d... Это вот из того что вспомнил пока писал список этот. По работе ковырялся в коде у клиентов, дописывал, переписывал... S>Опять же, про "изучение" я не говорил, я писал
что архитектура становится понятной. А между "понять" и "изучить" пропасть может быть длинной в жизнь. S>Опять же, ради чего это всё делается тоже надо принимать во внимание. Давеча я вон писал про ковыряния в постгресе. Я не изучал постгрес изнутри при этом, зачем оно мне? Я быстро пробежался по исходникам, понял куда мне надо расставить вывод логов и что в эти логи вывести. Расставил, скомпилил, поднял, почитал, понял куда дальше идти, удалил.
Это никакая не архитектура Так работают ДевОпсы — быстрый набег с гиком и свистом, размахивание томагавками, и такой же быстрый уход со сцены. Вывод логов сделан девелоперами постгреса так, что бы ты мог разобраться за полчаса без знакомства с архитектурой.
M>>Когда 60-80% поправок в ядро Линукса приходит от корпораций, это не называется «помогать». Это называется «разрабатывать». А вот «сообщество» именно и делает, что помогает разрабатывать. Более того, это пресловутое сообщество не способно обеспечить даже прожиточный минимум людям, которые не работают на корпорации, а занимаются разработкой опенсорса индивидуально. S>У тебя очень хорошо получается мечтать
Я тебе даже статистику кернела привел. Но у тебя это называется «мечтать».
Это относится к любому опенсорсу вообще. Крупный опенсорс разрабатывается почти исключительно компаниями. Потому что мифическое «сообщество» неспособно поддержать разработку ничего сложнее, чем "hello, world".
Чувак взял самые популярные проекты на OpenCollective, данные по донатам и количество full-time contributors в проектах. Ты ж посмотри, больше половины проектов не обеспечивают даже прожиточный минимум: https://staltz.com/software-below-the-poverty-line.html
Здравствуйте, Privalov, Вы писали:
S>>Тоже не такая большая проблема — поснимать хеши с участков кода и сравнить их с хешами вирусов из БД плюс определить набор признаков, по которым можно предположить наличие в коде деструктивных частей. P>Так вот кто шароварщикам и тем, кто проверяет лицензию, спать спокойно не дает! Вот, оказывается, кто пачками проверки лицензий отключает и крякнутый софт на торренты и варезники выкладывает!
Про полиморфные вирусы только не рассказывай ему
А то он придёт со своими знаниями из 90-х к Касперскому и тем придётся весь код для поведенческого анализа (или как у них маркетологи это назвали) выкинуть на помоечку...
Здравствуйте, AleksandrN, Вы писали:
AN>Сумма этих процентов от общего числа изменений, без учёта строк none, unknown и consultants — 63,5.
Каждый из участников хорошо помогают сообществу, часть которого является.
Здравствуйте, AleksandrN, Вы писали:
AN>Вероятность появления ситуация, когда надо понять, "что у нас тут происходит", всегда больше нуля. Поэтому, о логировании или других средствах диагностики поведения программы на этапе эксплуатации, стоит подумать заранее и использовать их с начала разработки проекта.
Всё верно. Но так же ситуация когда нужно разобраться в коде другого человека тоже больше нуля.
P>>>Кстати интересно, с помощью каких умозаключений ты пришел к выводу о тепличных условиях, исходя из факта неприменения нами open source без документации. S>>Нет, исходя твоих слов можно сделать вывод что у вас всегда документация есть, сроки соблюдаются, заказчики согласны на озвученные сроки за озвученные деньги, разработчики зависимостей всегда в кратчайшие сроки выполняют таски и так далее.
P>Документация есть. Возможно, для некоторых однофайловых скриптов ее нет. Но сисадмины заказчика в курсе, что это такое. Они получили инструкции, что это и зачем нужно.
Говорил — же: какие то ванильные условия. Мне почти всегда прилетали таски типа "вот древний легаси код без документации, его надо дописать"
P>Сроки — это, как всегда. Бывает всякое. Реальность — штука суровая, иногда подбрасывает сюрпризы. Но мы справляемся.
Ну и я справляюсь
P>Заказчик обычно согласен за озвученные деньги на озвученные сроки. Консенсус достигается в результате переговоров, иногда жарких. Как и везде.
У вас наверное манагер — бывший программист или инженеров приглашают к обсуждению.
P>Таски выполняются не в кратчайшие сроки, а в заданные. По степерт важности и срочности.
И никогда не бывает "всё бросай, надо срочно вот это допилить!11"?
P>Для написания примера использования нужно читать исходник? А зачем? Достаточно в доке посмотреть, что функция принимает и что возвращает.
Ванильные условия, да. У меня доков к исходникам было чуть менее, чем никогда.
P>А вот что ты делать будешь, если в открытой библиотеке нужного функционала нет, а выбор простой: использовать закрытую библиотеку или писать самому. И, разумеется, сроки и бюджет влияют.
Дописать самому, конечно.
S>>Ну хз. Один проект где я так участвовал помогает медикам рак выяснять, второй почти в каждом городе запущен и хитро синхронизирует гигабайты контента. P>В качестве кого работал?
Программист, девапс. В вышеописанных проектах — единственный из команды на проекте.
S>>Как выясняли? P>Тестами, разумеется. Есть другой способ?
Тесты куда/как писали?
Такой способ появился по той же причине, по которой появились nvm'ы и pyenv'ы.
И не скажу, что жто было так уж тривиально. В конечном итоге поправил в бинарнике только пару команд, но там ни хитрого шифрования, ни хэшей, ни противоотладочных приемов не было. Просто хорошо оптимизированный код.
