>>143774> Нет смысла отвечать на пачку односложных предложений без пруфов.
Потому что их большинство - первые статьи в гугле или в заголовках википедии
Это не я утверждал об микроядерности Linux'а.
> если ты толстишь так, что вылезаешь из треда, то зачем это всё?
А от этого только вздыхать хочется, ты бы еще про троллинг упомянул.
> Трогать в другое место иди, я твои предпочтения не разделяю.
К сожалению :3
>>143775Но давай делиться ссылками на википедию, почему бы и нет.
> Дистрибутивы с альтернативными инитами с тобой не согласны. Другие ОС тоже.
Я помню твое утверждение, что Arch перешел на systemd, потому что это считается модным. Но давай посмотрим их официальный реддит?
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlcИ ни слова про модность, только про проблемы и их решение.
Вот еще один большой тред, адекватно обсуждающий systemd. И Поттеринга там не упоминают, потому что к вопросу использования он ортогонален.
https://lwn.net/Articles/777595/> см. выборы в Debian.
А я посмотрел!
https://wiki.debian.org/Debate/initsystem/systemdИ опять увидел только набор проблем против набора systemd решений.
> Обоснования ты, конечно, всему этому не дашь.
Что делает клиент, а что делает сервер?
По сути клиент обращается за данными и делится информацией о произошедших событиях.
Что делает Х сервер? Отправляет клиентам положение мышки и нажатия на клавиатуре, как пример, т.е. выступает в качестве клиента.
Больше на тему астрономической боли и иксов.
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html> Можно впилить внутрь безопасность и сделать её обязательной.
Мне больше всего нравится FAQ xscreensaver'a по этому поводу:
https://www.jwz.org/xscreensaver/faq.html#no-ctl-alt-bsПонятно, что за много лет протокол и его реализацию вылизали практически до блеска, так про весь UNIX-мир, к сожалению, говорить можно.
> Даже внутри ядра пилили, емнип
В винде также перенесли реализацию в ядро, к слову, первое что вспомнилось.
> Что-то, что не будет сервером одной реализации и ОС
Но это также протокол, а реализация уже стоит за тобой.
> Linux, FreeBSD, NetBSD, OpenBSD, MacOS, Solaris
Современные? Да ни разу: они все либо корнями уходят в древние реализации UNIX'a, либо используют в своей основе подходы из 60-ых.
> GNU Hurd
К сожалению, мертв.
0.9 / 18 December 2016; 3 years ago
> Остальное
Про остальные ничего не знаю, может на досуге почитаю.
Также ты не назвал ни одной оси (из тех, которые я знаю, повторяюсь), которые появились в 21 веке, к слову о современности.
> Расскажи нам, что такое "современное"? То, у чего больше лайков на Твиттере?
То, что оприается на современные научные публикации и использует современные технологии.
NixOS один пример, Rust - совершенно в другой сфере, но второй.
Haskell - пусть и морально старый, он в 2000-ых годах предлагал больше, чем популярные языки сейчас. Agda, Idris, Elm, F#, TypeScript еще примерами. К сожалению, современных популярных микроядерных осей пока еще нет.
Опять-таки, может Rust что-то исправит в ближайшее время, надеюсь?
> Только этой цели не стояло.
А давай посмотрим
почему не стояло. Посмотри на долю рынка одного относительно второго, и, скажи, стоит ли того головная боль. Да, конечно!
https://w3techs.com/technologies/comparison/os-bsd,os-linux> Чем тебе не нравится препроцессор?
Потому что он работает с текстом, а не с кодом. Никакие правила скоупа не применяются, он может заменить в коде что угодно, где угодно и когда угодно.
Это одно из тех зол, с которыми приходится мириться, Unix - другое зло, потому что без них сейчас никуда не деться.
За 8 лет наконец-то получилось добавить их в стандарт:
https://isocpp.org/blog/2012/11/modules-update-on-work-in-progress-doug-gregor> Кусается больно?
Да, очень.
> Кто действительно умеет писать код, тот допускает меньше ошибок.
Давай писать все на ассемблере, кто действительно умеет писать, тот допускать ошибок все также не будет. Этот снобизм постоянно проявляется в юникс-мирке. От "You're not supposed to understand this code" комментариев, до "If you don't know what kernel functions do, you probably shouldn't be using them" документации, до "Тот, кто не умеет писать код, не сможет писать и на расте" комментариев.
> unsafe-код — это всё ядро
Ядро - это не только общение с драйверами. А необходим unsafe-код по большей части именно там.
> Рак точки с запятой. Там, где они не нужны, их не надо совать.
Не очень понимаю про что ты. Как абстракции связаны с точками с запятой?
> Си — это общий знаменатель. Потому что общий знаменатель именно таков.
Прости, я не прослеживаю мысль. Любому языку будет трудно общаться с любым другим языком, да. Общаться с си - одна головная боль, ему ни указателей дать нельзя в свои структуры, потому что со сборкой мусора не дружит, нельзя даже в других потоках запускать, потому что си-коду иногда это очень не нравится. Си лежит в основе всего только по историческим причинам.
> Теперь объясняй, почему твоя модель оптимальна для всех многозадачных программ. и почему правильная модель только одна?
Во-первых, афинные типи и заимствование не являются моделью как таковой - это низкоуровневые конструкции, позволяющие реализовать другие более высокоуровневые модели на них, читай абстракция. Они на столько же модель, на сколько мьютексы являются моделью.
Во-вторых, unsafe-code.
> Boehm GC, ARC
Подразумевая, что другой си код может свободно вызывать все подобные эти библиотеки. Нет, просто большинство структур данных идентичны си - не надо маршалить их одну в другую, отсутствие сборщика мусора позоляет игнорировать создание промежуточных пулов памяти для общения с сишкой и низкоуровневость языка позволяет точно отслеживать как, когда и на каких потоках этот код будет вызываться.
> Компилятор обычно не умнее человека.
Компиляторы во много раз умнее людей. Количество различных оптимизаций и евристик не сравнятся с знаниями среднестатистического программиста.
И даже если раст будет медленнее - мы живем в 21 веке, у меня 16Гб ОЗУ и 4 ядра с двумя потоками на каждом. Мне не жалко лишних циклов процессора во имя безопасности. Да и все почти всегда упирается в IO в любом случае.
> с функциональным кодом в каше вместе оптимизируются не очень хорошо
Покажи, покажи.
> Вызывает не сишечка, вызывают те, кто не умеет писать код или пользоваться библиотеками на сишке.
Снобизм и gatekeeping обсудили.
> Никогда не приходилось подбирать опции для JVM?
Нет, и надеюсь не придется.
> Каким образом обёртка определённого языка над разделяемой памятью проще независимой от языка абстракции, работающей на файлах?
Это не обертка, это не определенного языка, это подход, который можно использовать для IPC. Да и ты спрашивал мой любимый, любимый я тебе и показал.
Если хочешь чего-нибудь более близкого душе:
https://hackage.haskell.org/package/conduit-1.3.2/docs/Data-Conduit.html#g:1Посмотри, типизация, простота комбинации "пайп" между собой, устойчивость к ошибкам и исключениям. В баше, который работает на уровне строк, этим даже и не пахнет.
> Кавычки ставят тогда, когда надо
Мне нравятся консистентные языки, без непродуманного синтаксиса и с тысячью внегласных правил. Еще я люблю, когда мои абстракции подчиняются четким законам, вот парочку примеров:
https://wiki.haskell.org/Monad_laws> разучил тебя обрабатывать ошибки и ставить условия
Наоборот, наоборот! Хаскель меня всегда заставляет обрабатывать ошибки и ставить условия! Если я использую Either, или ExceptT, или Maybe, или вообще что-нибудь завязанное на логику и типы, то компилятор меня всегда наругает за плохой код, а не поощряет, чтобы потом случайно умереть и сделать что-то вредное, как баш.
> гнутой документации
Документация мне нужна для документации - не для политических идей и стязаний.
> И винда, с которой ты пришёл и хочешь, чтоб было, как в ней.
Все мы откуда-то пришли, и все мы чего-то хотим. Только некоторые коммьюнити огораживаются от всего мира огромным забором и тыкают вилами во все, что им не нравится, что не как по старинке.
> За три года CVE в целой ОС меньше
На три больше - это во-первых. Во-вторых CVE растут пропорционально с количеством пользователей. И systemd использует куда больше людей, плохо-ли-хорошо это.
https://www.cvedetails.com/vulnerability-list/vendor_id-7971/product_id-38088/Freedesktop-Systemd.html> Трог-трог-обратно :3
> Хочешь выкинуть? Расскажи, чему надо придерживаться unix-подобным системам. Каким стандартам? Пожирнее?
Стандарты нужны, когда есть конкуренция и множество
популярных реализаций. Как пример, в Хаскеле есть больше 100 различных прагм для языка, и над стандартизацией этого всего никто не волнуется. Haskell2020 должен был появиться, но, к сожалению на общей почте последние обсуждения по этому поводу проводились более трех лет назад. Вторым примером будут плюсы, которые первый стандарт получили только после ~10 лет жизни без него - потому что он стал необходим, потому что появились альтернативы компиляторов.
> Бернштейна и OpenBSD ты намеренно игнорируешь
Да, явно, и с повернутой и приподнятой головой.
> централизованное хранилище кода
Чтобы не ломать зависимости, чтобы проверять работу всей архитектуры вместе, за тем же за чем нужен Stackage в Хаскеле.
> всю технику старше трёх, пяти, десяти и более лет
Вся техника, для программирования на которой создавался си, давно стоит в музеях и занимает целые комнаты. Сейчас железо куда дешевле софта - если течет память (что происходит с си постоянно), чаще проще купить больше серверов и перезапускать их время от времени. И это факт, с которым надо смириться.
> не можешь даже в простенький шелл
Не могу и не могу правильно - две разные вещи. Раст эргономичен и помогает тебе во множестве ситуаций - компилятор мой самый лучший друг, хотя бы потому что у меня других нет.
> К слову, назови мне те линуксспецифичные фичи, которыми ты пользуешься.
Возможно никакими? Но их большинство было написано до меня, декларативно, и все что мне надо - изменить буловский флажок для их работы - никакого чтения мануалов и сайдэффектящих изменений.
> Тем, что это должен быть простой cantrip. Линейный
Возможно должен? Меня все устраивает однако. Да и "потому что должен" аргументы не очень помогают.
> исходник генератора
> никакой синхронизацией
Вот он и является элементом синхронизации.
> оно глючило и падало
Да, потому что вся система, в которой приходится работать, этому всеми очень способствует.