OpenBSD 6.2

Болтун! Иди уже, пиши патч в openbsd для поддержки аппаратного рейда (или чего ты там хотел), вместо того, чтобы ныть на ЛОРе.

В отличии от него я себя к разработчикам OpenBSD не причислял.

Но болтаешь тут ты не меньше.

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

Ну а Боб пользуется OpenBSD и тоже что-то там понимает — но можно ли сказать, что он понимает больше Алисы, если ни та, ни другой LVM настраивать не умеют (и не планируют)?

Да, в этом случае (при прочих, кроме LVM, равных) безусловно можно сказать, что Боб больше понимает в OpenBSD, чем Алиса понимает в Linux.

Тебе бы логику прокачать.

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

Можно еще прятать порнуху от мамки, например. И да, как то спокойнее живется когда не видишь все те говна в хомяке.

Это так же не запрещает репортить и обсуждать баги этой системы. А нытьё и обида за любимую систему лишь у таких как ты и буратино.

Опустим обычную газету в серную кислоту, а журнал ТВ-Парк - в дистиллированную воду...

Можно еще прятать порнуху от мамки, например.

Можно. Но лучше завести для мамки другого пользователя. Ещё лучше, конечно, купить ей другой компьютер и отселиться от неё в другую квартиру.

Тю, это не юникс-вей.

Типа того.

Юникс-вей без мамкиного борща не тащит?

нет конечно

этож сам готовь, стирай, убирай... системД какой-то ))

Ты снова говоришь о привычках, но etc - etcetera (и так далее)

Как бы то ни было, это пролезло во все ОС, включая Windows, так что можно считать что слово etc означает «директория с конфигурационными файлами». В таком значении ничего плохого нет, и никакой нужды переделывать его я не вижу.

а cfg - configuration (в переводе не нуждается). cfg - определённо правильнее.

А почему ~/cfg, а не ~/configuration, ~/config, ~/conf или ~/.config ?

~/etc лучше тем, что её можно указывать в шаблонах типа {~,}/etc. Если называть свалку конфигов в домшней директории не etc, то и системное хранилище тоже надо назвать иначе, как и /usr/etc

Как бы то ни было, это пролезло во все ОС, включая Windows, так что можно считать что слово etc означает «директория с конфигурационными файлами». В таком значении ничего плохого нет, и никакой нужды переделывать его я не вижу.

А мы разве обсуждаем переделку UNIX? Без массы проблем с совместимостью её под Plan 9 не переделать. Что касается Windows, то там эта директория для трёх с половиной файлов, ни для чего другого не используется и всё равно находится в нестандартном (с точки зрения UNIX) месте.

А почему ~/cfg, а не ~/configuration, ~/config, ~/conf или ~/.config ?

Наверное в первых UNIX-ах не было автодополнения. Большинство других системных директорий UNIX тоже трёхбуквенные bin lib dev usr log var tmp sys. Затем те же разработчики продолжили использовать трёхбуквенные директории и в Plan 9.

~/etc лучше тем, что её можно указывать в шаблонах типа {~,}/etc. Если называть свалку конфигов в домшней директории не etc, то и системное хранилище тоже надо назвать иначе, как и /usr/etc

На сколько я понял в Plan 9 вообще нигде нет etc.

так что можно считать что слово etc означает «директория с конфигурационными файлами»

Л - логика! Опроси юзеров, не ушибленных юниксом, что может значит etc. Зуб даю, вариант «там лежат файлы настроек» получит не болен 0 голосов.

Есть ли у кого опыт работы сабжа на raspberry pi?

Запускал на BeagleBone пару релизов назад. Работало всё, кроме USB.

• https://www.openbsd.org/arm64.html (Raspberry Pi 3)
• https://www.openbsd.org/armv7.html (BeagleBone)

Как впечатления по производительности? Стоит вопрос о замене raspbian.

Как по мне — вполне себе. (Мну даже Go на нём компелял ☺) Мне главным образом нужен был GPIO и там он гораздо приятнее сделан, чем в linux'е.

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

