Страница пересобрана: 09:05 18.03.2019
[d | an-b-bro-fr-hr-l-m-med-mi-mu-ne-o-ph-r-s-sci-sp-tran-tv-x | bg-vg | au-tr | a-aa-c-fi-jp-rm-tan-to-vn | gf | azu-dn-hau-ls-ma-maid-me-mo-p-sos-t-w | misc-vnd | stat ]
[Burichan] [Futaba] [Gurochan] - [Архив - Каталог] [Главная]

[Назад]
Ответ
No.204577  

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

>> No.204578  

>>204576

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

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

>> No.204579  

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

>> No.204580  

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

>> No.204581  

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

>> No.204582  

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

>> No.204583  
Файл: 1537598899551.jpg -(47 KB, 766x431, sup.jpg)
47

>>204582
Perfect!

>> No.204584  

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

>> No.204585  

>>204576

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

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

>> No.204586  

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

>> No.204587  

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

>> No.204593  

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

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

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

>> No.204594  

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

>> No.204595  

>>204594

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

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

>> No.204598  

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

>> No.204599  

>>204598

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

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

>> No.204600  

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

>> No.204601  

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

>> No.204602  

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

>> No.204603  

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

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

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

>> No.204604  

>>204594

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

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

>> No.204622  

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

>> No.205824  

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

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

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

>> No.205825  

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

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

>> No.205827  

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

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

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

>> No.205830  

>>205827

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

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

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

>> No.205831  

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

>> No.205832  

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

>> No.205834  

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

>> No.205839  

>>205827

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

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

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

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

>> No.205846  

>>205832

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

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

>> No.205870  

>>205846

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

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

>> No.205871  

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

>> No.205898  
>POSIX-совместимости

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

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

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

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

>> No.205907  

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

>> No.207092  

>>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...

>> No.207096  

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

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

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

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

>> No.207097  

>>207092

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

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

>> No.207099  

>>207096

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

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

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

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

>> No.207103  

>>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) должны быть жесткими (не символическими!) ссылками друг на друга, тогда не будет дублирования кода.
Не так красиво, как было бы на чистых шаблонах с одой парой файлов на всё про всё, но хоть что-то.

>> No.207110  
Файл: 1550336586682.png -(80 KB, 500x355, this-is-what-you-really-like-right-senpa(...).png)
80

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

>> No.207111  
Файл: 1550338556610.png -(189 KB, 1440x900, 3c9.png)
189

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

>> No.207112  

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

>> No.207169  

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

>> No.207170  

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

>> No.207172  

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

>> No.207173  

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

>> No.207176  

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

>> No.207179  

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

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

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

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

>> No.207180  

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

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

>> No.207181  

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

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

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

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

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

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

>> No.207182  

>>207180

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

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

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

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

>> No.207183  

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

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

>> No.207184  

>>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 делать.

>> No.207185  
Файл: 1551276402419.jpg -(192 KB, 1000x1000, 0411.jpg)
192

>>207184

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

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

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

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

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

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

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

>Нинуж…

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

>> No.207186  

>>207185

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

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

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

>> No.207187  

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

>> No.207188  

>>207187

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

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

>> No.207190  

>>207185

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

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

>> No.207191  

>>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 что-то или только смотрит наличие обновлений.

>> No.207195  

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

>> No.207197  

>>207188

>Почему это?

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

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

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

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

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

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

>> No.207210  
Файл: 1551393737208.jpg -(29 KB, 278x400, 0059483.jpg.jpg)
29

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

>> No.207211  

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

>> No.207212  

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

>> No.207213  

>>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-юнит у пользователя, но он выкинет ошибку монтирования как бы ни на что ровным счетом не влияет. Это явно та конфигурация, которая не поддерживается и соответственно и не будет работать.

>> No.207217  
Файл: 1551429787512.jpg -(56 KB, 500x780, __alice_margatroid_touhou_drawn_by_arnes(...).jpg)
56

>>207210

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

https://wiki.archlinux.org

>> No.207219  

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

>> No.207220  

>>207219

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

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

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

>> No.207221  
Файл: 1551439809880.png -(151 KB, 341x314, 1471331795706.png)
151

>>207220

> из десятки

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

>> No.207224  

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

>> No.207227  

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

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

>> No.207228  

>>207213

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

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

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

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

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

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

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

>> No.207229  

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

>> No.207230  

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

>> No.207231  

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

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

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

>> No.207233  

>>207231

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

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

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

>> No.207235  

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

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

>> No.207237  

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

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

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

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

>> No.207239  

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

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

>> No.207241  

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

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

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

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

>> No.207243  

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

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

>> No.207244  

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

>> No.207245  

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

>> No.207247  

>>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>, и это оправдывает потерю контроля над частью системы, потому что <вставь хоть какую-то причину, более уважительную чем УМВР сюда>".

>> No.207250  

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

>>207197

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

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

>> No.207251  

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

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

>> No.207303  

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

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

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

>> No.207304  

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

>> No.207305  

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

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

>> No.207343  

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

>> No.207344  

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

>> No.207345  

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

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

>> No.207346  

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

>> No.207376  

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

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

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

systemctl --user start openbox.target

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

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

>> No.207377  

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



Удалить сообщение []
Пароль
[d | an-b-bro-fr-hr-l-m-med-mi-mu-ne-o-ph-r-s-sci-sp-tran-tv-x | bg-vg | au-tr | a-aa-c-fi-jp-rm-tan-to-vn | gf | azu-dn-hau-ls-ma-maid-me-mo-p-sos-t-w | misc-vnd | stat ]
[Burichan] [Futaba] [Gurochan] - [Архив - Каталог] [Главная]