Опыт перехода с Windows На Linux/Unix. Часть2 / forpes.ru

Главная
Опыт перехода с Windows На Linux/Unix. Часть2

Опыт перехода с Windows На Linux/Unix. Часть2 -37

22.04.2016 19:15

MetaAbstract 106 10000 Источник

Linux forever!

Debian 7 продолжал стоять у меня второй операционной системой. Из-за загрузки по работе времени разбираться в нем с одной стороны не было как и осуществить проект по LFS, а с другой меня не устраивало качество шрифтов. Иногда проводя по в день по 10..12 часов напротив дисплея портить зрение мне не хотелось. Все примененные руководства по улучшению шрифтов результата не давали.
Тем не менее на серверной части на очередном проекте я решил опереться на Linux в серверной части, используя для этой цели нанятого админа, оперируя только архитектурой. И я остался крайне доволен результатами, т.к. удалось интегрировать LDAP, авторизацию по ключам в Apache и поднять сервер приложений через FastCGI. Все это вращалось на виртуалке за 500 рублей в месяц пока было в стадии разработки.
Тем временем вышел Debian 8 и как то вечером я решил проапгрейдить Debian с 7 на 8. Но то ли я был усталый, то ли я не туда тыкнул мышкой — затер MBR на винте. Как бороться теоретически было ясно, но было принято волевое решение установить только Debian, т.к. стало ясно, что без этого прогресса не будет. Тем более, что шрифты в Gnome 3 оказались вполне приемлемые. Сказано сделано и не рабочий компик под Linux. Какое то время я в нем обживался и приспосабливался, пока не освоился окончательно. Тем временем разработка велосипеда на рабочей машине стала подходить к финальной стадии и стало ясно, что пора ставить SSD для повышения производительности. Под эту идею было решено и перевести среду разработки под linux, т.к. я уже более менее в нем освоился и был готов двигаться дальше.Дальше история будет ближе к теме.
Первая задача, которую пришлось решить это настройка файловой системы для SDD. В целом сложностей это не вызвало, хотя и правильную конфигурацию удалось создать не с первого раза.
Вторая задача, которая отняла пять дней жизни, стала настройка почтового сервера. Зная, что linux сильна в области сетей, я считал что задача тривиальна. Оказалось, как я потом прочитал, это одна из сложнейших задач администрирования. Может я плохо искал, но существуют две ситуации. Первая, что почтовая система интегрирована сильно в операционную систему и многие программы шлют уведомления на root@localhost. Вторая ситуация заключается в том, что есть отдельно pop3(imap) сервер(dovcote) и smtp сервер (postfix) и настройка их совместной работы с интеграцией авторизации, учитывая фейковое dns имя хоста для целей разработки является не тривиальной задачей. Но благодаря чтению постов на хабре и курению манулалов я это осилил.
Следующей проблемой опять стали шрифты. 1C предприятие требовало каких то отдельных шрифтов, а java требовало настроек в конфигурации. Кроме этого качество шрифтов при постоянной работе опять же не устраивало в целом. Пришлось ставить набор патчей Infinality. И тут был первый настоящий вызов для меня в системе. После очередного обновления системы с ядром, что то стало не совместимо с патчем от Infinality и графическая среда не загрузилась, ругаясь, что какие то символические ссылки то ли не туда ведут, то ли не на то указывают. Но удаление Infinality и ее переустановка решили проблему. Можно сказать, что я что то починил. Кстати не знаю прав я или нет, но мне кажется, что в отличии от Windows визуальное качество шрифтов зависит от угла наклона монитора.
Второй проблемой стало то, что корпорация зла как всегда игнорирует общепринятые стандарты и Ctrl-Break, необходимый в длительных операциях в 1С для прерывания, не работает в linux. И тут я написал свой первый скрипт, который по Ctrl-Break создает файл stop1c, а в 1C системную проверку прерывания заместил своей функцией. И все заработало. Кстати такого решения в сети я не нашел. И горжусь своим первым скриптом:
#!/bin/bash
touch /home/....../stop1c.txt
Все остальное в целом работает и я очень доволен тем, что система полностью под моим контролем и планирую уже подъем собственного сервера, т.к. бороться с хостингом занятие утомительное. И у меня даже появились дальнейшие коммерческие идеи по поводу Linux:)
Теперь про недостатки Linux. Первым недостатком системы я считаю отсутствие стандарта и стандартного интерфейса на конфигурационные файлы. Второй недостаток это все таки безумные количества колючей на командах. Я конечно уже освоился с базовым арсеналом, но опять же хотелось бы иметь стандартного мастера для конструирования параметров и ключей команды. И третьим недостатком я считаю синтаксис bash. Понимаю, все темы флеймовые, а последняя в собенности, но синтаксис крайне архаичиный. И что делать… Скоро придется курить мануалы.
Как итог хочу сказать следующее. Windows и Linux не сопоставимы между собой как по возможностям, так и по уровню контроля над ситуацией. Сравнение явно в пользу Linux и рекомендую всем сдвигаться в этом направлении.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Комментарии (106)

maisvendoo
22.04.2016 22:33
#8865825
+2
Понимаю, все темы флеймовые, а последняя в собенности, но синтаксис крайне архаичиный.

