URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 136916
[ Назад ]

Исходное сообщение
"Для FreeBSD развивают опциональную поддержку компонентов базовой системы на Rust"

Отправлено opennews , 21-Май-25 21:45 
Проект HardenedBSD, занимающийся улучшением механизмов защиты FreeBSD и выпускающий защищённые сборки FreeBSD, представил первые результаты работы по предоставлению возможности использования компонентов пространства пользователя FreeBSD, написанных на языке Rust. Разработка ведётся в отдельной ветке hardened/current/rust-in-base...

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


Содержание

Сообщения в этом обсуждении
"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 21:45 
Очередное подтверждение тому, что за растом будущее. Объяснять его ненужность теперь все сложнее и сложнее. Но сишникам удается!

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 21:58 
Ну... если уже смотреть глобально, то нужность фри еще предстоит объяснить)

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Sadok , 21-Май-25 22:49 
объясни это citrix ли netflix, например. потом возвращайся. по пути к микрософту или к DARPA загляни

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 22:56 
> объясни это citrix ли netflix, например. потом возвращайся.

Ты забыл еще вспомнить плейстейшн)

> по пути к микрософту

А что у мелкомягких?
У них половина бизнеса построена на линуксовых дистрибутивах.

> или к DARPA загляни

А после дарпы заглянем в список топ500 суперкомпов? Или посмотрим с какими ОСь можно купить ноуты (dell/hp и тд)
Или не надо? Ну чтобы убогих не так сильно унижать)

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

ps хотя после этой новости, мое мнение о БСД улучшилось)
судя по всему, хотя бы часть решила развиваться


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено bOOster , 22-Май-25 10:56 
Так netflix достаточно чтобы обьяснить тупым оголтелым то что Linux просто непригоден для RealTime приложений со своей корявой архитектурой и таймингами сетевого стека, значительно худшими чем на FreeBSD

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:00 
> Так netflix достаточно чтобы обьяснить тупым оголтелым то что Linux просто непригоден
> для RealTime приложений

Самое время вспомнить об этом, учитывая что недавно в линухкеренел прирутили вот именно реалтаймные гарантии характерные для RTOS-ов. Так что если хочется блеснуть экспертизой на публику сполна - самое время о реалтайме поговорить :)

А о свободах надо тогда говорить - на примере плейстейшна.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено bOOster , 22-Май-25 11:37 
> Самое время вспомнить об этом, учитывая что недавно в линухкеренел прирутили вот
> именно реалтаймные гарантии характерные для RTOS-ов. Так что если хочется блеснуть

Хехе, то есть этой цитатой ты подтверждаешь что твоя тупая башка просто не понимает что такое вообще RTOS  в своей современной сути?? Кроме расшифровки названия RealTimeOS??
Ну в целом то я и не сомневался в этом.
Какой-то очередной проплаченный бред - реалтаймные гарантии с тупым медленным IP стеком, хуже чем во FreeBSD а уж с реальными RealTimeOS которые работают без многозадачности, коим нахрен многозадачность не нужна уж и подавно.
Вообще конечно - тянуть Linux на устройства которые выполняют единственную задачу что в 99% и есть RTOS - верх тупоумия..


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 08:44 
> Хехе, то есть этой цитатой ты подтверждаешь что твоя тупая башка просто
> не понимает что такое вообще RTOS  в своей современной сути??
> Кроме расшифровки названия RealTimeOS??

Я как раз в курсе что есть RTOS. И буквально пару версий ядер как - в Linux сделали настоящие ртосовые гарантии, что на интервале X реалтайм задача будет работать не менее Y, "хоть там что". Это изначально проектом RTLinux делалось, для управляющих систем, как отдельные патчи. Но примерно пару версий ядра как - майнлайн дорефакторили и смогли вкатить туда! И теперь Linux до кучи - RTOS! Да, большой, стремноватый и жирный RTOS, а включение "RT" не халявное и здорово нагибает экономию питания и добавляет оверхеда. Но в управляющих системах это приемлимо.

И вот тут мы посмотрим - сможет ли ваш сабж во что нибудь сравнимое, или где. Раз уж мы про реалтайм тут песнь завели :).

> Ну в целом то я и не сомневался в этом.

Я тоже не сомневался в вашем таланте удачно похвастаться в правильное время.

> Какой-то очередной проплаченный бред - реалтаймные гарантии с тупым
> медленным IP стеком,

Он давно не тупой и не медленный. Медленные - те кто букмарки апдейтить не успевают.

> хуже чем во FreeBSD а уж с реальными RealTimeOS которые работают
> без многозадачности,

Вот те раз, а эмбедеры то и не в курсе что ртосы у них не многозадачные. Вообще-то почти весь пойнт с RTOS связываться - многозадачнсть. Если это не надо - тогда это bare metal firmware без RTOS как раз. Внезапно, да? Так можно куда более жесткие времянки - но и програмить без абстракции переключаемых задач менее удобно.

Для экспертов я сообщу: реалтайм ортогонален многозадачности. Он вообще - про ГАРАНТИИ времени отклика. Количество задач в эту формулу не входит, только ГАРАНТИЯ времени реакции.

> коим нахрен многозадачность не нужна уж и подавно.
> Вообще конечно - тянуть Linux на устройства которые выполняют единственную задачу что
> в 99% и есть RTOS - верх тупоумия..

Надо рассказать автомотивщикам и интелу что они глупые, в отличие от вас. Странно что вы свой Intel еще не запилили, не понаделали убийц Tesla, и и не завалили мир своей продукцией.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено bOOster , 24-Май-25 15:34 
> Я как раз в курсе что есть RTOS. И буквально пару версий

Только ты не знаешь что такое железка STM32 например.. Хехе

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 12:50 
> таймингами сетевого стека, значительно худшими чем на FreeBSD

Окей, FreeBSD это отличный перекладыватель сетевых пакетиков.
И больше толком ни на что не годится.

А линь - универсальная серверная платформа.
Доказано современным состоянием индустрии.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 08:46 
>> таймингами сетевого стека, значительно худшими чем на FreeBSD
> Окей, FreeBSD это отличный перекладыватель сетевых пакетиков.

И на его горе в лине запилили немеряно оптимизаций для - шустрого перекладывания пакетиков. Например fast path (софтварный офлоад) установленых соединений и тому подобное, когда процессинг - минимизирован. Оверхеду - дали бой, сделали zerocopy интерфейсы типа io_uring и проч.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Смузихлеб забывший пароль , 22-Май-25 13:33 
С подобным же успехом, наличия древнего г.на в американских/австралийских банкоматах/банках достаточно чтобы объяснить оголтелым, что любые современные технологии просто непригодны для профильной деятельности

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

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

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Bottle , 22-Май-25 19:02 
Почему тогда музыкальные продюсеры работают на винде и маке вместо реалтаймовой бзди?
Запись звука с минимальной задержкой тоже важна, но почему-то бздю не применяют.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 21:45 
Это правда. FreeBSD настолько примитивна, что сделать из неё перекладыватель байтов с диска в оптику действительно проще простого, благо поддержку своих карт Мелланокс впилил. О чём ты скромно умолчал — и я понимаю почему — так это о том, что всё остальное (вообще всё, включая указания какие байты кому с тех BSD отдать) — работает на Linux. И, по слухам, Нетфликс уже засматривается на io_uring и DPDK, чтобы уже наконец перестать патчить BSDшное ядро и просто пользоваться мейнстримом как и все.

Откуда там только RT взялся для сетевого приложения с буфферизацией у клиента — ума не приложу. Это тебе ребята из Netflix такое рассказали, или ты сам для пущего понту придумал?


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 21:58 
> О чём ты скромно умолчал — и я понимаю почему
> — так это о том, что всё остальное (вообще всё, включая
> указания какие байты кому с тех BSD отдать) — работает на Linux.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Slew , 23-Май-25 07:59 
В случае таких проектов как тот же нетфликс, с их нагрузкой и требованиями в некоторых участках, на имеющемся в наличии в виде линуксов и бздей, особо не разгонишься. Все равно придется пилить специализированное решение. И тут с бздей скорее всего будет проще, просто в силу менее интенсивного ее колупания легионом других разрабов и большей возможности стать во главе мейнстрима, что нетфликс и сделал. Такая себе тихая гавань. Сейчас фряха-это фактически проект нетфликса.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 08:52 
> во главе мейнстрима, что нетфликс и сделал. Такая себе тихая гавань.
> Сейчас фряха-это фактически проект нетфликса.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Slew , 23-Май-25 10:52 
Не тянет ванильный Линукс из коробки те нагрузки. Никакие io_uring не помогут, и что ты там не делай и как не настраивай. Как и бзди, если из коробки. Там нужно спецрешения, повторюсь. Ты наверно просто не участвовал в подобных проектах и не в курсе. Есть такие известные открытые спецрешения для линуксов, но решили свое запилить, что тоже многие делают.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 24-Май-25 06:06 
> Не тянет ванильный Линукс из коробки те нагрузки.

Из-за пришествия сверхскоростного IO в линухе оверхеду дают бой, на чертовой куче уровней, которые *bsd не снились. И достигли определенных успехов. Это moving target, имхо, как обычно - не успеете заапдейтить букмарки, вместе с девами сабжа почивая на лаврах. И ВНЕЗАПНО окажется что "догоняющий" - обошел на круг.

> Никакие io_uring не помогут, и что ты там не делай и как не настраивай.

А это мы как раз будем посмотреть :)

> Как и бзди, если из коробки. Там нужно спецрешения, повторюсь.

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

> Ты наверно просто не участвовал в подобных проектах и не в курсе.

Я достаточно участвовал в активности вокруг Linux Kernel чтобы увидеть ряд интересных аспектов.

> Есть такие известные открытые спецрешения для линуксов, но решили свое запилить, что
> тоже многие делают.

Есть. Но как вы понимаете - закончится это все тем что большую часть этого начнет уметь майнлайн. Сразу, просто, быстро, для всех. Без левых сторонних костылей, io_uring это шаг в именно ту сторону.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 08:50 
> Linux. И, по слухам, Нетфликс уже засматривается на io_uring и DPDK,
> чтобы уже наконец перестать патчить BSDшное ядро и просто пользоваться мейнстримом
> как и все.

Ну так они с удовольствием спихнут с себя затраты на майнтенанс и уменьшат свой software BOM. Потому что ничего личного, это бизнес. В Linux io_uring самим пилить не надо. И патчить врядли чего придется.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено bOOster , 22-Май-25 10:59 
> ps хотя после этой новости, мое мнение о БСД улучшилось)
> судя по всему, хотя бы часть решила развиваться

Даже google лжеИИ сейчас пишет
-"В общем, FreeBSD демонстрирует более низкую задержку и большую производительность сетевого стека по сравнению с Linux, особенно при выполнении задач, требующих высокой производительности и низких задержек. В частности, Zenarmor отмечает, что FreeBSD обычно быстрее и отзывчивее, чем Linux на том же оборудовании."


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:01 
> стека по сравнению с Linux, особенно при выполнении задач, требующих высокой
> производительности и низких задержек. В частности, Zenarmor отмечает, что FreeBSD обычно
> быстрее и отзывчивее, чем Linux на том же оборудовании."

Ты еще не понял? AI тебя раскусил как облупленого - и сказал тебе то что ты хотел слышать. И только.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено slew , 22-Май-25 11:23 
>Даже google лжеИИ сейчас пишет

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено bOOster , 22-Май-25 11:43 
>>Даже google лжеИИ сейчас пишет
> Зачем ты тут постоянно ретранслируешь мифы и предания из интернетов? Это не
> лавочка с бабками, а технический форум. Поставь тесты фри и линукса,
> прогони, покажи тут всем какая фряза крутая. Будь уверен, что результаты
> тебя самого сильно удевят не в пользу фряхи, какие-бы ты тесты
> не ставил.

Хехе - я действую также как и оголтелые последователи "святого грааля" в Операционных системах Хехехе. А тесты ты найдешь самостоятельно. Полно их. Нищие лакеев не имеют.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено slew , 22-Май-25 12:51 
>А тесты ты найдешь самостоятельно

Не нахожу, скинь ссылку хоть на один.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено An , 23-Май-25 06:46 
Да вот же https://www.phoronix.com/review/bsd-linux-threadripper-7980x

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 09:02 
> Да вот же https://www.phoronix.com/review/bsd-linux-threadripper-7980x

И что оно доказывает? Что это - сплошной mixed bag? Ну ладно - в номинации fork пингвины всем бсд дали конкретный мастеркласс.

А так вон то - в основном математика и больше тест дефолтных опций компилера и тому подобного. А тут внезапно козыряли - ФС и отгрузкой трафа. А по той ссылке примерно 0 бенчей на тему.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено An , 23-Май-25 10:34 
Ну в этом "mixed bag" FreeBSD выглядит получше Linux.
Так что без доказательств не стоит записывать производительность ее стэка в мифы и предания.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 24-Май-25 06:12 
> Ну в этом "mixed bag" FreeBSD выглядит получше Linux.

Этот mixed bag актуален - для синтетической математики в основном.

На десктопах - никто не будет убиваться за 5% FPS в x26x/av1 кодере. А вот хреновое управление питанием и голимая поддержка железа - сами понимаете.

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

На серверах в основном ДРУГИЕ нагрузки, и этим бенчем тема вообще не раскрыта.

> Так что без доказательств не стоит записывать производительность ее стэка в мифы
> и предания.

Не очень понятно какой именно стэк вон те бенчи тестировали? Кодогенерации компилера чтоли? :)


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Кошкажена , 21-Май-25 23:32 
> то за растом будущее

Может быть, но на данный момент это просто прототип, о чем сказано в новости

> На момент написания отчёта заявлена поддержка только сборки и установки Rust-приложений, работающих в пространстве пользователя. Поддержка библиотечных crate-пакетов запланирована в будущем. Использование Rust в ядре пока не поддерживается, так подобная возможность требует большого объёма работы и выходит за рамки начального прототипа.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:20 
> Таким образом, ничего серьёзного. Не ясно зачем очередная новость об этом. Похоже на дешевый пиар.

Пиар чего?
Думаешь кто-то из местных прочитает новость и пойдет коммитить в это ХардндБСД?
Ой, что-то я сильно сомневаюсь)

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено xPhoenix , 23-Май-25 16:26 
Типичный сишник: рассказывает как безопасно писать на C.
Он же спустя секунду: складывает и умножает указатели, а затем читает мусор из результата.

И ничего, вот вообще НИЧЕГО в голове не щёлкает.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено IdeaFix , 21-Май-25 21:45 
Портировали бы уж сразу системд на расте...

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Минона , 21-Май-25 21:51 
А этот процесс точно будет называться "портирование"?

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено name , 21-Май-25 22:26 
Поттерирование?

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено 12yoexpert , 22-Май-25 08:36 
аннигиляция

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено IdeaFix , 22-Май-25 15:05 
> А этот процесс точно будет называться "портирование"?

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

С другой стороны, в 2к25 и инновации в линуксаторе - это уже не плохо.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 22:00 
Так фряха только этим недокомпилятором и (не)собирается, ровно никаких препятствий для поддержки раста. Если бы раст поддерживался gcc, я уверен, претензий и с линуксом куда меньше было.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 22:04 
Но линукс уже довольно давно может собираться шлангом.
docs.kernel.org/kbuild/llvm.html

Андроид, насколько я помню, тоже.
Так что не вижу острой необходимости в вендорлочном GCC.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 22:26 
Сам линукс собирают, в основном, стараниями разработчиков андроида. А вот юзерспейс не очень хорошо шлангом собирается, что можно видеть на примере фряхи. Только шланг код всё ещё хуже и менее универсальный выдаёт, в принципе не способен на эффективные оптимизации (размер бинаря и оптимизации профилирования), есть дистрибутив линукса, собранный шлангом и он всегда ощутимо хуже был. В связи с чем собирать шлангом особого проку нет, кроме корпоративных интересов и унификации с проприетарными компиляторами (те же самые корпоративные интересы).

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Минона , 22-Май-25 09:24 
> А вот юзерспейс не очень хорошо шлангом собирается, что можно видеть на примере фряхи.

