>>204576
Ты знаешь, зачем тебе linux?

>>204576

> подводные камни при пользовании данной OC

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

>>204576
Подводных камней нет

>>204577
Производительность

>>204580
А что производить собираешься?

>>204581
Слабоумие

>>204582
Perfect!

>>204576
С поддержкой железа искаропки бывает не все гладко. Вифи/блютус модули у ноута могут не заработать, например. Драйвер нужно будет искать ставить отдельно.
Могут вылезти какие-нибудь проблемы, решение которых неочевидно (особенно для нуба).
Могут возникнуть проблемы с кривой реализацией UEFI, который нормально распознает предустановленную венду, но линукс ВНЕЗАПНО не видит. И даже не факт, что это будет решаемо.
Поэтому рекомендую на всякий случай оставить себе возможность загрузиться в венду.

>>204576

> подводные камни

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

>>204578
Ну вовсе не обязательно компании об этом информировать.

>>204576
Это линукс. Почти все подводные камни растут из этого.

Не слушай их, няш. Просто тут не все пользователи хороших систем.

> есть ли подводные камни при пользовании данной OC

Для новичка их не будет, в принципе. Как подрастешь и наберешься опыта, может и будешь видеть, хотя не факт.

>>204593
О чём ты говоришь? У линукса нет недостатков в принципе! Гибкая, дружественная система, открытый код, фундаментальное отсутствие троянов и вирусов, невероятное быстродействие, скромные системные требования, безграничная кросплатформенность, простота освоения, бесплатность софта (такого же свободного, шустрого, открытого, итд), безграничные возможности по написанию недостающего своего... на что там, всего не перечислишь. Многие программы под линуксом работают даже лучше чем под родными операционными системами. Не понимаю, почему до сих пор ещё весь мир не перешёл на линукс. Линукс - мечта во плоти, то к чему всю жизнь ты подсознательно стремился. Стоит только попробовать и линукс тебя не отпустит.

>>204594

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

Кроме простоты освоения всё верно.
К чему весь этот сарказм, форточник?

>>204595
Если всё верно, то почему сарказм? Может потому, что ничего не верно? А что и можно притянуть, с такими оговорками что лучше не стоит?

>>204598

> Если всё верно, то почему сарказм? Может потому, что ничего не верно?

Ты прекрасно понимаешь, что я имею ввиду, но все равно спрашиваешь. Форточники такие форточники, бжемой.

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

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

>>204576
Не сможешь моделировать магнитостатические системы в FeMM-e.

>>204601
На венде NTFS - самая ужасная файловая система.
На венде самые ужасные пути.
На венде самые ужасные переменные среды.
На венде ужасная архитектура.
На венде ужасные проблемы ядра.
На венде ужасное WinAPI.
На венде ужасная адрессация памяти.
На венде был баг с удалением System32.
На венде зонды.

> И хотел задеть, напомнив о их комформизме.

Меня вот так просто не задеть.

>>204594

> Многие программы под линуксом работают даже лучше чем под родными операционными системами

Где-то я уже слышал подобный бред. Сам понял, что написал?

Я бы всерьез рекомендовал debian unstable или debian sid, раз уж это все с дебиана растет. Причина: сидеть в самом-самом даунстриме - страдание.
Насчет подводных камней - пока не опишешь точно, для чего будешь использовать свой машинЪ, никто тебе четко не распишет. Если собираешься играть в игры, оставайся лучше на венде, там лучше кормят.

Linux-тред у нас здесь, да? Более другого всё равно не нашел.

Вот проясните мне кто-нибудь за ssh и systemd. Ленарт наш Поттер, или как там его, советует в своей книжке запускать sshd через сокеты. В стандартном пакете дебиана имеются оба варианта конфигов, но запускается по умолчанию по умолчанию всё же ssh.service, а отнюдь не ssh.socket.

Вопрос — какие у второго варианта подводные камни и стоит ли его юзать?
И да, если ssh у нас, допустим, на нестандартном порту, то где его в этом варианте менять — только в ssh.socket, или и там, и в sshd_config?

>>205824
ssh.socket — это фактически то же самое, что запуск через inetd. Да, все новое — это очень хорошо забытое старое.
В этом случае на порту висит не ssh, а systemd. sshd же будет запущено по соединению с портом.
Естественно порт в такой схеме нужно менять в юните/оверрайде systemd.
Преимущество в том, что если по ssh никто не подключен, то не используется дополнительная память на демон. Недостатки в том, что в случае подключения к ssh идет не форк, а запуск бинарника, что более ресурсоемко, так что такая схема не подходит для систем с высокой ssh-активностью. Ну, и плюс еще есть вопрос о том, насколько администратору комфортно выставлять systemd в публичную сеть, да и насколько systemd можно доверять для столь критичного сервиса как ssh.

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

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

>насколько администратору комфортно выставлять systemd в публичную сеть

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

>>205827

>А как там, вообще, с безопасностью?

http://without-systemd.org/wiki/index.php/Arguments_against_systemd
https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

Если вкратце, то потенциально очень плохо. Своевременное латание дыр - это только часть безопасноти.

>>204603
И чем же плох ВинАПИ? Львиная доля функций разрабатывалась уже с оглядкой на то, как реализовано под линухами и некоторые вещи выходили действительно более мощными и в то же время более простыми.

>>205831
Виндовые кодовые страницы и UTF16 — это просто невероятная куча дерьма, заставляющая вонять весь WinAPI.
Плюс отсутствие POSIX-совместимости. Плюс C++ вместо чистого C со всеми веселостями плюсового API.
WinAPI — это ужас.

>>205832
Плюсового АПИ у самой Винды нет. COM - это библиотека, поддерживаемая со стороны ОС, но никак не API ОС.

>>205827

>можно очень легко задавать ей разные правила для разных портов

Конструкции вида unit@foo@bar.service, afiak, не поддерживаются.

А тут, по-хорошему, нужна именно такая. Сперва ssh@.socket, с условием, скажем, ConditionPathIsDirectory=/etc/ssh/%i (где %i — порт. И папка, в которой будут нужные конфиги). Дальше оно должно, по идее, стартовать что-то вроде ssh@@.service, но так, похоже, нельзя.

Можно первый уровень шаблона генерировать каким-нибудь скриптом, но это криво…