На Pi вроде есть. Но у меня нет Pi проверить.

Из коробки завелось все кроме Wi-Fi

Да ну?!!! Что, и bluetooth завелся, и fingerprint-reader, и все-все-все???

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

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

Я помню времена, когда в Linux тоже мало что работало

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

опа, первое место в топ-10 месяца

кто ещё хочет поговорить о незначимости OpenBSD, и о том, как три дня гнлались, чтобы сказать, как безразличны :)

Ты к какой-то ерунде придрался, а на действительно интересный вопрос так и не ответил.

По ссылке нет вопроса.

Хорошо, вопрос. Чем так хороша документация OpenBSD, если два примера когда я в неё заглянул и в обоих сразу видны недочёты? Или это я не туда посмотрел и описание OpenBSD grep есть где-то лучше?

А ещё:

А в чём разница для пользователя? Ну кроме того что в GNU grep например grep pattern directory -r работает, а в OpenBSD вроде не работало (проверь?) или то же отсутствие до недавнего времени sed -i... Хотя если ed есть изкоробки, можно и без него. Вот в линуксах сейчас часто ed изкоробки нет.

Из документации OpenBSD grep не понятно, будет ли работать grep pattern directory -R

Правда из документации GNU grep это тоже не очень ясно, просто на практике работает.

Из документации OpenBSD grep не понятно, будет ли работать grep pattern directory -R

Правда из документации GNU grep это тоже не очень ясно, просто на практике работает.

Если я правильно помню, это фича glibc. Я не уверен даже, будет ли это работать в том же самом GNU grep, собранном с musl.

Из документации OpenBSD grep не понятно, будет ли работать grep pattern directory -R

Зачем тебе гадать, будет ли это работать, если ясно написано, что должно быть grep -R pattern directory? Вот откуда эта тяга найти где-нибудь недокументированную возможность, которая работает в силу стечения обстоятельств, и расшибить об неё голову?

-r

В GNU grep -r и -R — разные опции с разным значением.

В GNU grep -r и -R — разные опции с разным значением.

Я тоже читал man.

Так вот. Из OpenBSD man grep, одинаковые это опции или разные вообще не ясно, и ни к каким опциям не указано, что делается с симлинками. Как это понимать? Где хвалёная полнота документации?

если ясно написано, что должно быть grep -R pattern directory?

Где написано? Ты про строчку в самом начале?

grep [-abcEFGHhIiLlnoqRsUVvwxZ] [-A num] [-B num] [-C[num]] [-e pattern] [-f file] [--binary-files=value] [--context[=num]] [--line-buffered] [pattern] [file ...]

Из неё вообще следует, что опции можно указывать только в этом порядке. А например --context=12 -e pattern поставить нельзя, если так читать, как ты предлагаешь. Или что, правда нельзя?

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

-C[num] Print num lines of leading and trailing context surrounding each match. The default is 2 and is equivalent to -A 2 -B 2. Note: no whitespace may be given between the option and its argument.

А это что за глупость вообще? Почему в опциях -A и -B можно ставить пробел, а в опции -C нельзя?

Как это понимать?

Так понимать, что -r использовать не надо. В мане это написано.

что делается с симлинками

Нашел баг в документации? Оформи баг-репорт, не сри просто так на ЛОРе.

Так понимать, что -r использовать не надо. В мане это написано.

Но разве в мане не должно быть написано, почему не надо и что эта опция делает?

Оформи баг-репорт, не сри просто так на ЛОРе.

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

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

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

Ну если ты вывалишь из своей такую же кашу, что здесь, то пошлют.

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

А еще лучше будет, если ты откроешь сорец, посмотришь на реальное поведение по отношению к ссылкам и пришлёшь сразу патч к ману.

Но это ведь надо быть немного адекватным человеком, понимающим, что никто в интернете тебе ничего не должен, а не ЛОР-аналитиком.

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

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

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

В таком случае вежливо пошлют читать какой-нибудь другой man, FAQ или ещё что-нибудь навроде. А мне это надо?

Да пусть там хоть вообще манов не будет, мне-то что...

