git начинает ржаветь

По делу давай, не отвлекайся.

Пригорело когда в мяконькое тыкнули, правда про твою секту не нравится? Так сиди тихонько в уголочке и дымись. А варежку разевать на тех, кто ваше обосранное исподнее всем демонстрирует - не стоит.

Какой процент из тех, кто топит за раст вообще знают о существовании Cargo.lock? Ну же, скажи - 0.01%? Меньше?

Нормальное развитие событий, когда софтина требует bar v1.16 - меинтейнер софтины обращается к меинтейнеру bar на предмет апгрейда оного в дистре. И уже меинтейнер bar, который много лет знает bar как свои пять пальцев производит аудит нового кода bar и апает версию. Чётко понятно кто отвечает за софтину, кто за bar, и кого бить ссаными тряпками если что-то пошло не так.

В случае rust, такого в принципе быть не может. Меинтейнер растовой софтины, слепо веря в байку про «защищённость раста» будет в самом лучшем случае читать чейнжлог bar, даже не пытаясь посмотреть что там на самом деле в этом bar поменяли. А зачем - rust же такой защищённый. И в любом случае, даже если каким-то чудом он решит поковыряться в новом bar, не будучи спецом по этому bar - то откуда он этот новый bar возьмёт? Правильно, с crates.io. А кто контролирует crates.io? А неизвестно.

Что, люборасты, пригорает, когда вас за шкирку и мордой в ваше дерьмо тыкают?

rust - это такое NGO/секта в мире программирования, целью которой является установление контроля над кодом свободного ПО через ублюдочную систему сборки завязанную на crates.io который контролируется неизвестно кем.

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

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

И именно поэтому rust, как религия совершенно недопустим в сввободном ПО.

Rust в целом - это как раз квинтэссенция худших кошмаров Столлмана, о которых даже он побоялся рассказать. Хардкорная экранизация «права читать» с кровью, кишками и человеческими жертвоприношениями.

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

Я скорее о том, что в системе сборки языка, приверженцы которого злоупотребляют понятием безопасность, по-умолчанию нет запрета на использование загруженных бинарников (с добавлением опции --allow-downloaded-binaries для каких-то временных особо тяжёлых случаев). Вот прям как borrow checker не даёт прохода (даже для очевидно валидного кода), так и от cargo я ожидал, что никаких загруженных бинарей, всё собирается исключительно из исходников (и объектников собранных ранее).

Я скорее о том, что в системе сборки языка, приверженцы которого злоупотребляют понятием безопасность, по-умолчанию нет запрета на использование загруженных бинарников (с добавлением опции –allow-downloaded-binaries для каких-то временных особо тяжёлых случаев). Вот прям как borrow checker не даёт прохода (даже для очевидно валидного кода), так и от cargo я ожидал, что никаких загруженных бинарей, всё собирается исключительно из исходников (и объектников собранных ранее).

Если ты не читал код, то какая разница, бинарь там или нет? Изменение, кстати, завернули.

Пригорело когда в мяконькое тыкнули, правда про твою секту не нравится? Так сиди тихонько в уголочке и дымись. А варежку разевать на тех, кто ваше обосранное исподнее всем демонстрирует - не стоит.

Не нервничай ты так.

Какой процент из тех, кто топит за раст вообще знают о существовании Cargo.lock? Ну же, скажи - 0.01%? Меньше?

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

Нормальное развитие событий, когда софтина требует bar v1.16 - меинтейнер софтины обращается к меинтейнеру bar на предмет апгрейда оного в дистре.

Зависит от дистра, часто просто бампают пакет и говорят «можна запушу?».

И уже меинтейнер bar, который много лет знает bar как свои пять пальцев производит аудит нового кода bar и апает версию.

Ахахаха. Что? Ты серьезно? Проводит аудит? Вылезай из мира чудесных поней. Чаще всего мейнтейнер:

1. Читает changelog
2. Прогоняет тесты (дай бог)
3. Молится

В случае rust, такого в принципе быть не может. Меинтейнер растовой софтины, слепо веря в байку про «защищённость раста» будет в самом лучшем случае читать чейнжлог bar, даже не пытаясь посмотреть что там на самом деле в этом bar поменяли.

Как и любой другой мейнтейнер. Они не проводят аудит кода, лол.

А зачем - rust же такой защищённый. И в любом случае, даже если каким-то чудом он решит поковыряться в новом bar, не будучи спецом по этому bar - то откуда он этот новый bar возьмёт?

Правильно, с crates.io.

Неправильно. Он возьмет его из гита проекта.

А кто контролирует crates.io? А неизвестно.

Кто контролиует GitHub? Коварные масоны поменяли код в зависимости!

Что, люборасты, пригорает, когда вас за шкирку и мордой в ваше дерьмо тыкают?

У тебя какая-то фиксация на говне, ты не замечал?

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

Если бы мы только могли проверить в одну строку то, что мы скачали с crates.io… А, ну да, мы можем.

Debian - это такое NGO/секта в мире программирования, целью которой является установление контроля над кодом свободного ПО через ублюдочную систему сборки завязанную на ftp.debian.org который контролируется неизвестно кем.

Починил. Не благодари.

Кстати, в отличие от Rust, за Debian есть история по запихиванию бэкдоров в код. Например, в OpenSSL:

https://freedom-to-tinker.com/2013/09/20/software-transparency-debian-openssl-bug/

segmentation fault, memory cannot be read и buffer overflow