>>205832

>отсутствие POSIX-совместимости

Просто у вас линукс головного мозга. Мир не крутится вокруг юникс-совместимого софта. Как и вокруг винды.

>>205846

>Мир не крутится вокруг юникс-совместимого софта.

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

>>205870
Разумеется. Я и ездить не буду.

>POSIX-совместимости

https://www.opengroup.org/openbrand/register/

Линукс + POSIX = лотерея.

В принципе не лотерейная совместимость в линуксе достижима, в списочке два китайских дистрибутива например, на деле никто и за lsb-core гнаться не старается. Будет ли при желании достижима через 20 лет текущим курсом вопрос открытый.

Твой банк использует, скорее всего, UNIX совместимый мейнфрейм .. и все.

>>205898
POSIX-совместимость и сертификация — это все-таки разные вещи.

>>205839

>Конструкции вида unit@foo@bar.service, afiak, не поддерживаются.

И все же, я не оставляю надежды. Дано:

$ sudo systemctl --full | grep tstsrv
  tstsrv@1-127.0.0.1:9900-127.0.0.1:52438.service    loaded active running   test server: service 1 (127.0.0.1:52438)
  system-tstsrv.slice                                loaded active active    system-tstsrv.slice
  tstsrv@9900.socket                                 loaded active listening test server: socket port 9900

Вопрос. Возможно ли хоть как-то внутри tstsrv@.service получить номер порта, на котором сидит .socket? Или хотя бы всю строку 1-127.0.0.1:9900-127.0.0.1:52438? В %i у нас только 1...

>>207092
Так дефисы ведь вроде обладают служебным значением для имен в systemd. Не в этом проблема? Что в %I, кстати?
А вообще зачем это получать из service? Оно может быть активировано не только через TCP-сокет, но и напрямую, например.

Это может иметь значение для самого бинарника для правильной обработки дескриптора. Но он может получить нужную информацию через getsockname и sd_is_socket_inet при получении того самого переданного fd от systemd.

В общем-то юнит типа service не должно интересовать на каком порту висит юнит socket.

И вот это про активацию однозначно стоит прочитать: http://0pointer.de/blog/projects/socket-activation.html

>>207092

>1-127.0.0.1:9900-127.0.0.1:52438
>В %i у нас только 1...

Интересно… systemd 215 возвращает всю стоку целиком. А вот 232 — только первую цифру. И 239 тоже. Это баг или фича?

>>207096

>А вообще зачем это получать из service?

Передавать ему разные конфиги в зависимости от того, на каком порту он запущен, как предлагалось в >>205827, например.

>Что в %I, кстати?

Тоже только первая цифра.
В %n — tstsrv@1.service

>>207099

>Передавать ему разные конфиги в зависимости от того, на каком порту он запущен

Решение найдено:

$ sudo systemctl --full | grep tstsrv
  tstsrv-9009@0-127.0.0.1:9009-127.0.0.1:39374.service    loaded active running   test server: service port 9009 (0) (127.0.0.1:39374)                                       
  tstsrv-9900@2-127.0.0.1:9900-127.0.0.1:41888.service    loaded active running   test server: service port 9900 (2) (127.0.0.1:41888)                                       
  system-tstsrv\x2d9009.slice                             loaded active active    system-tstsrv\x2d9009.slice                                                                
  system-tstsrv\x2d9900.slice                             loaded active active    system-tstsrv\x2d9900.slice                                                                
  tstsrv-9009.socket                                      loaded active listening test server: socket port 9009                                                              
  tstsrv-9900.socket                                      loaded active listening test server: socket port 9900                                                              

Требуется systemd 239 или выше. Для указания порта следует использовать параметр %j.
Файлы для разных портов (например tstsrv-9009.socket и tstsrv-9900.socket) должны быть жесткими (не символическими!) ссылками друг на друга, тогда не будет дублирования кода.
Не так красиво, как было бы на чистых шаблонах с одой парой файлов на всё про всё, но хоть что-то.

>>204576
Такой тред и ни одного поста про арч. Я удивлён.

>>207110
А что арч? Что до меня, то если уж я надумаю куда уходить с дебиана — то это будет пикрелейтед. Но вряд ли это случится в ближайшее время.

>>207110
Слишком не для новичков. Да арчвики на все вопросы махом отвечает.

>>207111
Генту уже давно мертва. Сидела на ней лет пять в своё время, потом на funtoo ещё пару, но не признавать очевидного глупо. Arch поддерживается лучше, имеет более удобный пакетный менеджер и позволяет писать PKGBUILD'ы так же, как под гентой пишутся ebuild'ы. Пересобрать систему в ABS тоже можно, если зачем-то захотелось, но обычно это ограничивается отдельными пакетами всё же. Зато никаких депенденси хеллов с километровыми логами емержа. И большие поддерживаемые бинарные репы есть рядом с юзерскими сорцовыми, к отормы бтв тоже пакетный менеджер есть.

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

Генту не мертва, она просто так пахнет.
Сириусли, норм дистр. Ну, часть ебилдов ломается периодически и чтоб продавить свой фикс в portage tree, порой надо пободаться с бюрократией (ну, или становиться мэйнтейнером как вариант), и еще как я понял у нее в какой-то момент была охуенная популярность, а потом хайп прошел, а куча ебилдов-сирот осталась, но этого мало, чтобы называть дистр мертвым. Он работает. А еще там есть crossdev и catalyst (или metro для funtoo).

Смотрю на вас, линуксоидов и чувствую себя как в зоопарке.

>>207173
Линус, залогинься.

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

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

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

Если ссылаться на catalyst/metro как на средство сделать stage3 системы на каком-то пути, то в арче есть тот же pacstrap, которым собственно и производится установка исходного stage3. Бутабельных образов правда не сделает, это уже юзеру придётся решать со stage3 делать. Но в плане организации чрутов/nspawn-контейнеров -- самое то.

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

Но долгие сборки — это, конечно, проблема.

>>207179
Ебилды, хоть и являются по сути теми же слегка подточенными шелскриптами, круче пкгбилдов. Портаж обладает use-флагами, блаблабла. Хотя сам портаж тот еще ужас. Он такой медленный, в смысле его просчет зависимостей занимает очень долго.