И в чем же выражается архаичность синтаксиса bash?
1. MetaAbstract
  22.04.2016 22:36
  #8865831
  +4
  Например конструкция if ...fi;
  1. maisvendoo
    22.04.2016 22:38
    #8865833
    +1
    Гхм, честно говоря, не понимаю, что тут архаичного. А как было бы не архаично?
    
    Принципиальный недостаток это, да, ммм…
    
    MetaAbstract
    22.04.2016 22:46
    #8865847
    +1
    if(){
    
    }
    более привычно.
    Принципиальные недостатки тоже есть, но это надо сеть загуглить. Насколько помню там что то с большим количеством предопределенных переменных и статусами возврата.
    Если в целом то меня скорее напрягает то, что надо не стандартный синтаксис изучать в дополнение к другим синтаксисам. Наверно возраст))))
    
    maisvendoo
    22.04.2016 22:51
    #8865851
    if(){} более привычно.
    
    Ну так есть же вот, но POSIX не совместимо.
    
    Вообще же командных оболочек много, можно выбрать любую на вкус и цвет
    
    MetaAbstract
    22.04.2016 22:57
    #8865857
    -3
    Именно. POSIX не совместимо. Тем более что половина дистрибутива это скрипты на bash. По любому час икс когда в них привидеться залезть приближается.
    Мне кажется странно, что в наше время, когда новые языки появляются чуть ли не раз в месяц, bash не замещают чем нибудь более современным по синтаксису. Теоретически же можно конвертировать все скрипты автоматически.
    
    maisvendoo
    22.04.2016 23:00
    #8865861
    +4
    bash не замещают чем нибудь более современным по синтаксису
    
    Честно говоря, не в обиду, звучит смешно. Чем
    if () {}
    современнее чем
    if .. fi
    unix, bash и язык C родились примерно в одно время, в начале 70-х
    
    И потом — взять вот и заменить. А обратная совместимость?
    
    Теоретически же можно конвертировать все скрипты автоматически.
    
    Теоретически можно. Но зачем?
    
    MetaAbstract
    22.04.2016 23:07
    #8865869
    Я пишу одновременно на трех языках программирования и в нескольких DSL.
    Еще один синтаксис специфичный в голове держать тяжеловато как то. Особенно если он такой специфический.
    У Вас сколько синтаксисов и DSL одновременно в работе?
    
    maisvendoo
    22.04.2016 23:12
    #8865873
    +4
    С/C++/C#, bash, Java, Pascal, Basic, D, asm x86, Maple, Matlab… в разное время на чем-то из перечисленного что-то писал
    
    MetaAbstract
    22.04.2016 23:18
    #8865877
    Это не одновременно я так понимаю. Когда одновременно пишешь на нескольких, то каждый отличающийся сильно мозг нагружает, а еще думать надо что делаешь. Я поэтому bash уже месяца три никак осилить не могу, надо отдельно время выделить, сконцентироваться и т.д. Не то что с Java например было. Месяц… два и уже Swing и J2EE читаешь
    
    maisvendoo
    22.04.2016 23:30
    #8865891
    Не одновременно, но проблем с переходом от одного к другому не возникало. Ах да, Lua ещё забыл…
    
    Собственно, вопрос восприятия и усвоения — вопрос субъективный и к технической стороне вопроса относится мало.
    
    MetaAbstract
    22.04.2016 23:38
    #8865897
    +3
    Перфокарт я конечно в деле не использовал, но имел дело и с VAX и с ЕС. С тех пор я много разных языков встречал и использовал. Но такого не понятного синтаксиса визуально как bash я ни разу не встречал. Может впечатление архаичности и ложно, тут я не до конца компетентен. Но избавиться от него не могу. А Вы прямо любой скрипт открываете в системе и сразу ясно какие команды что делают в принципе?
    
    maisvendoo
    22.04.2016 23:42
    #8865901
    +1
    А Вы прямо любой скрипт открываете в системе и сразу ясно какие команды что делают в принципе?
    
    Нет не любой. Так вообще никто не может. Просто одни принимают что-то созданное до них как данность и разбираются, другие предлагают наполеоновские планы по глобальным реформам без видимых объективных причин. Разница в подходе к вопросу
    
    MetaAbstract
    22.04.2016 23:45
    #8865903
    Я имею ввиду не в целом. Это конечно понять не возможно сразу, а что отдельные инструкции делают. Я вот в примере ниже процентов 10 инструкций понимаю о чем речь.
    
    maisvendoo
    22.04.2016 23:48
    #8865911
    Я вот в примере ниже процентов 10 инструкций понимаю о чем речь.
    
    Это дело наживное
    
    MetaAbstract
    22.04.2016 23:51
    #8865913
    обнадежили)))))
    не боги конечно горшки обжигают, но придется озадачиваться этим серьезно когда нибудь.
    
    MetaAbstract
    22.04.2016 23:42
    #8865899
    +1
    case "$prog" in *less) more=less ;; *) more=more ;; esac if test "`echo -n a`" = "-n a"; then # looks like a SysV system: n1=''; n2='\c' else n1='-n'; n2='' fi oldtty=`stty -g 2>/dev/null` if stty -cbreak 2>/dev/null; then cb='cbreak'; ncb='-cbreak' else # 'stty min 1' resets eof to ^a on both SunOS and SysV! cb='min 1 -icanon'; ncb='icanon eof ^d' fi
    
    Я например еле еле отдельные куски с ходу понимаю
    
    ZyXI
    23.04.2016 01:13
    #8865991
    +2
    Я спокойно одновременно пишу на C99, lua, Zsh, Python, VimL. В таких случаях считаю за благо, когда некоторые вещи либо совершенно непохожи на себя же в других языках, либо абсолютно одинаковы. «Слегка различные» функции/синтаксические конструкции/… — гораздо бо?льшее зло.
    
    К примеру, в zsh вы можете написать
    
    if (test -z $1) { echo "First argument is empty" }
    
    но это запустит test -z в подоболочке. Конкретно в if это почти всегда незаметно?, но в таком стиле можно и while циклы писать.
    
    К примеру,
    
    echo abc | while read i ; do echo $i done
    
    выведет abc, тогда как
    
    echo abc | while (read i) { echo $i }
    
    выведет пустую строку. И вы будете долго отлаживать код, потому что положились на сходство синтаксиса, хотя синтаксис здесь на самом деле while {restricted-list} { {list} }?, где под {restricted-list} понимается что?то вроде «любая команда в скобочках»: группировка {read i} (в этой форме второй цикл заработает), тесты [[ -z $var ]]/(( i%4 != 3 )) (но не [ … ], для одинарных нет специального синтаксиса), … запуск в подоболочке (true).
    
    ? Подумаешь, лишний fork. Во?первых zsh умеет делать exec без fork’а, если видит, что исполняемая команда последняя, так что лишний fork один, а не два. Во?вторых, в большинстве случаев проседание производительности незаметно.
    ? Обычный цикл: while {list} do {list} done, так что можно писать
    
    while echo abc | grep foo do echo Here done
    
    … или
    
    # Infinite cycle while false ; false ; false ; false ; false ; false ; true do echo There done
    
    MetaAbstract
    23.04.2016 01:31
    #8866005
    +2
    Самая жесть системных скриптов))))
    Как по мне, то я бы предпочел на одном языке везде писать. На суть алгоритмов это не влияет.
    
    Delphinum
    23.04.2016 01:50
    #8866021
    Настройте себе snippets, будете на одном диалекте везде писать.
    
    MetaAbstract
    23.04.2016 02:03
    #8866031
    Это кстати очень интересная идея с сильной абстракцией. Благодарю. Надо ее обдумать.
    
    Delphinum
    23.04.2016 02:04
    #8866035
    Ничего у вас не получится, но попробуйте, за одно полюбите различные синтаксисы )
    
    MetaAbstract
    23.04.2016 02:10
    #8866041
    Как раз нет. Мне в отдаленной перспективе предстоит язык разрабатывать наверно. Идея со снипетами как раз туда похоже может лечь красиво. Только не понятно как еще.
    
    Delphinum
    23.04.2016 02:12
    #8866045
    Ну я желаю вам удачи, конечно.
    
    MetaAbstract
    23.04.2016 02:17
    #8866049
    Благодарю, но и не говорите, задача не тривиальна.
    
    hudson
    22.04.2016 23:52
    #8865915
    Ну так пишите на чем-то одном, если текущая ситуация вас напрягает. Выбор за вами. Если выбор не за вами, то у вас 2 варианта — либо оставить таки выбор за вами, либо перестать жаловаться на то что «еще один синтаксис специфичный в голове держать тяжеловато как то».
    
    MetaAbstract
    22.04.2016 23:56
    #8865917
    Выбор не за мной, а за решаемой задачей и имеющихся условиях. А они требуют писать параллельно на нескольких языках и DSL.
    
    hudson
    23.04.2016 00:14
    #8865933
    +1
    Ну либо вы решаете задачу, либо задача решает вас =) Я просто не совсем понимаю, почему необходимость держать сколько-то «синтатаксисов» в __вашей__ голове как-то пересекается с особенностями прочих сред и языков? Ну да, такой синтаксис в bash. Да, исторически сложилось. Ну не пользуйтесь, если не нравится. Скрипты в shell можно писать на… да почти на чём угодно можно писать. Ну а если скрипт не нравится — напишите решение вашей задачи на С, на Java, на Go…
    
    MetaAbstract
    23.04.2016 00:23
    #8865939
    Тут выше поднимался вопрос. Дело в posix совместимости и системных скриптах. Если что то лечить, чинить, настраивать — то придется bash использовать. Так что уж придется в него углубляться.
    И работая под linux постоянно сталкиваешься со скриптами на bash. Интересно же заглянуть что внутри) А я сейчас как не загляну — ничего не понятно.
    
    Delphinum
    23.04.2016 01:49
    #8866019
    +2
    Я пишу одновременно на трех языках программирования и в нескольких DSL
    
    Невероятные способности (сарказм). Придет время, когда вы поймете, что это далеко не предел.
    
    MetaAbstract
    23.04.2016 02:47
    #8866075
    +1
    Скорее придет время, когда я забуду как комп включать (ирония)
    
    Delphinum
    23.04.2016 01:47
    #8866015
    более привычно
    
    Более привычно для кого, C-программистов? bash командный интерпретатор, он разбирает команды, а не конструкции языка.
    
    MetaAbstract
    23.04.2016 01:59
    #8866029
    И интерпретирует скрипты с конструкциями sh
    
    Delphinum
    23.04.2016 02:03
    #8866033
    +1
    У командной оболочки нет конструкций, у нее есть команды. Команда if определяет начало условного блока, команда fi ее конец. Языки основанные на командах просты в реализации, потому часто в качестве sh используются именно они.
    
    MetaAbstract
    23.04.2016 02:16
    #8866047
    Я понимаю о чем Вы говорите, но вот прям ссылка.
    Если есть скрипт, переменные, циклы и условия — значит есть и конструкции языка. Другой вопрос, что он интерпретируется выполнением команд в отдельных процессах не редко, т.е. что то типа соеденяющий процессы конструктив. Если я правильно понял учебник bash.
    
    Delphinum
    23.04.2016 02:20
    #8866051
    Ну буханку тоже можно назвать тролейбусом, разница только в том, что для интерпретации конструкций языка нужен один механизм разбора, а для интерпретации команд, совершенно другой. Потому как бы вам этого не хотелось, bash не может использовать {...} для обозначения блоков. Отсюда можно сделать простой вывод — пишите на C, вызывать его можно в Linux точно так же, как и bash скрипты.
    
    MetaAbstract
    23.04.2016 02:38
    #8866069
    Самое интересное, что я эту мысль обдумывал. Зачем с bash извращаться, когда можно на C написать.
    
    для интерпретации конструкций языка нужен один механизм разбора, а для интерпретации команд, совершенно другой
    — а в чем разница? Объясните если не сложно. Вопрос интересный.
    
    Delphinum
    23.04.2016 02:51
    #8866085
    В отсутствии необходимости учитывать контекс (с оговорками) при разборе синтаксиса и в использовании минимального набора состояний. Длинная тема, в двух словах не опишешь.
    
    MetaAbstract
    23.04.2016 02:56
    #8866091
    Я понял. Спасибо.
    
    ZyXI
    23.04.2016 02:42
    #8866073
    +1
    Как так, zsh может, а bash нет? Механизм разбора в bash не более основан на интерпретации команд, чем в IPython. Здесь есть построение AST, расширить парсер (который основан на YACC), чтобы понимать тот же синтаксис, что понимает zsh особых проблем не составляет: вполне современный механизм разбора, к командам не имеющий никакого отношения, кроме того, что он, собственно, разбирает. Блоки в фигурных скобках, к слову, здесь есть: как при определении функций, так и просто на ровном месте в целях группировки.
    
    VimL я привёл потому, что он использует архаичные методы: никаких YACC, никакого AST, берём строку исходного кода и исполняем как есть прямо по мере разбора. Нужен цикл? Будем разбирать строку на каждой итерации. И, главное, вся работа выполняется командами и функция парсера верхнего уровня знает только пустые строки, комментарии, то, что можно приписать каждой команде (т.е. диапозон строк, для которых команда будет исполняться, иногда используемые по другим назначениям) и, собственно, команды.
    
    Сильно подозреваю, что tcsh написан так же: некоторые ошибки на это намекают.
    
    Delphinum
    23.04.2016 02:50
    #8866083
    вполне современный механизм разбора
    
    Важно замечание ) Bash разросся из простого командного языка.
    
    VimL я привёл потому
    
    Да, Vim использует каноничный командный интерпретатор.
    
    ZyXI
    23.04.2016 02:21
    #8866055
    +1
    Даже если fi выглядит как команда, он ей совершенно не является. Есть стандарт на синтаксис оболочки: посмотрите на синтаксис в http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_10_02, из него явно следует, что в AST (абстрактное синтаксическое дерево) if затянется одним куском. Да и если вы попробуете выполнить if echo abc ; then echo def (т.е. без fi), то вы получите syntax error сразу, echo abc запускать никто не будет, не говоря уже об echo def. Если бы if было обычной командой, то вы бы увидели abc, потом def, а потом что?то вроде runtime error, говорящую о том, что конец файла достигнут, а fi не найдено.
    
    Все (проверял в busybox, posh, bash, dash, ksh, zsh) оболочки при вводе if echo abc<CR>then<CR>echo def<CR> будут ждать от вас fi и только потом что?то запустят (или EOF и потом сообщат вам о синтаксической ошибке). Хотите язык реально основанный на командах — смотрите VimL. Он запустит echo abc даже в echo [system('echo abc') (команда не завершена: отсутствует закрывающая квадратная скобка), да и внутри if и endif отличаются от остальных команд только тем, что изменяют состояние редактора.
    
    Delphinum
    23.04.2016 02:23
    #8866059
    Даже если fi выглядит как команда, он ей совершенно не является
    
    Мне просто лень вдаваться в подробности реализации bash )
    
    Хотите язык реально основанный на командах — смотрите VimL
    
    Спасибо, обязательно посмотрю ))
    
    thatsme
    23.04.2016 20:12
    #8866659
    Вообще, год назад к 1-му апреля я подготовил патч для bash, который расширяет синтаксис, эквивалентно заменяя then, do, done, fi на {}, при этом сохраняя и старый синтаксис.
    Так как патч был шуточный, я и статью на хабр выложил (названия не помню, и статья не прошла). А не прошла она т.к. этот патч к bash я назвал ebash…
    Да это то о чём вы подумали, но в статье это звучало как Effective Bash, и обыгрывалась тема экономии символов.
    
    Да код становится совершенно не очевидным, т.к. списки в bash также используют {}…