Что ты имеешь ввиду под юзерспейсом в контексте фряхи?
Базовая система (ядро + мир) прекрасно собирается llvm.
А порты это порты, чем девелопер собирает, тем и собираются.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:20 
GCC открыт и свободен, поэтому не явлется вендорлочным. Ибо любой может посмотреть, как и что он творит со входным и выходным кодом.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:03 
Ага, конечно не вендорлокнутый.
А чего тогда пришлось придумываться GCC Runtime Library Exception ?
www.gnu.org/licenses/gcc-exception-3.1.html

А потому что это проприерастный кусок заражал любой код GPL.
Взял я твой код вод свободной БСД, скомпилил... и теперь ты должен перелицензировать под коммуняцкой лицензией.
Здорово, правда!? (с)

Причем ввели Exception только в 2009 году.
А когда GCC появился, можешь посмотреть в интернете.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 13:19 
Очевидно, ты не в курсе, что до 2007 года gcc был под лицензией GPLv2. И она всех устраивала включая BSD. Последний компилятор под лицензией GPLv2 gcc-4.2.1 они еще долго использовали.

И объяснялось все просто. Поменяли лицензию - выявили проблемы, придумали как обойти. У куска, который вызывал проблемы сделали исключение. А для этого надо было договориться со всеми кто в него вносил свои патчи или переписать код.

То что после этого BSD не вернулись на gcc - это или религиозные мотивы, или психологическая незрелость.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 13:40 
> То что после этого BSD не вернулись на gcc - это или религиозные мотивы,
> или психологическая незрелость.

Нет, они просто поняли, что гнутикам верить нельзя. Вот выпустят они GPLv4 и НЕ исправят проблему. Напр. из-за религиозного фанатизма или банальной лени. Это будет уже не важно.

Поэтому с GCC в том анекдоте - но "стоило один раз овцу". Свой кредит доверия они потеряли. Поэтому все объединились для разработки свободного компилятора. И у них получилось.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:26 
> Нет, они просто поняли, что гнутикам верить нельзя. Вот выпустят они GPLv4 и НЕ исправят проблему. Напр. из-за религиозного фанатизма или банальной лени. Это будет уже не важно.

Ну так и используй последнюю версию gcc. В крайнем случае форкни его. Помнишь такой egcs?

> Поэтому с GCC в том анекдоте - но "стоило один раз овцу". Свой кредит доверия они потеряли. Поэтому все объединились для разработки свободного компилятора. И у них получилось.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 28-Май-25 00:39 
> В крайнем случае форкни его. Помнишь такой egcs?

Участь будет та же...
P.S.
(быть всего-лишь форком GCC... кому ты будешь нужен?)


И эта срaнь(Исключение) - никак не совместимо же с GPL... любой.

И до неё: GPL-библиотеки GCC - делали BSD код нелицензионным
(как и сам GCC, т.к.компиляция подразумевает подключение исходных пользовательских кодов, т.е.тот самый Linking), отчего и стали использовать LLVM (но, оставив все грабли GCC, видать для обратной совместимости, но и как диагноз... алиенского кривомозгия).

Всё прочее ты высосал из пальца.

/мимопрходил


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 16:02 
Этот exception был до версии 4.2.1, в которой на GPLv3 перешли, и после неё. Придумывать ничего не пришлось, и раньше была. Просто вернули после перехода на 3. А некоторые переполошиться в промежутке успели, да так, что до сих пор не отойдут.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено MinimumProfit , 22-Май-25 16:52 
Компиляторы GCC C и GCC C++ - по лицензии GPL 3. А что это значит? GPL 3 крепко привязана к особенностям законодательства США, и, фактически, в других странах не имеет юридической силы, потому что невозможно переписать требования GPL 3 в терминах законов других стран.

Поэтому использование GCC C и GCC C++ в странах, отличных от США, фактически, является нелицензионным.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 28-Май-25 00:41 
Если я правильно понимаю то и LLVM... т.к.требует мин.регистрации как ПО,
про какие либо гарантии отсутствия дыр вовсе молчу.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено 12yoexpert , 22-Май-25 00:00 
только этого не будет. суть раста это вендорлок

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 03:08 
Вы про Clang? Если да, то не понимаю почему его многие так хейтят. Он часто генерит лучший код, чем GCC. У клэнга работа с векторами интереснее, можно например как в OpenGL обращаться к части вектора. Или делать перемешивание просто написав a = b.yzxw;
Хороший компилятор, в общем.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 06:07 
> Вы про Clang? Если да, то не понимаю почему его многие так хейтят.

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

Пересобрать LLVM и тем более clang? Это такой сильно отдельный квест, с скачкой половины интернета и затратами дофейхоа ресурсов. Так что если у вас вдруг версия этого не та - это обрекает на много боли. Чтобы не было скучно оно обречено жиреть и тормознеть в неограниченных рамках - ибо абсолютно все и вся живет в ОДНОЙ либе. Которая уже отросла до примерно ста мегов в последних версиях - и это явно не предел, учитывая что оно не умеет половину архитектур рюхаемыех GCC-ами.

А вот отребилдить GCC под конкретно вон ту штуку, вон той версии - как раз в пределах сил человеческих. Особенно bare metal тулчейн для мк, ядер, фирмварей, и тому подобного. С LLVM это все - сильно более другой уровень боли в з@днице.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:07 
Помимо неоптимального кода (лапша из goto, впрочем, пользователям нравится) ещё заметил что чуть неправильно собранный тулчейн llvm (ну там если gcc где-то 1 из пакетов собрал, или линкер был не ldd, или --rtlib=compiler-rt с -stdlib=libc++ не добавлены в ключи хотя default и так выставлены, которые теперь надо убрать потому что не поддерживаются новой версией, каждое обновление что-то новое) приводят к интересным багам в том же расте (программах на нём), которые невозможно ни диагностировать ни отладить, особенно забавно, когда это непонятным образом влияет на глюкалово вроде веббраузера. Или вон --undefined-version линкеру теперь добавлять чтобы хромиум мог слинковаться и буквально каждое обновление что-то ломается само по себе.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 09:12 
> Помимо неоптимального кода (лапша из goto, впрочем, пользователям нравится) ещё заметил
> что чуть неправильно собранный тулчейн llvm (ну там если gcc где-то
> 1 из пакетов собрал, или линкер был не ldd, или --rtlib=compiler-rt

Собссно жил да был некто iZEN, фанат FreeBSD. Рассказывал мне как ща шланг этого нашего GCC сделает, и вообще, под правильной лицензией, быстрей компилит, все дела.

В ответ я бурчал что-то типа "бойтесь своих желаний".

Через несколько лет чат повторился. Изен был значительно менее оптимистичен насчет своего фетиша - его желания исполнились. При том ему запихали в систему по моему аж штуки так три разных LLVMа. А с учетом любви адептов BSD ребилдить все из сорца такой подарок в паре с подкрутками оптимизаций до уровня сравнимого с GCC - и таим же падением скорости компила - это мало кого оставит равнодушным :)

Собственно LLVM/Clang и Rust это 2 причины кончины Gentoo как чего-то популярного, без датацентра набитого EPYCами она мучительна уж очень. Но за фряхой с ее адептами этот апокалиптец ведь тоже как раз и пришел, и как раз скребется в дверь. Вы еще не купили топовый EPYC? Бабок не хватило? А зря. Ибо скоро без него вы вообще не доживете до окончания компила всей этой офигенной лабуды.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 09:25 
Ну сейчас собственно приходится держать прошлый шланг для раста и меза (уже обновили ебилды, не знаю детали), для блендера с интеловскими либами приходилось держать позапозапозапрошлый шланг. Несколько тулчейнов это не так ужасно, мне точно так же приходится держать позапозапрошлый гцц для dxvk (чтобы не было рандомных падений) и прошлый потому что то же ядро линукса не собирается текущим и его уже размаскировали.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:43 
> Потому что кусок жирной энтерпрайзятины, делаемой полутора корпами под свои нужды с пофигом на вообще всех остальных.

Ух набросил так набросил.
Во-первых там спонсоров полтора десятка, включая явных конкурентов, типа NVidia-Amd, Qualcomm-ARM, Google-Microsoft-AWS и тд.

Во-вторых, посмотри кто сидит в коммитете GCC.
gcc.gnu.org/steering.html
IBM, Google и тд


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:05 
> Ух набросил так набросил.
> Во-первых там спонсоров полтора десятка,

А код реально пишут: Apple, Google и (немного) AMD. Поэтому де факто оно обслуживает интересы 2.5 корпораций. На все остальное им таким красивым...

> включая явных конкурентов, типа NVidia-Amd, Qualcomm-ARM, Google-Microsoft-AWS и тд.

А комиты в основном - от вон тех двух с половиной корп. Оно и развивается - в сторону нужную им. А остальное им сильно похрен.

> Во-вторых, посмотри кто сидит в коммитете GCC.
> gcc.gnu.org/steering.html
> IBM, Google и тд

В GCC комитят явно более разносторонние комитеры - и его есть под намного большее число архитектур. А если это все в LLVM попробовать втащить - "ты же лопнешь, деточка"?!


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:34 
> А код реально пишут: Apple, Google и (немного) AMD. Поэтому де факто оно обслуживает интересы 2.5 корпораций.

Если остальным подходит написанное эплом - то обслуживают такие всех.

> А комиты в основном - от вон тех двух с половиной корп. Оно и развивается - в сторону нужную им. А остальное им сильно похрен.

Опять же повторюсь, если остальные довольны, значит развивается в нужном и им направлении тоже.

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

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:40 
> Это как хвастаться "зато мы умеем карбюратор для москвича-408 настраивать"

Это как хвастаться что у нас сейчас есть инструменты для настройки всех выпускаемых машин. Даже тех что в Россию официально попасть не могут.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 09:11 
> Если остальным подходит написанное эплом - то обслуживают такие всех.

Ага, автомобиль Форд может быть любого цвета - при условии что он черный. И тут как-то так же.

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

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

Эти остальные в основном состоят из гугла, эпла и их подпевал. Валв например ни в раз доволен не был и запилил для компила шейдеров на амд свой ACO. А менее попсовый архитектуры оно не умеет. И при попытке их туда - с такой архитектурой будет шикарное "ты же лопнешь, деточка?!"

> Коммитить они могут что угодно, но развитие определяет комитет.

Реальный комитет - это те 2.5 корпы.

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

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

> Это как хвастаться "зато мы умеем карбюратор для москвича-408 настраивать"

Скорее просто "умеем карбюратор настраивать". И тут оказывается что есть нехило живых иноварок с этим - и спрос на это все. А так процессорных архитектур довольно много. Всякие soft core под FPGA, а порой потом и в ASIC так и отлитые - куда они денутся?


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 11:18 
> Правда эпл и тут попользовался бсд свободами. Для себя у них отдельный проприетарный форк. Даже нумерация другая вроде.

Но у васянов код остался.
Могут пользоваться сколько угодно.

> Эти остальные в основном состоят из гугла, эпла и их подпевал.

Неправда. Там есть и прямые конкуренты эплу.

> Валв например ни в раз доволен не был и запилил для компила шейдеров на амд свой ACO.

Вот! Значит возможность есть.

> А менее попсовый архитектуры оно не умеет. И при попытке их туда - с такой архитектурой будет шикарное "ты же лопнешь, деточка?!"

Попсовой? Скорее мейнстримной.
Не всем хочется некрофилисть и разбираться в древних маргинальных архитектурах.

> Реальный комитет - это те 2.5 корпы.

Но эпла там нету)
Nvidia, Red Hat == IBM, SUSE, Google, SiFive (эти кстати риск5 продвигают) и даже институт метеорологии (Koninklijk Nederlands Meteorologisch Instituut, ваще хз зачем им нужен gcc)

Получается парадоксальная ситуация: яблока в комитете нет, но большую часть кода пишут они. Но при этом (почти) все довольны!

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

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

Но я что-то сомневаюсь, что поддержка v850 (31 год назад), pdp11 (старше СИшки), m68k и прочие, прям жизненно необходима.
Да и не вижу особой проблемы в двух тулчейнах. Зачастую оно или полностью компилится одним, или полностью компилится другим.

> Скорее просто "умеем карбюратор настраивать". И тут оказывается что есть нехило живых  иноварок с этим - и спрос на это все.

Вот как раз наличие спроса у меня вызывает сомнения)
Думаешь сильно много осталось TILEPro64? А сколько под нее пишут сейчас?
И не норм ли будет им взять компилятор старой версии?

> А так процессорных архитектур довольно много. Всякие soft core под FPGA, а порой потом и в ASIC так и отлитые - куда они денутся?

Уйдут на свалку истории и на обычную)



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 24-Май-25 09:17 
> Но у васянов код остался.

Какой код? Кода именно проприетарной эпловской версии - эпл не выкладывает, потому и проприетарной собссно :)

> Могут пользоваться сколько угодно.

Отбросами нате на лопате, угумс. А первый сорт зарезервирован для эпла, унутрях эпла.

>> Эти остальные в основном состоят из гугла, эпла и их подпевал.
> Неправда. Там есть и прямые конкуренты эплу.

Называя вещи своими именами:
- С одной стороны я вижу порты GCC всякими (не)васянами на не очень попсовые процы, по мере возникновения у кого-то такой нужды.
- С другой - я не вижу этот процесс для LLVM, это - prohibitive experience.

Т.е. налицо унылый 100% corp controlled crap обслуживаюший нужды полутора корпов. Просто по тому как оно разрабатывается. А этим конкурентам эпла нехило подумать что они будут делать если эпл перекроет кислород. Если это не про гугл конечно. Эти то свои проблемы рещат, но из них такая корпорация добра образовалась что я в этом жабогадюкинге буду разве что за тотальную взаимную аннигиляцию болеть.

>> Валв например ни в раз доволен не был и запилил для компила шейдеров на амд свой ACO.
> Вот! Значит возможность есть.

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

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

> Попсовой? Скорее мейнстримной.

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

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

Кроме некрофилии бывают task specifc архитектуры и тому подобное. Скажем для soft core заливаемых в FPGA если там вдруг хочется - немного нормального проца. Или архитектуры поюзанные там и сям, по каким-то своим поводам производителя. GCC для такого - есть. А LLVM...

>> Реальный комитет - это те 2.5 корпы.
> Но эпла там нету)

Вы же понимаете что в конечном итоге решают - фактические комиты, и в LLVM реально код пишут гугл, эпл и (специфично и меньше) AMD. При том амд те еще софтварщики. Пока том их достижений это нормальная ядерная часть, но "виноваты" в этом linux kernel dev как таковые, которые сильно поганить поляну не дают и подтягивают амд на свой уровень, а не проваливаются на их.

> и даже институт метеорологии (Koninklijk Nederlands Meteorologisch Instituut, ваще хз
> зачем им нужен gcc)

Мы таки про LLVM тут или про GCC? oO

> Получается парадоксальная ситуация: яблока в комитете нет, но большую часть кода пишут они.

Кому какое дело до кучки декораций? Фактические комиты решают. На голову сввлится - это, а не номанальные декларации.

> Но при этом (почти) все довольны!

Эти почти все с вами в одной комнате? Гугл ессно доволен - пилит софт для себя. Амд .. известен бардаком в user mode части драйвера. В том числе и за счет LLVM. Одна из причин по которым нвидия все еще на пьедестале. Если бы AMD не валяли дурака в софтострое, они бы нвидию вынесли уже. Железки то хорошие. Но вот с софтом - метания и страдания.

> Вопрос в кол-ве. И качестве.

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

> Сколько запросов на поддержку, будут ли требующие эти архитектуры как-то помогать и тд.

LLVM очень неудобен для кастома, и из-за распухания, и из-за заточенности процесса на полтора мегакорпа и обслугу их нужд.

> Но я что-то сомневаюсь, что поддержка v850 (31 год назад), pdp11 (старше
> СИшки), m68k и прочие, прям жизненно необходима.

M68K - до сих пор производится, и довольно популярен допустим для rad-hard процов AFAIK. А какой-нибудь AVR - он сабжем нормально поддерживается, или где?

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

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