>Crossdev это конечно здорово, но не сказать что прямо так уж и сильно.

crossdev он и есть простая оболочка над emerge. Можно устроить кросс-сборку дистра парой команд. Сильно или нет - это облегчает сборку, установку и управление директориями для этой фигни.

>Если ссылаться на catalyst/metro как на средство сделать stage3 системы на каком-то пути

Эта штука не просто пакует их, она их собирает же. Продакш, еба, автоматическая ежедневная сборка stage3 (или там stage4), если нужно.

Я сам сидел когда-то на раче, но когда они пару раз сломали аби, а затем затолкали systemd, я подумал, что оно мне не надо.

>>207180

>Но долгие сборки — это, конечно, проблема.

Собственно, да.

Можно наметить два выхода:
1) Собрать мощную числодробилку и компилировать на ней в 8 или более потоков (что makeflags, что emerge поддерживают несколько jobs, очевидно) (несколько потоков emerge помогает с долгими configure-time для autotools)
2) Собирать тяжелый софт как можно реже или не собирать его вовсе (с относительно недавнего времени mesa перешла на llvm, и теперь нужен полный llvm в системе, ололо, end my life; у меня довольно дохлая затычка для pciexpress слота вместо видеокарты, так что я все еще на 13 mesa где-то, мне все равно и я могу держать старые пакеты).

Но у генту все же проблемы, конечно. Много проблем. Portage и его многочисленный обвес - очень амбициозный проект, и у него недостает consistency, к сожалению.

>>207181
Systemd - правильный путь. Вместо того чтобы иметь десяток вотчдогов, за которыми всёравно надо следить руками (или ещё хуже - fire-and-forget sysinitv), гораздо удобней иметь одного, универсального и дистронезависимого. И иметь ивентом не только переходы по ранлевелам, а фактически весь скоуп удева и дбаса, плюс юзерские юниты и cgroup-контейнеры, если от юзера надо запустить штуку, которая требует рута. А возможность реагировать на фактические ивенты позволяет иметь в рантайме только те демоны, что непосредственно нужны, а не десяток не делающих ничего полезного, кроме обогрева комнаты.

Не говоря уже про адекватный депенденси-менежемент, апдейты конфигов и консистентные именования девайсов с маунт-поинтами.

>>207183

>fire-and-forget

Не вижу с этим проблем.

>фактически весь скоуп удева и дбаса

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

>ранлевелам

Надо полагать, наиболее значимые ранлевелы - с иксами или без.
Я запускаю иксы через startx, and you should too.

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

Это ты про socket activation? Вроде есть inetd или как там его.

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

>Не говоря уже про адекватный депенденси-менежемент, апдейты конфигов и консистентные именования девайсов с маунт-поинтами.

Не понял, про что ты.
ДМ чего, сервисов? Адекватный во всех случаях в вакууме он быть все равно не может. Программа стартует, но ей, скажем, нужно неопределенное время на какой-то бутстрап, чтобы быть надежным сервисом. Допустим, программа не умеет отправлять условные ивенты для условного systemd в принципе (честно говоря, не знаю, поддерживает ли systemd этакие "внутренние состояния программ" через ipc, просто думаю, что это возможно). Ничего не сделать. Допустим, программа достаточно интегрирована в экосистему systemd, ну и что? Она все равно может работать неправильно какое-то неопределенное время, 95% of code is shit. Это ненужная гонка контроля.
Как бы здесь я не могу понять, какую принципиальную проблему решает systemd, которая уже не была решена кем-то ранее на базе sysvinit. Systemd меня отпугивает этим переносом логики управления сервисами глубоко под капот. Страх, ужас и тоска виндового svchost, когда ты не можешь прибить какой-то рандомный сервис (который не работает или который мешается какой-то зависимостью), все еще свежа в памяти.

>апдейты конфигов

Здесь я не понял ничего в принципе. Конфигами занимается пакетный менеджер.

>консистентные именования девайсов с маунт-поинтами

Нинуж… Эхм, помоему это можно и без systemd делать.

>>207184

>Мои претензии к systemd в то время были просты - оно заявляло, что имеет какую-то функциональность, по факту ее не имея (она была либо недописана, либо сломана).

Подтверждаю, это до сих под так (попробуйте, например, с использованием mount-юнитов организовать монтирование smb-шар на уровне юзера. Разных для разных юзеров, ага).

А причина — пикрелейтед.
Если бы systemd не пыталась сесть сразу на все стулья и подменить собой всё и вся (зачастую, сломав при этом оригинальные механизмы) — цены бы ей не было. Действительно, система которая могла бы просто запускать цепочки задач/сервисов по зависимостям/эвентам и контролировать их выполнение, с примерно такой, как у systemd, системой управляющих юнитов — была бы очень востребована. Хочешь — используй для управления загрузкой системы (полностью или частично). Хочешь — для запуска и контроля комплексных серверов, вроде апача со всеми php/mysql потрохами. Хочешь — вообще организуй на ее базе систему сборки приложений вроде cmake или анта.
А так — получили убийцу unix-way.

>Страх, ужас и тоска виндового svchost, когда ты не можешь прибить какой-то рандомный сервис

И здесь это именно так. Я потратил больше суток, выковыривая из свежеустановленного debian 9 все malware сервисы, которые обновляли систему без моего ведома и согласия. Всего их там нашлось где-то штук пять разных, причем один — был частью этого systemd. И то у меня нет полной гарантии, что где-то не прячется еще.

>Конфигами занимается пакетный менеджер.

Видимо, имеется в виду, что конфиги/юниты для systemd в пакетах идут "искаропки". И соответственно, при "наивном" их редактировании перепишутся заново при следующем обновлении. И запустят заново всех зловредов.

>Нинуж…

Я бы сказал — вредно. Порой такие монструозные имена юнитов из-за этого получаются… Про systemd-ecsape вообще молчу.

>>207185

>например, с использованием mount-юнитов организовать монтирование smb-шар на уровне юзера

https://atkdinosaurus.wordpress.com/2015/08/19/how-to-mount-a-cifs-directory-with-systemd/

Что-то такое что ли?

>>207186
Это не на уровне юзера. Это на уровне всей системы, но в домашний каталог юзера, что в корне неправильно. На уровне юзера приходится извращаться и использовать service вместо mount.

