Опубликован выпуск проекта uutils coreutils 0.0.29, развивающего аналог пакета GNU Coreutils, написанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, способной работать в том числе на платформах Windows, Redox и Fuchsia. В отличие от GNU Coreutils реализация на Rust распространяется под пермиссивной лицензией MIT, вместо копилефт-лицензии GPL. Дополнительно той же командой разработчиков развиваются написанные на Rust аналоги наборов утилит util-linux, diffutils, findutils и bsdutils...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62584
Зачем переписывать то, что и так работает? Почему бы не написать что-нибудь ещё не написанное, например драйвера для устройств, используя новый интерфейс Линукс-ядра?Или допилить поддержку CMYK в gimp?
Или всякие нейросеточки потренировать для семантического поиска и тому подобного? Или хоть wayland до feature parity с Х11 доделать?
Ты им хочешь заплатить? Или ты хочешь забесплатно поуказывать кому что делать и что разрабатывать в чужой компании или даже в личное свободное время?
Ты что от него хочешь? Хочешь чтобы он не высказал своего мнения? Тогда зачем вы высказываете ваше мнение.
ты зачем свой коммент написал? он поэтому же.
А смысл есть, потому что в отличии от bash портянок есть ещё проект nushell - и скорее всего он использует эту имплементацию как основу своих утилит cd, ls и т.п.
Увы, не похоже
https://github.com/nushell/nushell/tree/main/crates/nu-comma...
> проект nushell - и скорее всего он использует эту имплементацию как основу своих утилит cd, ls и т.п1. “cd” не может быть утилитой, поскольку понятие «текущая директория» принадлежит текущему же процессу (шеллу). То есть только он сам может себе изменить ТД, другая программа ему изменить не может.
2. Нюшел создан и развивается виндузятниками, хотя линуксоиды там тоже есть, и поэтому по-умолчанию не пытается быть похожим на гнутые инструменты в принципе.
как это не может быть утилитой, когда я использую zoxide (на rust кстати написан) вместо cd
Zoxide не меняет текущую директорию. Её меняет твой шелл. Шелл может всего лишь проконсультироваться с другой программой вроде zoxide о том, какой должна быть новая директория. Грубо говоря это тоже самое, какcd $(/bin/echo /some/path)
При этом «cd» - это встроенная в бэш команда, а не внешняя. Потому что внешняя запустилась бы в новом процессе, а один процесс не может поменять текущую директорию в другом, уже запущеннос процессе.
это понятно, что "текущая директория" - это внутреннее состояние оболочки, но устанавливаться оно может и сторонними утилитами
Расскажи, какой сискол в линуксе или макоси или винде позволяет изменить значение текущей
директории для стороннего, уже запущенного процесса.
причем тут сисколы и сторонние процессы когда речь конкретно об оболочках. вообще не понятно о чем дискуссия
«Оболочка» - это такой же процесс ОС как любой другой. Если один процесс (оболочка) запускает другой процесс (zoxide), то это два разных процесса. Говоря, что утилита (программа отдельная от оболочки, запускаемая поэтому как посторонний процесс) может менять текущую директорию в чужом процессе (оболочке), ты утверждаешь что это позволяет делать ядро. Потому что именно оно определяет возможности и ограничения процессов операционной системы.Всё, что могут делать пользовательские (userspace) программы - это просить ядро выполнить одну из предпоределённых функций этого ядра, называемых syscall. Если не существует сискола который позволяет сделать то, о чём ты говоришь, то не существует возможности это сделать вообще. Поскольку же ты уверенно утверждаешь, что линукс это может - сискол на стол.
Ну или напиши программу, которая произвольному процессу изменит текущую директорию. А я напишу программу, которая будет раз в секунду выводить свою текущую директорию на экран.
> ты утверждаешь что это позволяет делать ядроНет, я этого не утверждаю. Я говорю лишь о том, что утилита может попросить оболочку поменять текущую директорию
> Ну или напиши программу, которая произвольному изменит текущую директориюТипичная проблема айтишников, overthinking называется - придумать что-то за других и потом спорить с этим.
> утилита может попросить оболочку поменять текущую директориюНе может. Такого функционала ни в одном мейнстримовом ядре не предусмотрено.
Процессы могут общаться через:
- файловую систему
- сокеты
- общую память
- stdin/out/err
- сигналыНо это просто передача произвольных данных (кроме сигналов, но и они не устанавливают директорию). API который делает то, о чём ты говоришь просто не существует.
Единственный способ одному процессу повлиять на текущую директорию другого процесса - это если влияющий сам запускает влияемого, что отражено в API ядра и происходит в шеллах. В обратную сторону это не работает.
https://man7.org/linux/man-pages/man2/chdir.2.htmlA child process created via fork(2) inherits its parent's current working directory. The current working directory is left unchanged by execve(2).
Тебе помочь с переводом?"Дочерний процесс наследует текущую директорию родителя. execve(2) не меняет текущую директорию."
Где тут дочерний процесс (zoxide), который может поменять текущую директорию родителя (bash)?
Я тебе дам на "подумать" как домашнее задание. cd это обычная утилита (не обязательно оболочки), ls тоже. Я делаю cd /tmp. Потом ls. Что выведет команда ls? Почему? Думай Шерлок.
Сискол на стол.
Сисколл называется "environment". Можешь почитать про это. Который наследуется.
Это все еще ни о чем не говорит. На стол конкретную инструкцию, как ты через "eNvIrOnMeNt" можешь поменять рабочую директорую другому процессу.Все, что ты можешь сделать, - поменять текущую рабочую директорую через chdir(), и запустить новый процесс из этого же самого процесса.
Поменяв условный PWD в environ или putenv(), ты директорию не поменяешь. Я уж молчу, что в environment variables чужого процесса ты вообще лезть напрямую не можешь.
> cd это обычная утилита (не обязательно оболочки)Нет.
"$ type cd" -> "cd is a shell builtin"
"$ which cd" -> "which: no cd in (/home/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)".cd буквально не может быть внешней утилитой, ибо у тебя никакого системного интерфейса, который давал бы возможность одному процессу изменить рабочую директорую другому процессу. Даже родительский процесс не может послать подобное указание дочерному процессу. Самое близкое, что нам предоставляет Linux, - chdir(). И то, "$ man 3 chdir":
> The chdir() function only affects the working directory of the current process.
> ls тожеСогласен, тут по факту.
> Потом ls. Что выведет команда ls? Почему? Думай Шерлок.
Потому что ты сперва в рамках своего Shell'а, то есть актуального процесса, поменял директорию на другую, а оттуда запустил ls. Опять же, твой Shell сперва сделает fork(), а потом execve() в ls, но это все тот же самый первый процесс, в котором ты выполнил "$ cd".
Если ты все еще утверждаешь обратное, - информацию о конкретном syscall'е, хотя бы его название, или man страницу, которая описывала бы системный интерфейс, предоставляющий описанный тобой функционал.Иначе - балабол, говоря на языке фактов.
zoxide интегрируется с шеллом и под капотом всё-равно вызывает его встроенную функцию для смены текущей директории
Именно. Только для уменьшения путаницы стоит отделять:1. Zoxide как исполняемый бинарь (то, что называют утилитой)
2. Бэш-скрипт, который вызывает zoxide, что бы спросить его какая должна быть новая директория, что бы бэш в неё совершил переходСама утилита ничего изменить не может, может только шелл.
>“cd” не может быть утилитойВсё верно. cd - это команда GNU bash. Думаю, что в других командных интерпретаторах (dash, fish, csh ...) эта команда видимо тоже присутствует.
cd - обще-юниксовое.
Вот не знает человек ни GIMP, ни что такое CMYK, а от X11 и вяленого у него волосы на заднице дыбом встают - что делать? А так люди, никому не мешая, тренируются писать на новом языке утилиты, поведение которых всем известно, да ещё и есть готовый тестовый набор. Только кексперты-онанимы лезут не зная куда, пытаясь реализовать не знаю что.
Почему бы им для обучения не выбрать какой-нибудь нормальный язык?
Раст нормальный. То, что лично тебе он показался слишком сложным в сравнении с питоном, это твои проблемы.
Борьба с боровом вместо написания программы это ненормально.
Типичный тяп-ляп сишнек. В зависимостях либы протухли 5 лет назад, но компилируется - в продакшон. Выходы за границы буфера?! Ну потом как-нибудь поправим когда CVEшки повылазят.
> В зависимостях либы протухли 5 лет назад, но компилируется - в продакшон.Вот этого никогда не понимал: если нет серъезныз багов, то зачем обновлять? Вы наверное тоже добавляете бота, который ходит и обновляет зависимости каждый день и посылает pr?
> Борьба с боровом вместо написания программы это ненормально.А зачем с ним бороться? Он же помогает , а не мешает.
Борьба возникает у всяких 6ыdloкодеров, которые привыкли куда угодно писать, откуда угодно читать, не заботясь ни о чем, а потом х-к, х-к и в продакшен.
Правда потом в продакшене будет пара CVE))
> Или допилить поддержку CMYK в gimp?М... зачем? Особенно если ты им не пользуешься и не собираешься.
Как раз лучше что можно сделать с gimp - закопать и переписать с нуля на чем угодно, только не так как оригинал.> Или всякие нейросеточки потренировать для семантического поиска и тому подобного?
Для этого нужна соответствующая видяха. А она денег стоит.
> Или хоть wayland до feature parity с Х11 доделать?
Вот только не нужно пихать все Х11е омно в новый протокол!
wayland именно по этой причине так назвали, а не Х12 - чтобы не тянуть все дремучее легаси.
А всякие прдлики пусть продолжают сидеть на иксах.
> Зачем переписывать то, что и так работает?затем, что сейчас оно собирается и работает само по себе, а на расте сборка будет зависеть от доступа к crates.io;
и от его содержимого;
Может зависеть, а может и нет. Документацию достаточно почитатьиз своего реестра:
[dependencies]
some-crate = { version = "1.0", registry = "My-Registry" }из git-репы:
[dependencies]
avian3d = {git="https://github.com/Jondolf/avian.git", rev="2540add"}локально:
[dependencies]
some_crate = { path = "../path_to_some_crate" }
ага.
и что, весь софт с crates.io сам переместится на заданные вами ресурсы?а если не переместится, то как вы его собирать будете, если в силу санкций вас от crates.io отключат?
почитать документацию мало -- надо иногда головой подумать.
> ага.
> и что, весь софт с crates.io сам переместится на заданные вами ресурсы?Не, я его один раз скачаю)
> а если не переместится, то как вы его собирать будете, если в силу санкций вас от crates.io отключат?
А если тебя снаружи или (что более вероятно) изнутри закрою гитхаб?
Дальше дело техники - ВП.., а это слово запрещено, торренты, диски с запрещенкой, почтовые голуби...> почитать документацию мало -- надо иногда головой подумать.
В статье написано "успешно выполнено 506 тестов (в прошлой версии 476), 67 (94) тестов завершилось неудачей, а 41 (43) тест был пропущен"
Так что думаю с головой у них все ок, раз тесты проходят.
Оптимистам всё нипочём (они же не свой бизнес строят на Rust'e)
> Зачем переписывать то, что и так работает? Почему бы не написать что-нибудьТ.е. ты пользуешься оригинальными cat/cp/dd/ls/итд, а не сабжем? 😲
А где тег сарказм?
> Зачем переписывать то, что и так работает?Для уменьшения технического долга. Чем старше становится код, тем сложнее его поддерживать и развивать. По целому ряду причин. В какой-то момент вносить новые фичи становится настолько сложно, что написать тоже самое с нуля проще.
Ты не знаешь как устроены сишные утилиты. Исходный код их небольшой, читаемые и реактивные. Между прочим, в книге Кернигана и Ритчи есть упрощённый вариант утилиты cat.Ты наверно путаешь юниксовые утилиты с большими Энтерпрайзными прогами исходники, которых обёрнуты в тяжеловестные простыни ООП.
> Ты не знаешь как устроены сишные утилитыЗнаю. С чего ты взял, что нет?
> Ты наверно путаешь
Утилитки с историей на более чем 50 лет. Не путаю.
> Исходный код их небольшой
--------------------------------------------------------------------------------
Language Files Lines Blank Comment Code
--------------------------------------------------------------------------------
C 3337 556258 73962 109744 372552
C/C++ Header 1083 399706 20983 38021 340702
Plain Text 14 94182 150 0 94032
Bourne Shell 1054 69665 11191 18171 40303
TeX 1 11988 865 3506 7617
Perl 66 11019 1677 2319 7023
Makefile 49 7186 773 1292 5121
C++ 94 5404 1350 1243 2811
Yacc 1 2452 286 308 1858
Autoconf 11 1730 40 344 1346
Python 20 10699 933 9085 681
Lisp 1 376 8 62 306
CSS 2 183 42 14 127
Java 1 31 1 25 5
--------------------------------------------------------------------------------
Total 5734 1170879 112261 184134 874484
--------------------------------------------------------------------------------
40303 строк шелла 🤢
7023 строк перловки 🤮
(Слава (богу (хоть (лиспа) всего) 306) строк)
Ну и почти 600к дыряшки!Хорошо если это все закопают.
> Чем старше становится код, тем сложнее его поддерживать и развивать.Полная глупость, конечно.
Чем старше код, тем больше в него вложено человекочасов опыта и кодинга. В какой-то момент написать такую же программу с нуля (не подсматривая в старый код) становится невозможно, потому что старые программисты умирают, а у новых нет такого жизненного опыта, который наводит на правильные решения.
Старый проггер когда-то был новым. Но старый проггер умер, придёт новый, посмотрит на этот якобы хорошо отлаженный код и поймёт, что это нереально поддерживать. И начнёт новый проггер новый проект. Колесо Сансары сделает оборот.
> Зачем переписывать то, что и так работает?Ну так ты новость хоть раз прочитай, а не сразу беги комментарии строчить.
Написано же:
"Целью проекта является создание *кроссплатформенной* альтернативной реализации Coreutils, способной работать в том числе на платформах Windows, Redox и Fuchsia"
>"Целью проекта является создание *кроссплатформенной* альтернативной реализации Coreutils, способной работать в том числе на платформах Windows, Redox и Fuchsia"Windows - сами разработчики вантуза давно сделали ставку на мышь. Да-да знаю у них есть болтливый PowerShell, но это не отменяет моего предудыщего тезиса: "Винда для мышевозов".
Redox - хм ..., мэйби бэйби.
Fuchsia - Гугл с своём фирменном стиле его дропнул. Никогда такого не было, и опять.
Касаемо растаманов. У них есть мечта, заменить экосистему GNU, на свою.
>>давно сделали ставку на мышьА скрипты автоматизации?
Или по обезьяньи все мышью? Кадый раз.Не спроста же появилсь Cygwin и WSL и другие порты консольных утилит для Windows.
>>заменить экосистему GNU, на своюТочнее, цель уничтожить. Если бы сделали форк Linux и ковырялись с переписыванием, да им бы слова плохого не сказали, только хвалили бы.
> Точнее, цель уничтожить. Если бы сделали форк Linux и ковырялись с переписыванием,
> да им бы слова плохого не сказали, только хвалили бы.Сам-то веришь?
Вот тут вот - никто не "пропихивает" раст в gnu coreutils, переписывают в отдельном проекте. И как, много "на(х)валили" в комментах?
взял и с козырей зашёл негодник
> взял и с козырей зашёл негодникС козырей? Да там мизер какой-то.
Сразу видно аффтор троль, или, еще хуже "любитель чтобы была одна система, одна программа и вообще путь все ходят строем".
Любителей ein fuhrer надо посылать на винду, там все как они любят.
А забавно получается, всё как в далеком прошлом когда gnu переписывали unix: Сейчас system76 пилят DE, другие пилят всякие utils, - остается чтобы кто-то взялся за само ядро, - хотя наверное проще будет написать новое! Хотя, учитывая что system76 также продает железо, а также имеет отношение к Redox, то возможно у них есть какие-то интересные далекоидущие планы, - так что посмотрим к чему всё в итоге придёт!
Пусть эти переписыватели для начало servo напишут.
Его уже написали, это проект других чуваков.
Виснет в YT, не проходит Acid3.
> Хотя, учитывая что system76 также продает железо, а также имеет отношение к Redox, то возможно у них есть какие-то интересные далекоидущие планыНет.
>А забавно получается, всё как в далеком прошлом когда gnu переписывали кривущие и отсталые, зато дорогие unixFTFY
gnu - делал прогресс
rustаманы - делают прогрессивноене путай
с каких пор добавить пару опций в описанные 100 лет назад утилиты и забить на нормальное описание своей реализации - прогресс?
как итог .. поддержка unix и posix до сих пор в каждой микроволновке, а хну во всю переписывают на что-то более модное.
> как итог .. поддержка unix и posix до сих пор в каждой микроволновке, а хну во всю переписывают на что-то более модное.да, да, ты уже много рассказывала про божественны ПОФИГС, правда когда начинались вопросы про версии и обратную совместимость, сливалась
может пора идти на на кухню мыть посуду?
Хотят переписывать пусть переписывают. Если я правлильно понимаю, ядро Linux и GNU утилиты изначально сишные и децентрализованные. Rust предлагает централизованную инфраструктуру без всяких тарболов, чтоб можно было одним рубильником отрубить всё и сразу.
>централизованную инфраструктуруто опция по умолчанию. все так же будет работать если указывать кастомные репозитории/реджистри в манифестах
> все так же будет работать если указывать кастомные репозитории/реджистри в манифестахЧтобы это знать - нужно доку читать.
А зачем читать доку, если хочешь тупо хейтить.
>то опция по умолчанию. все так же будет работать если указывать кастомные репозитории/реджистри в манифестахПроблема не в том, что репозиторий могут отключить, а в том, кто и как будет определять его содержимое. Представим, если некие люди захотят сделать небольшое изменение во всех пакетах, либо повлиять на разработчиков в плане их отбора по нужным идеологическим критериям, либо просто ввести прямую цензуру кода. Что вы сделаете тогда со всеми вашими зеркалами?
От всего уберечься невозможно.
Появится реальная угроза — появится и решение.
Для этого лок-файлы и существуют, но кто ж на Плюке правду думает^W^W^Wопеннете документацию читает?
> Представим, если некие люди захотят сделать небольшое изменение во всех пакетах, либо повлиять на разработчиков в плане их отбора по нужным идеологическим критериям,Ты хочешь сказать, что это может произойти незаметно, или о том, что оно может произойти заметно всем, и у них не будет никакой возможности этому противостоять?
Но незаметно не выйдет, пакеты разрабатываются в git, есть блокчейн куда незаметно вставить изменения не выйдет. Идеологический отбор тоже не пройдёт незамеченным, с учётом количества вовлечённых в это.
Если же это произойдёт, то противостоять этому элеметарно, достаточно поднять альтернативу cargo.io. Ты сам можешь это сделать, если захочешь.
> либо просто ввести прямую цензуру кода.
В ответ на что на следующий же день возникнет десяток новых "cargo.io".
Твои модели угроз вполне применимы к модели разработки ядра линукс, например. Или к репам debian. "А что если, Торвальдс начнёт цензурировать по идеологическим мотивам и внедрять бекдоры?" Но тебя это почему-то не волнует, почему?
Только чего то все не выходит каменный цветок.
Делать свой кривой ржавый велосипед, в то время, как существует нормальный, активно развивающийся, - самое бесполезное, что можно придумать в программировании.
Вот именно. Зачем делали гнутый велосипед, если были нормальные юниксовые утилиты?
Но нет, почему-то захотелось и сделали.Так и тут. Раньше хотели избавиться от проприетарной лицухи и сделать утилиты свободнее.
А сейчас от коммунистического гнурака и сделать их еще свободнее.> самое бесполезное, что можно придумать в программировании
Но превзойти бесполезность Гну ХУРД все равно не получится.
> Зачем делали гнутый велосипед, если были нормальные юниксовые утилиты?Хорошие. Только за денежку) Так что аналогия не прокатывает.
> А сейчас от коммунистического гнурака и сделать их еще свободнее.
Тогда ошиблись с выбором языка - раст уже вовсю огорожен, даже на уровне использования названия и логотипа.
> Но превзойти бесполезность Гну ХУРД все равно не получится.
"Разработка ведётся медленно по причине существования Linux — уже готовой свободной замены ядрам Unix-систем" - одного поля ягоды, что переписывание на расте, что разработка Hurd, когда уже есть Linux.
> Тогда ошиблись с выбором языка - раст уже вовсю огорожен, даже на
> уровне использования названия и логотипа.https://www.fsf.org/blogs/licensing/protecting-free-software...
> The FSF holds copyrights and common law trademarks to the GNU family of General Public Licenses. Moreover, the FSF holds registered trademarks for "FSF," "Free Software Foundation," and "GNU."
> We do not allow anyone to make unauthorized derivative works of our licenses. We also do not allow and cannot accept confusing uses of the FSF's trademarks. We have allowed using the GPL's terms to create other licenses, but only under specified conditions,https://www.gnu.org/graphics/heckert_gnu.html
> The GNU head is, however, also a trademark for the GNU Project. If you want to use the GNU head to link to a website run by the Free Software Foundation or the GNU project, feel free, or if you're using it in contexts talking about GNU in a supportive and accurate way, you can also do this without permission. For any other requests, please askРасскажи, почему "этодругое"?
Поправку на время действия не забывай делать. Утилиты GNU появились, когда в IT был тренд, провозглашённый Билли, что всё должно быть проприетарным.
Для Анонов и не только, задающихся вопросом "А зачем? Оно же работало?!"Так вот затем, чтобы такой фигни не было:
- www.opennet.ru/opennews/art.shtml?num=60490
"Уязвимость в утилите GNU split, приводящая к переполнению буфера"- www.opennet.ru/opennews/art.shtml?num=42235
"Уязвимость в утилите GNU sort"А есть еще одна CVE-2015-4042 - тоже sort.c и Integer overflow.
Профессиональные "настоящие программеры" тапляпнули уязвимость на 9.8.Ну и второй момент - не каждый хочет использовать коммунитсическое ГНУ, если есть альтернативы.
GNU коммунистическое? Вы это ещё настоящей коммунистической лицензии не видели.
Рецепт приготовления труЪ коммунистической лицензии:1.Берем AGPL 3
2.Берем пункт с https://commonsclause.com/
3.Тщательно перемешиваем ...
4. ????
5.NO PROFIT!
Плеваться будут ВСЕ. Корпы из-за того что им нельзя закрыть код или продавать софт. FSF и OSI из-за того что это будет (в соответствии с их дефинициями) закрытый и несвободный код, причем под вирусной проприетарной лицезией!!
> Плеваться будут ВСЕ. Корпы из-за того что им нельзя закрыть код или продавать софт. FSF и OSI из-за того что это будет (в соответствии с их дефинициями)
> закрытый и несвободный код, причем под вирусной проприетарной лицезией!!И название выбрать: opennet troll licenst 1.0 unported :))
Бонус: В названии лицензии желательно включить ☭ (серп и молот), так как в некоторых странах коммунистическая символика запрещена
Ну тогда давай еще добавим пропеллер фюррера.
И вообще все вещи которые могут быть где-то запрещены или кого-то оскорбить.
И назвать "Лицензия Картмана"))
Не пропеллер а трезубец.
> 3.Тщательно перемешиваем ...И получается... получается... а да, получает то самое омно.
Впрочем с остальным коммунизмом получилось примерно тоже самое.
Так что логично.
>>такой фигни не было:Такое будет всегда, независимо от языка. Наивно думать, что профессиональные программисты смогли вдруг случайно сделать такую детскую ошибку. Всё же прекрасно понимают, что это был явный бекдор, замаскированный под "опечатку". И на расте такие бекдоры будут внедряться. Но их обнаружить будет гораздо сложнее не только из-за сложного синтаксиса, но и из-за веры в "безопасный" раст.
У раст нет сложного синтаксиса, достаточно базовый учебник прочесть. Это современный, выразительный, безопасный язык.> Такое будет всегда
Такое будет всегда в Си. В Раст надо стараться чтобы выстрелить себе в ногу, в Си надо стараться чтобы не выстрелить.
С "прострелить себе ногу" не уместно.
В этой байке речь об ограничених языка, и тем более при целенаправленных действиях на "прострел" ноги.
Руст это не запрещает, и более того и без unsafe тоже позволяет, разве что более многословно.Вот, что снижает шанс нечаянно вляпаться, это верно.
>Это современный, выразительный, безопасTный язык.Программируешь и выражаешься, и выражаешься.
Бритвы Хэнлона в помощь. Детская ошибка от матерого профессионала гораздо более вероятней чем намеренный бэкдор по убедительной просьбе товарища майора (а если бы было наоборот, то мы бы жили в мире по сравнению с которым КНДР - опора свободы и демократии)
> Бритвы Хэнлона в помощь. Детская ошибка от матерого профессионала гораздо более вероятнейИ чем помогут эти "бритвы"? Есть ли какие-либо научные исследование, подтверждающие эту теорию, с конкретными цифрами/фактами или это субъективное утверждение, основаное на художественной литературе?
Есть просто жизненый опыт что глупости встречаются гораздо чаще коварных многоходовочек. На этом бритва и основана. Если вы с этим не согласны, то вы либо параноик - либо человек из параллельного мира где каждый второй - великий комбинатор и мастер интриг
Как говорится "если вы не параноик, это не значит, что за вами не следят"
Жизненый опыт как раз показывает, что чаще преступники прикидываются дурачками, чтобы себя оправдать. Продавцы в магазине всегда "ошибаются" только в свою пользу. Спалившийся вор в толпе всегда "случайно" суёт руку в ваш карман. Наркокурьер всегда "путает" одежду в раздевалке после концерта. И такие примеры постоянно. Просто вам вешают лапшу на уши и втирают про какие-то "бритвы" чтобы вы верили.
> Продавцы в магазине всегда "ошибаются" только в свою пользу.Не правда, не всегда.
Мне периодически приходится возвращать продавцам неправильно посчитанную в мою пользу сдачу. И обычно они так забавно глазами блымают, как будто розового невидимого единорога увидели.> Просто вам вешают лапшу на уши и втирают про какие-то "бритвы" чтобы вы верили.
Все равно нельзя недооценивать человеческую глупость.
злоумышленнику выгодно притворится что его деяние это глупость (если нужно оправдание), но из этого нельзя делать вывод что всё то что является глупостью - злодеяние. Строго наоборот, среди множества вещей которые выглядят как глупость подавляющее большинство это действительно настоящая глупость, а не замаскированное злодеяние. Максимум инцидент может дать повод для расследования, на всякий случай так сказать.
> Продавцы в магазине всегда "ошибаются" только в свою пользу.Мой личный опыт показывает, что нет, не только в свою.
> Спалившийся вор в толпе всегда "случайно" суёт руку в ваш карман. Наркокурьер всегда "путает" одежду в раздевалке после концерта.
Тут у тебя методические проблемы. Преступники совершают преступления по-определению. Вопрос в другом, как часто не преступники совершают действия похожие на преступления, и собственно интересно-то то, не происходит ли это чаще, чем аналогичные преступные действия. Но твои формулировки проходят мимо сути предмета.
> Как говорится "если вы не параноик, это не значит, что за вами не следят"
Да, но это бестолковый майндсет, если твоя задача обезбажить код.
До тех пор, пока разработка ПО не научилась надёжно отлавливать даже баги совершённые по глупости, нет смысла разговаривать об отлове багов совершённых намеренно. Баги совершённые по глупости должно быть проще отловить, потому что при их создании не уделялось внимания тому, чтобы сделать их скрытыми, намеренно оформить их так, чтобы они проходили бы через все процессы призванные отловить баги до попадания в релиз.
Ты не читаешь AdmiralCloudberg? Я люблю этот блог, потому что Кира Демпси не просто разбирает авиакатастрофы, но фокусируется на процессе "отладки" всей авиапромышленности. Этот процесс отладки уже привёл авиапромышленность к беспрецедентной безопасности авиаперелётов, хоть ему и потребовалось на это более полувека. Но я к тому, что одним из принципов, которому следует NTSB (американская служба, занятая расследованием авиаинцидентов), это принцип презумпции невиновности людей, вовлечённых в инцидент. Пилотов например. Если пилот совершил грубейшую ошибку и разбил самолёт, и нет никаких свидетельств тому, что он сделал это намеренно, то значит пилот не виноват, виновата система, которая допустила ситуацию, когда пилот могущий совершить такую ошибку оказался в ситуации, когда у него возникла возможность её совершить, и мало этого, система не смогла предотвратить эту ошибку. Например, пилот выбирает угол атаки выше того, что допустимо конструкцией самолёта на текущей высоте, самолёт переходит в сваливание, и оба пилота в кабине лихорадочно пытаются разобраться в том, что происходит вплоть до момента, когда самолёт разбивается о воду Атлантического океана, и так и не успевают понять[1]. Бессмысленно обвинять пилотов в этом, они явно сделали всё, что им позволяла их квалификация, для того, чтобы спасти самолёт. Надо обвинять систему, которая не дала пилоту достаточной теоретической подготовки к пониманию сваливания и причин его возникновения, не дала подготовки к детекции сваливания, не научила выходить из сваливания. Может быть надо обвинять систему, которая допустила что в кабине самолёта сидело сразу два пилота, которые могут допустить сваливание, не могут детектировать сваливание и не могут отреагировать на него корректно.
Разработка софта, которая тоже развивается в направлении снижения числа багов, допускаемых в процессе разработки, тоже действует примерно так, и это правильно, потому что очень просто обвинить программиста в злом умысле, наказать его и оставить всё как есть. Или начать охоту на ведьм, пытаясь избавиться от всех программистов в команде, которые возможно имеют злой умысел. Это просто, но бесполезно. А вот менять подходы к написанию кода и приёму в основной репозиторий таким образом, чтобы багов в релиз попадало бы меньше -- это хоть и гораздо сложнее, но зато в перспективе решит проблему не только с ошибками по злому умыслу, но и с ошибками "по глупости".
С ошибками "по глупости" бесполезно бороться обвиняя программистов в злом умысле. Это понятно почему, или надо объяснять?
[1] https://admiralcloudberg.medium.com/the-long-way-down-the-cr...
Что забавно, даже такие "консервативные" ребята как гентушники пробовали сабж для замены [1] стандартных Coreutils.Serpent OS (но он пока объективно сырой) использует.
[1] opennet.ru/opennews/art.shtml?num=61418
Консервативные райсеры? Пробовали потому что думали cp будет быстрее.
БезопасТно. Нет копирования нет опасностей.
Достаточно уже GNU vs BSD идеологической фрагментации, а тут в добавок технологическая подоплёка.
Допустим лицензия, ладно.Как по мне, смысл переписывать софт в том, чтобы сделать реализацию проще, менее ресурсоёмкой, более быстрой.
Реализация на раст проще, быстрее, требует меньше памяти?
>Допустим лицензия, ладно.Нет, не ладно. Копилефт, только копилефт! GNU COreutils имеют лицензию GPLv3+.
>Как по мне, смысл переписывать софт в том, чтобы сделать реализацию проще, менее ресурсоёмкой, более быстрой.
GNU Coreutils написана на чистой сишке, проще и быстрее не придумаешь.
>Реализация на раст проще, быстрее, требует меньше памяти?
Реализация на Раст будет собираться полдня.
>>Допустим лицензия, ладно.
> Нет, не ладно. Копилефт, только копилефт! GNU COreutils имеют лицензию GPLv3+.Э-э-э, а что тогда с таким вот ГНУ-копилефтом https://www.gnu.org/graphics/copyleft-sticker.en.html
> CreatorTool="Adobe Photoshop CS6 (Macintosh)"это ладно, не-ладно или "этодругое!"?
На сайте gimp.org - ни слова о его связи с GNU. Какие тогда претензии?
https://www.gimp.org/docs/userfaq.html=Is there a company or a foundation behind GIMP?
No. We are a diverse group of volunteers from around the world who work on this project in their spare time.
=Are you trying to develop a Photoshop killer app?
No. Most generic image editors look like Photoshop simply because Adobe’s application was among the first image editors as we know them now, so developers tend to stick to what people know — in general terms.
What we aim to do is to create a high-end image manipulation application that is free to use and modify by everyone, ever.
> На сайте gimp.org - ни слова о его связи с GNU. Какие тогда претензии?М... А то что оно "GNU" image manipulation program это типа ничо?
Да и претензия не к гимпу, а мерзкому лицемерию гнутиков из GNU.> What we aim to do is to create a high-end image manipulation application
Угу, high-end))) "Ну вот и вы говорите" (с)
В чем лицемерие, поясни? Не нравится Гимп? Сделай лучше
> В чем лицемерие, поясни?Лицемерие в том, что фанатики gnu.org топять за шво6одку, требуют открыть сорцы всего до чего могут дотянуться, называют всех авторов несвободных (с точки зрения секты) программ "вредителями" и предлагают от них отказываться и всячески избегать!
Даже списочек самых-самых сделали и туда попадает Adobe gnu.org/proprietary/malware-adobe.htmlА потом внезапно оказывает, что в этой вредоносной богомерзкой програмулине делали логотипчики для их сайта! Вот что может быть более мерзко и лицемерно чем это?
Это же на уровне "глава комитета по борьбе с коррупцией попался на взятке". Хотя это уже классика в этой стране))Не удивлюсь? если после смерти Столлмана у него под матрасом найдут фотографии маленьких детей... или что еще хуже - его макбук на М4Pro)))
>> Э-э-э, а что тогда с таким вот ГНУ-копилефтом https://www.gnu.org/graphics/copyleft-sticker.en.html
>> CreatorTool="Adobe Photoshop CS6 (Macintosh)"
>> это ладно, не-ладно или "этодругое!"?
> На сайте gimp.org - ни слова о его связи с GNU. Какие тогда претензии?Э-э ... и причем тут GIMP?
> Э-э ... и причем тут GIMP?Все правильно говоришь.
Гимп абсолютно не причем, потому что ему до Adobe Photoshop CS6 как до луны.
С другой стороны - других "свобоных" графических редакторов не завезли.
эмм а как же крита? инкспейс? паинт нет? последнее конешено не кросс но всё ж таки бесплатно. а насчёт гимпа согласен с тем кто писал выше надо закопать и наваять с нуля что-то более адекватное и юзабельное. как мне видится их технический долг слишком огромен чтобы его исправлять и улучшать
> Реализация на раст проще, быстрее, требует меньше памяти?При прочих равных - требования по ресурсам одинаковые. Но на расте писать проще, быстрее и меньше багов на выходе.
Проще и быстрее потому что язык более удобный, и можно с лёгкостью переиспользовать высококачественные, кроссплатформенные либы.
>Но на расте писать проще, быстрее и меньше багов на выходе.
>Проще и быстрее потому что язык более удобный, и можно с лёгкостью переиспользовать высококачественные, кроссплатформенные либы.Ложь. Обычная ложь.
Ты Раст и Си умеешь?
> Ты Раст и Си умеешь?Он буковки писать умеет.
Разве этого недостаточно, чтобы одаривать всех своим кекспертным мнением?
Ну не прямо ложь.
Если кому то Руст удобней, и нравится его синтаксис, работа с библиотеками, то для них он таки удобней.
А про высококачественные либы и качественный код, это уже вера в непогрешимость, а на деле от прямоты рук зависит, и от запутанности оригинального ПО, которое переписывают.
Ложь. Обычная ложь. Статистика.
> Реализация на раст проще, быстрее, требует меньше памяти?Зависит от определения критерия оптимальность, думаю главным критерием переписывания является безопасТность, которую дает раст. Интересно было бы посмотреть в будущем на баги найденные в сишной реализации, которых по определению не должно было быть в растовой реализации.
"Реализация на раст проще, быстрее, требует меньше памяти?"Не надо быть наивными, корпорации (а это они переписывают всё на Rust) думают только о своём кармане. Сейчас они считают что переписывание на Rust принесёт прибыль. Однако в любой момент могут изменить своё мнение.
Прямо как свитбэби. Те корпы тоже думают, что пропихивание повесточки принесет им прыбыл.
Ну посмотрим, раст сейчас такая же повесточка.
>смысл переписывать софт в том, чтобы сделать реализацию ... менее ресурсоёмкойЭто фантастика из мира IT.
> Как по мне,В том то и дело, что "сколько людей - столько мнений".
Кто-то готов переписывать чтобы изучить как оно работает или улучшить навыки и знания ЯП.
Кто-то - потому что "там все написано не правильно!!111".> смысл переписывать софт в том, чтобы сделать реализацию проще, менее ресурсоёмкой, более быстрой.
Сейчас все перечисленное тобой мало актуально. Достаточно чтобы оно было "не слишком хуже" чем было.
А слово "надежность" ты специально не назвал?
Например исправить родовые косяки архитектуры или убрать подходы которые приводят к ошибкам.> Реализация на раст проще, быстрее, требует меньше памяти?
Раст по скорости не сильно медленнее СИ (разница в пару процентов или долей процентов),
памяти потребляет возможно больше, но это сильно зависит от сборки - некоторые горе сборщики в пакеты пихают версии с дебажной информацией.
Сизифов труд. На 100 % совместимость не получится никогда. Coreutils всегда будет бежать впереди.
А им и не нужен результат им надо повизжать ро Раст.
Когда-то SysV init бежал впереди, а теперь остался только в маргинальных дистрах, 1% от 1%. Думай теперь.
>Когда-то SysV init бежал впередиSysV init никуда не бежал. Он так и остался трушным инициализатором.
> SysV init никуда не бежал.Он полз как мог!
> Он так и остался трушным инициализатором.
Но как был унылыми занюханными башпортянками, так и остался.
И сейчас его используют только уж совсем отбитые васяны.
Меня прям радует, что все глупости написаны анонимами, потому что если писать с аккаунта, потом стыдно будет логиниться
> все глупости написаны анонимамиРазумеется не все!
Некоторые пишут совсем неаноны вроде Васи Пупкина.
Таким трушным, что стремительно был выброшен из всех мейнстримных дистров при первой же возможности. Таким трушным, что количество установок в проде стремится к общему количеству установок DragonflyBSD. Расскажи что-нибудь ещё плоскоземельное.
Тут не думать, а отдаваться надо кому надо.
>Думай теперь.Все давно придумано дедами, и в данном случает ответ будет "99% мух не могут ошибаться".
А... ты у нас наверное муха?99% людей, например, не убивает других людей.
99% не жрут какули.
96% не пользуется маргинальными поделками от бомжвасянов ради страданий во имя Щв06одьки.Как-то так.
Не знаю муха ты, или нет, но мозг у тебя явно хуже чем у нее соображает, раз не понял что я не вхожу в твои 99%.
> Не знаю муха ты, или нет, но мозг у тебя явно хуже чем у нее соображает, раз не понял что я не вхожу в твои 99%.Слушай, я в общем-то не против всяких меньшинств.
Будь это любители гончарства, страданий или маргинальных недо-десктопов.
Но не суди по своим извращениям весь мир.
Смешно слышать призывы думать от анонима, у которого "собственная мысль" навязана большинством (и он этого так и не может осознать)
Что делать, все мы обусловлены. Кроме тебя, конечно, ты у нас оригинал каких мало. Уникум.
> Когда-то SysV init бежал впереди, а теперь остался только в маргинальных дистрах, 1% от 1%. Думай теперь.А мейнстрим-инитом (ну и до кучи много еще чем) в не-маргинальных дистрах вместо гнутого клона SysV -- стал инит от разраба из МС, поддерживаемый Ай-Би-Эмой. И чо думать-то?
> стал инит от разраба из МСВот почему вы все так любят врать?
СистемД начали в 2010, в 2011 уже заменили апстарт на него в федоре.
В 2012 выкинули на мороз SysVinit из Arch Linux.
Ну и наконец в 2014 к ним присоединились Дебиан и Убунту.
И все это время - 2008 по 2022 - Поттеринг работал в Red Hat.А теперь вопрос - при чем тут разраб мелкософта?
Вам лишь бы ляпнуть? Или когда видите "мелкософт" глаза кровью наливаются и мозг перестает работать? Не то чтобы он и раньше у вас хорошо работал... но сейчас вапще ахтунг какой-то.
>> стал инит от разраба из МС
> Вот почему вы все так любят врать?
> СистемД начали в 2010, в 2011 уже заменили апстарт на него вГде _сейчас_ работает Поттеринг? Он уже _перестал_ быть "разрабом из МС"? Или перестал обильно коммитить в свое детище? (подсказка: неа).
Интересно, почему фанаты системды так любят обвинять других во вранье? Видимо, у кого что болит.> А теперь вопрос - при чем тут разраб мелкософта?
> Вам лишь бы ляпнуть? Или когда видите "мелкософт" глаза кровью наливаются и
> мозг перестает работать? Не то чтобы он и раньше у вас
> хорошо работал... но сейчас вапще ахтунг какой-то.Местная классика в целом и классика системд-фанбоев в частности - сначала "вы фсе врети!", c плавным переходом - "ты дурак! Вот! Поэтому все - нисчитаица!".
> Где _сейчас_ работает Поттеринг?А какая разница _где сейчас_ он работает, если основные работы по системд были сделаны за 10 (десять!) лет до его ухода из Шапки?
> Или перестал обильно коммитить в свое детище?
А с чего бы он должен был переставать коммитить, если детище его?
> c плавным переходом - "ты дурак!"
Ну как бы да))
Ты настолько пытаешься натянуть сову на глобус, что она сейчас лопнет.
> А какая разница _где сейчас_ он работает, если основные работы по системд были сделаны за 10 (десять!) лет до его ухода из Шапки?И вы до сих пор сидите на той версии системды, да? Ну или версии 2022 года, без всяких фиксов? Или опять "это другое, вы все врети!"?
Ладно-ладно, Поттеринг на самом деле белый и пушистый и его переход к "̵л̵ю̵т̵о̵м̵у̵ ̵в̵р̵а̵г̵у̵ ̵о̵п̵е̵н̵с̵о̵р̵с̵а̵,̵ ̵р̵а̵з̵р̵а̵б̵а̵м̵ ̵м̵а̵з̵д̵а̵й̵к̵и̵"̵ "лучшему другу опенсорса, платиновому спонсору" - заброс гнутого разведчика для лучшего контроля ситуации, а не "ничего личного, джаст бизнес".
>> Или перестал обильно коммитить в свое детище?
> А с чего бы он должен был переставать коммитить, если детище его?И делает он это (113 коммитов за январь, 2800 за прошлый год, 4300 за позапрошлый)
https://github.com/poettering/systemd/activity?actor=poettering
конечно же исключительно в свободное время, вместо сна.> Ну как бы да))
> Ты настолько пытаешься натянуть сову на глобус, что она сейчас лопнет.Совы, глобусы ...
Факт в том, что автор (и по совместительству, до сих пор самый активный разраб, причем объем коммитов там нехилый) системды - разработчик из "мелкософта".
Не менее факт - системда является "мейнстримным" инитом для GNU/Linux дистрибутивов.И никакие вопли фанатов вида "мозг не работает!" и "глаза че-то-там-кровью" - никак не изменят реальность, увы для них.
> И вы до сих пор сидите на той версии системды, да?
> Ну или версии 2022 года, без всяких фиксов?Ты не поверишь! Вот прям сейчас systemd 247. Релиз от Thu Nov 26 18:03:35 UTC 2020.
Ну и немного патчей и багфиксов, которые бекпортнули дебианцы.
До перехода Поттеринга в мелкософт оставалось два года)))> а не "ничего личного, джаст бизнес".
Как будто в этом есть что-то плохое.
> И делает он это (113 коммитов за январь, 2800 за прошлый год, 4300 за позапрошлый)
> конечно же исключительно в свободное время, вместо сна.Отличная продуктивность! Завидуешь?))
Угу, а сколько он сделал коммитов в 2022м? в 2021? в 2012? НоЭтоДругое?))> Факт в том, что автор (и по совместительству, до сих пор самый активный разраб,
> причем объем коммитов там нехилый) системды - разработчик из "мелкософта".
> Не менее факт - системда является "мейнстримным" инитом для GNU/Linux дистрибутивов.Факт в том, что сотрудник РедХат больше десяти лет писал инит, которыей всего за 4 года выбросил на помойку практически все 6omжоиниты и вонючие башпортянки и стал де-факто стандартом индустрии.
Факт в том, что только через 8 лет после этого его разраб перешел в мелкософт.
Факт в том, что это его самое успешное творение, в отличие от напр. пшш-пшш-аудио, где идея была хороша, а вот реализация так себе.
Факт в том, что мелкософт, как платиновый спонсор заинтересована в дальнейшем его развитии - они на азурах очень неплохо зарабатывают, намного больше чем на десктопной винде - поэтому они позволяют - читай оплачивают - своему сотруднику возможность продолжать работать над системд.И вот это реальность ты изменить никак не сможешь)))
Поэтому можешь продолжать вопить "майкрософт!!! заговор!!1111"ЗЫ: интересно, если Линуса все достанет и он перейдет в майкрософт или ibm, ты тоже будешь говорить "Сотрудник мелкософта написал ядро"?
я всё чаще думаю, что неплохо бы для ЦА раста запилить какой-нибудь микросервис по подписке с "ИИ". судя по некоторым местным комментариям, половина здешних анонимов сразу же побегут нести мне мешками свои кровно заработанные очередными градусами сколиоза
А в этом и необходимости нет. Пусть бегут.
Как будто во всех дистрах самые последние гнутые корутилсы?
В stable deb 9.1, в unstable - 9.5. А последняя версия вообще 9.6. И живут как-то.Нужно предоставить паритет даже не на 95%, а и на 90% хватит.
>Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, способной работать в том числе на платформах Windows, Redox и Fuchsia.Про то, что оно не будет работать кроссплатформенно на линуксе и бсд, мы и так уже знали.
> Про то, что оно не будет работать кроссплатформенно на линуксе и бсд, мы и так уже знали.Не будет?
Дядя ты совсем бобо?
У них бздя и линукс в tier 1. Там даже CI есть)
https://uutils.github.io/coreutils/docs/platforms.html
Все утилиты из пакета реализованы?
Все опции реализованы?
Какой размер?
нет
нет
да
Никто не задаётся вопросом, почему уже 4 года пилят полный аналог имеющегося софта с готовыми алгоритмами, документацией и тестами и никак не допилят? А ответ прост: на растовский код уходит сильно больше времени чем на сишный. Типа часть проблем с памятью решает? Ну ок.
По твоему переписать весь GNU с нуля на C можно за 4 года или даже быстрее?
это не по-евойму, это факт
Его и за пол года можно переписать, всё дело в затрачиваемых ресурсах.
> Его и за пол года можно переписать, всё дело в затрачиваемых ресурсах.Звучит как "9 баб могут родить за 1 месяц".
>> Его и за пол года можно переписать, всё дело в затрачиваемых ресурсах.
> Звучит как "9 баб могут родить за 1 месяц".Это другая крайность. Но для такого проекта вполне подходит - утилиты отдельные и в общем-то атомарные. Берешь по ̶о̶д̶н̶о̶й̶ ̶б̶а̶б̶е̶ одному разрабу на утилиту и пусть себе рожает.
А вот был бы монолит... тогда да.Но ресурсы - это же не только количество людей. Это еще и время.
Одно дело когда у тебя есть разраб на фултайме, а другое когда писака пишет по вечерам после работы от силы пару раз в неделю, ну и может еще на выходных вместо личной жизни))
Результат по срокам будет ооочень разный.
> для такого проекта вполне подходит - утилиты отдельные и в общем-то атомарные. Берешь по ̶о̶д̶н̶о̶й̶ ̶б̶а̶б̶е̶ одному разрабу на утилиту и пусть себе рожает.А как же повторное использование кода? Например, в ряде утилит есть опция -h, чтобы размеры выводились бы в более удобном для человека виде, что теперь пускай каждый разработчик для каждой утилиты реализует это самостоятельно? В ряде утилит есть опция, запрашивающая придерживаться одной фс, не переходя по симлинкам или маунтам на другие, и? Помимо этого, навскидку, можно вспомнить поддержку уродского i18n, с его LC_*, которая нужна всем утилитам.
Но проблема не только в том, что существуют вещи, которые можно шарить между утилитами, проблема ещё и в том, что полный список таких вещей возможно составить только после того, как ты переписал все утилиты.
> А как же повторное использование кода? Например, в ряде утилит есть опция
> -h, чтобы размеры выводились бы в более удобном для человека виде,
> что теперь пускай каждый разработчик для каждой утилиты реализует это самостоятельно?Эм... ну для этого как бы есть планирование и возможность обсудить кто и что делает.
Ты можешь на старте договориться, что делаешь, а потом синкаться и обсужать - есть ли что-то общее. Разумеется это будет работать не на 100% и где-то будут факапы, но ускорение от параллелизма будет профитней.> Но проблема не только в том, что существуют вещи, которые можно шарить
> между утилитами, проблема ещё и в том, что полный список таких
> вещей возможно составить только после того, как ты переписал все утилиты.Нет, ты просто пишешь по одной утилите и синкаешься с коллегами в процессе.
А далее или первый дошедший пишет с нуля, или переиспользует реализацию.
Для поддержания "осведомленности" - добавляешь их на ревью, чтобы они хоть знали где что есть.Хуже будет только есть в оригинальных утилитах окажется несколько реализаций. Причем с некими минорными, но очень значимыми в редких случаях отличиями в поведении.
Тогда придется городить костыли и параметризировать все особые случаи.
> Эм... ну для этого как бы есть планирование и возможность обсудить кто и что делает.То есть это уже не ситуация, когда разработчики работают независимо, они вынуждены синхронизироваться друг с другом, и они получают констрайнты на порядок выполнения работ.
> Нет, ты просто пишешь по одной утилите и синкаешься с коллегами в процессе.
> А далее или первый дошедший пишет с нуля, или переиспользует реализацию.Ты в результате получишь вместо шаред кода груду костылей, которую сделали под один случай, потом изолентой примотали возможность использовать их в ещё одном случае, потом всплыл третий юзкейс, и изолентой примотали немного ещё, и тп.
Или если существующая реализация переписывается, вместо использования изоленты, то во-первых, придётся переписывать и код, использующий этот API, а во-вторых, вероятно, это придётся делать несколько раз. И в любом случае придётся синхронизироваться со всеми, кто уже столкнулся с нуждой в данной функциональностью и в перспективе со всеми, кому она ещё понадобится.
Это можно сделать, и даже без изоленты, но это уже ситуация которая вовсе не похожа на "каждый разработчик пишет свою утилиту независимо от других".
> А как же повторное использование кода? Например, в ряде утилит есть опция -h, чтобы размеры выводились бы в более удобном для человека виде, что теперь пускай каждый разработчик для каждой утилиты реализует это самостоятельно?А когда это все писалось, то оно как было?
Сели, составили план, обсудили где можно вынести в общие функции.
Или, скорее всего, каждый писал как мог, а потом рефакторили?> Но проблема не только в том, что существуют вещи, которые можно шарить между утилитами, проблема ещё и в том, что полный список таких вещей возможно составить только после того, как ты переписал все утилиты.
Или просто откроешь код со свободной лицензией, например БСДшную реализацию и смотришь что они вынесли в общее.
И все)
> просто откроешь код со свободной лицензией, например БСДшную реализацию и смотришь что они вынесли в общее.Это не сработает, точнее это будет андерутелизацией Rust'а. Раст, по сравнению с C, позволяет гораздо более сложные вещи выносить в модули. Простейший пример тому -- это динамический массив. В C нет в стандартной библиотеке динамического массива и не будет никогда, потому что такое в C можно реализовать разве что через массив указателей на void. В C динамические массивы выпиливаются каждым программистом по месту, и для Cшной программы совершенно нормально иметь несколько реализаций динамического массива для разных типов аргументов.
Раст достаточно отличен от C, чтобы игнорировать абстракции C, и создавать новые.
> Сели, составили план, обсудили где можно вынести в общие функции.
Это идеальный план, который может не сработать. Запланированные наперёд абстракции имеют тенденцию не работать. Именно поэтому ты можешь горы оверинженеринга в корпокоде: они создают абстракции которые призваны работать во всех случаях и ещё кофе заваривать, чтобы вне зависимости от того, как дело пойдёт дальше, не возникло бы необходимости переписывать созданные абстракции и всё уже написанное, что на них опирается.
Ты не слышал про DRY, конкурента ему WET, и всех аргументов вокруг этого? Эти споры возникают не на пустом месте, а как раз как попытка создать методику, которая позволяет избежать и оверинженеринга, и абстракций, к которым задним числом изолентой приматываются новые возможности, которые не догадались заложить в них сразу.
> Это не сработает, точнее это будет андерутелизацией Rust'а. Раст, по сравнению с C, позволяет гораздо более сложные вещи выносить в модули.
> Раст достаточно отличен от C, чтобы игнорировать абстракции C, и создавать новые.Это сработает частично - тк можно будет посмотреть "что получилось общего в коде на СИ".
Т.к переписывающие должны хоть немного его знать, то разницу с растом они думаю понимают.
>> Сели, составили план, обсудили где можно вынести в общие функции.
> Это идеальный план, который может не сработать. Запланированные наперёд абстракции имеют тенденцию не работать. Именно поэтому ты можешь горы оверинженеринга в корпокоде ... вне зависимости от того, как дело пойдёт дальше, не возникло бы необходимости переписывать созданные абстракции и всё уже написанное, что на них опирается.Я и не говорю, что это получится легко и с первого раза.
Можно вообще не оптимизировать, и вынести общий код когда все будет написано - может это будет не сильно дольше чем куча обсуждений.
А можно сделать общий минимальный код, а все остальное в след итерацию.> Ты не слышал про DRY, конкурента ему WET, и всех аргументов вокруг этого? Эти споры возникают не на пустом месте, а как раз как попытка создать методику...
Т.к споры возникают регулярно - значит нет какой-то 100% рабочей методики. Оно сильно зависит от проекта, квалификации программеров и тд
Иногда комбинированные методы дают весьма хорошие результаты.
Речь шла обо всём GNU, а не только о Coreutils. Если взять весь GNU, даже без его невзлетевшего микроядра, переписать даже некоторые отдельные его части за пол года совершенно нереально. Например аналоги GCC, GDB, make, bash. Кроме того между многими, даже на много более простыми компонентами GNU существуют зависимости. То есть полностью отделить их разработку друг от друга тоже не получится. Отдельно Coreutils за пол года переписать толпой народа наверное можно, с качеством proof of concept. Затем придётся допиливать, сводить велосипеды в библиотеки и прочее. То есть проект всё равно затянется. Но отдельно неGNUтый Coreutils не имеет большого смысла. Смысл имеет полное переписывание GNU.
Возможно я чего-то не понимаю, но зачем для, например, утилит типа sort, echo, или ls наличие GCC, GDB, make ?
Оно может вполне работать и отдельно. Да и цель у них cross-platform.> Но отдельно неGNUтый Coreutils не имеет большого смысла. Смысл имеет полное переписывание GNU.
Почему?
Аналоги такх же утилит есть в БСД и вообще пошли с юниксов.
> Возможно я чего-то не понимаю, но зачем для, например, утилит типа sort,
> echo, или ls наличие GCC, GDB, make ?
> Оно может вполне работать и отдельно. Да и цель у них cross-platform.Где вы видели настоящий cross-platform? На ум приходит разве что JVM, но это не наш метод.
> > Но отдельно неGNUтый Coreutils не имеет большого смысла. Смысл имеет полное переписывание GNU.
>
> Почему?
> Аналоги такх же утилит есть в БСД и вообще пошли с юниксов.В том-то и дело, что аналоги. GNU изначально задумывалась как полноценная и самодостаточная операционная система. И продолжая традицию предыдущих UNIX систем там так же начали лепить всякого рода расширения и привязки к этим расширениям. С этим пытаются бороться при помощи GNU Autotools и прочих костылей, но это лишь увеличивает сложность дальнейшей разработки, переносимости и поддержки. Поэтому уж если переписывать, то всё скопом, с выкидыванием костылей и прочих велосипедов.
> Почему уже 4 года пилят полный аналог имеющегося софта с готовыми алгоритмами,
> документацией и тестами и никак не допилят?В код там точно подсматривать нельзя, в доку - не уверен что можно.
Поэтому пишут через тесты.> А ответ прост: на растовский код уходит сильно больше времени чем на сишный.
Разумеется. Наомнякать можно быстро. Но потом годами испрвляешь баги.
А тут поход другой - пишешь медленнее, но качественнее.
> Поэтому пишут через тесты.зачем переписывать, если ты даже не понимаешь, как работает то, что ты переписываешь? казалось бы, при чём тут именно раст. а потому что только на нём таким страдают
> если ты даже не понимаешь, как работает то, что ты переписываешь?Кто сказал что не понимаешь? Поведение как раз задокументировано.
Просто нужно соблюдать некую гигиену, чтобы случайно не подцепить гнурак.
А из-за того что он крайне заразен, им даже пришлось сделать отдельное предупреждениеWarning!
uutils is original code and cannot contain any code from GNU or other implementations. This means that we cannot accept any changes based on the GNU source code. To make sure that cannot happen, you cannot link to the GNU source code either.
в github.com/uutils/coreutils/blob/main/CONTRIBUTING.mdЗато в свободный код подсматривай как хочешь:
It is however possible to look at other implementations under a BSD or MIT license like Apple's implementation or OpenBSD.> казалось бы, при чём тут именно раст. а потому что только на нём таким страдают
Казалось бы, метод Clean room design придумали задолго до раста, но откуда анону об этом знать.
И почему нельзя подсматривать в код? Переписывая код с C на Rust никаким образом сплагиатить его не получится.
> И почему нельзя подсматривать в код?Возможно там все равно остаются кусочки кода, который можно именно оттранслировать в раст с поправкой на синтаксив. А дальше уже суд будет решать плагиат это и нарушение лицензии или нет. Ну и прецедентное право дает шанс что решение будет иным, чем в Oracle-vs-Google.
Учитывая, что FSF кроме как судиться ничего не умеет, то лучше не давать этим копирастам лишнего повода прикопаться. Поэтому на всякий случай запретили и добавили Warning.
Желаю этому проекту всяческих успехов. Надеюсь, что он и подобные ему другие проекты на Rust станут годной альтернативой всей той помойки, в которую превратился GNU. Кто хоть раз пробовал собрать бутстрапить GNU из исходников должен понимать о чём я.
А я в принципе пожелаю таким проектам успехов, не ограничиваясь только лишь растом. Как пример, хочется вспомнить саклес, они много работы сделали.
> Кто хоть раз пробовал собрать бутстрапить GNU из исходников должен понимать о чём я.И какие там проблемы? Есть GNU Mes. А для ратса нет ничего для бутстрапа. Только не надо тут кидать их бутстрап, который опирается на бинарь раста более ранней версии. Это не бутстрап.
> И какие там проблемы? Есть GNU Mes. А для ратса нет ничего для бутстрапа. Только не надо тут кидать их бутстрап, который опирается на бинарь раста более ранней версии. Это не бутстрап.Ну т.е. оф. бутстрап gcc, предполагающий наличие ISO С++ 14 компилятора
https://gcc.gnu.org/install/prerequisites.html
"этодругоепониматьнадо!", а
https://github.com/dtolnay/bootstrap
> This repo contains a minimal reliable setup for compiling the most recent stable Rust compiler from source on Linux i.e. without downloading any already compiled Rust binaries from the internet.
> This setup uses mrustc which is an alternative Rust compiler implemented in C++ able to compile certain old versions of rustc and cargo,"нищитаица!"?
>> И какие там проблемы? Есть GNU Mes. А для ратса нет ничего для бутстрапа. Только не надо тут кидать их бутстрап, который опирается на бинарь раста более ранней версии. Это не бутстрап.
> Ну т.е. оф. бутстрап gcc, предполагающий наличие ISO С++ 14 компилятора
> https://gcc.gnu.org/install/prerequisites.html
> "этодругоепониматьнадо!", а
> https://github.com/dtolnay/bootstrap
>> This repo contains a minimal reliable setup for compiling the most recent stable Rust compiler from source on Linux i.e. without downloading any already compiled Rust binaries from the internet.
>> This setup uses mrustc which is an alternative Rust compiler implemented in C++ able to compile certain old versions of rustc and cargo,
> "нищитаица!"?Нет, потому что есть проект GNU Mes, который бутстрапит gcc, а уже из него g++. Для раста и соответственно llvm ничего такого нет.
> Это какой-то ноунейм проект....
> Нет, потому что есть проект GNU Mes, который бутстрапит gcc,Уй да, а GNU Mes - официалка от gcc (но только в альтернативной реальности опеннета).
Писал бы короче - "этодругое!". Я ж предлагал.> А как будет бутстрапиться mrustc? Через копмилятор g++? Об этом автор умалчивает. Так что нет, это не полноценный бутстрап
И какая именно религия мешает забутстрапить g++ тем же Mes?
> а уже из него g++. Для раста и соответственно llvm ничего такого нет.
Начнем с того, что llvm, в принципе, не нужен (есть бэкэнд полностью на расте, правда с обычными проблемами современных самопальных бэкэндов - поддерживаемых архитектур раз-два и обчелся), закончим тем, что llvm -- можно собрать с помощью gcc.
В общем, писал бы короче - "нищитаица".
>> Это какой-то ноунейм проект.
> ...
>> Нет, потому что есть проект GNU Mes, который бутстрапит gcc,
> Уй да, а GNU Mes - официалка от gcc (но только в
> альтернативной реальности опеннета).
> Писал бы короче - "этодругое!". Я ж предлагал.GNU Mes официальный проект GNU и использует в guix. А где используется указанный noname проект с 1 автором не понятно.
>> А как будет бутстрапиться mrustc? Через копмилятор g++? Об этом автор умалчивает. Так что нет, это не полноценный бутстрап
> И какая именно религия мешает забутстрапить g++ тем же Mes?Этого мало. Нужно бутстрапить llvm, чтобы последний компилятор раста работал. Про это вообще ни слова.
>> а уже из него g++. Для раста и соответственно llvm ничего такого нет.
> Начнем с того, что llvm, в принципе, не нужен (есть бэкэнд полностью
> на расте, правда с обычными проблемами современных самопальных бэкэндов - поддерживаемых
> архитектур раз-два и обчелся), закончим тем, что llvm -- можно собрать
> с помощью gcc.Хах. Любитель ржавчины как обычно: есть, но сырое.
> GNU Mes официальный проект GNU и использует в guix.Кекспертиза, аз из. Впрочем, после
>> Кто хоть раз пробовал собрать бутстрапить GNU из исходников должен понимать о чём я.
> И какие там проблемы? Есть GNU Mes.можно было не читать - сразу видно опеннетного теоретика.
> А где используется указанный noname проект с 1 автором не понятно.
Использование Меs, помимо "смотрите, как я могу!" - вообще-то тоже. Сам бы понял, если бы попытался. Но от этого "noname" не перестал работать.
>>> А как будет бутстрапиться mrustc? Через копмилятор g++? Об этом автор умалчивает. Так что нет, это не полноценный бутстрап
>> И какая именно религия мешает забутстрапить g++ тем же Mes?
> Этого мало. Нужно бутстрапить llvm, чтобы последний компилятор раста работал. Про это
> вообще ни слова.Зачем, во имя Вселенной, бутстрапить llvm, если его просто можно собрать из исходников?
Кексперты бы поинтересовались для начала, зачем _вообще_ нужен бутстрап (нет, не для "У самурая нет цели только путь!").
>>> а уже из него g++. Для раста и соответственно llvm ничего такого нет.
>> Начнем с того, что llvm, в принципе, не нужен (есть бэкэнд полностью
>> на расте, правда с обычными проблемами современных самопальных бэкэндов - поддерживаемых
>> архитектур раз-два и обчелся), закончим тем, что llvm -- можно собрать
>> с помощью gcc.
> Хах. Любитель ржавчины как обычно: есть, но сырое.Хах, опеннетный кексперт (никаким боком не причастный ни к разработке бэкэнда gcc, ни к llvm), как обычно спрыгнул с темы и надулся от гордости (собственно, за что? За чужие заслуги?).
Но рассказать, почему тот же QBE c поддержкой 1½ платформ (но зато на труЪ-ЯП) - "этодругоепониматьнадо!" он стестняется.
>> GNU Mes официальный проект GNU и использует в guix.
> Кекспертиза, аз из. Впрочем, после
>>> Кто хоть раз пробовал собрать бутстрапить GNU из исходников должен понимать о чём я.
>> И какие там проблемы? Есть GNU Mes.
> можно было не читать - сразу видно опеннетного теоретика.Переход на личности происходит, когда нечего сказать по делу. Показывать непонятный проект без бутстрапа исходного компилятора и говорить, что это аналог готовому решению, просто не выдерживает никакой критики.
>> А где используется указанный noname проект с 1 автором не понятно.
> Использование Меs, помимо "смотрите, как я могу!" - вообще-то тоже. Сам бы
> понял, если бы попытался. Но от этого "noname" не перестал работать.Во-первых, где используется GNU Mes написано на странице проекта и это работает. Во-вторых, noname проект не понятно, где используется и работает ли. Очень сомневаюсь, что вы выделяли 150 Гб и пробовали.
>>>> А как будет бутстрапиться mrustc? Через копмилятор g++? Об этом автор умалчивает. Так что нет, это не полноценный бутстрап
>>> И какая именно религия мешает забутстрапить g++ тем же Mes?
>> Этого мало. Нужно бутстрапить llvm, чтобы последний компилятор раста работал. Про это
>> вообще ни слова.
> Зачем, во имя Вселенной, бутстрапить llvm, если его просто можно собрать из
> исходников?Чтобы собрать из исходников, нужно собрать компилятор из исходников, чтобы быть уверенным, что бинарь не был скомпрометирован.
>>>> а уже из него g++. Для раста и соответственно llvm ничего такого нет.
>>> Начнем с того, что llvm, в принципе, не нужен (есть бэкэнд полностью
>>> на расте, правда с обычными проблемами современных самопальных бэкэндов - поддерживаемых
>>> архитектур раз-два и обчелся), закончим тем, что llvm -- можно собрать
>>> с помощью gcc.
>> Хах. Любитель ржавчины как обычно: есть, но сырое.
> Хах, опеннетный кексперт (никаким боком не причастный ни к разработке бэкэнда gcc,
> ни к llvm), как обычно спрыгнул с темы и надулся от
> гордости (собственно, за что? За чужие заслуги?).Во-первых, про сырой бэкенд компилятора сказали вы. Во-вторых, тема осталась та же: бутстрап и неподготовленность к нему всей инфраструктуры раста. Предложение скачать бинарь компилятора и потом им все собирать - абсурд.
>> Хах. Любитель ржавчины как обычно: есть, но сырое.
> Переход на личности происходит, когда нечего сказать по делу.Самокритично.
Но вот тебе по делу:
> GNU Mes официальный проект GNU и использует в guixhttps://savannah.nongnu.org/projects/mescc-tools
> This group is not part of the GNU Project.А вот - "как оно на самом деле", а не "И какие там проблемы? Есть GNU Mes.":
https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-.../> Показывать непонятный проект без бутстрапа исходного компилятора и говорить, что это аналог готовому решению, просто не выдерживает никакой критики.
"Готовое" оно правда лишь у комментаторов опеннета, дальше заголовка не читавших.
Вбивать hex0 ручками в загруженную с MBR программу ввода они не пробовали (и даже, возможно, не подозревали о необходимости этой "детали").>> Зачем, во имя Вселенной, бутстрапить llvm, если его просто можно собрать из
>> исходников?
> Чтобы собрать из исходников, нужно собрать компилятор из исходников, чтобы быть уверенным, что бинарь не был скомпрометирован.Еще раз, какие именно религиозные догмы мешают собрать LLVM с помощью GCC?
(Я ж даже не спрашиваю, проверял ли кто сорц GCC на предмет компрометации, о замене проприетарного BIOS на либребут и использовании проца без PSP/ME вообще не заикаюсь).> Во-первых, про сырой бэкенд компилятора сказали вы. Во-вторых, тема осталась та же:
> бутстрап и неподготовленность к нему всей инфраструктуры раста.Во-первых, в том же бэкэнде gcc или llvm - докрена _человеколет_ работы (в том числе и тестирования), но да, хихикать, стоя на плечах гигантов довольно просто.
Во-вторых: советую все же посмотреть в _деталях_ и почитать доку к gnu mes/бутстрапу (ну или хотя бы посмотреть на дату его появления) - то же самое верно и для современных си/плюсов.
> Предложение скачать бинарь компилятора и потом им все собирать - абсурд.Так и запишем: официальный GCC bootstrap, по мнениею авторитетного опеннетчика - абсурд.
>>> Хах. Любитель ржавчины как обычно: есть, но сырое.
>> Переход на личности происходит, когда нечего сказать по делу.
>
> Самокритично.
> Но вот тебе по делу:
>> GNU Mes официальный проект GNU и использует в guix
>
>https://savannah.nongnu.org/projects/mescc-tools
>> This group is not part of the GNU Project.Вот ссылка https://savannah.gnu.org/projects/mes
> https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-.../
А теперь, пожалуйста, аналогичную для раста.
> "Готовое" оно правда лишь у комментаторов опеннета, дальше заголовка не читавших.
> Вбивать hex0 ручками в загруженную с MBR программу ввода они не пробовали (и даже, возможно, не подозревали о необходимости этой "детали").В чем проблема?
> Еще раз, какие именно религиозные догмы мешают собрать LLVM с помощью GCC?
Где про это сказано в noname проекте, который вы так отчаянно показывали? Вы только недавно показывали как собрать бинарь раст g++, но там предполагается, что g++ уже есть.
>> Во-первых, про сырой бэкенд компилятора сказали вы. Во-вторых, тема осталась та же:
>> бутстрап и неподготовленность к нему всей инфраструктуры раста.
>Во-первых, в том же бэкэнде gcc или llvm - докрена _человеколет_ работы (в том числе и тестирования), но да, хихикать, стоя на плечах гигантов довольно просто.
> Во-вторых: советую все же посмотреть в _деталях_ и почитать доку к gnu mes/бутстрапу (ну или хотя бы посмотреть на дату его появления) - то же самое верно и для современных си/плюсов.Во-первых, "хихикаете" тут только вы. Вопрос бутстрапинга (я сейчас если что возвращаюсь к теме, от которой вы хотите убежать в сторону) не решен в расте и llvm. Ничего тут смешного нет.
Во-вторых, не понятно, причем тут дата появления?
>> Предложение скачать бинарь компилятора и потом им все собирать - абсурд.
> Так и запишем: официальный GCC bootstrap, по мнениею авторитетного опеннетчика - абсурд.Опять переход на личности. Да, абсурд, потому что вот откуда вы уверены, что в первоначальном компиляторе нет закладок? Правильный процесс описан здесь https://stackoverflow.com/a/65708958
hex0 -> hex1 -> hex2 -> M0 -> M2-Planet -> Mes -> Mescc -> TCC -> GCC
> Да, абсурд, потому что вот откуда вы уверены, что в первоначальном компиляторе нет закладок? Правильный процесс описан здесь https://stackoverflow.com/a/65708958
> hex0 -> hex1 -> hex2 -> M0 -> M2-Planet -> Mes -> Mescc -> TCC -> GCCДавай еще по пунктам:
1. Инструкция с офф. сайт GCC гласит gcc.gnu.org/install/prerequisites.html
Tools/packages necessary for building GCC
ISO C++14 compiler
не является авторитетной.2. Инструкция от анонимного васяна со stackoverflow - гораздо надежнее.
3. Про подписи/хеши и прочие механизмы подтверждения целостности бинарников никто не слышал.
4. Если бекдор или закладка будет в бинарнике от авторов GCC, то думаю оно будет прямо в исходных кодах.
>> Да, абсурд, потому что вот откуда вы уверены, что в первоначальном компиляторе нет закладок? Правильный процесс описан здесь https://stackoverflow.com/a/65708958
>> hex0 -> hex1 -> hex2 -> M0 -> M2-Planet -> Mes -> Mescc -> TCC -> GCC
> Давай еще по пунктам:
> 1. Инструкция с офф. сайт GCC гласит gcc.gnu.org/install/prerequisites.html
> Tools/packages necessary for building GCC
> ISO C++14 compiler
> не является авторитетной.Вы путает install/building с bootstraping.
> 3. Про подписи/хеши и прочие механизмы подтверждения целостности бинарников никто не слышал.
Руками будете считать? Это тоже надо чем-то собрать.
> 4. Если бекдор или закладка будет в бинарнике от авторов GCC, то
> думаю оно будет прямо в исходных кодах.Не факт.
> Вы путает install/building с bootstraping.Неа.
Я просто пришел на сайт GCC и спрашиваю "как мне получить ваш компилятор".
И они не начинают несть бред "вам обязательно нужно взять священное писание с камменой скридали, написать на бумажку, потом набить hex кодами и вот тогда вы получите...".
Они просто пишут "можете скачать бинарник прямо тут у нас".Кому у меня больше доверия - создателям гцц или каким-то чувакам со стековерфлоу?
(вопрос риторический)>> 3. Про подписи/хеши и прочие механизмы подтверждения целостности бинарников никто не слышал.
> Руками будете считать? Это тоже надо чем-то собрать.О, так у нас нет ничего кроме компа с пустым диском и бумажки?
А как ты получишь заветные hex0 -> hex1 -> hex2 ?
Из интернета скачешь? Или они в библиотеке записаны в талмуде?>> 4. Если бекдор или закладка будет в бинарнике от авторов GCC, то думаю оно будет прямо в исходных кодах.
> Не факт.Конечно не факт) Тут найти рабочий пример бекдора в цепочке поставки компилятора - уже задача со зведочкой.
А вот баг в компиляторе который уязвимость - запросто
opennet.ru/opennews/art.shtml?num=59763
>[оверквотинг удален]
> Неа.
> Я просто пришел на сайт GCC и спрашиваю "как мне получить ваш
> компилятор".
> И они не начинают несть бред "вам обязательно нужно взять священное писание
> с камменой скридали, написать на бумажку, потом набить hex кодами и
> вот тогда вы получите...".
> Они просто пишут "можете скачать бинарник прямо тут у нас".
> Кому у меня больше доверия - создателям гцц или каким-то чувакам со
> стековерфлоу?
> (вопрос риторический)Вопрос не в этом. Вы опять в сторону уходите. Мы говорили про бутстрапинг. Ни gcc, ни rust не будут про него писать в руководстве по установке, к сожалению.
>>> 3. Про подписи/хеши и прочие механизмы подтверждения целостности бинарников никто не слышал.
>> Руками будете считать? Это тоже надо чем-то собрать.
> О, так у нас нет ничего кроме компа с пустым диском и
> бумажки?Да, как иначе?
> А как ты получишь заветные hex0 -> hex1 -> hex2 ?
> Из интернета скачешь? Или они в библиотеке записаны в талмуде?Не важно. Суть в начальных этапах, что код максимально простой, его немного и его можно прочитать. Об этом написано тут https://github.com/oriansj/stage0
>>> 4. Если бекдор или закладка будет в бинарнике от авторов GCC, то думаю оно будет прямо в исходных кодах.
>> Не факт.
> Конечно не факт) Тут найти рабочий пример бекдора в цепочке поставки компилятора
> - уже задача со зведочкой.
> А вот баг в компиляторе который уязвимость - запросто
> opennet.ru/opennews/art.shtml?num=59763Еще раз: мы говоим про разные векторы атаки. Сборка "проверенным" компилятором закрывают одну из них.
> Вопрос не в этом. Вы опять в сторону уходите. Мы говорили про бутстрапинг.Именно.
Началось все с "А для ратса нет ничего для бутстрапа."
Причем без объяснения нафига это нужно)
В стиле "порш плохая машина, больше двух мешков картошки в багажник не влазят".> Ни gcc, ни rust не будут про него писать в руководстве по установке, к сожалению.
И не нужно. Если кто-то хочет заниматься извращениями, то пусть пишет инструкцию сам.
Но и отношение к серьезности его заявлений, будут прямо пропорцианальны степени его извращенности.>> О, так у нас нет ничего кроме компа с пустым диском и бумажки?
> Да, как иначе?И микросхема биоса тоже пустая, контроллер дисков, куча всяких МК на матплате?
Можно все, что угодно довести до абсурда.>> А как ты получишь заветные hex0 -> hex1 -> hex2 ?
>> Из интернета скачешь? Или они в библиотеке записаны в талмуде?
> Не важно.Неа, очень важно. Вдруг вражина-шпийон туда прокрадется и карандашиком подправит один символ.
> Суть в начальных этапах, что код максимально простой, его немного и его можно прочитать. Об этом написано тут https://github.com/oriansj/stage0
О, так у нас тут священное писание, полное волшебных констант.
> Еще раз: мы говоим про разные векторы атаки. Сборка "проверенным" компилятором закрывают одну из них.
Какую?
Я в нескольких темах раньше просил привести пример успешной атаки.
И не получил ни одного.
Реально как басня про хакера и солонку.
>> Вопрос не в этом. Вы опять в сторону уходите. Мы говорили про бутстрапинг.
> Именно.
> Началось все с "А для ратса нет ничего для бутстрапа."
> Причем без объяснения нафига это нужно)
> В стиле "порш плохая машина, больше двух мешков картошки в багажник не
> влазят".Вопрос ремонтопригодности у хороших инженеров на первом месте. Иначе, получаем фольксвагенгрупп, в которой без диллерской сети мастерских и сертифицированного оборудования никуда не уехать. Точно также, если для сборки компилятора вам нужен некий бинарник - вызывает вопросы о контролиуремости вашей системы в целом.
>> Ни gcc, ни rust не будут про него писать в руководстве по установке, к сожалению.
> И не нужно. Если кто-то хочет заниматься извращениями, то пусть пишет инструкцию
> сам.
> Но и отношение к серьезности его заявлений, будут прямо пропорцианальны степени его
> извращенности.Иметь контроль над программой - это не изврашение.
>>> О, так у нас нет ничего кроме компа с пустым диском и бумажки?
>> Да, как иначе?
> И микросхема биоса тоже пустая, контроллер дисков, куча всяких МК на матплате?Опять уход в сторону. Мы не говорим о железе сейчас.
> Можно все, что угодно довести до абсурда.
>>> А как ты получишь заветные hex0 -> hex1 -> hex2 ?
>>> Из интернета скачешь? Или они в библиотеке записаны в талмуде?
>> Не важно.
> Неа, очень важно. Вдруг вражина-шпийон туда прокрадется и карандашиком подправит один символ.Поэтому я написао выше "что код максимально простой, его немного и его можно прочитать".
>> Еще раз: мы говоим про разные векторы атаки. Сборка "проверенным" компилятором закрывают одну из них.
> Какую?
> Я в нескольких темах раньше просил привести пример успешной атаки.
> И не получил ни одного.
> Реально как басня про хакера и солонку.Басня - это про безопасность скачивания с интернета. Искать инфу за вас, я не намерен. Тем более учитывая ваш стиль общения и дешевый тролинг. Только недалекий человек может отрицать ползеность бустрапинга.
> Вопрос ремонтопригодности у хороших инженеров на первом месте.О, начинется передергивание))
Ремотнопригодность это как?
Наличие готовых запчастей или возможность выплавить шаровую опору по чертежам и металла из пивных банок?> Точно также, если для сборки компилятора вам нужен некий бинарник - вызывает вопросы о контролиуремости вашей системы в целом.
Вы доверяете авторам компилятора? А ведь там может быть бекдор.
В схеме hex0 -> hex1 -> ... уже примерно на TCC или GCC колво кода не позволит прочитать и аудировать его.> Иметь контроль над программой - это не изврашение.
Есть такое понятие как достаточность.
Получить от разработчика (которому вы, наверное, доверяете) бинарь подписанный его подписью - это достаточно для миллионов нормальных людей.> Поэтому я написао выше "что код максимально простой, его немного и его можно прочитать".
Его да.
А код M2-Planet? А код Mescc или TCC - осилите прочитать полностью?> Басня - это про безопасность скачивания с интернета.
Ты прямо сейчас на свой комп качаешь данные с сайта опеннет, включая скрипты.
Причем ты его качаешь в браузер в котором 100% есть уязвимости, через роутер в котором тоже могут быть уязвимости и тд.
Срочно прекращай, а вдруг что-то плохое случится.> Искать инфу за вас, я не намерен.
Т.е слился?
Понял-принял.> Тем более учитывая ваш стиль общения и дешевый тролинг.
Дешевый?! Это уже оскорбление.
> Только недалекий человек может отрицать ползеность бустрапинга.
Например создатели GCC, clang и даже создатели TCC!
Того самого который вы же предлагаете для бутстрапа.
bellard.org/tcc/ -> кнопка Download и видим те самые бинарники.
Как жаль что такие люди, оказались "недалекими"(((
>> Вопрос ремонтопригодности у хороших инженеров на первом месте.
> О, начинется передергивание))
> Ремотнопригодность это как?
> Наличие готовых запчастей или возможность выплавить шаровую опору по чертежам и металла
> из пивных банок?Это ответ на передергивание с вашей стороны.
>> Точно также, если для сборки компилятора вам нужен некий бинарник - вызывает вопросы о контролиуремости вашей системы в целом.
> Вы доверяете авторам компилятора? А ведь там может быть бекдор.
> В схеме hex0 -> hex1 -> ... уже примерно на TCC или
> GCC колво кода не позволит прочитать и аудировать его.Вы не читаете мои сообщения или пытаетесь уйти в сторону. Уже ответил выше: это 2 разных ветора атаки.
>> Иметь контроль над программой - это не изврашение.
> Есть такое понятие как достаточность.
> Получить от разработчика (которому вы, наверное, доверяете) бинарь подписанный его подписью
> - это достаточно для миллионов нормальных людей.Миллионы мух не могут ошибаться? Чего мелочиться, даже неподписанным пакетам из pypi или npm доверяют миллионы людей (нормальных?) каждый день, а уязвимости в них находят постоянно.
>> Поэтому я написао выше "что код максимально простой, его немного и его можно прочитать".
> Его да.
> А код M2-Planet? А код Mescc или TCC - осилите прочитать полностью?mescc да, он же на лиспе. Но еще раз: это 2 разных ветокра атаки. Уже выше же ответил. Мы начинаем без бинаря вообще. Вы спрашиваете: а как так? А вот так простой код, который можно прочитать. Мы этому доверяем, потому что прочитали и поняли, а далее уже доверяем софту выше. Можете не доверять, тогда нужно его изучать. Но это уже одельный разговор.
>> Басня - это про безопасность скачивания с интернета.
> Ты прямо сейчас на свой комп качаешь данные с сайта опеннет, включая
> скрипты.
> Причем ты его качаешь в браузер в котором 100% есть уязвимости, через
> роутер в котором тоже могут быть уязвимости и тд.
> Срочно прекращай, а вдруг что-то плохое случится.Сразу после вас.
>> Искать инфу за вас, я не намерен.
> Т.е слился?
> Понял-принял.Хочу, чтобы вы поработали головой хоть немножко.
>> Тем более учитывая ваш стиль общения и дешевый тролинг.
> Дешевый?! Это уже оскорбление.
>> Только недалекий человек может отрицать ползеность бустрапинга.
> Например создатели GCC, clang и даже создатели TCC!
> Того самого который вы же предлагаете для бутстрапа.
> bellard.org/tcc/ -> кнопка Download и видим те самые бинарники.
> Как жаль что такие люди, оказались "недалекими"(((Вы опять путаете скачивание и бутстрапинг. Выше вам уже писал. Перечитайте.
> Миллионы мух не могут ошибаться?К счастью люди - не мухи.
99% людей не совершают преступления.
99% людей не кушают какашки.
98% людей выполняют ПДД.
Если вы хотите ориентироваться на "особенных" то ваше право.> Чего мелочиться, даже неподписанным пакетам из pypi или npm доверяют миллионы людей (нормальных?) каждый день, а уязвимости в них находят постоянно.
Или подписанному ядру линукс в котором бекдоры живут по 10 лет.
> mescc да, он же на лиспе. Но еще раз: это 2 разных ветокра атаки. Уже выше же ответил. Мы начинаем без бинаря вообще.
Это понятно.
> Вы спрашиваете: а как так? А вот так простой код, который можно прочитать. Мы этому доверяем, потому что прочитали и поняли,Это тоже.
> а далее уже доверяем софту выше. Можете не доверять, тогда нужно его изучать. Но это уже одельный разговор.Звучит как "я проверил чистоту чашки, чистоту ложки, пересчитал чаинки, а потом вылил туда что-то из термоса, который нашел на автобусной остановке в бутово"
Вот тут мне уже совершенно непонятно.> Хочу, чтобы вы поработали головой хоть немножко.
Я и поработал. Даже почитал форумы, где люди рассказывают страшилки, но ни одного рабочего пример не приводят.
>>> Только недалекий человек может отрицать ползеность бустрапинга.
>> Например создатели GCC, clang и даже создатели TCC!
>> Как жаль что такие люди, оказались "недалекими"(((
> Вы опять путаете скачивание и бутстрапинг. Выше вам уже писал. Перечитайте.Нет не путаю.
Я обращаю ваше внимание, что ни один из упомянутых создателей компилятора, не пишет о чрезвычайной важности бутстрапинга. Хотя в компиляторах они, я думаю, разбираются.
> https://github.com/dtolnay/bootstrapЭто какой-то ноунейм проект. А как будет бутстрапиться mrustc? Через копмилятор g++? Об этом автор умалчивает. Так что нет, это не полноценный бутстрап.
18k звезд у проекта, который даже до релиза не дорос. И не говорите после этого, что растровые проекты не накручивают специально
Это у всех шлаковых проектов. Например, звезд у раскраски консоли на жс больше чем у апача.
Желающих кастомизировать символы в колнсольке школьников на манер хакеров заметно больше, чем админов сайтов.
Зачем апачу звезды на гитхабе там же просто зеркало и какой-то особой пользы оно не несёт.Ну а вообще звезда этотдобпвление в избранное типо что бы не потерять потом если что посмотреть что стало с проектом.
Так что не вижу смысла ставить звезды bash потому что всегда помогу посмотреть в пакетном менеджере где домашняя страница.
> Зачем апачу звезды на гитхабе там же просто зеркало и какой-то особой
> пользы оно не несёт.
> Ну а вообще звезда этотдобпвление в избранное типо что бы не потерять
> потом если что посмотреть что стало с проектом.Это идет в разрез с тем, что вы сказали выше. Можно вполне хотеть смотреть как развиваетяс проект, хоть это и зеркало. Просто интереса к нему нет, а есть интерес к разным проектам по раскраске консоли.
К тому же есть закладки в браузере.
> Так что не вижу смысла ставить звезды bash потому что всегда помогу
> посмотреть в пакетном менеджере где домашняя страница.А как объясните звезды вот этого персонажа https://github.com/sindresorhus/ ?
Разбудите меня и спросите, что будет через 10 лет. Я отвечу: выходят новости по переписыванию очередного проекта на раст, которому не видно конца; в них те, кто не пишут на расте спорят с теми, кто не пишет на си.
FF тоже пилят пидят, всё допилить не могут 🤣
> Опубликован выпуск проекта uutils coreutils 0.0.29, развивающего аналог пакета GNU Coreutils, написанный на языке Rust.С учётом того, что пилит его Сильвестр Ледру, к этому проекту следует относиться серьёзно.
Особенно, если обратить внимание на Goals: uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.
Конкретно эти ребята -- доведут дело до конца. Они прикормленные. Через несколько лет у нас будет coreutils под пермиссивной лицензией.
>С учётом того, что пилит его Сильвестр Ледру, к этому проекту следует относиться серьёзно.Относимся серъёзно.
>Конкретно эти ребята -- доведут дело до конца. Они прикормленные. Через несколько лет у нас будет coreutils под пермиссивной лицензией.
Этому не бывать. Пусть сами бздуны и растаманы uutils используют. Не позволим экосистему GNU/Linux разрушить
> Этому не бывать. Пусть сами бздуны и растаманы uutils используют. Не позволим экосистему GNU/Linux разрушитьЛол, типа вас будет кто-то спрашивать.
Системд скушали.
Дроп ХОрга скушали.
Раст в ядро скушали.
И это тоже скушаете.
> Не позволим экосистему GNU/Linux разрушить.При всей моей любови к старым порядкам, чего ради?
Они умудряются контролировать GPL-лицензированные проекты. Это означает лишь то, что GPL не работает. Так что им в целом плевать на лицензирование. Да, с GPL им немного больше геморроя, но вообще говоря у корпов всё настолько зашибись, что им даже сабжевый проект в общем-то по барабану -- иначе бы он пилился гораздо быстрее.
Суть в том, что они сделают с экосистемой всё, что захотят: потому что у них есть ресурсы и единая воля, задающая направление.
Короче, концепция СПО мертва. Нужен новый путь. Не исключено, что в его основу лягут наработки GNU, равно как не исключено, что это могут быть и вещи типа uutils, когда они будут допилены.
> С учётом того, что пилит его Сильвестр Ледру, к этому проекту следует относиться серьёзно.О, звучит круто!
Я за проектом не сильно следил, и думал что это какие-то васяны, которые его бросят через год-два.> Особенно, если обратить внимание на Goals: uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.
Шикарная цель.
Спасибо что написал, пожалуй может тоже поучаствую.> Конкретно эти ребята -- доведут дело до конца. Они прикормленные. Через несколько лет у нас будет coreutils под пермиссивной лицензией.
Наконец-то. А то старые БСДшные уже местами протухли и давно не обновляются.