> Вот как раз наличие спроса у меня вызывает сомнения)
> Думаешь сильно много осталось TILEPro64? А сколько под нее пишут сейчас?

Я думаю что M68K - применяется в космосе. Xtensa, LM32 и проч - в куче всяких девайсов как сервисное ядро и в FPGA. AVR - абдурина. Вроде даже какой-то бэк для LLVM был, только он "экспериментальный" лет пять. Google и Apple он же не нужен. А остальные там убьются нахрен, через дебри корпоративных наслоений лезть что-то пытаться улучшить.

> И не норм ли будет им взять компилятор старой версии?

Старой версии чего? LLVM это когда-то умел? И они мило и добро дропанули то что не надо гугле и япле? :)

> Уйдут на свалку истории и на обычную)

Soft core - можно залить в FPGA "здесь и сейчас". И вот уже FPGA'ха до кучи - еще и проц, выполняющий код. И это можно делать - столько сколько хочется.



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 11:21 
Под "большую часть кода пишут они" имел в виду "те кто сидят в комитете".
А то не очень понятно получилось.

Т.е есть тот же гугл у которых андроид собирается LLVMом, но ему не впадлу заседать в GCC коммитете.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:36 
> Он часто генерит лучший код, чем GCC

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 28-Май-25 00:48 
Но, начало всего - лицензия... GCC тупо для GPL ПО, выше расписал.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 22:26 
Заголовок вводит в заблуждение. Может показаться что FreeBSD развивает поддержку Rust.
Но это не так. HardenedBSD развивает свой форк.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 22:48 
> Может показаться

Только если ты читаешь не глазами)
Что не ясно во фразе "Для FreeBSD развивают..." ?
Это как "для linux сделали дрова для apple silicon".

ps вполне возможно что их наработки и патчи можно будет накатить на обычную FreeBSD.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Кошкажена , 21-Май-25 23:29 
> ps вполне возможно что их наработки и патчи можно будет накатить на обычную FreeBSD.

Там из наработок 50 строк в мэйкфайле и покарска волос в синий цвет.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено name , 21-Май-25 22:30 
А в FreeBSD и не знают.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 21-Май-25 23:16 
> А в FreeBSD и не знают.

Все они знают.
Уже была новость, в прошлом году, в начале и середине года:
"Разработчики FreeBSD обсуждают использование языка Rust в базовой системе"
opennet.ru/opennews/art.shtml?num=60473

И потом на БЗДшом саммите тоже возвращались к этому вопросу:
opennet.ru/opennews/art.shtml?num=61456
"Среди рассмотренных на саммите тем:
    Интеграция инструментария Rust в базовую систему, поставка и переписывание приложений на языке Rust и предоставление возможности разработки компонентов ядра на Rust."

Так что думаю они с интересом наблюдают и думают "а может цап-царапнуть к себе?"


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 00:25 
Как с интересом можно наблюдать makefile?

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Ан Оним , 21-Май-25 23:51 
Чем плох C и C++ - тем что эти языки захватил в свою собственность ISO. Он на них деньги делает, никому бесплатно не даёт спецификацию. Это неправильно, не должны свободное ПО писаться на языках, чьи спецификации мало кто видел и они несвободны. А вот спецификации Rust, Java, Free Pascal - бесплатные и в открытом доступе.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 00:01 
... и распространяются в виде бинарников, в которые можно засунуть что угодно.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 00:13 
собирайте из исходников
https://github.com/rust-lang/rust/blob/master/src/bootstrap/...

да, если что, то для "бутстрапа" gcc требуется С-совместимый компилятор, плюс всякие binutils


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Кошкажена , 22-Май-25 00:07 
> А вот спецификации Rust - бесплатные и в открытом доступе.

У раста нет спецификации.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 00:09 
https://github.com/rust-lang/spec

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Кошкажена , 22-Май-25 00:16 
> https://github.com/rust-lang/spec

Во-первых, этот репозиторий пустой.

Во-вторых, это расту передали наработки другой организации для другого комплиятора раста https://blog.rust-lang.org/2025/03/26/adopting-the-fls/


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Карлос Сношайтилис , 22-Май-25 00:28 
А у с/с++ нет единого стандарта, но никто не жалуется, почему-то

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 06:16 
> А у с/с++ нет единого стандарта, но никто не жалуется, почему-то

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 28-Май-25 00:53 
И ANSI, я уж не требую максимально-алиенско криволапый K&R.

А, на этом ISO - это же уже никакой не С/С++ оригинальные... Подделки.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Кошкажена , 22-Май-25 10:19 
> А у с/с++ нет единого стандарта

https://isocpp.org/std/the-standard


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Карлос Сношайтилис , 22-Май-25 23:28 
>> А у с/с++ нет единого стандарта
> https://isocpp.org/std/the-standard

Резиновую уточку тоже можно назвать атомным ледоколом, но это не значит что на ней далеко уплывёшь.

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

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

Это не стандарты, это набор общих рекомендаций. Причем расплывчатых.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 23:52 
> Это не стандарты, это набор общих рекомендаций. Причем расплывчатых.

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

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

Ваши хотелки никого не интересуют.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Карлос Сношайтилис , 24-Май-25 02:07 
> Это стандарты, которые подразумевают возможность неполной реализации.

Насколько неполной? На 1%? На 10%? На 99.99%?

Ты сам знаешь ответ: на любой процент. Но продолжаешь называть это СТАНДАРТОМ.



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 28-Май-25 00:54 
Да, за одно упоминание термина "стандарт" - их бы за мошенничество посадить бы...

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 09:59 
А это тогда что?
https://github.com/rust-lang/rfcs

Ничем не отличается от RFCшек на интернет.
Типа RFC-822 благодаря которому почта ходит тудою-сюдою.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Кошкажена , 22-Май-25 10:18 
Отличается, причем сильно. Где там, например, описание модели памяти? И что там делает, к примеру, ранжирование crates.io https://github.com/rust-lang/rfcs/blob/master/text/1824-crat... ?

У питона есть pep, у scheme есть rfc, однако у питона нет стандарта, а у схемы есть.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 00:12 
Ясен пень. Винда давно уже переходит на раст, линукс запоздало, но тоже пытается. И остальные перейдут, никуда не денутся - потому что это серьёзный технический прогресс который невозможно игноровать. Что на этот счёт думают админы локалхостов никого не волнует.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 00:29 
Когда невозможно будет игнорировать, а не игноровать - тогда и приходите.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 03:24 
Это просто блаж и неведомый социальный феномен.
У нас вот у людей засели в головах маркетплейсы. У них - раст. Стадная движуха такая, на максималках - все пользуются.
В тоже время, на ответственных, высокопроизводительных проектах по прежнему будут использовать си. Платят там нормально, так что типичных ошибок не должно быть - просто потому что зп позволяет на таких проектах несколько раз вычитывать код и делать соотвествующие тесты.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:24 
> блаж

блажь

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

https://snapcraft.io/scx-rustland и не только раст, но и бпф.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 00:13 
Так, куда теперь побегу бежавшие от раста с линукса на фрибсд?

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Карлос Сношайтилис , 22-Май-25 00:29 
На плейстейшн!

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 06:21 
Так речь про форк фряхи. Про ванильную фряху речь не идет.
Также ещё остается illumos, Openindiana к примеру.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:31 
> Так речь про форк фряхи. Про ванильную фряху речь не идет.

Форкайте, можно. Хотя... Есть же Openbsd, Netbsd, DragonflyBSD. Первая даже на мой ноут ставилась 2 года назад. Уже ни одна из них не ставится.

> Также ещё остается illumos, Openindiana к примеру.

Снова таки, пару лет назад Индиана даже на мой ноут ставилась. Сейчас разве что проприетарная соплярка и OmniOS(без гуя) пойдут. Без звука и войфая конечно, но чем ради безрастовости не пожертвуешь...


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Эксконтрибутор FreeBSD , 22-Май-25 12:26 
> Openbsd, Netbsd

Не являются форками фряхи
NetBSD — независимая ОС
OpenBSD — форкнулась в 90ых от NetBSD


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:00 
На DragonFly

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:33 
И как она у вас на железе? 5 лет назад я её мог даже юзать, но уже даже не ставится.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено An , 22-Май-25 10:06 
Во первых в FreeBSD пока rust не тащат.
Во вторых - есть еще NetBSD.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:35 
> Во первых в FreeBSD пока rust не тащат.

А о чём новость, напомните пжлст?

> Во вторых - есть еще NetBSD.

А она точно есть? Чтобы ответить на этот вопрос, найдите себе комп и попробуйте.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 12:32 
> А о чём новость, напомните пжлст?

Напоминаю: новость о форке, который написал makefile и надеется что его добавят в FreeBSD. Поддержки Rust нет, в FreeBSD правок тоже не было.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено An , 23-Май-25 06:50 
У меня NetBSD на двух компах(домашний сервачек wiki/файловый сервер и на нетбуке).
Считается что я "попробовал"?

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 28-Май-25 00:59 
надеюсь они 386-4MB? Иначе незачёт.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 21:48 
> Во первых в FreeBSD пока rust не тащат.

Lua в ядро втащили, втащат и Rust, не переживай.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 22:02 
>> Во первых в FreeBSD пока rust не тащат.
> Lua в ядро втащили, втащат и Rust, не переживай.

*рукалицо.жпг*
Экспертиза опеннета, которую мы заслужили (за грехи наши) ...


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 27-Май-25 20:31 
Ну это поправимо — иди да почитай как на Lua под бсдшное ядро писать. Там несложно.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 27-Май-25 21:12 
> Ну это поправимо — иди да почитай как на Lua под бсдшное ядро писать. Там несложно.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 00:51 
Теперь make buildworld будет в 4 раза дольше... и больше...

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:47 
-j n+k

где к - число докупленных ядер :)


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 01:55 
Мне вот интересно, на какой ещё язык начнут всё подряд без разбору переписывать когда детвора наиграется в раст и осознает, что после "давайте всё перепишем!" начнётся "а теперь надо всё переписанное дальше поддерживать", а это скушненько и неинтересненько?
А то с джавой уже было, с го было...

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 02:01 
Как только ты покажешь другой язык, который решает проблему работы с памятью и эффективности траты ресурсов лучше, чем Раст. Но ты его не покажешь, потому что к тому времени как подобное придумают, раст уже успеет ускакать вперёд через Полониус, уже будет крепко сидеть во всех операционках и в целом обрастёт ещё более обширной экосистемой, чем сейчас. Задолбаешься догонять. Это тебе придётся изобрести что-то немыслимое, что перевернёт всю индустрию, но при этом всем будет понятно, что в расте это сделать невозможно.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 03:17 
> потому что к тому времени как подобное придумают, раст уже успеет ускакать вперёд через Полониус, уже будет крепко сидеть во всех операционках и в целом обрастёт ещё более обширной экосистемой, чем сейчас. Задолбаешься догонять. Это тебе придётся изобрести что-то немыслимое, что перевернёт всю индустрию, но при этом всем будет понятно, что в расте это сделать невозможно.

Понимаешь... Тут такое дело... Я немного дольше в ИТ сфере вращаюсь, чем не только время появления раста, но и многих других попсовых "решающих все проблемы" языков программирования. И такую телегу слышал уже неоднократно. Почитай как ту же джаву Sun продвигал и какие великие дела с помощью неё обещал делать, это должна была стать чуть ли не главная веха в истории ИТ, буквально революция. На ней писали буквально всё подряд. На неё буквально всё подряд переписывали. Даже драйвера для всяких устройств. Приложения и игры на телефонах. В процессоры нативные инструкции добавляли (см. Jazelle). И где всё это сейчас?
Отсюда и скептицизм - мы всё это уже видели. И "революционеров" с очередным "мы изобрели очередную и самую лучшую серебряную пулю", и вьюнош с горящими глазами, всецело в это уверовавших и стремящихся побыстрее всех вокруг обратить в эту новую "веру".
Посмотрим, где будет ваш раст годиков так через 15-20. А пока - это всё просто очередной хайп.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:01 
> Посмотрим, где будет ваш раст годиков так через 15-20.

Там же где и Java. Он выгрызет себе нишу и прочно там обоснуется, чтобы на десятилетия потом занимать почётное место в top10 языков.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 17:13 
> Сложно представить, что это будет, и для каких задач оно будет подходить, но оно может реально подвинуть раст.

Да! Я тоже давно это мнение высказываю. Сильно подозреваю, что подобный проект будет создаваться при помощи AI (точнее даже ASI).


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:22 
> попсовых "решающих все проблемы" языков программирования. И такую телегу слышал уже неоднократно.
> "революционеров" с очередным "мы изобрели очередную и самую лучшую серебряную пулю",

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

Вы все, воины против Раста, одинаковые: сами себе чушь придумали, сами ее и разоблачили. Весело, наверное?

> Почитай как ту же джаву Sun продвигал и какие великие дела с помощью неё обещал делать, это должна была стать чуть ли не главная веха в истории ИТ

И это дейстаительно была веха.

> И где всё это сейчас?

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 10:13 
> Раст решает "не все проблемы", а конкретно проблему с памятью

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

> Вы все, воины против Раста, одинаковые: сами себе чушь придумали, сами ее и разоблачили. Весело, наверное?

Так это ты придумал "воинов против раста", в которых видишь всех, кто в очередную религию не ударился вместе с тобой. Так что, спроси себя, весело ли тебе. Я на эти очередные "войнушки" смотрю скорее с нескрываемым ехидством.

> А вообще, серьезный энтерпрайз, для которого Java в первую очередь юзали и юзают

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:56 
> И даже эту проблему он лишь якобы решает, ибо доказано это может быть лишь на практике

Чел, на практике растовый borrow checker просто не скомпилирует программу, где есть эти проблемы. Во время компилиции, понимаешь? Какие еще доказательства тебе нужны?

Ну, можешь еще посмотреть статистику Гугла и Майкрософта о снижении до нуля количества дыреней при работе с памятью после перекатывания кода с C и C+j на Rust. Хотя вряд ди тебя это переубедит - куда там Гуглу и Майкрософту до такого знатного эксперта, как опеннетный Celcion...


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 11:08 
> Чел, на практике растовый borrow checker просто не скомпилирует программу, где есть эти проблемы. Во время компилиции, понимаешь? Какие еще доказательства тебе нужны?

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

> Ну, можешь еще посмотреть статистику Гугла и Майкрософта о снижении до нуля количества дыреней при работе с памятью после перекатывания кода с C и C+j на Rust.

Эта статистика построена на базе ML-анализа кода. К практике имеет отношение примерно такое же, как большинство выкладок теоретической физики - в теории всё верно, а вот бьётся ли с практикой - покажет время и дальнейшие исследования.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:47 
> Ты внимательно читаешь? Написано же прямым текстом - лучшим доказательством является практика.

1.5 миллиона строк раст кода в 13 андроиде, это уже практика?
Сейчас напомню уже 16 версия выходит.

Microsoftʼский гипервизор, это уже практика?
Hickory который используется Let's Encrypt, это уже практика?
Pingora, которую использует Cloudflare, это уже практика?
Всякие прикладные приложения типа COSMIC, это уже практика?

> Практики применения раста мы ещё толком не видели.

Наверное ты просто плохо смотришь)

> Эта статистика построена на базе ML-анализа кода. К практике имеет отношение примерно такое же, как большинство выкладок теоретической физики - в теории всё верно, а вот бьётся ли с практикой - покажет время и дальнейшие исследования.

А такая статистика?
Memory Corruption практически на порядок обгоняет все остальные проблемы.
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 11:57 
> 1.5 миллиона строк раст кода в 13 андроиде, это уже практика?

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

>> Практики применения раста мы ещё толком не видели.
> Наверное ты просто плохо смотришь)

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 12:09 
> Какие сроки я имел в виду - я писал выше. Но тебе читать неинтересно, это я уже понял.

Если ты про "Посмотрим, где будет ваш раст годиков так через 15-20" то это просто эталонная глупость из палаты мер и весов.

> Так я оцениваю по времени, а не по тому, сколько и где кто-то на волне хайпа что-то напереписывал.