>>207187

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

Почему это? Монтировать файловые системы в любом случае может только root. Исключение — это те, которые заданы на уровне всей системы с флагом user в fstab.
Чем это исключение отличается от того, что mount-юниты должны быть заданы на уровне системы?

>>207185

> Всего их там нашлось где-то штук пять разных, причем один — был частью этого systemd.

Можно список, кроме очевидного unattended-upgrades и plasma-discover из >>206947? Интересно знать, на что надо обратить внимание при установке нового Debian.

>>207190

>Можно список,

Попробую.

>unattended-upgrades и plasma-discover

Угу. Причем настойки unattended-upgrades, естественно, выкручены на максимум.

Номер три (самый вредный) — это /usr/lib/apt/apt.systemd.daily, который, внезапно, часть systemd, а вовсе не апта. Запускается через юниты, через крон и, возможно, откуда-нибудь еще.
Чтобы заставить его отключиться, надо создать /etc/apt/apt.conf.d/10periodic и добавить туда APT::Periodic::Enable "0"; (нет, это не часть unattended-upgrades).

И последнее, что я нашел — packagekit.service и packagekit-offline-update.service. Но здесь я уже не уверен, устанавливает этот PackageKit что-то или только смотрит наличие обновлений.

>>207191
/usr/lib/apt/apt.systemd.daily — это аналог старого кроновского скрипта APT, который по умолчанию ничего не делал? Теперь эти дефолтные настройки изменились?

>>207188

>Почему это?

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

>Монтировать файловые системы в любом случае может только root.

И для исправления этой досадной ситуации было сделано множество вещей, начиная с fuse и кончая каким-нибудь pam_mount или gvfs.

>Чем это исключение отличается от того, что mount-юниты должны быть заданы на уровне системы?

Если бы они должны были быть заданы на уровне системы — это было бы еще туда-сюда (хотя тоже не очень). В том-то и дело, что они на уровне юзера есть. Но не работают.
А, например, механизм активации по заходу в директорию, поддерживается, afiak, только для связки mount/automount. Как сделать что-то аналогичное для service — я не нашел. И в этом — весь systemd. Аналогичая фигня у него буквально во всём.

>>207195
Теперь — делает. А чтобы перестал делать — нужно плясать с бубном как сказано выше. И да, внутрь того „старого кроновского скрипта“ оно тоже себя прописывает.

Мне тут дали почитать самоучитель по линуксу Костромина, насколько эта книга актуальна и есть ли более современные альтернативы для ньюфага?

>>207210
Не нужно. Там все сплошь устаревшее.
Научись в гугл. Это лучший самоучитель.

>>207211
В гугл я всегда успею.

>>207197

>начиная с fuse и кончая каким-нибудь pam_mount или gvfs.

Так что тебе мешает их использовать? Зачем тебе тогда именно mount-юниты?

>Если бы они должны были быть заданы на уровне системы — это было бы еще туда-сюда. В том-то и дело, что они на уровне юзера есть. Но не работают.

Прямо в самом начале мана по systemd.mount написано:

>systemd passes two parameters to mount(8); the values of What= and Where=. When invoked in this way, mount(8) does not read any options from /etc/fstab, and must be run as UID 0.

Фраза "must be run as UID 0" прямо подразумевает, что mount-юнит может быть задан только на уровне системы.
То, что ты можешь создать mount-юнит у пользователя, но он выкинет ошибку монтирования как бы ни на что ровным счетом не влияет. Это явно та конфигурация, которая не поддерживается и соответственно и не будет работать.

>>207210

>самоучитель

https://wiki.archlinux.org

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

>>207219

>не интересен линукс
>базовые знания о нем плюс работа в баше

Тогда зачем тебе виртуалка вообще? Запусти WSL, которое Windows Subsystem for Linux из десятки, и получишь точно такой же экспириенс по своей сути.

И в качестве самоучителя хватит какого-нибудь https://linuxconfig.org/bash-scripting-tutorial-for-beginners или подобного туториала.

>>207220

> из десятки

Мне еще и десятку ставить?

>>207221
Ты же все равно винду используешь. Ты от десятки ведь никак не убежишь как бы.

Да, винду часто приходится использовать, но не обязательно же на реальном железе.

В libvirt/qemu, с kvm, да vfio PCI-passthrough для видеокарты -- самое то. Главное целиком IOMMU-группу с девайсом аллоцировать, что на большинстве матерей уже совсем не проблема, они зачастую поканальные даже.

>>207213

>Зачем тебе тогда именно mount-юниты?

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

>Это явно та конфигурация, которая не поддерживается и соответственно и не будет работать.

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

• socket — см >>207103 и выше (задача была, вроде бы, решена, но КАК…).
• mount — только ванильный, никаких продвинутых бэкендов вроде fuse.
• path — не поддерживает и половины возможностей inotify.
• automount — а почему, собственно, это вообще отдельный тип юнита, работа которого искусственно ограничена связью с mount, а не часть path, работающая везде?

Ну и так далее.

В общем, классика: вместо „делать что-то одно и делать это хорошо“ имеем „делать всё сразу и делать это плохо“. А и еще, пожалуй, если параноить, то можно заподозрить целью отучить юзеров хотеть странного…

>>207228
Юзеры всегда будут хотеть странного. Единственный способ этому помочь - дать им возможность реализации своих странных идей. Сорцы у них есть, пили - не хочу. Потом могут ещё в ревью патчей накидать и получить рекомендации по чистке своего кода и выбору оптимальных решений. А через пару итераций и в апстрим можно.

>>207229
Вот было бы у меня в сутках не 24 часа, а хотя бы 144 — то может быть я бы его и фрокнул. И запилил бы что-то в том ключе, как писал в >>207185 (идеи, что и как там можно сделать — есть, и много). А так — увы.

>>207228
Так это ведь старое доброе противоречие того, что красивые механизмы не работают в странных ситуациях.
У systemd декларативная философия настраиваемой системы, да она в общем-то красива, но она делает логику самой системы все более сложной, чем больше специальных вещей в нее внедряется для странных ситуаций. Разработчики вынуждены где-то чертить линию на тему того, какие ситуации они готовы внедрять и поддерживать в "ядре", а какие нет.
Философия программируемой системы, как например sysvinit или OpenRC, в том, что все в программируемых скриптах и соответственно сложные ситуации легко реализовать, а между скриптами и ядром только ограниченное API, но и стандартные ситуации тогда становятся для реализации одинаково сложными с нестандартными.