1. sshikov
  23.04.2016 12:32
  #8866339
  В том, что вы не можете писать нормальные функции. В том, что нет нормальной обработки ошибок. В том, что нет нормальных структур данных.
  
  И это все совсем не к синтаксису претензии. Хотя он тоже тот еще… недавно у нас в проекте забыли кавычку где-то на 20 строке. Упало на строке 89, перед этим выполнив предыдущие 88. Шикарный синтаксис, который не защищает от пропуска закрывающей кавычки, не правда ли?
  
  Чисто практический опыт показывает, что переписывание (там где это можно) с bash на нормальный язык, сокращает объем примерно в три раза, сохраняя или увеличивая читаемость кода. Да хоть на python или perl. Я пробовал на groovy. На что угодно — только не bash и это семейство (ksh в общем туда же, плюс-минус).
  
  Прекрасно понимаю, что избавиться от всего добра, которое на нем написано, вряд ли возможно, тем не менее совершенно непонятно, ради чего его защищать? По сегодняшним меркам он архаичный весь, от и до.

EugeneNuke
22.04.2016 22:33
#8865829
+13
Очень сумбурно, непонятна аудитория вашей статьи.
1. MetaAbstract
  22.04.2016 22:41
  #8865841
  Признаюсь об аудитории я не размышлял. Просто изложил все с чем столкнулся и личные впечатления. Мне кажется полезно тем, кто планирует переход, прочитать про чужой опыт. В сети в основном либо мануалы, либо руководства по конкретным ситуациям. Например проблема с почтовым сервером для меня стала неожиданностью, после hMailServer под Windows.
  1. EugeneNuke
    22.04.2016 22:54
    #8865855
    +17
    Если бы изложение было бы более литературным, захватывающим чтивом, я думаю, Вам простили бы даже небольшую информационную нагрузку. Что касается аудитории: линуксоиды просто посмеются (могут и высмеять), а «люди не в теме» вынесут из статьи, что у линукса проблемы со шрифтом и архаичная (ха-ха-три-раза) командная строка, а из коробки ничего не работает. Как-то так.
    
    MetaAbstract
    22.04.2016 23:02
    #8865865
    Не способен писать литературно :( Но поделиться хотел опытом без технических деталей.
    Кстати про проблемы со шрифтами.
    Меня больше всего возмущает в ситуации со шрифтами, что государство закапывает кучу денег в разные проекты, а шрифтов российских не сделало. Есть какие то, но они насколько я понял, не очень качественные.
    
    EvilFox
    23.04.2016 00:52
    #8865971
    +2
    государство закапывает кучу денег в разные проекты, а шрифтов российских не сделало.
    Врёте.
    
    MetaAbstract
    23.04.2016 00:58
    #8865977
    -1
    Я был в курсе, но на них был плохой отзыв от специалиста. Вы считаете они качественные?
    
    EvilFox
    23.04.2016 01:16
    #8865993
    +1
    Если в курсе то зачем давать заведомо ложную информацию?
    Отзыв какого специалиста? Их качество не смущало. PT Mono у меня стоит в текстовых редакторах и консоли, остальные шрифты использовал в дизайне. Правда я в основном на Windows и только сервера на Linux.
    
    MetaAbstract
    23.04.2016 01:37
    #8866011
    Спец по linux сказал, когда я у него про шрифты консультировался и эти шрифты в пример приводил. Они кстати, я сейчас еще раз посмотрел, под Windows. Под freetype в этих шрифтах хинтинга нет, если я все правильно понял. Так что информация не ложная.
    
    EvilFox
    23.04.2016 01:52
    #8866025
    1. Шрифты плохо выглядят под linux ? государство шрифтов российских не сделало.
    2. У них было обновление и вносили правки под юниксы: http://paratype.livejournal.com/12393.html?thread=38761#t38761 ещё было повторное обновление http://paratype.livejournal.com/21560.html
    3. А в первой записи http://paratype.livejournal.com/10009.html#cutid7 они дают своё мыло для решения проблем.
    
    MetaAbstract
    23.04.2016 02:07
    #8866037
    Там же запись было, что чтобы хинтинг не делать растры вставили. Вопрос же в LCD мониторах.
    Хорошо соглашусь что государство сделало шрифты, только почему не под открытый стандарт. В целом это кривой подход.
    
    EvilFox
    23.04.2016 03:01
    #8866093
    Я не знаю что там с хинтингом в линуксе (вообще ШГ в линуксе это норма), но ребята явно занимались им.
    А в вики написано:
    
    PT Sans is included in the Fedora Linux package repository since February 2010, in the Gentoo Linux repository since January 2011, and in OS X since Lion.
    Не думаю что плохой шрифт приняли бы в ту же Федору. Так что мне думается тут больше проблемы конкретно вашей и специалиста систем.
  1. Shtucer
    22.04.2016 23:09
    #8865871
    +16
    Статьёй это сложно назвать. Сочинение какое-то. Как я провёл Линукс.
  1. iassasin
    23.04.2016 01:32
    #8866007
    -4
    У линукса есть одна классная особенность, которая мне нравится: он заставляет разбираться в том, что делаешь, в отличие от windows, где зачастую достаточно нагуглить одну галку, погребенную в дебрях GUI, и потом не вспомнишь, зачем она вообще была нужна (а в новой версии windows ее еще и перепрятать могут).
    А после того, как разберешься — сразу ЧСВ поднимается, и чувствуешь себя героем :) Да и при дальнейшем копании в системе начинаешь больше понимать, как и почему так все работает.
    Причем больше понимаешь не только в линуксе, но и в windows. Например, я раньше и не догадывался, что в windows есть понятие mount-а.
    
    iassasin
    25.04.2016 02:47
    #8867813
    А за что минусы то? Писал исходя из собственного опыта. Получается, у меня неправильный опыт был? Поясните, пожалуйста.
    
    ZyXI
    25.04.2016 02:51
    #8867815
    +1
    Основной посыл комментария — «linux нужно осваивать для повышения Чувства Собственной Важности» :) По?моему, вы просто выбрали неудачные формулировки для выражения своей мысли.
    
    iassasin
    25.04.2016 03:06
    #8867817
    Основной посыл задумывался в самой первой строчке («заставляет разбираться в том, что делаешь»). А про ЧСВ — это вообще с юмором писал. Не умею я шутить, видимо :(
    Спасибо за пояснение.

dmitry_dvm
23.04.2016 00:11
#8865927
+9
«Поставил линукс — напиши на хабр». Классика.
Чтобы не мучиться с почтой есть iRedMail.
1. MetaAbstract
  23.04.2016 00:17
  #8865937
  +1
  iRedMail во первых не встал на систему как мне надо, а во вторых я потом два дня его вычищал из системы, т.к. он мне некоторые конфигурации порушил и вообще прав много хотел для своей деятельности.
  Это конечно более легкий путь, но не совсем правильный.
  Я по результатам рекомендовал его не использовать.

ZaEzzz
23.04.2016 00:27
#8865947
Немного накипело: знаете, что меня бесит как пользователя в среде *nix? Ресайз окна. мелкие поняли какой должна быть область по ширине бордера, чтобы зацепить окно. Никто в GUI никсовых не подумал, что эта область должна быть больше 1px бордера.

P.S. фряшник.
1. MetaAbstract
  23.04.2016 00:31
  #8865949
  Да… а я все думаю, что так окно тяжело зацепить за край мышкой иногда. Это оно?
  Меня реально напрягает, что в GNOME например когда комбинации клавиш настраиваешь окно не раздвигается и нельзя прочитать полный текст на что кнопка привязана. Я с этим в нескольких местах сталкивался.
1. TargetSan
  23.04.2016 00:58
  #8865981
  +2
  Cinnamon, зона ресайза явно больше одного пикселя. Только что проверил.
1. ZyXI
  23.04.2016 01:20
  #8865999
  +1
  Fluxbox. Зажал Alt и тащи правой кнопкой хоть из самого центра, правда изменять размер можно только направо?вниз, если не использовать специальную resize зону (которая у меня на большинстве окон отключена вместе с рамкой вокруг окна). Этих зон две в нижних углах, что добавляет налево, но не вверх. Зона явно больше одного пикселя, как и сама граница. Но всё равно придётся целиться.
  
  Уверен, будь у вас 1px, то с 1920x1080 вы бы границу просто не заметили бы.
  1. rkfg
    23.04.2016 12:31
    #8866337
    Это работает и в MATE, да и в других DM наверняка есть. Система — Параметры — Окна, можно переключить на Winkey, если Alt не устраивает. А так Alt+левая кнопка — перемещение окна, Alt+правая — ресайз.
  1. ZaEzzz
    24.04.2016 08:25
    #8866863
    Часто нет желания нажимать на лишние сочетания клавиш. Так же как и в консольке нет желания брать мышку.
    
    Да, с 1px я погорячился. У меня на ноуте 1366x768 и область ресайза все таки где-то 3px, в которые тяжело попасть, при этом размер границы 1px.
    Сейчас еще провел один маленький эксперимент: на Windows 7 отключил в параметрах указателя «Включить повышенную точность установки указателя» — уровень удобства пользования UI стал ниже, но все равно выше, чем в никсах. Интересно, есть-ли подобные параметры для других систем.
1. thatisme
  25.04.2016 11:13
  #8868173
  Ресайз окна зависит от используемого оконного менджера. Да, в оконном менеджере GNOME сделано плохо.
  Но практически везде есть возможность ресайза с зажатым модификатором — и не нужно целиться в край окна.

Cheater
23.04.2016 00:43
#8865959
> Первым недостатком системы я считаю отсутствие стандарта и стандартного интерфейса на конфигурационные файлы.

Эм, а «в самой лучшей ОС» такой стандарт есть, что ли? И каков же он? Ini? И какой смысл иметь единый стандарт, если какие-то приложения конфигурируются парами ключ-значение, а каким-то нужен фактически тьюринг-полный язык для конфигурирования?

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

Опять некий мифический «стандартный мастер» для конфигурирования любых приложений. Что значит «конструирование параметров и ключей», я не знаю, но скорее всего вам нужны bash aliases. Нет, вру, сначала разумеется нужна статья на хабр, где вы авторитетно открываете всем глаза на то, как надо работать с юниксовыми консольными приложениями.

> И третьим недостатком я считаю синтаксис bash. Понимаю, все темы флеймовые, а последняя в собенности, но синтаксис крайне архаичиный.
И кто тогда неархаичный? Синтаксис то ли Си, то ли Perl с фигурными скобками, который вы выше приводите? Ему как бы тоже не один десяток лет.
1. MetaAbstract
  23.04.2016 00:55
  #8865973
  Стандарт:
  Например json+json schema+ например json editor
  Мастер:
  Не буду вдаваться в детали, но решение существует для этой проблемы.
  Архаичность bash:
  Выше в целом все обсуждено. Меня бы например javascript устроил вполне.
  1. ZyXI
    23.04.2016 01:58
    #8866027
    +1
    Часть программ настраивается с помощью полноценного языка программирования. JSON тут в пролёте. Те, кому это не нужно, может и могли бы перейти на JSON, но вам знаком такой термин как «обратная совместимость»? Это мало кому нужно (обычно языки в конфигурации просты как три копейки) и много кому поломает их скрипты или иногда даже программы.
    
    Я тоже не понимаю, что именно вы имели ввиду под «стандартным мастером». Команды, вводимые в оболочку, нужно воспринимать как библиотечные функции в других языках программирования: за некоторыми исключениями (слабо представляю себе библиотечную функцию, запускающую тяжёлое GUI?приложение) они выполняют именно эту роль. Я как?то не слышал про мастера конструирования для библиотечных функций. А документация на команды есть, и она более или менее стандартна.
    
    Возьмите node.js и попробуйте там написать сложный shell скрипт с фильтрами. Взвоете. Скрипты на bash ориентированы на сопряжение команд (т.е. основную работу выполняет не bash а какой?нибудь grep) и довольно удобны для их сферы применения, языки вроде javascript ориентированы на то, что наибольшую часть работы выполняет код на javascript (возможно, библиотечный). В некоторых случаях «на javascript или совместимых языках» (т.е. исполняющихся в JVM или находящихся в разделяемых библиотеках со стандартным C?шным интерфейсом вызова).
    
    Можно попытаться что?то скрестить как сделал zsh выше ([t]csh не смотрите, его писали люди, которые явно хотели пытать программистов, а не писать оболочку), но, скорее всего, получите лишь то, что количество символов в скрипте уменьшится на 1%, синтаксис в целом сильно не изменится, а программисты начнут путаться. Или что синтаксис будет как в javascript, но количество символов увеличится в несколько раз, а программисты будут искренне недоумевать, как вы могли назвать свою поделку языком для оболочки. Так зачем заниматься фигнёй с заменой синтаксиса, если сильно лучше не будет, а переделать всё придётся?
    
    Лучше развивать что уже есть. Как используемый мною zsh: чтобы понимать любой скрипт на zsh придётся выучить на целый порядок больше информации: поэтому zsh — это моя любимая оболочка (чтобы добиться того же результата однострочником в bash иногда нужно написать в два и более раз больше символов), но системные скрипты на zsh я бы не приветствовал. При этом возможно писать скрипты, которые нормально работают в POSIX sh, bash, ksh и zsh одновременно.
    
    MetaAbstract
    23.04.2016 02:27
    #8866061
    Буду отвечать отдельными постами.
    Конфигурация в JSON.
    Конфигурация это данные. JSON прекрасный формат, чтобы его и читать глазками и компиком. Ну а то, что некоторые программы настраиваются кодом, это уже не конфигурации, скрипты какие то наверное.
    
    ZyXI
    23.04.2016 02:49
    #8866081
    Во?первых, есть форматы и получше. Во?вторых, я не говорил, что JSON плох. Я говорил, что он либо не применим, либо не будет понят уже написанными программами. Никто не будет менять формат конфигурации, просто потому что кто?то решил сделать какой?то новый формат стандартным.
    
    UNIX появился задолго до того, как возник Javascript, не говоря уже о JSON. И в среде, где «обратная совместимость» реально важна большинству пользователей.
    
    MetaAbstract
    23.04.2016 02:55
    #8866089
    +1
    Какой например? Я пока лучше не встречал.
    С обратной совместимостью ситуация понята, но весь софт, который используется практически всегда на поддержке. По крайней мере в Debian как я понял. Такую операцию вполне можно провести. Всем бы жить легче стало. А то открываешь Apache — один стиль, php — другой и т.д. уже в глазах от этих конфигов рябит)))
    
    ZyXI
    23.04.2016 03:05
    #8866095
    Для конфигурационных файлов я всегда предпочёл бы YAML: его удобнее читать человеку (компьютеру, наоборот, сложнее). Правда, я бы оформлял всё дело не как файл(ы) с настройками, а как configfs с двумя вариантами доступа: vim /path/to/configfs/root/appname/…/file.yaml для пользователя с доступом на чтение?запись и bool config_query(const char *appname, const char *config_file_path, const struct query *query, const enum query_return_type return_type, void *query_result) (+несколько обвязок вроде config_query_integer) для собственно приложения (разумеется, с другими API на других языках): чтобы реализовать парсер YAML один раз и без внешних зависимостей (системные библиотеки не считаются) и вообще тратиться на разбор настроек только один раз после записи, а не при каждом старте приложения.
    
    ZyXI
    23.04.2016 03:14
    #8866097
    (Если вы нашли очевидные проблемы: во?первых, один раз после записи ? один раз немедленно после записи. Запись должна стирать кэш, а config_query уже будет проводить разбор, который будет кэшироваться до следующей записи. Во?вторых, заодно именно здесь должны показываться ошибки, если они есть: системные API для чтения?записи файлов не позволяют нормально сообщить о проблеме разбора YAML файла. Хотя нужно было добавить ещё аргумент в функцию — для возврата ошибки либо callback, принимающий описание ошибки в аргументах.)
    
    bromzh
    23.04.2016 08:07
    #8866125
    +4
    JSON прекрасный формат, чтобы его и читать глазками и компиком.
    
    Ага, особенно радует отсутствие комментов, один вид кавычек, необходимость эти кавычки ставить в ключе, отсутствие trailing comma (это когда нельзя делать так: [1, 2, 3,]), скудность типов, и ещё куча недостатков. Наличие попыток сделать свой формат на основе JSON или добавить ему костыли — лишнее тому подтверждение.
    
    Если настройки сводятся к ключ-значение, то ini и подобные ему куда лучше. Если настройки начинают выходить за эти рамки, то по мне уж лучше писать конфиг на каком-то языке программирования, например lua или js.
    
    grossws
    23.04.2016 11:39
    #8866271
    +1
    Соглашусь с первой частью, но не со второй. Интерпретируемый/компилируемый конфиг — это жесть, т. к. с ним становится почти невозможно работать из другого софта (в том числе SCM).
    
    bromzh
    23.04.2016 12:57
    #8866365
    Интерпретируемый/компилируемый конфиг — это жесть
    
    Ну это смотря для чего конфиг. Если настроить программу, у которой куча опций плагинов и др. возможностей — самое оно. Собственно, все современные редакторы кода построены по такому принципу. В мире nodejs тоже предпочтительнее использовать js-код, а не просто json. Банально уменьшает количество копипаста.
    
    с ним становится почти невозможно работать из другого софта
    
    Мы же про ОС говорим? И про всякие более-менее стандартные (не узкоспециализированные) программы. Зачем с конфигом программы работать из другого софта? Кому может понадобится конфиг, например, nginx'а кроме него самого?
    
    Если же некие конфиги будут использоваться кучей программ, то да, нужно что-то статическое и со схемами. Но тут xml наверное будет получше, хотя зависит от задачи.
    
    grossws
    25.04.2016 12:19
    #8868269
    Собственно, все современные редакторы кода построены по такому принципу.
    
    Не знаю, какие именно редакторы вы имеете ввиду. Тяжелые IDE которыми я пользуюсь имеют статический конфиг. Часть систем сборки — статический декларативный конфиг.
    
    И про всякие более-менее стандартные (не узкоспециализированные) программы. Зачем с конфигом программы работать из другого софта? Кому может понадобится конфиг, например, nginx'а кроме него самого?
    
    Я же недвусмысленно написал пример: разные SCM (ansible, salt, puppet, chef etc). Другой классический пример IDE и системы сборки. Интеграция с gradle обычно не на высоте в первую очередь потому, что это скрипт.
    
    MetaAbstract
    23.04.2016 02:28
    #8866063
    Про настройку команд с ключами, я как говорил развивать тему не хочу, но решение мне известно. Конечно я в этом не на 100% уверен, т.к. надо на практике проверить, но на 90%.
    
    MetaAbstract
    23.04.2016 02:33
    #8866065
    Скрипты на javascript.
    Я как пример привел. Это тема требует размышлений, может javascript не подходит. Может надо отдельный синтаксис и семантику разработать. Хотя сейчас асинхронная часть языка активно развивается. Промисы, генераторы и т.д. Так что может и подойдет.
    
    ZyXI
    23.04.2016 03:42
    #8866105
    Синтаксис и функциональность асинхронной части не особо в тему: основная проблема, что я не представляю, как можно сократить cat /var/log/messages | grep \^"$(LANG=C date -d-1day +'%b %d')" до чего?то, меньшего чем
    
    stdout.write(pipe(cmd('cat', '/var/log/messages'), cmd('grep', '^' + env({LANG: 'C'}, cmd, 'date', '-d-1day', '+%b %d').read().trim())))
    
    Ни promis’ы, ни какая?нибудь другая асинхронная фигня, ни callback’и тут особо не помогут: так, как выше, можно писать уже сейчас (если грамотно поизвращаться с callback’ами; если не извращаться, то код будет более похож на JS, но длиннее). Добавите что?то из новых возможностей — будет ещё длиннее, а не короче: внешние процессы и так запускаются асинхронно, а возможности для асинхронного запуска JS кода здесь нафиг не нужны.
    
    grossws
    23.04.2016 11:32
    #8866261
    +3
    В некоторых случаях «на javascript или совместимых языках» (т.е. исполняющихся в JVM или находящихся в разделяемых библиотеках со стандартным C?шным интерфейсом вызова).
    
    Взаржал в голос. Не только среди хрюшек, оказывается, есть люди путающие java и js.
    
    ZyXI
    23.04.2016 23:10
    #8866769
    +1
    Я неправильно выразился здесь. Я не имел ввиду, что JS исполняется на JVM. Я просто под «javascript» имел ввиду класс языков, исполняющихся в VM (javascript, Java/…, Python, lua). Т.е. то, что в предложении раньше назвал «языками вроде javascript».
    
    И для таких языков нормально сопряжение либо средствами VM (Java, C#), либо через C?шный ffi.
    
    grossws
    25.04.2016 12:22
    #8868279
    ОК, просто звучало очень неоднозначно. Т. к. "javascript и совместимые языки" с высокой долей вероятности указывают на те языки, что транслируются в js.
  1. MikalaiR
    24.04.2016 10:19
    #8866909
    В таком дистре, как OpenWRT, используется есдиная система конфигов (UCI — Unified Configuration Interface). И оно реально очень удобно.
    
    MetaAbstract
    24.04.2016 10:21
    #8866911
    Супер тема! И кстати модель файлов конфигурации очень мощная.

Delphinum
23.04.2016 02:08
#8866039
+7
Автор, этот комментарий, возможно, изменит твою жизнь, так что будь осторожен:
Изменяющий жизнь текст
Ядро Linux позволяет реализовать собственный дистрибутив на его основе. Возможно создать свою ОСь с json в качестве стандарта конфигурирования, JavaScript в качестве командного интерпретатора и единым интерфейсом для всех подсистем. Дерзайте.
1. MetaAbstract
  23.04.2016 02:34
  #8866067
  +1
  LFS осилю — там посмотрю))))