Угу. Если 20 лет не проработало, то хайп.
Интересно, были ли такие же дундуки которые говорили "СИ всего 9 лет! Это хайп! Зачем если есть pdp-11?!"



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 12:44 
> Если ты про "Посмотрим, где будет ваш раст годиков так через 15-20" то это просто эталонная глупость из палаты мер и весов.

Да конечно. Умные люди - любую технологию, даже толком недоделанную, пихают везде и сразу. Это давно известно.

> Угу. Если 20 лет не проработало, то хайп.

Читать ты, видимо, так и не научился. Прискорбно.

> Интересно, были ли такие же дундуки которые говорили "СИ всего 9 лет! Это хайп! Зачем если есть pdp-11?!"

Как бы тебе объяснить... Си решал несколько более широкий спектр задач, чем "у вас память небезопасная! срочно все переписываем!" Ты бы это знал, наверное, если бы хоть немного интересовался темой. Но тебе же неинтересно. У тебя религия и зуд быстрее всех "неверных" в неё обращать.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 13:11 
> Да конечно. Умные люди - любую технологию, даже толком недоделанную, пихают везде и сразу. Это давно известно.

Умные люди берут какой-то маленькие проект и обкатывают.
Если проблем не возникло, продолжают эксперемент и/или расширяют сферу применения.
А сидеть ждать 20 лет, будут только "особо развитые".

>> Угу. Если 20 лет не проработало, то хайп.
> Читать ты, видимо, так и не научился. Прискорбно.

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

> Как бы тебе объяснить... Си решал несколько более широкий спектр задач, чем "у вас память небезопасная! срочно все переписываем!" Ты бы это знал, наверное, если бы хоть немного интересовался темой.

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

> Но тебе же неинтересно. У тебя религия и зуд быстрее всех "неверных" в неё обращать.

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



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 13:50 
> Умные люди берут какой-то маленькие проект и обкатывают.

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

> А сидеть ждать 20 лет, будут только "особо развитые".

Расскажи это банкам, которые до сих пор COBOL используют. Они ведь недоразвитые.

> Странно, я же привел цитату, твою же.

Нет, ты привёл свою ее интерпретацию, из которой понятно, что в суть ты вникать не стал.

> Если бы слегка интересовался темой, то знал, что раст решает все те же задачи что СИшка, но еще и с обеспечение безопасности памяти.

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

> Ну, аргументов у тебя не осталось, так что ты решали все свести к "религии".

Так это именно она и есть. Изначально. Потому что хайпово, потому что все вокруг говорят "у нас внезапно самая большая проблема - это небезопасная проблема с памятью!". И в стороне оставаться нельзя, "все побежали - и я побежал".


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:49 
> Действительно. Но в случае с растом это, увы, не так. Здесь сразу с места в карьер и уже даже кореутилсы на той же бубунте планируют на растовские заменить, хотя там даже по собственным простеньким тестам, не покрывающим и половины юзкейсов - всё красное.

О, какое классное вранье.
github.com/uutils/coreutils - судя по pass тестам проходит 500 из 600.
У религиозных фанатиков это "всё красное" ?

> Расскажи это банкам, которые до сих пор COBOL используют. Они ведь недоразвитые.

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

> Нет, ты привёл свою ее интерпретацию, из которой понятно, что в суть ты вникать не стал.

Штош, попробую еще раз.
Кто написал вот тут opennet.ru/openforum/vsluhforumID3/136916.html#53
"Посмотрим, где будет ваш раст годиков так через 15-20. А пока - это всё просто очередной хайп."
А? Ну давай, покажи класс в интерпретации)

> Ну а завтра выйдет ещё один язык, который тоже какую-нибудь одну, но жуть какую важную проблему решает - будем тоже на него всё переписывать?

Если она будет такая же существенная - то да.
А порча памяти это топовая проблема таких важных проектах как линукс
cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33

> Потому что хайпово, потому что все вокруг говорят "у нас внезапно самая большая проблема - это небезопасная проблема с памятью!".

А разве нет?
Посмотри статистику CVE/RCE в ядре.
Посмотри статистику CVE/RCE в других больших проектах типа ХОрг.
Включи мозг и посчитай. А потом подумай, откуда у тебя такая фанатичная вера в то, что "ошибки с памятью не проблема!".

> И в стороне оставаться нельзя, "все побежали - и я побежал".

Разве? Неужели приходят домой и заставляют устанавливать раст?
Не нравится - не пользуйся.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:53 
>  500 из 600.

Это реально все красное.

А если еще учесть, что это тесты не на совместимость...


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:58 
И да

> 500 из 600

Это этап: "Мужики, смотрите, я тут пилот настрогал. Если хотите присоединяйтесь и мы сделаем когда-нибудь аналог".


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 16:30 
> О, какое классное вранье.
> github.com/uutils/coreutils - судя по pass тестам проходит 500 из 600.

Я про эти тесты: uutils.github.io/coreutils/docs/test_coverage.html
К тому же, понимаешь, смотреть можно не только на одну общую циферку, но и на разбивку по конкретным утилитам. И ужасаться от того, что даже в date фэйлится три теста из пяти.
Но это сложно, вникать надо, я понимаю.

> Если она будет такая же существенная - то да.

А если всем навязать мысль, что она существенная? Была вот такая проблема, Y2K называлась, всем миром боялись. А оказались пустым пшиком. Вот ведь бывает...
Я понимаю, что стул уже начал прогреваться, поэтому поясню - суть не в том, что проблемы безопасной работы с памятью нет вовсе. Суть в том, что она есть не везде и не везде её требуется решать. Но апологетам растовской религии это объяснять бессмысленно, они готовы переписать буквально всё подряд. И глупо именно это.

> А разве нет?

Смотря когда и где. Смотря про какой язык речь идет. Смотря про какое время и какие программы.
Тупо "смотреть статистику" - это довод из рязряда "а вы капитализацию Apple видели?!"
Доводы плана "общей температуры по больнице" - мне неинтересны.

> Не нравится - не пользуйся.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 16:41 
> Смотря когда и где. Смотря про какой язык речь идет. Смотря про какое время и какие программы.
> Тупо "смотреть статистику" - это довод из рязряда "а вы капитализацию Apple видели?!"
> Доводы плана "общей температуры по больнице" - мне неинтересны.

Что ж ты вертишься как уж на сковородке)?  

У нас есть ядро линукс.
В нем есть CVE по памяти.
Их у нас большая часть из всех найденных.

А теперь вопрос: "у нас внезапно самая большая проблема - это небезопасная проблема с памятью" или нет?



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 17:02 
> У нас есть ядро линукс.

У кого "у нас"? Это ты свёл разговор к ядру линукса, я про него вообще не говорил.

> В нем есть CVE по памяти.

Ну и что?
Предлагаешь переписать все 40+ миллионов строк кода ядра линукса?
Ну, дерзай. Расскажешь потом об успехах.

> Их у нас большая часть из всех найденных.
> А теперь вопрос: "у нас внезапно самая большая проблема - это небезопасная проблема с памятью" или нет?

Нет. Потому что не определено, что в данном случае является "проблемой". Если проблемой (самой большой) безопасности - то нет, потому что основное количество взломов не через утечки памяти происходит, да и не любой CVE с такими утечками имеет реалистично реализуемый вектор атаки.
Понимаешь, теоретическая проблема != практическая.
Опять же, тут важен ещё и вопрос рисков. Если решение проблемы несет в себе рисков больше, чем сама по себе проблема - то оно по определению не может быть решением. Ну, то есть, если очередной запальчивый вьюноша с горящими глазами, видя перед собой целью переписать на расте всё подряд и не видя препятствий, наломает в процессе дров, решив проблемы с утечками памяти, но насобачив при этом других уязвимостей (ведь раст от них не защищает, увы) - то цель всего этого мероприятия лично мне становится не особо понятной.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 17:29 
> У кого "у нас"?

У меня в телефоне и на дестопе.
А еще на серваке сервисов которыми я пользуюсь.
Возможно у тебя ядра линукса нету.

> Это ты свёл разговор к ядру линукса, я про него вообще не говорил.

А про что ты говорил?
А... точно, ты же не написал.
Хотя примеры с андроидом, амазоном и прочими раскритиковал.
Давай посмотрим не на ядро, а на, например, OpenSSL.
Там безопасность памяти нужна? Или Heartbleed это "ничего страшного".
Уязвимости во всяких libwebp, glibc, curl и прочих библиотеках и утилитах?
Или в Хорге который, еще лет 10 назад, имел монополь

Но моя любимая это все-таки дырень в Grub - 28 нажатий backspace и ты можно загружать свое ядро. БезопасТность аж прет.

> Предлагаешь переписать все 40+ миллионов строк кода ядра линукса?

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

> Ну, дерзай. Расскажешь потом об успехах.

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

> Нет. Потому что не определено, что в данном случае является "проблемой".

Я виду проблему в повышении привилегий или выполнении кода.

> Если проблемой (самой большой) безопасности - то нет, потому что основное количество взломов не через утечки памяти происходит

Причем тут утечки памяти?
А выход за пределы буфера? А double-free?

> Понимаешь, теоретическая проблема != практическая.

Так практических полно.

> Опять же, тут важен ещё и вопрос рисков. Если решение проблемы несет в себе рисков больше, чем сама по себе проблема - то оно по определению не может быть решением.

И кто определяет риски?
Ну не ты же. А создатели проектов.
Это их решение.

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

А если не насобачит?
Но даже в твое пессимистичном сценарии - будет паритет с древними ЯП, там тоже логические ошибки не отлавливаются

> то цель всего этого мероприятия лично мне становится не особо понятной.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 18:06 
> А про что ты говорил?

Я говорил в целом про подход "давайте всё подряд на расте переписывать".

> Но моя любимая это все-таки дырень в Grub - 28 нажатий backspace и ты можно загружать свое ядро. БезопасТность аж прет.

Да, только видишь в чём дело - ошибки можно делать и даже на расте, просто в силу криворукости разработчика, либо банальных ошибок. Шок, правда?

> Предлагаю начать с тех кусков, в которых проблем больше всего.

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

> И даже не переписывать, а начать новые писать на расте.

Да, давай, напиши новое ядро линукса на расте. Подскажи только: там, где ты это будешь делать - попкорн рядом продаётся?

> Если корпы решат что это выгодно, то перепишут.

А, ну то есть - если дяденька решит, то перепишут.
Фи, так неинтересно.

> Причем тут утечки памяти? А выход за пределы буфера? А double-free?

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

> И кто определяет риски?

Есть давно известные и хорошо прописанные процессы. Погугли "risk management", узнаешь много нового.

> А если не насобачит?

То есть, будем заменять решение, прошедшее сотни аудитов безопасности и работающее десятилетями на поделку какого-то вьюноши, пообещавшего, что он всё это переписал на расте и теперь точно всё будет безопаснее?
Хорошая идея.

> Но даже в твое пессимистичном сценарии - будет паритет с древними ЯП, там тоже логические ошибки не отлавливаются

Как б тебе объяснить, чтобы ты понял, наконец - ошибки не начинаются и не заканчиваются только работой с памятью.

> Или тебе просто пофиг на безопасность твоих пользователей.

Мне не пофиг, ровно поэтому я и против очередных "улучшателей" всего подряд и без разбору.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 18:31 
> Я говорил в целом про подход "давайте всё подряд на расте переписывать".

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

> Да, только видишь в чём дело - ошибки можно делать и даже на расте, просто в силу криворукости разработчика, либо банальных ошибок. Шок, правда?

Нет. Это не правда.
Правда в том, что плохим инструментом накосячить гораздо легче.
Отсюда растут ноги кожухов для ремней станков и пильных дисков, всякие ТБ и ПУЭ.
И если рас позволит убрать половину ошибок которые программисты умудряюбтся сделать кривым инструментов - то это уже вин-вин.
А по поводу криворукости, ну знают СИшники что надо писать аккуратно.
Но за десятилетия так и не научились.

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

Да. Они хотели сделать proof-of-concept, показать что это возможно.
Ты же помнишь что опенсорс, это когда ты делаешь то, что тебе интересно.

> Да, давай, напиши новое ядро линукса на расте. Подскажи только: там, где
> ты это будешь делать - попкорн рядом продаётся?

Шутка, классная, в стиле Евгений Вагановича.
Посмотрим кто будет смеяться, когда ты без раста не сможешь ядро собрать.

> А, ну то есть - если дяденька решит, то перепишут.
> Фи, так неинтересно.

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

> Всё это вместе - не является основной проблемой безопасности. А знаешь, что является? Социальная инженерия, слабые пароли и намеренные сливы от "кротов". И - вот беда - раст от этого никак не защищает.

Давай пруф.
А то это голословное утверждение не подкрепленное вообще ничем.

> То есть, будем заменять решение, прошедшее сотни аудитов безопасности и работающее десятилетями

Ты бы хоть написал про какой софт говоришь.

Потому что ни ведро, ни хорг, ни кучи библиотек не видели никакой "сотни аудитов безопасности"
В хорге находят ошибки из 88 года. В ядре линукс Dirty COW жила почти десятку, и потом еще находили ее потомков.

> на поделку какого-то вьюноши, пообещавшего, что он всё это переписал на расте и теперь точно всё будет безопаснее?

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

> Хорошая идея.

Отличная идея. Заодно можно будет сбросить балласт из бракоделов.

> Как б тебе объяснить, чтобы ты понял, наконец - ошибки не начинаются и не заканчиваются только работой с памятью.

Как бы тебе объяснить, что опасных ошибок (т.е CVE/RCE) с памятью большинство.
От 70% по результатам мелкомягких, до 80-90% по статистике CVE в ядре.

> Мне не пофиг, ровно поэтому я и против очередных "улучшателей" всего подряд и без разбору.

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



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 21:38 
> И где ты такой подход видишь?

Буквально в этом треде и в сообщении каждого "просвященного".

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

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

> Ты же помнишь что опенсорс, это когда ты делаешь то, что тебе интересно.

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

> Посмотрим кто будет смеяться, когда ты без раста не сможешь ядро собрать.

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

> Код пишут корпы. Но им можно помочь. Иногда даже за хорошую зарплату.

Ну а ты, стало быть, бесплатно тут всех агитируешь. Соболезную.

> Давай пруф.

Так а смысл? Начнётся очередное "сайты не сайты", "ссылки не ссылки", "пруфы не пруфы".
Гугл - знаешь такой сайт? Вот. Открой его, введи там "security breaches human error percent" - и можешь хоть обчитаться. Выбирай любые сайты, какие тебе больше нравятся.

> Переписывают в большинстве случаев те самые разработчки, которые писали оригинал.

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

> А если нет - то кто сказал, что они напишут хуже, чем те что уже натяпляпали?

Так никто и не запрещает эксперементировать на локалхосте. Проблема в том, что они пропихивают это в системы всем остальным, кому эти чудесные эксперименты могут быть не особо интересны.

> Отличная идея. Заодно можно будет сбросить балласт из бракоделов.

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

> Как бы тебе объяснить, что опасных ошибок (т.е CVE/RCE) с памятью большинство.

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

> Но грустная правда в том, что тебя никто спрашивать не будет.

Тут, увы, вынужден согласиться.

> Но я приветствую прогресс, а ты упираешься.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 12:26 
> Буквально в этом треде и в сообщении каждого "просвященного".

Ну... может тебе оно мерещится)

> От инструмента это вообще никак не зависит. Мне кажется, современные разработчики на
> голанге это весьма убедительно доказали.

Хахаха, вот это ты пошутил!
От инструмента зависит выстрелит себе горе-разработчик в ногу или нет.

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

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

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

Угроза? Какие мы обидчивые! А если я бы написал "вот завтра останетесь без i486" ты бы в полицию позвонил?

> Ну а ты, стало быть, бесплатно тут всех агитируешь. Соболезную.

Агитирую? Громко сказано. Скорее устраиваю флуд и флейм.

> Так а смысл? Начнётся очередное "сайты не сайты", "ссылки не ссылки", "пруфы не пруфы".
> Вот. Открой его, введи там "security breaches human error percent"