В данном случае mount-юнит банально вызывает mount с соответствующими параметрами. mount ограничен работой только с UID==0, поэтому mount-юниты от пользователя не работают. Все логично.

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

>>207231

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

И лекарство от этого известно.
Модульность и расширяемость. Система, запускающая процессы в окружении cgroups — отдельно, модульная система конфигурации на основе юнитов — отдельно. Большое количество разных плагинов, реализующих запуск разных типов юнитов на основе разных событий, триггеров и условий — тем более отдельно. PluginAPI — прост и очевиден, написать свой плагин и расширить функционал юнитов (или вообще создать свой их тип) может каждый.
Система юнитов не требует наличия именно этого процесса с pid 1, и может, в принципе, работать из-под чего угодно, просто связанная с cgroups часть функционала при этом будет недоступна (и, опять же, должна быть возможность прикрутить туда бэкендом другую реализацию этого функционала).
Сам коревой процесс вообще ничего про систему юнитов не знает, он предоставляет возможность управления другими процессами через cgroup и связанный с этим функционал, которым может воспользоваться любой.
И так далее…

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

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

Да и определенный уровень унификации, который systemd привнес, — это ведь тоже не последняя вещь.

>>207235
И того, мы получили… Собор vs. базар.
Ну, или, если более развернуто — ту же разницу, которую мы наблюдаем между миром свободного и коммерческого софта.

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

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

А монолит… ну, это путь уже совсем другой стороны…
Так что systemd — убийца unix-way еще и ЭТОМ плане.

>>207237
В таком случае и ядро linux — это собор, убивающий unix-way (?) в этом плане, ведь оно хоть и имеет модульное API, но тянет разработку всего, что возможно внутрь единого относительно монолитного продукта, пусть и конфигурируемого при сборке.

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

>>207239
Ядро linux — результат того, что Столман и K° не осилили hurd, а Линус очень вовремя появился со своим проектом. Ну а дальше — дарёному коню в зубы не смотрят: при всех его недостатках, тогда это было спасением для проекта GNU, а альтернативы просто не было.
Ну и потом, всё же, худо-бедно, но свои модули туда добавлять можно.
Ну а так — да, если hurd, всё же, доведут до ума, это, скорее всего, будет лучше, чем linux. В частности, описанной проблемы с монтированием там вообще нет.

>даже ценой потери некоторой части гибкости.

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

Ну и на этом, наверное, спор можно закончить, потому что дальше… „каждый выбирает по себе“.

>>207239
Но systemd не монолитен. В нём десятка два бинарей, каждый из которых делает что-то одно. В одном репозитории они только для удобства управления этим всем; с тем же успехом монолитом можно называть любой BSD-проект с core/bin-утилитами.

И пора бы уже понять, что unix-путь уже мягко говоря не актуален, он появился когда компьютеры были простыми, задачи были простыми и сетью пользовались по большим праздникам. Тогда может и было достаточно на старте системы запустить init'ом ряд демонов, примонтировать ряд систем и ожидать что inetd своими форками не сожрёт тысячи ресурсов, да и забыть про всё дело. А сейчас у нас и железа огромная куча и плагабельно оно в рантайме и в сети чёрт-знает что происходит и реагировать на это всё надо быстро и часто. Чем собственно systemd и является -- системой реакции на ивенты (сервисов, сокетов, девайсов и даже дбаса - полноценной шины сообщений), а не инит-системой, как некоторые по инерции старых путей думают.

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

>>207244
Разве не Red Hat несёт его идеи в сообщество?

>>207244

>свою систему реакции на ивенты

Она как бы была все это время, и мне не вполне ясно, чего достигает systemd в этом плане.
А на тему "актуальности" юникс-вей - вообще говоря, юникс-вея нет в принципе теперь. Современный юникс-вей был перерассмотрен в Plan 9, например, а легаси юникс наплодил усложнений к своей экосистеме за годы существования. Plan9/Inferno же занимают свою узкую нишу теперь.
Суть вопроса не в юникс вей, а в том, насколько хорошо systemd выполняет то, для чего предназначен. Критерии к "насколько хорошо" можно представлять разные.
Например, systemd не кроссплатформенный, он будет работать только с Linux. Например, systemd багованный, и, пусть вопрос о severity встреченных багов может быть открыт, команда порой реагировала на это плохо ("это не баг лол" на CVE). Например, systemd разрабатывается довольно закрытой командой и проталкивается, не принимая во внимание остальных (вообще, как только systemd вышел, появилось сразу несколько форков, демонстрирующих, как бы можно было это совершить, но systemd - это политика, в том числе политика выкручивания рук). Например, systemd СЛОЖНЫЙ - это, как расширение одного из предыдущих пунктов, означает, что у него наверняка есть скрытые баги (много), и активная разработка и личностные качества некоторых разработчиков этому не помогают.
Но все это достаточно иррелевантные замечания. Пусть ответы на этот пост будут построены так: "systemd решает такую-то проблему, которая актуальна для sysvinit и либо ее решение либо невозможно в рамках sysvinit, либо гораздо менее элегантно, а systemd делает это возможным/элегантным, потому что <insert systemd design decision here>, и это оправдывает потерю контроля над частью системы, потому что <вставь хоть какую-то причину, более уважительную чем УМВР сюда>".

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

>>207197

>начиная с fuse и кончая или gvfs.

Во-первых, можно ли как-то объяснить fuse, что для файлов и директорий хорошо бы использовать разные значения umask? (У cifs так, например, два разных параметра за это отвечает) А во-вторых, можно ли заставить gvfs передавать этому fuse разные параметры монтирования... ну, хотя бы, для разных схем (то, что хорошо для smb, уже не очень хорошо для sftp, например). А в идеале — так вообще свои для каждой точки монтирования.

>>207250
Мда. Вроде бы можно как-то извратиться, напрямую запуская бэкенды через d-bus, либо эмулируя оный командной строкой. Кажется, структура GMountSpecItem из файла gvfs/common/gmountspec.h выглядит похожей на параметр, который передаётся куда-то дальше. Возможно, в недра fuse.
В общем, там черт ногу сломит.