1. khrisanfov
  23.04.2016 02:49
  #8866079
  Ха-ха, в точку.

MetaDone
23.04.2016 09:06
#8866149
Если раннее не пользовались линуксом и переходите с винды, то выбирайте дружественные к пользователю дистрибутивы — Linux Mint, Ubuntu и т.п… Для экспериментов используйте VirtualBox — так если и поломаете внутри что-то, то потом откатите.
В комментариях выше правильно подсказали про почтовый сервер http://www.iredmail.org/, есть еще статья здесь

andreili
23.04.2016 11:56
#8866295
Все остальное в целом работает и я очень доволен тем, что система полностью под моим контролем

В Дебиане?
Не согласен. Кто хочет полный контроль — сидят на генте или слаке. Вот там свобода так свобода.
Я, пока осваивал генту, выучил синтаксис Shell-скриптов, в первые же месяцы разобрался как писать и подсовывать системе свои патчи. А после вдумчивого конфигурирования ядра (неделю примерно) уже имелись хоть какие-то представления о его структуре (пришлось лезть в сырцы и смотреть на причины конфликтов при сборке).
Зато после освоения генты путь LFS-BLFS до рабочего стола с кедами и плюшками прошел дня за 4 (при этом отучил всё, что можно от python2 и Qt4).

