LINUX.ORG.RU
ФорумTalks

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

 , , ,


0

5

Собственно, сабж. Разработчики git'а хотят разбавить его код кодом на Rust'е: https://www.phoronix.com/news/GCC-Rust-Developer-Discussion .

Using Rust within Git is being considered to lower the risk of memory safety bugs, making it easier when refactoring or adding new code to Rust, and opening up Git development to Rust developers that may not be experienced or comfortable in C.

★★★★★

Отличная новость же!

th3m3 ★★★★★
()

всё пропало

Напротив.

intelfx ★★★★★
()
Ответ на: комментарий от skyman

Ждём бинарей на 600 мегабайт.

Лучше так, чем segmentation fault, memory cannot be read и buffer overflow

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

skyman ★★★
()

opening up Git development to Rust developers that may not be experienced or comfortable in C

Этот мотив ваще странный. Про некомфортность. Примерно как «угнетение» чем угодно готовых угнетаться примерно всем. Пусть напишут свой гит с ансейфами и паниками на расте и узбагоятся.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 2)
Ответ на: комментарий от skyman

Но всё равно пусть работают наперёд и отсекают даже потенциальные ошибки

Вряд ли это сделают «developers that may not be experienced»

NickNotNick
()
Ответ на: комментарий от slackwarrior

Пятнадцать лет назад казалось нормальным держать ВСЮ АРХИТЕКТУРУ ПРИЛОЖЕНИЯ в голове, чтобы случайно не получить remote code execution, добавляя строчку логирования. Сейчас это кажется бредом для мазохистов.

cumvillain
()
Ответ на: комментарий от skyman

Это у тебя на репозиториях какого масштаба наблюдается?

AP ★★★★★
()

and opening up Git development to Rust developers that may not be experienced or comfortable in C.

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

eyrell
()
Ответ на: комментарий от cumvillain

А что в 2008-м такого особенного было? Библиотеки и приложения были маленькими, мозги у программистов большими, а трава зеленее?

red75prim ★★★
()

Полагаю разработчикам Гита виднее на чем разрабатывать свой продукт.

MoldAndLimeHoney
()

easier when refactoring

Клоуны

PPP328 ★★★★★
()
Ответ на: комментарий от skyman

А есть примеры падения git на каких то конкретных кейсах? Я правда не в курсе, у меня репы небольшие и не наблюдал такого ни разу

saibogo ★★★★
()
Ответ на: комментарий от Ros

Только не на js, а ts. Первые два со строгой типизацией

Shadow ★★★★★
()
Ответ на: комментарий от red75prim

Наверно, по спринтам не работали. А теперь память проконтролировать в спринте не успевают

Shadow ★★★★★
()

Уже пофиг, пускай пропихивают, а потом плакают что поддерживать некому будет.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

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

alex1101
()

Зовите Тсаря, в каментах слишком холодное обсуждение. На эту новость надо больше флейма.

WatchCat ★★★★★
()

… and opening up Git development to Rust developers that may not be experienced or comfortable in C.

Ненуачо. Квоты для LGBT+ уже выгребли, осталось подбирать инвалидов, ниасиливших C.

x22 ★☆
()
Ответ на: комментарий от alex1101

Миф. Давай так. Каждый выпуск линукса выходит с патчами от тысяч людей. Половина из которых каждый раз новые. Как ты думаешь, если переписать ключевые места на расте так что нетрогая его ничего не сделать это хорошо отразится на активность людей? Это каким либо образом решим проблему с майнтейнерами? Был один сложный язык, а теперь этих языков два и нужно знать оба.

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

Я бы понял если кто вышел и сказал, такс! Мы решили полностью, переписать проект на расте и когда он будет готов мы заменим им основной проект. Это бы я понял. Но вот эти вот на полшишечки, вот тут в кусочке и вон там в библиотечке, понавтыкать вкраплениями другой язык… Ничего кроме лишнего гемороя это не вызовет. Ладно бы какой встроенный язык там притащили и прикрутили сбоку.

Я всё понимаю, но просто делается всё странным и нелогичным образом типа «Так, надо просто что-то брякнуть и похер, где твой чемодан с деньгами от мозиллы? Мой вот. Ага, ну сё, билеты взял, поехали, теперь они сами посебе муааахахаха»

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Миф

В этом вопросе я больше доверяю мантейнерам ядра.

Был один сложный язык, а теперь этих языков два и нужно знать оба.

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

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

alex1101
()
Ответ на: комментарий от alex1101

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

Могу тоже самое предложить антифанатам сишки. Или ты лично мне предлагаешь? Ты аппокалипсиса захотел что ль? :D Яж если меня пустят Lua в ядро засуну и скажу что так надо, начну заливать про то что это более безопасный язык чем раст, что местами производительность ненужна и прочее =))) Проблема не в сишниках, не в растоманах и прочих проблема в инженерах которые знают свою предметную область например весь стек USB или PCI-E или ещё чего отдельное и попутно владеют языком разработки проекта. Если притащить 1000 майнтейнеров которые просто знают язык и отличного его знают, но не бельмеса не вкуривают ни в одну из сотен предметных областей какой от них толк? Майнтейнеров не хватает на предметные области и конкретные части кодовой базы, а не просто не хватает абстрактных сишников.

В этом вопросе я больше доверяю мантейнерам ядра.

А не надо доверять никому, там всё как на ладони, кто чего и куда. Просто глянуть какие куски кода годами не трогают, а если трогают то поднимают обсуждение типа «Кто-то знает что вот тут вообще происходит?»