зачем говорить о том на что тебе наплевать?

некоторые любят хвалиться что у OpenBSD якобы замечательная документация

у нее замечательная документация. А ошибок нет у тех, кто ничего не делает.

у нее замечательная документация.

По сравнению с полным отсутствием документации — конечно.

Но лучше ли эта документация, чем в NetBSD, FreeBSD, DragonflyBSD или GNU/Linux? Она везде в принципе есть и везде не без ошибок. Где пруфы, что именно у OpenBSD она в среднем лучше?

Неинклюзивное эмпирическое исследование свидетельствует что у GNU grep man лучше, например.

У меня сложилось впечатление, что про лучшую документацию где-то один раз похвастались в 90-х в списке рассылки, когда она может и правда была лучше чем у прочих, а с тех пор этот миф разносят все подряд, не подвергая критическому анализу, хотя может быть с тех пор другие ОС (как минимум GNU) подтянулись и документация теперь в среднем лучше у них, а не OpenBSD?

Но лучше ли эта документация, чем в NetBSD, FreeBSD, DragonflyBSD или GNU/Linux? Она везде в принципе есть и везде не без ошибок.

Лучше, на порядки.

Где пруфы, что именно у OpenBSD она в среднем лучше?

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

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

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

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

Xenius ★★★★★ (20.10.2017 10:14:03)
Последнее исправление: Xenius 20.10.2017 10:18:54 (всего исправлений: 7)

7 исправлений напомнило мне анекдот в духе *у меня есть мнение, но я с ним категорически не согласен!* :)

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

Сходи, полечись от мании величия.

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

То что ты прочитал все маны от OpenBSD не значит, что ты лучше других в чём-то другом кроме OpenBSD.

И уж тем более не говорит о том, что те, кто не прочитали все маны от OpenBSD — поголовно идиоты, дятлы и тд.

Для того, чтобы это понять, надо обладать информационным багажом и фундаментальными знаниями.

Ну то есть никакой конкретики ты предъявить не способен, пусть даже в виде частных случаев?

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

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

Ты дятел даже среди дятлов. Просто феерично.

ты еще не вышел из возраста измерения пиписек?

ты сначала определи критерии качества документации, а потом лезь в «неинклюзивные эмпирические исследования»

Да, буратино, это и есть уровень твоих оппонентов на лоре..

ты сначала определи критерии качества документации

Это должны делать те, кто утверждают, что у OpenBSD она лучше всех.

Мне тоже интересно, по каким критериям она лучше. Если лучше вообще.

Это не оппоненты, это спам. Я иногда отвечаю на спам :)

а ты купи слона...

ааа, ну т.е. ты просто попиздеть пришел

вот тебе инклюзивное эмпирическое исследование:

# ls -l
total 28
-rw-r--r--  1 root  wheel   87 Oct  4 07:13 .Xdefaults
-rw-r--r--  1 root  wheel  578 Oct  4 07:13 .cshrc
-rw-r--r--  1 root  wheel   94 Oct  4 07:13 .cvsrc
-rw-r--r--  1 root  wheel    5 Oct 19 16:11 .forward
-rw-r--r--  1 root  wheel  328 Oct  4 07:13 .login
-rw-r--r--  1 root  wheel  468 Oct  4 07:13 .profile
drwx------  2 root  wheel  512 Oct 19 16:10 .ssh
lrwxr-xr-x  1 root  wheel    4 Oct 20 12:25 ln_etc -> /etc
# grep -R rc .
./.cshrc:# $OpenBSD: dot.cshrc,v 1.13 2005/02/13 00:56:13 krw Exp $
./.cvsrc:# $OpenBSD: dot.cvsrc,v 1.1 2013/04/01 16:55:26 espie Exp $
#

PS:кстати, раз в мане ни слова про follow links значит не follow.

PS2: а вот тебе исследование на тему «почему это не указано в мане».

в мане что написано? - "-R Recursively search subdirectories listed."

# find . -type d
.
./.ssh
# find . -type l
./ln_etc
#