И чем этим гномы обкурились, что реализуют ООП в стиле C++, с блэкджеком и виртуальными функциями, на чистом C?

А вот проясните мне кто-нибудь насчет /var vs. /srv.

Раньше всякие сервера и тому подобные вещи традиционно ложились куда-нибудь в /var/www или что-то подобное. Сам /var при этом располагался на отдельном разделе. Теперь говорят, что правильно их ложить в /srv, который на отдельный раздел выносить не следует (если я правильно понял спеку).

Так где мне теперь это всё держать, если хочется, чтобы оно было и по феншую, и на отдельном разделе (и хорошо бы — на том же самом, где и остальное содержимое var)?

>>207303
Феншуя в этом деле не существует, только мода. Клади куда модно. А лучше куда сам линукс ложит. И ни в коем случае не трогай, если такие вопросы задаёшь. Ему виднее.

>>207303
/srv как раз на отдельный раздел выносить можно. Он имеет полностью свободную структуру на усмотрение администратора, чем делает возможным выделение всех машинно-независимых серверных данных туда.
Нельзя сейчас выносить /usr из корня, потому что он начинает использоваться очень рано во время загрузки из-за переноса /bin, /lib, /sbin в него и так далее.
/var вроде как выносить можно, но он сейчас настолько переплетен со всякими ранними системными функциями, что вряд ли это имеет смысл делать.

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

Ычанька, что поставить на домашний сервер-качалку? Традиционно накатывал Дебиан, но у него постоянно что-то отваливается, то Самба, то rdp. Настраивать и прикручивать, конечно, интересно, но я это интересное постоянно на потом откладываю.
Памяти гигабайт, проц — некроатом.

>>207343
поставь прошивку от олега

>>207343
Это что ты умудрился сделать, что у тебя на Дебиане что-то отваливается? Поставил sid что ли? Поставь stable.

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

>>207345
Так стабильный же.
Оно не столько отваливается, сколько изначально не прикручено, это я неправильно выразился. Нужно разбираться и лезть в конфиги, а там порой натыкаешься на неожиданное, когда в файле просят поменять пару строчек, а там мало того таких строчек нет, там вообще этого файла нет, и поди разберись, что теперь делать.
Алсо, на Дебиане регулярно крашится, к примеру, Codeblocks, взятый из своих же дебиановских репозиториев. Крашится, правда, из-за какой-то несущественной фичи автодописывания кода, которую я довольно быстро выудил, но всё равно я ищу ему вечную замену. Наверное перейду на Бубунту/Мяту и экосистему вокруг попытаюсь перевести.

И возвращаясь к вопросу systemd.

Вот, допустим, имеется у меня ~/.config/openbox/autostart, в котором запускается куча всякой фигни, да еще щедро разбавленной всякими sleep 2, из-за чего это всё тупит и тормозит. По мне — так очень напоминает аналогичные проблемы при загрузке системы, из-за которых systemd и создавалось, не так ли?

Соответственно, вопрос — можно ли как-то его приспособить к запуску этого дела?
Первая мысль — написать в openbox/autostart что-то вроде:

systemctl --user start openbox.target

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

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

>>207376
попроси поттеринга с командой, они добавят поддержку всех твоих зависимостей в systemd-openboxd
колобок.жпг

Не обновлял я арч несколько месяцев, теперь pacman -Syu валится с ошибками. В топку.

>>207197

>pam_mount или gvfs

Кстати, gvfs — полный отстой. Не позволяет нормально прописать права и грузит по dbus кучу левых неотключаемых "драйверов", которые делают разные вредные вещи. Впрочем, выше по треду про это уже написано: >>207251>>207250.

А вот pam_mount рулит. Совершенно замечательный пакет, с тонкой настойкой всего, что только можно. Собственно, единственное замечание — очень слабая поддержка xml entities. inb4 это защита от XXE А вот нихрена, если внешнюю сущность по всем правилам прописать в системе через xml catalog — он ее тоже не видит. Просто тупо нет нормальной поддержки. Видимо решили, что раз в xml только конфиг, а сам пакет про другое, то можно не заморачиваться.

А вообще pam сделан как раз примерно как в >>207233 описано. Свободная система с кучей плагинов. И никакого plugin hell, которым нас пугает >>207235, не заметно. Все плагины очень даже к месту.
Вот так и надо писать. А не… (ладно, молчу)

>>207377
С них станется…
На самом деле нет. Они просто выпилят поддержку всех боксов и сделают KDE (или Gnome) обязательным для всех и из коробки.

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

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

>>207524
То есть, ты хочешь сверять списки файлов и даты изменения всех файлов?

>>207525>>207524
Точнее, что является критерием изменения содержимого папки? Список файлов и даты изменения?

>>207524>>207525>>207526
Если ты хотел обойтись без хранения данных - не выйдет. Должна быть где-то база данных с хэшами списка файлов с датами.

>>207526
Любой из имеющихся в ней файлов был изменён/удалён, либо появился новый.

>>207527

>база данных с хэшами

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

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

>>207528
Изменения атрибутов и прав доступа тебя не интересуют? Можно сравнивать вывод ls и find | sha256sum с нужными ключами, но вообще для целей мониторинга файловой системы есть специализированные утилиты, например tripwire и aide.

>>207111

>А что арч?

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

>>207639
Один из немногих дистрибутивов со свежими пакетами в репозитории, а не позапрошлогодними rock stable.

>>207639
Это зависит от потребностей ведь.
Ставить арч на критически важные системы ни один в здравом уме рекомендовать не должен.
Совсем новичкам его тоже рекомендовать не стоит в большинстве случаев.

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

Для всех остальных случаев же есть другие дистрибутивы.

Еще один нуб в линухе. Подскажите, что делать. Mint не может обновить initramfs-tools, потому что не может сгенерировать initrd.img. Размер /boot всего 150, кажется, мегабайт, а initrd.img почему-то очень жирный, 60 мб, и для второго рядом места нет. Как разрулить такую ситуацию?