Звучит очень страшно. И цифры просто ужасные. Ну типа "95% of data breaches involve human error".
А начинаешь читать... и там "нам прислали письмо с вирусом, а мы его открыли! плак-плак".
Так в чем же была проблема, в том что письмо открыли или в том что оно смогло обойти изоляцию приложения и хакнуть систему?

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

Фраза "в большинстве случаев" тебе о чем-то говорит?
Если уже вспомнил модули ядра, то вот мнение Грега, который в ядре разбирается побольше чем я.
https://lore.kernel.org/all/2025021954-flaccid-pucker-f7d9&#.../
As someone who has seen almost EVERY kernel bugfix and security issue
for the past 15+ years (well hopefully all of them end up in the stable
trees, we do miss some at times when maintainers/developers forget to
mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I
can speak on this topic.

The majority of bugs (quantity, not quality/severity) we have are due to
the stupid little corner cases in C that are totally gone in Rust.

> Так никто и не запрещает эксперементировать на локалхосте. Проблема в том, что они пропихивают это в системы всем остальным, кому эти чудесные эксперименты могут быть не особо интересны.

Стоп-стоп. Что значит "пропихивают всем остальным".
Этих всех заставляют пользоваться таким софтом? Или может они подписали договор на обслуживание?
Если они пишут код, то их мнение может учитываться, а если нет?
С чего вдруг у них взялось право указывать разработчика что и как делать?

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

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

>> Как бы тебе объяснить, что опасных ошибок (т.е CVE/RCE) с памятью большинство.
> Доводы из разряда "надо есть экскременты, потому что миллионы мух не могут ошибаться" - неинтересны.

К счастью люди не мухи)
Именно поэтому десктопным линкусом пользуются маргиналы из 4% меньшинства (это даже меньше чем всяких ЛГБТшников)/

> Сам по себе этот факт - не значит ровным счётом ничего.

Для тебя.

> Тем более не значит, что надо всё срочно переписывать. Тем более не
> значит, что переписывать надо на раст.

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



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 13:03 
> От инструмента зависит выстрелит себе горе-разработчик в ногу или нет.

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

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

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

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

Почитай нить разговора. Ты сказал, что небезопасная работа с памятью является основной проблемой безопасности. Я тебе сказал, что основная проблема заключается в другом (статистически), ты попросил пруфы, я их тебе дал. Что непонятного?

> Этих всех заставляют пользоваться таким софтом?

Разумеется. Бубунту же на серверах используют, в том числе. Следовательно, пропихнутая туда растовая замена кореутилсов со временем дойдёт до всех. Соответственно, они будут вынуждены их использовать, согласны они на это, или нет.
Не все же админы локалхостов, чтобы аргумент "сделай своё", или "поставь другое" был для них валидным.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 13:48 
> Так, может быть, давайте сразу разрабатывать язык, который программисту будет сосочку автоматически в рот запихивать и подгузники менять?

Прием "доведение до абсурда"? Скучновато. Думаю ты можешь в софистику лучше.

> А лучше сразу вообще разработаем язык, который сам код пишет, а то вдруг даже тут кто-то  ошибётся.

Отличная идея! Жаль пока нет соответствующих технологий.
В свободное время подумай, зачем в автомобили ставят подушки и ремни, на ЖД переездах ставят шлагбаумы и заграждения, а у пресса по ТБ должны быть две кнопки разнесенные на расстояние и не позволяющие нажать их одной рукой.

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

Уже сколько десятилетий усиливают, а воз полный buffer overflow поныне там.
Все же сводится к практике. И она показывает что "не стрелять в ногу" не научились.
Расскажи где мне найти залежи адекватных СИшников, я пойду туда нанимать персонал.

> Хотя, конечно, это сложнее, чем принять стратегическое решение плана "а давайте всё писать на расте и все ошибки уйдут сами собой, по щучьему велению, без труда и без науки!", я понимаю.

Опять передергивание. Да еще и настолько унылое((
Но даже в нем есть здравая мысль: если переписывание выглядит более простым и надежным... то бизнес выберет именно это решение.

> Каким образом отсутствие драйвера для графики в эппловых ноутбуках связано с безопасностью?

Показать что на расте можно писать дрова. Такой "пруф от концепт", который смог пройти сертификацию Кроноса.
Но оставим те драйвера от Асаши. Вот тебе пример драйвера Nova для Нвидии.

А проблем с дровами в линуксе хватает.
Например "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP из состава ядра Linux " - это проблема безопасности или еще нет? А жила она с 2013 года. [1]
На что "WD разрабатывает NVMe-драйвер на языке Rust" который по производительности сопоставим с СИшным. [2]

> Почитай нить разговора. Ты сказал, что небезопасная работа с памятью является основной

проблемой безопасности.
Я сказал и повторюсь "проблема с памятью является основной проблемой безопасности в коде".
И она исправляется в коде. И статистику на CVE я тоже привел.
То что поверх нее есть еще проблема юзеров - это вторая проблема и решаться она должна другими методами.

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

>> Этих всех заставляют пользоваться таким софтом?
> Разумеется. Бубунту же на серверах используют, в том числе. Следовательно, пропихнутая туда растовая замена кореутилсов со временем дойдёт до всех. Соответственно, они будут вынуждены их использовать, согласны они на это, или нет.

Да. Именно так работает опенсорс.
Если они настолько недовольны, что аж кушать не могут - то могут взять другой дистрибутив, или сделать форк (типа как девуан).
Напомню что это на проприетарь, где (если ты достаточно крутой и богатый) можно подписать контракт на доступность 99.999 на 100500 лет.
Вам никто ничего не обещал и ничего не должен (AS IS!), а в случае СПО у вас еще и средств воздействия на разработчика мизер.

> Не все же админы локалхостов, чтобы аргумент "сделай своё", или "поставь другое" был для них валидным.

Пишите своему хостингу, вендору, провйдеру "мне не нравится убунта с Растом, дайте мне другую".

[1] opennet.ru/opennews/art.shtml?num=59940
[2] opennet.ru/opennews/art.shtml?num=57774


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 15:26 
> Прием "доведение до абсурда"?

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

> Все же сводится к практике. И она показывает что "не стрелять в ногу" не научились.

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

> Опять передергивание.

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

> Показать что на расте можно писать дрова.

Ну, показали. И что дальше? Как это проблему небезопасной работы с памятью-то решает?

> А проблем с дровами в линуксе хватает.

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

> Я сказал и повторюсь "проблема с памятью является основной проблемой безопасности в коде".

Вот когда проблема безопасности в коде станет основной проблемой безопасности в принципе - тогда и поговорим. А заделывать дырки в полу каюты тонущего корабля - занятие не особо полезное.

> То что поверх нее есть еще проблема юзеров - это вторая проблема и решаться она должна другими методами.

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

> Да. Именно так работает опенсорс.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 15:59 
> Ну а зачем мне оставиться в меньшинстве?

Ээээ? Сидя на сайте 4%ков? Действительно почему?

> Ты этот приём весь диалог используешь, почему мне нельзя?

Классическое "Нет ты! (с)" ))?  

> И с растом не научатся.

Опять утверждение без пруфов.
А я могу сослаться на опыт андроид команды, у которых в 13 андроиде
"To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
We don’t expect that number to stay zero forever, but given the volume of new Rust code across two Android releases, and the security-sensitive components where it’s being used, it’s a significant result."
security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

> Потому что от человеческих ошибок застраховаться вообще невозможно. И раст тут - никакой серебряной пулей не будет.

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

> Просто потому что unsafe никто не отменял.

Да, зато unsafe существенно уменьшает кол-во кода, в котором проверок нет. Это раз.
А два - 80% крейтов не используют unsafe.
opennet.ru/opennews/art.shtml?num=61251

> Да и сами разработчики раста ни раз заявляли, что гарантией от ошибок работы с памятью раст не является.

Пруф пожалуйста. У них прам на главной написано "rich type system and ownership model guarantee memory-safety and thread-safety"
А то без пруфов, это просто прдеж в лужу.

> А с тобой скучно общаться серьёзно.

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

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

О, как все печально((
Твой фанатизм и неолуддизм просто зашкаливает.
Особенно когда ты транслируешь релизиозный догмат "НИНУЖНА!!1" в ответ на факты, статистику или опыт других.

> Ну, показали. И что дальше? Как это проблему небезопасной работы с памятью-то решает?

Да, решает.

> Вот когда проблема безопасности в коде станет основной проблемой безопасности в принципе - тогда и поговорим. А заделывать дырки в полу каюты тонущего корабля - занятие не особо полезное.

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

> В том-то и дело, что она-то как раз и является основной, а вот небезопасная работа с памятью даже среди чисто ошибок в коде далеко не факт, что самая частая причина тех самых security breach.

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

> Потому что даже в случае эксплуатации таких ошибок причиной зачастую являются не ошибки сами по себе, а то, что обновления безопасности вовремя не устанавливаются.

И это тоже решается на другом уровне. Административном внутри компании, законодательным типа Cyber Resilience Act. Этим пусть занимаются менеджеры и политики.
Но дыры в коде исправляются на уровне кода и инструментов.

> Нет, так работают корпорации,

Неправда.
История опенсорса это история "вы делаете все не правильно, я сейчас покажу как".
Россыпь BSD появившехся, тк "мнения разделились".
Куча форков разных проектов, тк одни хотят кнопки слева, а другие справа.
Именно поэтому у нас есть Гном и КДЕ, причем у каждой есть форки старых версий.
Целый парад велосипедов различных дистрибутивов.

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

Правильно. Тот кто делает - тот и решает. Так что всё логично.
Вопрос "чего Сообщество™ забило на разработку" вторичен, но это выбор самого сообщества.



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 17:49 
> Классическое "Нет ты! (с)" ))?

Учитывая, что ты только этим и занимаешься всё дальнейшее сообщение - зеркалка такая зеркальная...

> Опять утверждение без пруфов.

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

> Зачем тогда придумывают всякие валгирды, санитайзеры, фаззеры для С и С++? Можно было бы сказать "от логических ошибок они не защитят, так что в мусорку".

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

> Пруф пожалуйста.

Да наздоровье: doc.rust-lang.org/book/ch15-06-reference-cycles.html
Читаем первый абзац и видим там буквально "Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust."
Ну, то есть, ошибка при работе с памятью (а утечка памяти - это именно она) всё равно возможна, пусть она и условно "безопасна". Про что я выше и писал.

> О, как все печально((
> Твой фанатизм и неолуддизм просто зашкаливает.
> Особенно когда ты транслируешь релизиозный догмат "НИНУЖНА!!1" в ответ на факты, статистику или опыт других.

Видишь, ты даже что-то вразумительное придумать в ответ не можешь, а просто отвечаешь в формате "сам такой".
Ну, ты реально унылый, уж извиняй за прямоту.

> Как я уже сказал, у нас есть разные уровни проблемы. И те что на уровне кода, решаются на уровне кода.

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

> Неправда.

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

> Россыпь BSD появившехся, тк "мнения разделились".

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

> Целый парад велосипедов различных дистрибутивов.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 18:43 
> Речь про то, что не научатся не стрелять себе в ногу. Для тех, у кого память длиной в одно сообщение - речь именно про то, что ошибки бывают не только обусловленные тем, от чего язык может защитить, но и тем, от чего не защищает.

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

> Вопрос скорее в том, что зачем придумывать целые отдельные языки, когда можно именно этими инструментами и пользоваться,

Потому что они недостаточно хорошо работают.
Вот opennet.ru/opennews/art.shtml?num=58622
Уязвимости в OpenSSL/LibreSSL: чтение вне буфера, use-after-free, double free, разыменование NULL.
И это при том что у них там и санитайзеры, и фаззинг, и тесты.
Можно даже посмотреть github.com/openssl/openssl/actions/runs/4124496105

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

И это тоже делают. Вернее - пытаются делать.
Делают новые ЯП - "TrapC развивает Си-подобный язык" opennet.ru/opennews/art.shtml?num=62224
Модифицируют компиляторы "На базе Clang для языка Си реализован режим проверки границ буферов"
https://www.opennet.dev/opennews/art.shtml?num=62606
Создают новые компиляторы "Fil-C - компилятор для языков C и C++, гарантирующий безопасную работу с памятью" https://www.opennet.dev/opennews/art.shtml?num=62241
Пробуют всякие MiraclePTR (спойлер: неудачно).

Но вот почитай какие там трейдофы, кроме слома обратной совместимости?
Как тебе "собираемые в Fil-C программы медленнее примерно в 1.5-5 раз"?

Еще есть Safe-C++ который расколол сообщество, и сейчас там 2 группы в комитете кидают друг в друга какахи.
И попадет оно в стандарт, думаю к годику 30му, если повезет.
thenewstack.io/c-committee-divided-on-memory-safety-plans/

> И вот вменяемого ответа на этот вопрос, кроме криков про то, что только раст и ничего другого - лично я пока так и не услышал.

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

> Читаем первый абзац и видим там буквально "Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust."

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

При этом другие ошибки памяти: "double-free", "use-after-free" они считают существенными и с ними борются.
https://doc.rust-lang.org/stable/book/ch04-01-what-is-owners...
https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

> Ну, то есть, ошибка при работе с памятью (а утечка памяти - это именно она) всё равно возможна, пусть она и условно "безопасна".
> Про что я выше и писал.

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

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

Важны для кого?
Те кто пишут код, сами решают, что для них важно.
Это их проект и их право.

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

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

> А переписывание программы целиком, как несложно догадаться, это самое дорогое из всех  возможных решений.

Значит разработчик оценит риски и примет решение.

> Все более-менее  значимые проекты разрабатываются на деньги каких-либо корпораций.

Т.е без корпораций СПО не будет?
Тогда откуда претензии и недовольство - большие дядьки порешали, так теперь и будет.

Хотя есть достаточно интересных проектов, за которыми нет корпораций. Например Гимп или Крита. Или VIM-Emacs.

> Он раньше был. А теперь, в основном, лишь парад респинов-болдженосов. В современных  реалиях и на одном джаст-фо-фане создать с нуля новый дистрибутив и (самое главное) сколь-нибудь долго его развивать и поддерживать, не говоря уж о том, чтобы добиться пользовательской базы более чем в пару соседей-собутыльников - задача малоподъёмная.

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



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 20:01 
> В языках без GC проблему утечки, насколько я знаню, пока не решил
> никто.
> При этом другие ошибки памяти: "double-free", "use-after-free" они считают существенными
> и с ними борются.

В C++ можно выстроить настолько продуманную систему управления ресурсами (например, через RAII, умные указатели и другие идиомы), что вопросы ручного управления памятью практически перестают беспокоить разработчика. Лично мне такой подход кажется крайне удобным - он сочетает эффективность с высокой надежностью, и в этом плане у меня нет никаких претензий к плюсам. Конечно, это требует понимания принципов работы, но при грамотном проектировании код становится не только безопасным, но и выразительным.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 16:48 
> И ужасаться от того, что даже в date фэйлится три теста из пяти.

А можно посмотреть на touch, который проходи 15 из 15, или на du с 28/30. Но зачем, да?

> Суть в том, что она есть не везде и не везде её требуется решать.

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

> в том числе в системные части,

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

> заменяя бинари, которые десятками лет

Ага, как иксы))) Которые "работали"))

> работали и никаких страшно-ужасных взломов через них сроду не было.

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

> Ну вот как в своё время пропихивали systemd. Тоже была серебряная пуля,
> решающая целую кучу проблем.

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

> Правда, по факту создал он проблем еще  больше, чем решил, но кому это интересно, правда?

А какие проблемы? Одмины-башпотянщики отправились мести улицы? Их уникАльные нагромождения скриптов стали внезапно никому не нужными, а они перестали быть незаменимыми. Серьзеные проблемы))

Плюс это только это с вашей точки зрения. А с точки зрения индустрии это де-факто стандарт. Без системд остались или специализированные дистры вроде alpine или васяноподелия от нетакусиков для нетакусиков.



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 17:19 
> А можно посмотреть на touch, который проходи 15 из 15, или на du с 28/30. Но зачем, да?

Ну да, "ты туда не ходи, ты сюда ходи".
Ведь если в других тулзах картина лучше - это же радикально меняет картину.

> Суть проблемы в том, что есть люди думающие что "не везде её требуется решать".

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

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