PS: И да — гента стала моим первым дистром, на котором я освоился. До этого были отдельные попытки с убунтой, но дольше пары недель они не длились — сильно проблематично разработчику там, приходится ставить просто пакет и его dev-версию, что бы в проекте подключить нормально. В генте это всё «из коробки». Поэтому это личное ИМХО как разработчика софта.

artgur
23.04.2016 12:30
#8866331
По поводу конфигов: есть проект etcd с API, json и распределенкой. Вам остается только переписать все сервисы на вашей системе для его понимания
github.com/coreos/etcd
По поводу bash: пишите на python, lua, groovy или в крайнем случае на C. Это не возбраняется
1. bromzh
  23.04.2016 12:45
  #8866357
  Ещё есть Tcl. Из коробки есть почти в любом дистре. Плюс, приятное дополнение в виде Tk.
  А вот у луа проблемы в плане работы с ОС (всякие операции с файлами и т.д.). Всё-таки он позиционируется больше как встраиваемый язык, так что там нет богатой стандартной библиотеки и удобной системы пакетов.

AnisimovAndrey
23.04.2016 12:31
#8866333
+5
Как итог хочу сказать следующее. Windows и Linux не сопоставимы между собой как по возможностям, так и по уровню контроля над ситуацией. Сравнение явно в пользу Linux и рекомендую всем сдвигаться в этом направлении.