>>208629
Ну, вариантов несколько в зависимости от текущей конфигурации, конечных потребностей и так далее.
Первый банальный вариант — это так или иначе увеличить /boot, если не подходит, то второй — это перенести /boot в корневой раздел, если невозможно, то третий вариант — это уменьшить размер initrd через изменение initramfs.conf с последующим update-initramfs и указание, например, что нужны только необходимые модули ядра, а не все, но это конечно грозит тем, что на другой конфигурации система может не загрузиться и потребуется ручное вмешательство.

Указание MODULES=dep в /etc/initramfs-tools/initramfs.conf с update-initramfs -u -k all будет, возможно, самым банальным решением.
Еще можно попробовать поменять COMPRESS там на xz или lzma, если ядро поддерживает, что нужно смотреть по конфигурации ядра и ключам CONFIG_RD_XZ или CONFIG_RD_LZMA там.

>>208631

> Указание MODULES=dep в /etc/initramfs-tools/initramfs.conf с update-initramfs -u -k all будет, возможно, самым банальным решением.

Это вот эту строчку поменять?

>>208631
В общем попробовал update-initramfs, initrd уменьшился на 12 мб, и все влезло, спасибо. Но насчет переноса бута я подумаю, потому что туда новое ядро вместе с новым initrd не влезет.

>>208629
Еще один вариант простой - просто почистить старые ядра. Оставляешь текущее и место для нового.

>>208831
У меня и было только одно ядро и initrd, для нового ядра место есть, а вот для нового initrd - нет. Руки все никак не дойдут перенести /boot в корень. Хотя у меня в дуалбуте винда, если я бут перенесу, у меня потом вся эта фигня работать будет?

>>208854
Да, будет в большинстве случаев после изменения конфигурации загрузчика.
Отдельный бут необходим фактически лишь в нескольких случаях — корень на сетевых либо странных/экспериментальных файловых системах, которые не поддерживаются загрузчиком; корень на контроллере, который не поддерживается без загрузки модулей; шифрованный корень; корень на всяких многоуровневых слоях из mdadm, lvm, bcache, vdo и прочих таких вещах в конфигурациях, которые загрузчик не поймет.

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

В общем на самых простых конфигурациях бут в корне будет работать вполне нормально.

>>210002

>Не люблю я среды KDE которые жрут 500мб оперативки.

Как тебе в 2010-ом? Сейчас гномокеды жрут не меньше гигабайта. А крысомать как раз 500Мб и отъедает.

Посоветуйте современный дистрибутив для слабой машины с 500 мб оперативки.

>>210046
Если на этой машине не планируется пользоваться интернетами (браузинг сайтов кроме Ычана или использование разных популярных мессенджеров, которые теперь все как один, блджад, нарисованы на электроне), то любой с каким-нибудь там XFCE или LXQt/LXDE.
Если всё-таки планируется использование не только в качестве печатной машинки, то ничто не поможет. 2019 год на дворе, докинь уже памяти!

>>210002
Ставил бы сразу с МАТЕ. Разница небольшая, а дистру она роднее.
>>210046

> современный
> 500 мб оперативки

Выбери одно.
>>210047

> любой

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

>>210094

>тот же Минт или Убунта даже с Xfce в 500 упрётся

Уже успело разжиреть?? Не далее чем полгода назад доводилось воспользоваться машиной с 512 мегабайтами, актуальным на тот момент дебианом, XFCE, Libreoffice, CUPS и каким-то принтером с общим доступом. Вполне себе работало стабильно чуть-чуть тормозило, но точно без гиперактивного использования свопа.

>>210094
Дешевле и проще новый компьютер докупить. Хотя бы б\у 20 летней давности. Всё больше мощности будет.
>>210097
Весь софт жиреет прямо на глазах. Спасибо растущим мощностям железа.

>>210098
20 лет назад 128МБ-то мало где было.

>>210100
Ты путаешь с видеопамятью. Сижу с 20 летнего. Имею 2гб оперативки и 32мб видео. Вот у 30 летнего уже да, дно по современным меркам.

>>210106
https://www.ixbt.com/cpu/p3-coolers.html

Вот например обзор 99 года с довольно продвинутой конфигурацией.
Windows 98 отлично работала на 48-64 МБ, многие игры больше и не требовали.

>>210106
Попридержи коней, бро, ты всё ещё в 2019 году живёшь.
...
...или тебя случайно занесло на несколько лет назад. Не баловался бы со временем - не писал бы глупости на Ычане!
Кстати, Ычан в твоём будущем в самом деле выглядит так же как сейчас? Слава Юкари, больше не будет нововведений.

Интересно что бы сказали пользователи первого пентиума с 16 мб оперативы, если бы им заявили что лет через 50 будет не хватать 16 гигабайт для офиса который выглядит намного примитивнее ихнего?
>>210108
Ну да, двухтысячные переломными годами были. Объёмы оперативной памяти стремительно наращивлись. Думаю неправильно приводить в пример то что было до 2000 виндоус. Там и килобайты были.

>>210111
Не обязательно копать так глубоко.
Скажи мне в 2006ом что браузер тормозит на системе, на которой сталкер летает так я тоже офигею.

>>210122
Свалкер в 2007 вышел так-то. Ну и у меня сейчас корь и3, 8 гигов оперативы, 650Ти, короче среднее железо 2013 года, с браузером проблем никаких, а сталкер все равно тормозит при входе на Росток со свалки, где долгари стоят. При том, что стоит на ссд.

>>210097

> дебианом
> Минт или Убунта

Ну и Xfce за последние полгода на GTK3 окончательно переползти успели.

>>207111
Дбиан тоже умеет в конмиляние с флагами и оптимизациями через apt-src

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

>>216110
Но зачем он нужен если уже есть Убунта? Неочевидно.

>>210111Они бы пожали плечами и сказали "закон Мура, совсем простые вещи компьютеры и без людей умеют, значит"

>>210129

>а сталкер все равно тормозит при входе на Росток со свалки, где долгари стоят

Причина тормозов та же, что и у The Sims 3. Он не был собран под 64 бита.

>>216113
Зачем нужна убунта, если есть минт? Неочевидно.
Если серьёзно, то по личному опыту могу сказать, что с минтом проблем сильно меньше. А в убунту даже после свежей установки могут сыпаться ошибки.

>>216322

>Зачем нужна убунта