Это говорит о криворукости современных погромиздов.

segmentation fault, memory cannot be read и buffer overflow

Это говорит о криворукости современных погромиздов.

Да, причём начиная с тех кто C придумал.

Это говорит о криворукости современных погромиздов.

Я как-то просил сишников показал мне проект сложнее хеллоуворлда без ошибок памяти в git log, и почему-то никто не смог.

Покажи мне его в ГИТЕ бжлад

Да ради бога:

https://github.com/search?q=repo%3Agit%2Fgit+segmentation+fault&type=commits

В целом было бы неплохо иметь альтернативную реализацию полностью на rust. Это бы позволило сделать, например, настоящий windows порт вместо того, что есть сейчас. Но mixed код с теми же зависимостями + rust точно никому лучше не сделает.
У mixed роектов есть ещё один большой минус - код на rust не всегда удобен для разработчиков остальной части проекта, как и наоборот - rust разработчику часто сложно работать с c++
Такое приводит к фрагментации в проекте, написанию дублирующих друг друга костылей. Смешанный код ещё заставит использовать unsafe блоки, с которыми не так то просто работать, ведь оптимизатор никуда не девается, а rustc в отличие от gcc не попытается раскрыть то или иное UB уже в какое-то привычное поведение.
По этой же причине мне не очень нравится добавление инструментария на rust в ядро, хотя если это позволит искоренить постоянные упсы и дедлоки, а ядерный код будет поддерживаться не одним лишь rustc - то я конечно за.

Таймаут. У нас похоже гитхаб теперь без sni не работает - ркн не дремлет

70 упоминаний только segmentation fault. Ещё полторы сотни off-by-one, 50 use after free и скорее всего столько же коммитов, где это формулируется другими словами :)

И все это в однопоточном проекте, лол.

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

https://github.com/Byron/gitoxide

Не думал, что всё так страшно…

Это C.

Меня бесит что современные CLI светятся как новогодняя елка.

И?

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

Куча багов у управлении памяти – это нормально.

Ни разу не слышал, что были какие-то проблемы в git с меморисейфти, что прям бизнесы страдали, не говоря о фор фан проектах.

Могу тоже самое предложить антифанатам сишки

Так они берут и вливаются. А ты бугуртишь вот.

Был бы прок. Пока не видно

Драйвер GPU для Apple Silicon (который, по словам его автора, был написан в рекордные сроки благодаря расту) ты предпочитаешь старательно не замечать?

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

Поэтому за COBOL я спокоен: ни одна транзакция растоманов не пройдет без его участия.

А чего мне ещё делать то :) Я подначиваю.

Ладно, так и быть. Поверю на слово. Каюсь.

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

Поэтому за COBOL я спокоен

Я почти уверен что COBOL в банках переживет даже меня.

Нет, просто кто-то взяв удочку поймал на крючёк не рыбу, а свой зад. Не все умеют пользоваться удочкой…

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

вот да, и что характерно, быстрее сишного git-а https://github.com/Byron/gitoxide/discussions/349, и в этом, похоже, и есть реальная причина какого-то нездорового антирастового психоза, единственная причина сишного пердолинга - якобы её непровзойдённая скорость (хотя за тем же фортраном сишка десятилетиями пыль глотала), не имеет никакого смысла

и что характерно, быстрее сишного git-а

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

anonymous-angler, ты своё лицо под моим комментарием обронил, подбери. (=

Это говорит о том, что ты дружишь с плохими сишниками. =P

Это говорит о том, что ты дружишь с плохими сишниками. =P

Это не мои друзья, это клоуны с LOR и некоторых других мест. Я не дружу с сишниками.

клоуны с LOR

Аа, ну ты нашёл где спрашивать… (%

Аа, ну ты нашёл где спрашивать… (%

На самом деле это показательно. Если мне за три года не смогли принести проект на C без проблем с памятью, значит это настолько редкая штука, что тезис «на C невозможно писать без ошибок с памятью без титанических усилий» – верный. И это вполне себе оправдывает существование альтернатив.

«Все настоящие ирландцы пьют виски»

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

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

чойта? LTO давно принесли. Если линковаться статикой, то там да, есть нюансы.

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

не смогли принести проект на C без проблем с памятью

Просто у них тесты как у Intel'а: https://lore.kernel.org/dri-devel/CAHk-=wgPJttFz8yrdpPTN-ypMmDXHOKw9yi1nZSEq ... .

(По ссылке простыня ругани Линуса Торвальдся на тот код, который присылает Intel)

Ну вот например.
https://hub.mos.ru/mittorn/http-folder-uploader/-/tree/master
(Нет аллокатора - нет проблем)

Если я её правильно помню - там мейнтейнеры той ещё хернёй маялись.

настоящий windows порт

Ненужно

На самом деле это показательно.

Опрос среди школьников, лжецов и прочих клоунов — показателен? xD

Ты ещё студентов опроси. xD Педагогического! xD

Иии… у тебя off-by-one, когда received + res = len:

int res = read(fd, &buf[received], len - received);
		if( res >= 0)
		{
			char *headend;
			int he1 = INT_MAX, he2 = INT_MAX;
			**buf[received + res] = 0;**

Видишь, ты и без аллокатора справился.

Так покажи используемую прогу на С без ошибок работы с памятью в анамнезе.

среди школьников

Каких школьников? Тут средний возраст около 30.

Тут средний возраст около 30.

До «лжецов» ты, наверное, не дочитал? (%