Насколько разобщены сообщества?

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

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

так ты определись уже: мерзкий опенсорц или всё ж таки гайдлайны и вот это всё. gcc писали более 30 лет. писали никакие не правильные копроративщики, а всякие анархисты и либералы.

Так 100 лет назад еще внукам оставался дедушкин парадный пиджак.

Ты кажется ноешь что прогресс ускоряется и то, что поддерживалось по 20 лет, сейчас никто не хочет поддерживать. Трансформируется отношение к софту и ты не подстраиваешься под эпоху.

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

если эти либы так уж прямо незаменимы, то тут возможны варианты:

1) собрать один раз компилятором X, и дальше держать только бинарь 2) включить компилятор X в «SDK» разработчика системы

Вообще, если какая-то либа написана на С++17, то скорее всего это какой-то новодел с нулевой пользовательской базой и соотв. нечего некому сломать. А широкоиспользуемые либы используют старый добрый С++. Например, Eigen - на С++98.

нет. внезапно, ты опять ничего не понял. ещё раз прочитай мои посты.

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

Да, а теперь boost который тебе когда-то нравился, стал playground для будущих стандартов

Да он вроде всегда таким и был?

http://www.boost.org/

С сайта до сих пор говорится, мол 10 библиотек из Boost’а включено в стандарт уже древнего C++11.

Да, возможно он таким и был с самого начала. Просто С++11 слишком долго делали.

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

и там только одна реально требующая поддержки компилятора фича - variadic templates. нужна чуть менее чем в 0.001% случаев. остальное спокойно можно было оставить в виде библиотек.

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

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

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

Я не фанат новых С++ стандартов, но большинство фич новых стандартов как правило затрагивают STL и в меньшей мере компилятор.

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

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

Здравствуйте, просьба пояснить, не рассматривали ли вы работу в более стабильных, читаемых(libc(хотя, наверное если вы патчите musl - не знаю что лучше читаемо..) и исходники всего дистрибутива) и цельно поддерживаемых средах, типа OpenBSD с отностительно новым Firefox?

Возможно, там не хватает аудио или видеодрайверов, но в таком случае можно перезагружаться для неосновной работы(отдыха)?

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

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

Глупый вопрос с очевидным ответом.

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

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

я использую только опенсорц. nvidia у меня просто отключена, пока она не поддерживается в nouveau. но мне хватает GPU в проце. жирнолис не использую с тех пор, как они свой код перевели на ненужно. мне ненужно не нужно и у меня на машине его не будет :) есть другие браузеры.

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

Понятно, спасибо!

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

В нём(OpenBSD) базовый дистрибутив основан на консервативном Си, и они до сих пор не выкинули поддержку своего патченного компилятора старинной версии. И старинную версию ev в свой дистрибутив встроили с правками.

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

А про сборку неотносящегося к дистрибутиву софта, может быть большая разница из-за отставания в реализации(отсутствие) разнообразных относительно Linux'а системных вызовов, а то что есть - однородно архитектурно спроектировано, сделано проще (не в смысле упрощения из-за недопонимания как должно быть правильно по каким-то субъективным канонам, а для целей минимизации ошибок, подстраивания под секурные механизмы смягчителей) и лучше документировано. И гиганты подстраиваются, типа Go, но основного энтерпрайза нет по сравнению с Linux. Если работа не связана с ним, то может и лучше будет подходить.. но наверное нет готовых драйверов для разнообразных сопрягаемых железок.

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

Chromium там есть: https://www.reddit.com/r/openbsd/comments/dm2j71/browsers_used_by_openbsd_dev...

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

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

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

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

в данном случае, я не совсем представляю себе, что такое «смягчители». но я считаю, что ошибки не надо смягчать. софт с косяками должен жёстко падать, без вариантов. ошибки в софте недопустимы. это сам смысл программирования. программирование с косяками - это как производство брака. нафиг оно нужно?

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

Насколько разобщены сообщества?

А насколько сообщены разобщества?

Я так понял, вы перешли не знаю с какого дистрибутива на Void.. рассматривали ли переход на консервативный Slackware, что-то не устроило м.б.?

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

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

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

ошибки надо вовремя отлаживать и устранять. если софтина падает - это не причина делать обёртку. это причина исправлять код. в норме софт должен запускаться без всяких обёрток.

Понятно, спасибо за развернутые ответы.

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

Какие-то приёмы на примерах может быть.. м.б. уникальность ловли всего на этапе отладки.. всё же интересно.

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

да нет никаких приёмов. обычный valgind и gdb. всё как всегда.

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

вообще, нельзя доказать отсутствие ошибок. можно доказать только наличие ошибки.

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

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

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

вообще, нельзя доказать отсутствие ошибок. можно доказать только наличие ошибки

Почему первое «нельзя», а второе «можно»? Раскрой мысль.

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

Можно доказать присутсвие продемонстрировав (не смогли пока).

Но если я правильно понял IronBug, она таки может.

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

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

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