Короче не всё так прямолинейно. Растоманы рвутся поддерживать и переписывать код без майнтейнеров? Почему-то нет. Вместо этого они лишь дополняют кодовую базу своим сторонним кодом которому теперь тоже нужна поддержка. Я вот про это говорю. Если и есть проблема, она с приходом нового языка чёт вот не решается. Но тогда и нечего эту проблему приплетать, она как была так и останется что с растом что без.

В любом случае, что ты, что я, две лалки, не более того. Посидим увидим.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

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

Антифанаты сишки уже идут в проекты, из-за чего раст и втаскивают повсюду.

alex1101
()
Ответ на: комментарий от LINUX-ORG-RU

Нет, я плюсы учу. Раст пока видится весьма сырым.

alex1101
()

О, и туда уроды пытаются пролезть… :)

Кстати, неужто никто тут вообще не отдупляет, что rust это в первую очередь про залочивание софта на crates.io, который неизвестно кто контролирует, и альтернатив которому не предусмотрено, а не про какие-то там вымышленные преимущества rust над C/C++?

Это же полный пипец полный если некий базовый софт в процессе сборки без предупреждения скачивает тонны неизвестно чего с весьма подозрительного источника и без спросу всё это втыкает в бинарь?

Кто из маинтейнеров дистров будет вручную проверять что там эта дрянь накачала, и что там в накачанное мутные личности контролирующие crates.io понапихали?

Ноды видимо мало было, теперь надо ещё более глубоких зондов напихать?

И нет, это совсем не то же самое, что PIP или CPAN. При сборке какой-нибудть софтины какой-нибудь build.pl не лезет без спросу куда-то и не собирает какие-то левые сырцы без предупреждения. Просит пользователя установить если чего-то не хватает или нужна версия поновее.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

залочивание софта на crates.io, который неизвестно кто контролирует

Да, вот эта херня меня напрягает в расте больше всего.

alex1101
()
Ответ на: комментарий от red75prim

Выбора не было. Были корявые плюсцы, был C (еще даже без атомиков, лол) и в общем-то все, если ты хотел быстрый компилируемый язычок под *nix с типизацией и живым апстримом без туманных перспектив.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 1)
Ответ на: комментарий от alex1101

Да, вот эта херня меня напрягает в расте больше всего.

Ну так не используй! Напиши все сам, как в git!

cumvillain
()
Ответ на: комментарий от Stanson

Просит пользователя установить если чего-то не хватает или нужна версия поновее.

Расскажи мне сакральную разницу между

  1. cargo лезет на crates.io
  2. cargo говорит мейнтейнерам дистрибутива, что им нужно залезть на crates.io

Потому что результат один и тот же, лол.

cumvillain
()
Ответ на: комментарий от Stanson

Кто из маинтейнеров дистров будет вручную проверять что там эта дрянь накачала, и что там в накачанное мутные личности контролирующие crates.io понапихали?

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

Вот конкретно для Rust'а есть такое, например:

при наличии ./Cargo.lock вызывается «cargo vendor»

saahriktu ★★★★★
() автор топика

Дело хорошее. Сишка для гита так себе. Если бы кресты были, то смысла не было бы. А так смысл есть. Та же работа с юникодными строками в расте хоть и не идеальна, но лучше чем в сишке или c++

peregrine ★★★★★
()
Ответ на: комментарий от Stanson

Это же полный пипец полный если некий базовый софт в процессе сборки без предупреждения скачивает тонны неизвестно чего с весьма подозрительного источника и без спросу всё это втыкает в бинарь?

Лолшто?

  1. cargo fetch
  2. cargo build

Теперь ты либо объясняешь как это отличается от скачивания исходников для сборки rpm, либо истеричка.

cumvillain
()
Ответ на: комментарий от LINUX-ORG-RU

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

Да как раз тот. Мне надоело читать патчи и думать «а вот это не создает случайно рейс кондишон вот с каким-нибудь кодом? А точно? Ой а там нет внутри queue_work?”. Итог: ревьюверы забыли про таймер, use after free, паника ядра.

Просто хватит, мы все устали от этого.

cumvillain
()

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

thesis ★★★★★
()
Ответ на: комментарий от cumvillain

Потому что результат один и тот же, лол.

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

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Невнятное нытье

По делу давай, не отвлекайся. Указано, что для библиотеки foo требуется зависимость bar=1.16. Учитывая наличие контрольных сумм в Cargo.lock, назови мне вектор атаки, который возможен с cargo и невозможен с созданием rpm пакета мейнтейнером?

cumvillain
()
Ответ на: комментарий от saahriktu

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

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

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

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

firkax ★★★★★
()
Ответ на: комментарий от Stanson

скачивает тонны неизвестно чего с весьма подозрительного источника и без спросу всё это втыкает в бинарь?

Хуже того. Из-за тормознутости компилятора, чтобы было быстрее, могут загружаться даже заранее скомпилированные куски. Драма: using serde_derive without precompiled binary (28.07.2023). Пока что давление оказалось достаточно большим. И несмотря на категоричность их решения, разработчики всё таки откатили изменение (после того как множество проектов заморозили serde на предыдущей версии, сделав дальнейшую разработку serde бесполезной).

Но. cargo build - это не rpm/deb, где мэйнтейнеры следят за тем, что собирается. Из cargo может в любой момент прилететь бинарь.

gag ★★★★★
()
Последнее исправление: gag (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)