Преподносится как вывод, хотя в тексте нет ничего, подтверждаюшего это.

agic
23.04.2016 12:31
#8866335
+7
неужели это статья уровня хабра? больше похоже на сочинение школьника

kireevco
24.04.2016 20:19
#8867561
Имхо, выглядит как заметка из серии "мой дневник". Очередной "переход" — это всего лишь "пора начать использовать Linux".
В тему по синтаксису — сам поддерживаю зоопарки машин, и затеи унифицировать ksh/bash/cmd/powershell умерли с появлением систем конфигурации. Если очень поверхностно, то абстракция этого уровня позволяет эффективно видеть саму конфигурацию, а особенности шелла прятать под капотом. Установить пакет? package {"git"} — пожалуйста. Это для тех, кто хочет универсальности. Обучайте-нанимайте системщиков знающий puppet/chef/ansible/… и все будет хорошо :)
1. MetaAbstract
  24.04.2016 21:03
  #8867585
  Так и есть «Мой дневник»).
  Кстати замечу на данный момент 34% проголосовавших не против увидеть историю в том же стиле про борьбу с сервером, так что тематика и формулировки людям интересны.
  По Вашей наводке почитал про системы управления. И если SaaS облако делать на арендованных виртуалках, то наверно без такой системы не обойтись. Но я тут тему изучил, и так как я на Debian уже заложился, то остановился на Bcfg2. Буду признателен, если прокомментируете.
  1. kireevco
    24.04.2016 21:14
    #8867603
    +1
    Я не знаком с bcfg2, не использовал, но когда смотрел изначально (года 4 назад) смутила ужасная на первый взгляд архитектура и отсутсивие (или неявность?) документации по непосредственно конфигурации систем.
    Я начинал с Puppet, потом немного Chef и сейчас Ansible.
    Рекомендую посмотреть в сторону ansible. Оно очень просто, в то же время эффективно.
    
    если SaaS облако делать на арендованных виртуалках, то наверно без такой системы не обойтись.
    
    Не обязательно. Любой конфиг через систему управления конфигурацией становится куском кода, к которому можно потом вернуться, либо дать другому пользователю.
    
    Моя идеология такая: например, вы разворачиваете чуть менее тривиальный nginx+php-fpm, с системой выкатки. Почему-бы не засунуть это все в Ansible, ведь наверняка придется разворачивать еще один такой же сервер через неделю или полгода?
    А ведь к тому моменту конфигурация может измениться, и если поддерживать роль Ansible, то новый сервер развернется "сам" :)
    
    К тому же держать конфиг сервера в git это просто хороший тон :)
    
    kireevco
    24.04.2016 21:18
    #8867605
    А еще плюс Ansible в том, что ему не нужен агент на целевой машине.
    
    MetaAbstract
    25.04.2016 07:51
    #8867889
    Благодарю. Когда придет время озадачусь.

r00tGER
25.04.2016 09:36
#8867957
Как после «фурора» первой части, могла появиться эта статья?
Выглядит, как натуральное тро-ло-ло.
1. MetaAbstract
  25.04.2016 10:05
  #8868017
  Судя по результатам голосования в конце статьи идея понятна части аудитории.

	Да
	Нет