Можно было остановиться здесь. Сейчас из дистрибутива сделали блотварную помойку, слабо отличающуюся от 10 по экспириенсу использования. Хотя, можно всем говорить что у тебя линукс - это несомненно плюс.

Хочу поменять себе дистрибутив, возник такой вопрос. Можно ли в лайв режиме со старой папки home перенести часть файлов в liveos/home? После установки нового дистрибутива, файлы же не должны пропасть? не хочу делать новый раздел на диске для папки /home, там всё-равно пару книг лежит

>>216337

> Можно ли в лайв режиме со старой папки home перенести часть файлов в liveos/home?

Можно. Но места на liveUSB будет очень мало. Все, что есть на live os сохраняется, но лишь до перезапуска. Честное слово, я бы рекомендовал перенести все файлы на какую-нибудь флешку, чтобы 100% их не потерять. >>216337

> Можно ли в лайв режиме со старой папки home перенести часть файлов в liveos/home?

Можно. Но места на liveUSB будет очень мало. Все, что есть на live os сохраняется, но лишь до перезапуска. Честное слово, я бы рекомендовал перенести все файлы на какую-нибудь флешку, чтобы 100% их не потерять.

>>216358
Спасибо, у меня всё так и вышло. Просто загрузил свою мини-библиотеку на флешку и потом перенес обратно на новый дистро.

>>216113
Минт сделали сильно позже, поэтому вопрос уместен. И сделали его надо сказать на 90% ради красивого интерфейса.

>>216325
Можно подумать минт не "блоатварная помойка".

>>216325

>Сейчас из дистрибутива сделали блотварную помойку, слабо отличающуюся от 10 по экспириенсу использования.

Unix-way и ориентированность на неподготовленного пользователя — понятия взаимоисключающие.
https://habr.com/ru/companies/ruvds/articles/556124

>>216113
>>216360
Сделали его потому что Убунта когда-то там не ставила какие-то патентно-копирайченные кодеки по умолчанию. Это уже потом случился Гном 3, и Юнити. А сейчас это ещё и убежище от снапов.

>>216361
Очевидно да. Индукция же!

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

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

К вопросу о альтернативесустемг.
Dinit.

>>216460

>v0.17.0pre (alpha release #9)

Да вы, батенька, издеваетесь.

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

>>216479
Отнюдь нет
Стабильная версия 0.16.
У mpd версия, если что, 0.23, так что ни о чем не говорит.
По поводу "зачем и почему" вот: https://github.com/davmac314/dinit/blob/master/doc/COMPARISON
Если же хочется чего-то легкого, но при этом стабильного (местами даже в демьяновском смысле), то есть runit. В нем просто нечему ломаться.
В том же войде он себя прекрасно чувствует. Кстати, в void десистемгзировано все.

>>216427

> Убунта когда-то там не ставила какие-то патентно-копирайченные кодеки по умолчанию

Не могу в это поверить. Эти кодеки ставятся и ставились очень просто. Только ради этого замутили полноценный дистрибутив? Удивительно.

>>216494
Вы недооцениваете принципиальных мозолеедов.

Так, кстати, еще и Гном появился.

Хочу поставить линупс на маломощный ПК, но пугает перспектива поиска драйверов. Есть ли у этой ОС такое же решение, как на вин10, чтобы сама определяла железо и ставила под них драйвера? Речь идет о миниПК.

>>216533
Так а что за железо?

>>216533
В линуксе основная масса драйверов железа сидит сразу в ядре. Если нужна поддержка именно нового (два-три года как вышедшего) железа -- бери дистрибутив со свежим ядром из коробки или ставь свежее ядро самостоятельно на любой понравившийся дистрибутив.
В никсах вообще всё не так, как в форторчах. Про linux-way говорят совсем не зря, знаешь ли.

>>216534
Я сам хз. Мини-ПК, который тормозит под вин10.

>>216535
Ок, нужно просто ставить и пердолиться. Хорошо, буду мучиться, всем спасибо.

>>216533 >>216535
Дополню. Если имеется такое железо на которое дров в коробке не идёт - можно ещё просмотреть репозиторий дистрибутива (т.е. в т.ч. он-лайн репозиторий) на предмет наличия в виде отдельных пакетов по запросу.
Если и там нет, то, в контексте озвученного первоначального вопроса лучше даже не будем об этом. Это уже про очень много красноглазия.
Но так всё верно - попробуй взять дистр на пару лет посвежей того железа на которое ставишь, поставить, если будет работать то что тебе от этого железа под Линуксом нужно - радуйся, на остальное забей.
>>216537
Ну так засунь так ту-же Аиду, или Эверест, и получи ими модель материнки и список оборудования.

>>216539

>Ну так засунь так ту-же Аиду, или Эверест, и получи ими модель материнки и список оборудования.

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

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

>>216535
Ты забыл про фирмварь.

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

Уже давно всё вокруг намекает, что пора перекатываться. Но куда? Mint вариант?
Семёрка мне нравится из-за своего внешнего вида, и потому что работает гораздо быстрее вин10 на моём древнем железе. (i5-2400, 8 Gb DDR3)

>>216560
Качай с десяток популярных комбинаций дистрибутив/DE и пробуй.

>>216561
Я спросил как раз чтобы этого избежать.

>>216562
Посмотри дефолтный гном на дефолтной убунте сначала.

>>216568
Ну и зачем ты так?

>>216569
Как "так"? Он вполне прав: посмотри на DE, которые тебе нравятся, попробуй разные, вот и получишь ответ на свой вопрос. Это же вопрос личного комфорта, на АИБ точный ответ не скажут.

>>216570
Гнум предлагать -- верный метод отвадить от линукса.

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

>>216571
Ваши предложения?

>>216560

>работает гораздо быстрее вин10 на моём древнем железе

Докинь SSD и поставь LTSC 2019 (минимально актуальная винда на данный момент).

>>216560

>мне нравится из-за своего внешнего вида

Любой дистр с кде4.

>>216575
Крыса, матэ -- примеры использования GTK здоровыми людьми, а не курильщиками. Матэ так вообще развитие второго гнома. Как крысу, так и матэ щупаю ежедневно, то есть знаю, о чём речь.
>>216572
И поэтому нужно предложить неопытному новичку фигню, после которой он будет плеваться и возненавидит никсы, ага.

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

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