В том-то и дело, что не пофиг. Потому и приходится отгонять палками очередных сектантов, целящихся всё переделать и улучшить, а по факту - всё ломающих и ухудшающих.
Есть тут один "улучшатель", Поттерингом зовут. Так всё классно улучшил, что его добрым словом много лет поминали и до сих пор многие поминают.

> Ну так она и решила! systemd это лучшее что случалось с линем за последние лет пятнадцать.

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

> Проблемы разумеется есть везде и всегда, но нужно сравнивать негатив с позитивов.

Вот люди и сравнили. Да так хорошо сравнили, что целые дистры существуют, единственная цель которых - выпилить systemd.

> А какие проблемы?

Ну, можешь почитать: without-systemd.org/wiki/index_php/Arguments_against_systemd/
Про башпортянки там, кстати, ничего нет. Печально, да.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 17:53 
> Ну да, "ты туда не ходи, ты сюда ходи".
> Ведь если в других тулзах картина лучше - это же радикально меняет картину.

Меняет. Потому что 500 из 600 это 500 из 600)))

> Не вы первые, не вы последние.

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

> целящихся всё переделать и улучшить, а по факту - всё ломающих и ухудшающих.

Да-да, "раньше было лучше" (с)

> Есть тут один "улучшатель", Поттерингом зовут. Так всё классно улучшил, что его
> добрым словом много лет поминали и до сих пор многие поминают.

Кто его поминает? Кучка маргиналов? А все остальные просто пользуются и радуюся унификации.

> С точки зрения админов локалхоста - безусловно.

Как раз с точки зрения админа хотя бы пары сотен серверов и больше. Не нужно ковыряться в "уникальных" сетапах от особенных админов.
А с точки зрения бизнеса - еще лучше. Админы стали взаимозаменяемыми и все настравивается однотипно.

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

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

> Вот люди и сравнили. Да так хорошо сравнили, что целые дистры существуют,
> единственная цель которых - выпилить systemd.

Ага, они нашли для себя суть для существования. Всякие девуаны, антиксы и прочее.
И можно посмотреть популярность этих васяноподелий)))
Но вот все реально рабочее - все на systemd.

> Ну, можешь почитать: without-systemd.org/wiki/index_php/Arguments_against_systemd/

Мда, я надеялся на какой-то нормальный разбор, а не на сайтик от фанатиков.
Ты бы еще опус probonopd про вейланд скинул.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 18:20 
> Меняет. Потому что 500 из 600 это 500 из 600)))

Вот когда будет 600 из 600 - тогда и приходите.

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

Это всегда вопрос целесообразности.

> С электричеством боролись, с автомобилями боролись, теперь с языками программирования воюют))

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

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

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

> Кто его поминает? Кучка маргиналов? А все остальные просто пользуются и радуюся унификации.

Это те радуются, кто не застал времена когда админы бессонными ночами чинили результаты этой "унификации".
Повторяю - ты судишь по тому, как оно СЕЙЧАС, спустя много лет и версий, которые были встраданы немалым количеством людей, жравших этот кактус.

> Тоже самое мы видели с вейландом, тоже самое мы видим с растом.

Только в отличие от wayland и systemd, раст нужен лишь для того, чтобы нитакусикам было приятно всем рассказывать как остальные отстали на тыщи лет от прогресса. Для них это, наверное, польза. Насчёт других - время покажет.

> Мда, я надеялся на какой-то нормальный разбор, а не на сайтик от фанатиков.

То есть, читать ты не пробовал. Ясно.
Вот только сайты багрепортов разрабов системд, гит там же и прочее - это тоже сайтики от фанатов? Потому что ссылки ведут именно туда.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 18:51 
> Вот когда будет 600 из 600 - тогда и приходите.

Не... ты не понял)) Вот это решать будете не вы)
Тебя поставят перед фактом и ты или будешь пользоваться, или пойдешь  ̶н̶а̶ ̶h̶u̶r̶d̶ на другой дистр.

> Так это ты воюешь. Увидел врага в "небезопасных языках" - и бегаешь
> ко всем пристаёшь, навязывая свою религию.

Угу, CVE совсем не CVE. Ясно-понятно.

> А в чём прогресс переписать уже существующее? Я бы понял, если бы
> что-то новое написали, а очередные перегонки существующего функционала на очередной расхайпленный язык - в чём тут прогресс?

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

> Только в отличие от wayland и systemd, раст нужен лишь для того,

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

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

Диды за 40 лет не научились не портить память. А часть из них до сих пор говорит "А чо такова??? Ну нашли же и исправили!" Рано или поздно это надоело бы. Не хотели делать это по-хорошему, значит будет иначе. В том числе административными методами.

> То есть, читать ты не пробовал. Ясно.
> Вот только сайты багрепортов разрабов системд, гит там же и прочее -
> это тоже сайтики от фанатов? Потому что ссылки ведут именно туда.

Ссылки идут на багрепорты, но выводы и перемещение в те или иные категории - это уже работа фанатиков.



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 19:37 
> Не хотели делать это по-хорошему, значит будет иначе. В том числе административными методами.

Полностью с вами согласен. Хватит уже останавливаться на полумерах. Пишешь на Си++ или Си - значит уголовник. Раст нужно объявить божественным откровением. А для тех кто не согласен - будут применяться административные методы, в том числе и инквизиция.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 19:47 
> Полностью с вами согласен. Хватит уже останавливаться на полумерах. Пишешь на Си++  или Си - значит уголовник.

Ээээ? Дядя ты совсем долбанулся?
Иначе как объяснить настолько дэʼгенеративные аналогии?

Достаточно обязать в гос-контрактах использовать только безопасные языки.
Ну или просто запретить AS IS (для всех, а не только для опенсорса).
Тогда разговор будет:
"- у вас тут дырень, утекло 100500 пользовательских данных, что вы сделали чтобы этого не произошло?
-- ну.. я использоваль библиотеку от анонимного васяна, которая написана на дырявом языке из 80х...
- отлично! вы наплевательски отнеслись к своим пользователям, вот вам штраф на 100500 денег"

Предложения уже поступают
opennet.ru/opennews/art.shtml?num=60273


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 22:15 
> - минимизация проблем с памятью

Так поучи стихотворения. Говорят, помогает.

> - избавление от небезопасных языков

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

> - избавление от ненужного функционала - это уменьшает кодовую базу

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

> - использование современных подходов к архитектуре, типам, обработке ошибок

И главное сразу запрещать всех несовременных!

> - привлечение молодых разработчиков, которым не хочется ковыряться в сишке

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

> Если с другим можно получить результат лучше, то инструмент заменяется.

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

> В том числе административными методами.

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

> Ссылки идут на багрепорты, но выводы и перемещение в те или иные категории - это уже работа фанатиков.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 11:53 
> Так поучи стихотворения. Говорят, помогает.
> Да чего там, давайте сразу от небезопасных программистов избавляться. И от небезопасных
> пользователей. Никакой свободы врагам свободы!
> И главное сразу запрещать всех несовременных!

Как же быстро ты скатился до клоунады. Больше нечего сказать?

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

О, вот в этом я не сомневаюсь!
Совсем не удивлен что в твоем кругу нормальных почти нет))

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

Сам придумал, сам шутканул. С другой стороны, что таким как ты остается кроме нытья и глупых шуток.

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

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

> А какая разница в каких оно категориях?

В интерпритации.

> Суть изложенного от этого никак не меняется.

Еще как меняется!

Напр. "systemd assimilates udev" (ссылочка, кстати дохлая, и она такая там не одна) или "systemd takes over logging" записывают в Scope creep и трактуют как недостаток. Хотя это точно также можно записать в достоинтсва.

Conceptional problems - половина надуманные пробелмы, половина хотелки каких-то васянов.
Вроде Do not parse "debug". Ему отвели, что нужно использовать loglevel, но вместо этого он пишет "I'd like to continue using "debug"" потому что "workflow a lot of
kernel people have been doing for years". Офигеть аргумент, не правда ли?
А потом это б$дло начинает оскорблять людей)))

Чем-то напоминает особо одаренных из эпичного bugs.freedesktop.org/show_bug.cgi?id=865
- Сделайте как мы хотим!
-- Это violate the X Keyboard Protocol Specification.
- Вам что трудно! Оно портит жизнь емакс-прдликам! (a lot of Emacs shortcuts don't work because of it.)
- Еще раз повторяю, это _explicit_ violation of the XKB specification (see section 4.4). Оно может непредсказуемо повлиять на другие системы.
-- Ой, всё! Вам важна только ваша "holy spec"! Почему вы не захотели make everybody happy!

А потом всякие клоуны годами бегают с этим "багом" и кричат "плахие фридесктопщики не принимают патчи от Сообщества™!!1111"

Поэтому да, твоя кучка ссылок не в общем-то ничего.
Всегда и везде есть недовольные луддиты, которые только и хотят "чтобы было как раньше"


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 12:51 
> Как же быстро ты скатился до клоунады. Больше нечего сказать?

Так это ты скатился в клоунаду, я тебе лишь ответил в той же стилистике.

> Совсем не удивлен что в твоем кругу нормальных почти нет))

В отличие от админов локалхоста, у меня никаких "кругов" нет, я просто общаюсь с людьми по работе. С разными и в разных местах. И вполне могу сравнивать какой средний технический уровень был у 20-25 летних айтишников лет 15 назад и сейчас. И сравнения эти навевают грусть.

> Ну так и будет. Рыночек порешает.

Вот уже пятое десятилетие пошло как сишников хоронят, всё никак не похоронят...
Не решает что-то рыночек.

> В интерпритации.

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

> Хотя это точно также можно записать в достоинтсва.

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

> Conceptional problems - половина надуманные пробелмы, половина хотелки каких-то васянов.

Так с тем же успехом можно сказать, что попытки в systemd затащить половину системы - это тоже хотелки васянов, у которых NIH в тяжелой форме.
Всё относительно.

> Офигеть аргумент, не правда ли?

Так если ты в опцию ЯДРА всовываешь обработчик сервиса, ломая тем самым тот самый воркфлоу - может, действительно стоит подумать головой и реализовать это как-то иначе?
Или комплекс бога "нам виднее" - это, на твой взгляд, реально разумный подход в таких вопросах? Если да, то вопросов к тебе, в общем-то, больше нет. С тобой всё понятно.

> Поэтому да, твоя кучка ссылок не в общем-то ничего.

Да никто и не сомневался, что пруфы будут не пруфами, потому что лично тебе не нравятся. Я потому и закинул ссылку, чтобы ты это сразу же подтвердил. И ты не подвёл. Молодец.

> Всегда и везде есть недовольные луддиты, которые только и хотят "чтобы было как раньше"

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 13:58 
> И вполне могу сравнивать какой средний технический уровень был у 20-25
> летних айтишников лет 15 назад и сейчас. И сравнения эти навевают грусть.

Угу, "раньше было лучше". Не устал еще это повторять?

> Вот уже пятое десятилетие пошло как сишников хоронят, всё никак не похоронят...

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

Что осталось на сишке? Даже современные сишные компиляторы переписали на плюсы.
Я тут всем предлагаю сыграть в игру - "Ты называешь софтину на сишечка, а я на плюса. И кто назовет больше". Но что-то все любители сишечки сливаются))

> Ну так попробуй не интерпретировать

А за меня проинтерпретировал создатель сего  ̶в̶ы̶с̶е̶р̶а̶ опуса, записав позитив в негатив.
После такой наглой лжи ты предлагаешь считать это валидными аргументами?

> а валидные аргументы почитать

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

¹ кроме кучки нитакусиков, которые только и могут что строчит какие-то манифесты

> Так смысл в том, что systemd изначально нарушал некоторые общие концепции и
> подходы unix-way. Очевидно, что если авторы сайта придерживаются этой концепции (о
> чем там явно заявляется), то они в этом видят недостаток.

Unix сдох, а unixway показал свою несостоятельность в современном мире.
Авторы сайта могут придерживаться любой концепции, но это не делает их утверждения верными. А у авторов systemd нет никакой обязанности поддерживать этих концепций.

> Так с тем же успехом можно сказать, что попытки в systemd затащить
> половину системы - это тоже хотелки васянов, у которых NIH в
> тяжелой форме. Всё относительно.

Можно сказать. Никто не запретит. А можно что это не NIH, а унификация.
Только с этой унификацией согласился весь мир, а NIH'ом считают полтора землекопа.

> Так если ты в опцию ЯДРА всовываешь обработчик сервиса, ломая тем самым
> тот самый воркфлоу - может, действительно стоит подумать головой и реализовать
> это как-то иначе?

А почему бы и нет? Невозможно сохранять отбратную совместимость ВЕЧНО!
Тем более им дали способ как это сделать правильно.

> Или комплекс бога "нам виднее" - это, на твой взгляд, реально разумный
> подход в таких вопросах?

Нет конечно, нужно ходить и спрашивать всех васянов из сообщества™ "а не поломает ли вдруг кому-то что-то" и сразу же отказываться от реализации если хоть кому-то это сломает его воркшлоу, каким бы странным он ни был)))
xkcd.com/1172

> Да никто и не сомневался, что пруфы будут не пруфами, потому что
> лично тебе не нравятся.

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

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

Очередное нытье "раньше было лучше". Ну смени пластину что ли...

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

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

> а пока ты это делаешь компания теряет бабло

Явный признак профнепригодности :(
Я бы на месте компании начал бы задавать вопросы одминчегу "почему вы некомпетентны и не справляетесь с использованием актуального софта?"


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 15:04 
> Угу, "раньше было лучше". Не устал еще это повторять?

У тебя до такой степени упрощённое восприятие действительности, что буквально всё надо сводить до уровня тиктока?
То, что какое-то время назад средний айтишник имел определённые знания, а теперь не имеет и даже не считает нужным их иметь - это не "раньше было лучше", это свидетельство общего снижения технического уровня. Когда тебе на собесе человек, называющий себя айтишником, не может объяснить что такое маска подсети и как она работает - это удручает.
И, собственно, вот эти попытки всё подряд переписывать - они, в основном, как раз и идут от недостатка опыта и знаний, потому что чем большим количеством опыта и знаний человек обладает, тем менее он категоричен в своих суждениях.

>> Вот уже пятое десятилетие пошло как сишников хоронят, всё никак не похоронят...
> А сейчас где?

В код ядра давно заглядывал?

> Что осталось на сишке?

Си остался почти везде, где был изначально.

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

Да понятно уже, что пруфы не пруфы, сайты не сайты и всё вот это вот.
Успокойся уже.

> Unix сдох, а unixway показал свою несостоятельность в современном мире.

Кому показал? Админам локалхоста, вроде тебя? Ну, возможно. Причём тут остальные?

> Только с этой унификацией согласился весь мир, а NIH'ом считают полтора землекопа.

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

> Тем более им дали способ как это сделать правильно.

Вот как раз с тем, насколько это ПРАВИЛЬНО - и возникли вопросы. Причём, возникли они не только у "васянов", но и у вполне именитых разработчиков. Но разрабы systemd включили комплекс бога "нам виднее" и на мнение плебеев забили.

> Нет, пруфы не пруфы не потому что "лично мне они не нравятся"

Именно поэтому, валидных других аргументов преведено не было. То, что ты там дальше написал - это просто натягивание совы на глобус.

> Очередное нытье "раньше было лучше". Ну смени пластину что ли...

Да у тебя всё сводится к этому. Что поделаешь, если твоя способность воспринимать информацию настолько примитивна.

> А если бы читал доки, ченджлоги, пробовал что-то новое - то для тебя это сюрпризом бы не стало))

Читать ченджлоги буквально тысяч разных компонентов десятков разных систем - способны лишь админы локалхоста, либо аутисты. У остальных есть и другие задачи.
К тому же, тут такое дело - современные разработчики как-то не очень любят нормально документировать свои изменения, потому что это скучненько и неинтересненько. Поэтому в половине случаев причину поломки того, или иного поведения приходится искать не там, а в самом исходном коде, потому что в ченджлоге, увы, просто запись вроде "some improvements and fixes".

> Я бы на месте компании начал бы задавать вопросы одминчегу "почему вы некомпетентны и не справляетесь с использованием актуального софта?"

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 15:56 
> Когда тебе на собесе человек, называющий себя айтишником, не может объяснить что
> такое маска подсети и как она работает - это удручает.

Мда... где вы их находите? Почему к нам приходят адекватные и знающие?

> И, собственно, вот эти попытки всё подряд переписывать - они, в основном,
> как раз и идут от недостатка опыта и знаний

Угу, расскажи это напр. разрабам Tor. Которые сам затеяли переписывание наевшись сишечкой по горло. И им есть много чего сказать по поводу "насколько просто писать на си безопасно"

> В код ядра давно заглядывал?

Тебе было лень процитировать две строки ниже про "В монстропоректах вроде ядра с аймфиннишем"? Зачем спрашивать очевидные вещи?

> Си остался почти везде, где был изначально.

А вот и нет. Раньше на си писали прикладуху - текстовые процессоры, игры и движки для игр, всякие кады, редакторы. А сейчас это все на с++ (и чуток на java и других.)
Прикладухи на сишке практически не осталось. Ею даже не пахнет (не, ну т.е. иногда попахивает, но такое лучше не юзать)
Как ты объяснишь, причину, почему GCC переписали на плюсы? Наверное от качества сишечки))

> Кому показал? Админам локалхоста, вроде тебя? Ну, возможно. Причём тут остальные?

Ахаха, ты прям на личности перешел)) Как же хорошо что у нас есть такие шикарные "спецы" как ты))

> Как именно systemd пропихивали во все популярные дистры - это вопрос отдельной дискуссии.

О да, так про "пропихивали", так "пропихивали".
Просто те, кто решают - решили, а те кто потребляют... поныли.

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

Девуан "живет" и "процветает". Сообщество™ могло бы поддержать их как морально, так и финансово. Но... это никому оказало не нужно.

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

Думаешь "аргументация к авторитету" должна сработать? Я уже приводил в пример "авторитета" probonopd и его хейт вейланда. Так что упаси господи от таких "авторитетов".

> Да у тебя всё сводится к этому. Что поделаешь, если твоя способность
> воспринимать информацию настолько примитивна.
>> А если бы читал доки, ченджлоги, пробовал что-то новое - то для тебя это сюрпризом бы не стало))
> Читать ченджлоги буквально тысяч разных компонентов десятков разных систем - способны лишь
> админы локалхоста, либо аутисты. У остальных есть и другие задачи.

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

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

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

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

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

> Просто тебя в такие места не берут, видимо, как раз таки по причине профнепрегодности.

Я просто восхищен твоими способностями к прорицанию!
Но мог бы вместо этого подтянуть свои знания как же на самом деле работает systemd.



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 17:00 
> Почему к нам приходят адекватные и знающие?

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

> Раньше на си писали прикладуху - текстовые процессоры, игры и движки для игр, всякие кады, редакторы.

И сейчас пишут. Количественно, в общем-то, тут мало что изменилось. В процентном отношении - возможно.

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

Если речь про чистый си - то оно и неудивительно. Он создавался немного в другое время и под другие задачи. Для больших программ и современной разработки он подходит не особо.

> Как ты объяснишь, причину, почему GCC переписали на плюсы?

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

> Думаешь "аргументация к авторитету" должна сработать?

Ну ты ж ровно с неё и начал, говоря про "васянов". Или стрелочка опять не поворачивается?

> Ты серьезно это пишешь на форуме гентуников, бсдшников, девуанцев и тд, а также прочих, которые прдлят десктопный линь во имя швo6oдки?

Ну, если ты к таковым относишься, то - соболезную.

> Но мог бы вместо этого подтянуть свои знания как же на самом деле работает systemd.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 16:56 
Вдогонку добавлю пример

Критическая 0-day уязвимость в Chrome и libwebp, эксплуатируемая через изображения WebP
opennet.ru/opennews/art.shtml?num=59746

"критическая уязвимость (CVE-2023-4863), позволяющая обойти все уровни защиты браузера и выполнить код в системе за пределами sandbox-окружения"
Звучит не очень классно.

"вызвана переполнением буфера в обработчике формата изображений WebP"
А это - весьма типично.

"Опасность уязвимости усугубляет то, что в сети выявлен рабочий эксплоит, который уже применяется злоумышленниками для совершения атак (0-day)"
Ага. Т.е ее нашли после того, как кого-то похакали, и начали разбираться.
Чудесно правда?

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:02 
> А сидеть ждать 20 лет, будут только "особо развитые".

Рассказать тебе о компаниях которые 10 лет ждали после выхода стандарта 11-го года, что бы понять существующие проблемы, методы их обхода, написать новые кодинг стандарты и наконец-то перейти на него?

Или про разработчиков ядра linux?


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:01 
> Я немного дольше в ИТ сфере вращаюсь, чем не только время появления раста,
> но и многих других попсовых "решающих все проблемы" языков программирования

Ну ты тут такой не один.
Кто-то застал как ассемблерщики рассказывали что сишка это попса и не дает нужного контроля.
Или как сишники носились с "аргументом" Торвальдса и рассказывали что у плюсов не было будущего. Ну и где сейчас плюсы, а где сишка.
Про джаву сам рассказал, но что-то забыл упомянуть, что на ней сейчас почти вся бизнеслогика крутится в тех же банках.
Как хейтили .net в общем и c# в частности, но и они нашли свою нишу.
Их относительно последнего - Kotlin vs Java для андроида. Сколько было "обсуждений", но сейчас уже большую часть нового пишут на котлине.

> должна была стать чуть ли не главная веха в истории ИТ, буквально революция.

Так она и произошла))

> Приложения и игры на телефонах.

Андроид передает тебе привет :)

> мы всё это уже видели

Видеть вы видели, а выводы сделали странные.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 10:25 
> Кто-то застал как ассемблерщики рассказывали что сишка это попса и не дает нужного контроля.

Сам себе придумал, сам посмеялся?

> Или как сишники носились с "аргументом" Торвальдса и рассказывали что у плюсов не было будущего.

Когда появились плюсы - Торвальдс ещё в школу ходил и едва ли его мнение было тогда кому-либо интересно.

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

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

> Как хейтили .net в общем и c# в частности, но и они нашли свою нишу.

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

> Видеть вы видели, а выводы сделали странные.

Выводы делаются относительно "что обещали" => "что получили в итоге". Ты просто пытаешься убедить в том, что всё это в итоге нашло свою нишу. С этим никто и не спорил. Речь про другое.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:58 
> Повторюсь, для неё ставились задачи куда шире, чем кормить разжиревших разрабов банковского легаси. Относительно этих планов - нынешняя ниша джавы просто ничтожна.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 11:13 
> Мало ли какие там задачи "ставились". Маркетинговый отдел старался как мог.

То есть, у раста "маркетинга" нет, да?

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

Как говорили в фильме Клерки 2, "I'm not even gonna point out the irony, here."

> Ты проверь, может жена твоя пыль протирала влажной тряпкой, и нечаянно стёрла все наслоения мудрости?

Эх, годы идут, а опеннет всё не меняется...


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:25 
> То есть, у раста "маркетинга" нет, да?

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

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

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:29 
> Не знаю, мне неинтересно. За пределами их манифеста о том, какой это замечательный язык, я ничего не читал.

Что даже растбук и доку?

> Я не оцениваю языки по маркетингу. Я могу посмотреть на применения этому языку,

Амазон, клоудфларя, майкрософт, гугл...
Сотни миллионов андроид устройств уже работают с раст кодом в продакшене.

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

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

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

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



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 13:27 
> Что даже растбук и доку?

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

> сомнительно что разберешьтся прямо сходу.

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

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

И что?

> Типа как у камаза грузоподьемность, а у феррари - скорость.

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

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 11:39 
>> То есть, у раста "маркетинга" нет, да?
> Не знаю, мне неинтересно.

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

> Я не оцениваю языки по маркетингу.

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

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

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

> Мудрость как бы пытается заменить интеллект, но работает это только выдуманной вселенной Толкиена.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 13:17 
> Ну, то есть, ты буквально критикуешь "маркетинговый булшит" одного языка с помощью маркетингово же булшита другого языка

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

> Примерно так же, как по маркетингу не оценивают го, питон, сишарп и т.д.

Да, совершенно верно.

> Корпорации в их продвижение просто так миллионы вваливают, им просто деньги некуда девать, это же очевидно.

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

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

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

> Гарри Поттера

Гарри Поттер-то тут причём? Во вселенной Роулинг побеждает любовь. Причём побеждает она как интеллект, так и мудрость. Мы ведь вовсе не об этом, не так ли?

> даже спорить не вижу смысла.

Доходит как до жирафа?


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 13:30 
> Как из этого ты делаешь вывод, что по маркетингу можно оценивать полезность языка?

А толку с твоих оценок, если степень использования именно маркетингом и определяется? Язык может быть хоть в 100500 раз лучше, чем всё сущее и вещее, только если им никто не пользуется - в этом просто нет никакого смысла.
Взять тот же питон, например - это <субъективщина>один из самых худших из когда-либо созданных языков программирования</субъективщина>, но он де-факто является одним из самых успешных. И построено это именно на маркетинге. Потому что определённые корпорации вваливают огромные деньги в его продвижение. И таким образом он выигрывает рынок у языков, которые якобы лучше. И остальные тоже вынуждены его использовать, потому что рынок на него уже ориентирован, а значит более "правильные" языки использовать - нецелесообразно, потому что и кодеров на них не найти и каких-то готовых решений почти нет.
Неужели это правда НАСТОЛЬКО непонятно?

> Гарри Поттер-то тут причём? Во вселенной Роулинг побеждает любовь. Причём побеждает она как интеллект, так и мудрость. Мы ведь вовсе не об этом, не так ли?

Там шутка была, забыл написать слово "лопата", извини.

> Доходит как до жирафа?

Увы, но в твоём случае - видимо, так и есть.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:51 
> А толку с твоих оценок, если степень использования именно маркетингом и определяется?

Ну например QNX в свое время решил из узкой ниши выбраться в универсальные ОС.

Много и упорного вкладывали деньги в маркетинг.

Результат на лице!


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 16:02 
> Много и упорного вкладывали деньги в маркетинг.
> Результат на лице!

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 17:58 
> Надо их не просто вкладывать, но и вкладывать с умом.

Тут не помогло бы ничего. Потому что QNX на микроядре. И это не лечится.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 15:25 
> А толку с твоих оценок, если степень использования именно маркетингом и определяется?

Глупости. Ты даже сам это понимаешь где-то в глубине души, но почему-то это понимание не регистрируется в сознании. Глянь на следующую твою фразу:

> Язык может быть хоть в 100500 раз лучше, чем всё сущее и вещее, только если им никто не пользуется - в этом просто нет

Да, именно так. Степень использования определяется _именно_ степенью использования. Основным причинным фактором влияющим на степень использования является именно степень использования.

> Взять тот же питон, [...] построено это именно на маркетинге.
> определённые корпорации вваливают огромные деньги в его продвижение

Пфф. Указать на эти корпорации, ты конечно же не можешь? Хочешь я объясню тебе почему ты не можешь? Потому что эти твои утверждения выстроены не на фактах, а на твоих "теориях" о том как работает мир. Ты выводами из своих теорий подтверждаешь эти самые теории. Тебя в школе на уроках математики никогда не били линейкой по рукам за циклический вывод?

Давай я в твою картину мира накидаю других факторов. Один из них ты озвучил, но так и не понял, по-моему.

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

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

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 16:08 
> Пфф. Указать на эти корпорации, ты конечно же не можешь?

А зайти на сайт питона и нажать там кнопочку Sponsorship в верху экрана ты сам не в состоянии, что ли?
Давай, попробуй, я в тебя верю. Может тогда и не придётся позориться, пытаясь это скрыть за простынями текста.

> Давай я в твою картину мира накидаю других факторов. Один из них ты озвучил, но так и не понял, по-моему.

Спасибо, Кэп, что озвучил прописные истины, которые ты вдруг решил, что я не знаю, а ты знаешь.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 16:49 
> А зайти на сайт питона и нажать там кнопочку Sponsorship в верху экрана ты сам не в состоянии, что ли?

И чем эти спонсоры занимаются, ты не интересовался? PSF публикует регулярные отчёты о том, как они потратили средства, какие траты из перечисленных для тебя выглядят маркетингом?

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

> Спасибо, Кэп, что озвучил прописные истины, которые ты вдруг решил, что я не знаю, а ты знаешь.

Судя по реакции, до тебя так и не дошло. Это уже начинает напоминать деменцию.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 17:26 
> PSF публикует регулярные отчёты о том, как они потратили средства, какие траты из перечисленных для тебя выглядят маркетингом?

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

> Судя по реакции, до тебя так и не дошло. Это уже начинает напоминать деменцию.

Понимаешь, сколько бы ты не пытался свести всё на личности, веса это твоим словам не добавит. Скорее, наоборот. Впрочем, аудитория Опеннета никогда не отличалась вежливостью и всегда отличалась хабалистостью и хамством, так что удивляться нечему.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 18:02 
> не устраивают всякие семинары, не оплачивают выпуск книг и прочего?

Способ заработать на разработке языка ты записываешь в маркетинг?

Ты очень далек от этой темы.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 18:22 
> Способ заработать на разработке языка ты записываешь в маркетинг?
> Ты очень далек от этой темы.

Понятно, аргументы окончательно иссякли, пошло тоскливое "ты ничего не понимаешь".


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 00:02 
> Понятно, аргументы окончательно иссякли, пошло тоскливое "ты ничего не понимаешь".

Те реально привел зарабатывание денег как пример маркетинга. Тут даже говорить ничего не надо.

Все видят твою компетенцию.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 00:41 
> Те реально привел зарабатывание денег как пример маркетинга. Тут даже говорить ничего не надо.

Ты прочитал то, что хотел прочитать. Мне уже откровенно лень разжёвывать написанное и специально что-то пояснять.

> Все видят твою компетенцию.

А эти все с тобой в одной комнате сейчас?


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 14:22 
> Все видят твою компетенцию.

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

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 13:42 
> А ты думаешь, что деньги даются просто так?

Нет не думаю.

> Что потом в каких-то собственных продуктах эти компании эти языки не использую

Они используют, но это не маркетинг, не так ли? Это вещь в некотором смысле противоположная маркетингу: не других убеждать использовать, а использовать самому.

> не делают каких-то решений для продвижения

Для продвижения чего?

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

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

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

> Понимаешь, сколько бы ты не пытался свести всё на личности, веса это твоим словам не добавит.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 15:34 
>> Что потом в каких-то собственных продуктах эти компании эти языки не использую
> Они используют, но это не маркетинг, не так ли?

Как думаешь, является ли продукт в виде фреймворка на определённом языке маркетингом этого языка?

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

То же самое могу предложить и тебе.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 17:57 
> Как думаешь, является ли продукт в виде фреймворка на определённом языке маркетингом этого языка?

Нет. Можно ли считать создание утилит разработки для языка маркетингом? Всякие там парсеры синтаксиса для treesitter'а, lsp-серверы, отладчики? Компилятор кстати тоже: можно ли считать создание компилятора маркетингом? Не всё, что помогает распространению языка -- это маркетинг. Это-то ты понимаешь?

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

> То же самое могу предложить и тебе.

Ну так предложи. Что ты тут мнёшься нерешительно? Будь мужиком, возьми и предложи.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 23-Май-25 18:02 
>> Как думаешь, является ли продукт в виде фреймворка на определённом языке маркетингом этого языка?
> Нет.

Всё ясно, думаю, дальше разговор особого смысла не имеет.

> Ну так предложи. Что ты тут мнёшься нерешительно? Будь мужиком, возьми и предложи.

Да я теперь уже понимаю, что это как бы и бессмысленно - в твоём случае с антресоли брать нечего.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 26-Май-25 05:47 
> Всё ясно, думаю, дальше разговор особого смысла не имеет.

Ты уже второй раз приходишь к этому выводу. В первый раз я спросил, не жираф ли ты, ты, кстати, так и не ответил.

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

1. Не существует того, о чём я не знаю.
2. Человек не обладает субъектностью.

Начнём по порядку с (1). Традиционные веб-фреймворки работают как готовый бекенд, который программисту надо настроить и навешать на него своих обработчиков. axum предлагает набор компонентов и способы их соединения в более сложные структуры. Он предлагает тебе из компонентов собрать свой бекенд, не предлагая готового. Это реально меняет подход к тому, как программисту приходится выпиливать бекенд. Но ты этого не видишь. Чтобы увидеть это надо либо взять axum и попытаться на нём что-либо сделать, либо хотя бы пойти и почитать, что люди пишут про axum, и может в третьей-пятой статье найти достаточно внятное объяснение тому, что в axum'е особенного.

Ты не пытался ничего писать на axum, и статьи не искал не читал. Ок, не интересно, не читай. Казалось бы. Да? Но дальше ты проделываешь финт, достойный шестимесячного младенца: то что не видно, не существует. Ты не видишь, чем axum отличается от других фреймворков, а значит отличий нет. Точнее есть одно отличие, о котором ты знаешь: он написан на rust'е.

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

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

Это выглядит очень глупо, когда это так излагаешь, но в нашей стране это довольно распространённая философия, потому что она продвигается государственной пропагандой. И не только государственной. Из этого, например, вытекают уголовные преследования участников несуществующих организаций. Ещё это удобно государству тем, что любой кто против него автоматом лишается статуса человека: он не обладает свободой воли, а значет действует по чьей-то указке. Таким образом, при всей видимой невероятности такого мировоззрения, оно весьма вероятно в наших широтах. Я думаю, что не меньше 60% населения видит мир именно таким образом. А раз так, вероятность того, что ты под влиянием этого >0.6.

Объединяя (1) и (2) мы получаем именно тебя. Ты видишь вокруг множество упоминаний раста по всяким разным поводам. Поводы для тебя не существуют, потому что ты не утруждаешь себя пойти и посмотреть о чём сыр-бор, но вот растущую популярность раста ты видишь. Значит цель всего этого -- растущая популярность. А поскольку это не может быть стихийной активностью, значит за этим стоит какой-то mastermind, и всё что ты видишь -- это управляемый процесс. Процесс, который где-то управляется через прямые выплаты в валюте, где-то за счёт промывки мозгов.

Вуаля! Взяв два простых допущения мы получили модель Celcion, которая точно предсказывает все его высказывания.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 26-Май-25 10:44 
> Вуаля! Взяв два простых допущения мы получили модель Celcion, которая точно предсказывает все его высказывания.

И не лень же тебе было весь этот псевдоинтеллектуальный бред писать...


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 26-Май-25 11:44 
Нет, не лень. И тебе я рекомендую не лениться, но записывать свои мысли словами. Мысль которая не была сформулирована -- это не мысль. Это кстати позволяет избегать зияющих дыр в рассуждениях очевидных всем, кроме тебя самого.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:25 
> Понимаешь... Тут такое дело... Я немного дольше в ИТ сфере вращаюсь [...] Почитай как ту же джаву Sun продвигал и какие великие дела с помощью неё обещал делать [...] Отсюда и скептицизм - мы всё это уже видели.

Я не "вращаюсь" в айти сфере, я и есть айти сфера. Мне не надо "читать про Сан" и их "обещания", я сам и на сях и на жаве и на расте пишу и знаю как они работают и на что способны. Никакие обещания никого не волнуют, речь про то, что раст делает уже сейчас. Даже без улучшений полониуса он навсегда оторвался по возможностям от всех языков планеты Земля. Обещания ему не нужны, обещания нужны только С++ который всё только обещает и ькжится а сделать не может. Ну и жава тоже последние 30 лет только обещает, что JIT всех победит, а на деле всё тупит и память жрёт. Раст ничего не обещает, он уже всё делает прямо здесь и сейчас. И конкурентов у него ноль. Это не вопрос того, кому что больше нравится. Выбора нет. Проблему с памятью уже решил (а не обещает решить) только он.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 11:44 
> Даже без улучшений полониуса он навсегда оторвался по возможностям от всех языков планеты Земля.

И полетел изучать другие планеты, ага...

> Раст ничего не обещает, он уже всё делает прямо здесь и сейчас. И конкурентов у него ноль.

Да. И каждый раз говорилось ровно то же самое про каждый новый "революционный" язык. А потом, с течением времени, практики применения и прочего - как-то всё оказывалось не так радужно. Не вижу смысла очередной раз повторяться. Почитай выше мной написанное, может дойдёт о чем идет речь. Ну, или не дойдёт, тогда и говорить дальше не о чем.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 12:54 
> И каждый раз говорилось ровно то же самое про каждый новый "революционный" язык.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 13:03 
> Про какой "каждый новый" язык говорилось, что он, сохраняя эффективность по ресурсам Си решил проблему ручного управления памятью? Тебе будет легко привести пример, ведь это было про каждый новый. Но давай хотябы один.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 13:07 
То есть ты не смог привести даже один пример. Зачем тогда врёшь?

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 13:11 
> То есть ты не смог привести даже один пример. Зачем тогда врёшь?

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 13:28 
> Я немного дольше в ИТ сфере вращаюсь,

Конечно, всем же известно что CelcionOne это специалист высочайшего класса!
О его подвигах слагают легенды....

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

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

Так она и стала революцией.
Банкинг и бизнес? Java
Написать IDE? Java
Jenkins, который широко используется? Тоже внезапно Java

> Приложения и игры на телефонах.

А сейчас что по твоему работает внутри андроида?
Google Earth, Uber, Netflix, MATLAB, Minecraft это разве не приложения или игры?

> Отсюда и скептицизм - мы всё это уже видели.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 14:28 
> Видеть видать видели, а понять судя по всему не смогли.

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 03:33 
Нет никакой проблемы работы с памятью. Посади таких растописателей в реальную среду и заставь писать код на нормальном языке - они ошибок будут делать похлеще "дидов". Нужно не языки новые писать, а новое поколение программистов обучать, прям с азов, как там все на железном уровне работает, обучать проектированию архитектур, логике и прочем. Не курсами кормить, а гнать в вузы на кафедру computer science.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:26 
> Нет никакой проблемы работы с памятью.
> Нужно не языки новые писать, а новое поколение программистов обучать

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 10:32 
> А, так это просто программистов не обучили, что нужно ресурсы освобождать?

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:50 
>> А, так это просто программистов не обучили, что нужно ресурсы освобождать?
> Ты не поверишь, но многие современные прогеры даже не догадываются о том, что ресурсы нужно освобождать и делают круглые глаза когда им про это говоришь

Но ведь речь шла о Рсте и С? Ты ведь С имел в виду, когда говорил про "нормальный язык", не так ли?


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Celcion , 22-Май-25 10:54 
> Но ведь речь шла о Рсте и С?

Я про си не говорил вообще.

> Ты ведь С имел в виду, когда говорил про "нормальный язык", не так ли?

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


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 11:01 
> Я про си не говорил вообще.

А, сори, перепутал.

> Слушай, я понимаю, что в твоей картине мира

существует только два стула.

Дело не в картине мира, а в контексте новости о системном программировании под FreeBSD, где подразумевается только C и Rust. Да, тут действительно только два стула.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:15 
> Нужно не языки новые писать, а новое поколение программистов обучат

Так диды за 40 лет не научились!
Думаешь они не знают что память нужно очищать только один раз? Знают!
Или что за пределы буфера писать низя? Тоже знают!
Это и первокурсник computer science знает. В теории. А на практике не получается ни у кого.

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

Сишка создавалась для ускорения портирования асм кодов юниксов на другие платформы.
Сколько строк в первом сишном юниксе v4 ты можешь посчитать сам (github.com/dspinellis/unix-history-repo/tree/Research-V4-Snapshot-Development). А теперь сравнить это число с современными программами на си. С ядром например :)


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 12:34 
> эффективности траты ресурсов лучше, чем Раст

Раст _никогда_ не будет управлять памятью лучше чем Си. Потому что боров чекер ограничивает тебя архитектурно когда и как ты пользуешься памятью и освобождаешь. Или будешь писать на unsafe? Тогда смысл в расте?


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 23-Май-25 11:10 
> Раст _никогда_ не будет управлять памятью лучше чем Си.

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

> боров чекер ограничивает тебя архитектурно

Плохому танцору всегда мешает что-то другое.

> Или будешь писать на unsafe? Тогда смысл в расте?

Вы не понимаете, что такое unsafe. Функция помечается как unsafe, если есть возможность допустить UB, вызвав ее с неверными параметрами. Вызывая unsafe-функцию, программист явно указывает, что он прочитал документацию, проверил параметры и берет на себя ответственность за возможные последствия. То же самое касается небезопасных операций, таких как разыменование сырых указателей, изменение статических переменных или вызов FFI функций. Если вы боитесь брать на себя ответственность, тогда как вы пишете на Си?


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Илья , 22-Май-25 05:42 
C#

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 07:40 
Я надеюсь это будет Borland Pascal.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 18:20 
Легендарный Borland опередил своё время. Их гениальные решения для быстрой разработки ПО стали эталоном практичности и удобства, а многие идеи, заложенные в их продуктах, до сих пор используются в современных инструментах. Borland доказал, что разработка ПО может быть быстрой, эффективной и при этом доступной. Многие концепции, которые сегодня кажутся стандартными, были популяризированы именно Borland.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:03 
Zig, здесь часто возгласы раздаются.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:26 
Для написания ядер ОС ещё компромиссом бы мог являться Hare де Волта. Такой осовремененный C с модулями. Он сам на нём микроядро наваял.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Erley , 22-Май-25 01:56 
Переписывание на Rust займёт много лет, поэтому будет HardenedBSD жить своей жизнью, а FreeBSD - своей. При этом FreeBSD будет майнстрим и всё новое появляться в ней и потом портироваться на HardenedBSD.

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

Официально вот что известно о Rust в _FreeBSD_: https://wiki.freebsd.org/Rust - там только про порты (почему бы и нет), helloworld модули и статьи всякие.

Заголовок новости нужно s/FreeBSD/HardenedBSD/ чтобы не вводить никого в заблуждение.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 06:55 
В отчёте ясно сказано о намерении продвигать работу в upstream, так что заголовок верный.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено bOOster , 22-Май-25 10:51 
Продвигать и продвинуть - разные вещи. FreeBSD -  прагматики и раста не будет в ядре до тех пор пока не будет проведен полноценный аудит безопасности языка, в том числе и в долгий период времени.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:18 
> Вспомните сколько лет заняло избавление от gcc в базе,
> а это просто другой компилятор того же языка С.

Наоборот. Проблема как раз в том, что это ДРУГОЙ компилятор того же языка С. И часть вещей была приколочена именно к нему. В случае с растом используется тулчейн раста (карго, растц и тд) и тот же самый llvm. Так что с этим проблема будет на порядок меньше. По факту, нужно просто интегрировать возможность сборки из стандартных тулов бсд.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 12:40 
То есть вы наивно думаете что переписывания с одного языка на совершенно другой быстрее и проще чем поправить точечные расхожденя работы компиляторов одного и того же языка Си? К слову, в clang добавили поддержку gnu расширений.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 13:52 
> То есть вы наивно думаете что переписывания с одного языка на совершенно другой

А где там написано про "переписывание"? Там про удобное использование раст-программ в BSD.

"We introduced a new BSD makefile [...] that enables building a Rust application during buildworld."

А теперь отзеркалю ваш же вопрос - вы действительно думаете что добавить гунтые расширения и "поправить точечные расхождения работы компиляторов" проще чем просто "сделать так чтобы софт на расте пересобирался во время buildworld" ?

> К слову, в clang добавили поддержку gnu расширений.

Да. И даже ядро стало билдиться.
Вот только на ломание этого вендорлока и адаптацию жццшного овна ушли годы.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:28 
Здесь:

> Переписывание на Rust займёт много лет, поэтому будет HardenedBSD жить своей жизнью, а FreeBSD - своей.

Не теряйте контекст обсуждения.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 14:57 
> Не теряйте контекст обсуждения.

Эта ветка обсуждает только процесс избавления от GCC (opennet.ru/openforum/vsluhforumID3/136916.html#94), переписывание чего-то на раст (opennet.ru/openforum/vsluhforumID3/136916.html#48) к этому треду никакого отношения не имеет.
Будьте внимательнее, пожалуйста.

Но раз зашла речь о переписывании, то повторюсь, по задумке авторов HardenedBSD ничего переписываться не будет. Цель проекта четко очерчена и цитату (вот от сюда hardenedbsd.org/article/shawn-webb/2025-05-20/optional-rust-freebsd-support-may-2025-status-report) я привел выше.
Все остальное - фантазии местных комментаторов.



"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 03:04 
То, что майкрософт на раст клюнул - тоже закономерно, сколько у них было технологий-однодневок - не пересчитать, начиная с VB6, Silverlight, MFC, OLE, COM, DirectShow, постоянные кидки-недоделки. То же самое и здесь будет - поиграются, бросят, и пойдут возбуждаться очередными хайповыми и баззвордными поделиями. Оно так по кругу и идёт давно, те кто по-старше могут сопоставить. Гуглята от майков в этом плане мало чем отличаются, современная раздутая айтишечка - непроходимое болото.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:16 
Разве^ COM куда-то делся? Посмотрите новость про (при)открытие WSL2, там на блок-схемах есть про COM-объекты.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 16:45 
COM+ точнее, просто задвинули подальше, хотя раньше эту технологию они пиарили как чуть ли не самую прорывную и центральную во всём, типа весь интернет, все приложения будут использовать, ActiveX, и всё такое. А сейчас всего лишь полузабытая узконишевая тема, о которой практически нигде не слышно.
Можно ещё вспомнить свистопляску с Metro, WinRT, UWP, сейчас типа уже WinUI, как они пытались всё перевести на дот нет, а потом кинули, что у них там с версиями и поддержкой, там у них такая каша, в которой они сами с трудом разбираются, а с добавлением вайб-шкодинга индусы майкрософт окончательно утопят, что по катастрофическим апдейтам бесятки уже заметно. Жаль конечно с одной стороны, но наверное это карма.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено MinimumProfit , 22-Май-25 17:05 
МикроСофт страшно боится отстать в чём-то от конкурентов, и что Windows из-за этого перестанет быть популярной. Если конкуренты что-то используют - надо тоже использовать, а хорошо это или нет - им это не важно. Если что-то стало популярно в народе - надо тоже у себя это сделать.

Популярны приложения Linux - надо тоже сделать чтобы они в Windows запускались.
Конкурент Гугль в своих ОС использует Rust - надо тоже в Windows использовать Rust, чтобы Windows не выглядела отстающей.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 17:16 
Да, так и есть.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 20:02 
А эти конкуренты с нами в одной комнате?

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 07:41 
Жду новостей о том что GNU/ Hurd и ReacOS переписывают на Rust.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Анониматор , 22-Май-25 08:02 
они ещё уровень Python не прошли

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 08:08 
В GNU/Hurd же сервисы, как отдельные исполняемые бинарники, со своим main. Поэтому, их можно писать на любом языке. Да хоть на интерпретируемом. Как это будет шустро, мы не говорим.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено bOOster , 22-Май-25 10:49 
Очередной бредовый заголовок. HardenedBSD построен на основе FreeBSD и никакого отношения к FreeBSD не имеет.
В отношении Rust на BSD - имхо ключевые решения в FreeBSD всегда были прагматичными - поэтому, как минимум раст не будет ядре до тех пор пока не будет проведен полноценный аудит безопасности раст, в том числе в достаточно длительном периоде времени.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 22-Май-25 10:54 
> Как минимум раст не будет ядре

Ты новость читал? При чем тут ядро?
Даже в HardenedBSD его добавляют в юзерспейс, а не в ядро.


"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено bOOster , 22-Май-25 11:51 
Для юзерспейса вообще нет разницы на чем писать. В этом контексте новость даже рассматривать смысла нет.

"Для FreeBSD развивают опциональную поддержку компонентов баз..."
Отправлено Аноним , 27-Май-25 14:06 
Ну и омтанется в конце понцов форкнуть нескорапченный линукс и фрю и развивать,мли пилить свок,без маркетингового токсичного мусора