js, systemd: что из них хрен, а что — редька?

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

ну js туда впёхнут, постольку поскольку xml

Ну так сделай сам, без системд и жс. Что мешает?

у меня не было выходных

системд и жс

gentoo: openrc и kde. Я про мейнстрим вообще-то говорил.

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

Просто есть два типа людей: те, которые ставят на первое место эффективность (производительность), и те, которым наиболее важна скорость разработки. Идеал, как всегда, где-то посередине.

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

>js
>удобно

Шо?

так еще и неудобно? Гм, а зачем тогда js вообще нужен?

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

В браузере гумнокод писать, потому что теперь менять там что-то уже поздно. Больше он ни зачем и не нужен :}

а не объясните мне (т.е. тому, кто в жизни ничем, кроме asm, c, VHDL/Verilog не пользовался) — в чем его профит?

Куча хомячков его уже знает. В чём профит (если он есть) сказать не могу, у меня к нему пламенная НЕНАВИСТЬ. Впрочем, я не люблю прототипированные языки вообще в принципе.

тормозной баш

Промытый мозг детектед.

про сарказм написать?

Промытый мозг детектед.

пруфы что баш не тормозной?

Предлагаю запилить systemd на js.

пруфы что баш не тормозной?

Давай пруфы будет предоставлять тот, кто сделал заявление.

(js)

Подражание вебу, бессмысленное и беспощадное.

(systemd)
я не хочу ни «быстрой» параллельной загрузки

Upstart, openrc, initng, simpleinit и прочие подобные никто не ругал, хотя и у них параллельная загрузка.
Наверное, всё дело в том, что они не комбайны со встроенным веб-сервером, и их никто не пытался навязать.

В порядке ныться я тоже сделаю заявление что как ЯП для больших и сложных скриптов bash (и все остальные sh) подходят плохо в силу того что

1) большинство действий делается внешними коммандами, что создаёт феерические (по сравнению с другими яп) тормоза.

2) бедность встроенных средств. Меня каждый раз коробит от проверки переменных типа if [ x$VAR = «x» ]; then ... . Не дай бог пробел пропустить или x забыть.

3) слабая поддержка арифметики. поддержка только целых чисел.

4) нет никакой защиты от ошибок. Даже с синтаксическими ошибками скрипт запустится.

5) отдельная статья это парсинг выхлопов различных утилит. Особенно если они изначально не были расчитаны. Поэтому сидишь и думаешь как парсить вывод какого-нить brctl.

А попытка поддерживать не только bash но и другие sh делает и без того скрипты ещё хуже.

Ехал function() через function(),
Видит function() — в function() function()
Сунул function() function() в function()
function() function() function() function()

большинство действий делается внешними коммандами, что создаёт феерические (по сравнению с другими яп) тормоза.

Теперь нужно замерить величину этих тормозов на типичной задаче «запуск системной службы».

Лучше не стоит предлагать это делать широким массам. Глядишь, в дебиане системде в тестинге по дефолту появится )))

Лучше не стоит предлагать это делать широким массам. Глядишь, в дебиане системде в тестинге по дефолту появится )))

А мне не нужно, чтобы он там появлялся.

в чем его профит?

Быстрая разработка, безопасность, неплохая скорость. Главное — распространенность.

Главное — распространенность.

Где? Я вот по работе из скриптовых языков сталкивался только с петоном и Tcl.

у меня федора не стартовала, когда поменялся UUID у свопа

Наверное памяти не хватило, у меня федора тоже начинает свопиться сразу после старта, 4гб оперативки уже мало, надо еще подбавить.

А я не знаю, что такое VHDL/Verilog. Наверное, какая-то локальная разработка мелкой компании.

Теперь нужно замерить величину этих тормозов на типичной задаче «запуск системной службы».

А, имхо, на баше такие вещи вообще писать не нужно. Сколько не видел скриптов они все внутри написаны... не то чтобы совсем страшно, но велосипеды повсюду т.к. bash как яп ацтой.

1. (systemd)

Вообще по моим наблюдениям upstart работает куда быстрее systemd. Если поставить дефолтную убунту 12.10 и дефолтную федору 17 - то запускаться будет быстрее убунта, проверялось на обыкновенном харде, SSD не использую, но, думаю, и там шубунта быстрее будет.

2. (js)

А вот вместо этого лучше python использовать ибо синтаксис читабельный и, как следствие, чужое быдлокодерство читать можно.

Теперь нужно замерить величину этих тормозов на типичной задаче «запуск системной службы».

А, имхо, на баше такие вещи вообще писать не нужно.

Ну, жалоба была на тормознутость, а не убогость языка.

Сколько не видел скриптов они все внутри написаны...

Перепишем же их на Си, чтобы исходники глаза не мозолили %)

Ну, жалоба была на тормознутость, а не убогость языка.

тормознутость

большинство действий делается внешними коммандами, что создаёт феерические (по сравнению с другими яп) тормоза.

Зато их можно легко изучать и модифицировать без компиляний и поиска исходников. А если скрипт используется для разовых операции (типа запуска определённого демона), то ничего страшного в небольшом проигрыше в производительности нет.

Меня каждый раз коробит от проверки переменных типа if [ x$VAR = «x» ]; then ... .

Только там, где нужна максимальная совместимость со другими интерпретаторами. Надеюсь, мне не нужно рассказывать тебе про [ -n $VAR ] и [[ $VAR ]]?

отдельная статья это парсинг выхлопов различных утилит. Особенно если они изначально не были расчитаны.

Это проблемы конкретных утилит, а не баша.

Ладно, если ты настаиваешь: что именно продемонстрировал твой замер?

Про perl ни одного слова... А ведь там нет глюков типа в v2 работает - в v3 пиши заново

А ведь там нет глюков типа в v2 работает - в v3 пиши заново

Это глюки в головах питонофобов.

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

Да ладно. При практически одинаковом коде, питоноскрипт с Tk - непереносим. Аналогичный на перле - работает везде. (тут ремарка о неосиливании питона и личной неприязни к питонофилам - остальные скриптовики не орут везде что $lang их лучше, чем другие)

При практически одинаковом коде, питоноскрипт с Tk - непереносим

Во-первых, ты лжешь; во-вторых, переносимость скриптам запуска системы не нужна; в третьих, Tk в скриптах запуска системы не нужен.

остальные скриптовики не орут везде что $lang их лучше, чем другие

Ну да, остальные (в твоем лице) говорят, что проги на Перле не нужно переписывать между мажорными версиями, хотя в деле наблюдали только Perl5 (Perl4? Perl6? не, не юзали).

Это проблемы конкретных утилит, а не баша.

Т.к. баш ничего другого не предоставляет, то это его личные половые проблемы :}

Про perl ни одного слова...

Perl допускает написания нечитаемых перлов.

А ведь там нет глюков типа в v2 работает - в v3 пиши заново

Это не глюк и от этого плохо никому не становится.

Тормоза баша, разумеется

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

Бедность встроенных средств порождает ненужные костыли.

Я ничего не имею против простых действий, шелл для них действительно удобен. Проблема в том что на что-то больше он не годится.

Это проблемы конкретных утилит, а не баша.

Да, но встроенная поддержка регекспов не помешала бы. awk/sed/perl/etc приходится достаточно использовать.

Только там, где нужна максимальная совместимость со другими интерпретаторами.

угу, зоопарк интерпретаторов это ещё одно зло из-за которого шелл-скрипты выглядят аля привет из 70-х.

жалоба была на тормознутость

окей, я таки скажу это. man bash, раздел BUGS, первая строчка :).

Перепишем же их на Си

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

Если поставить дефолтную убунту 12.10 и дефолтную федору 17 - то запускаться будет быстрее убунта

ммм, поставь arch, удивишься :). Впрочем, подтюненая убунта (читай с удалённым хламом) тоже может быстро стартовать.

а вот, кстати, хороший вопрос каким должен быть нормальный шелл.

Хороший шелл должен быть как bash/zsh. Простой, с короткими командами и хорошим автодополнением и прочими ништяками. А вот скрипты на нем, отличные от расширения базового функционала, писать противопоказано

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

хз, я постоянно вижу проблемы с чтением чужого кода, даже если всё нормально отформатировано. Пример: linux/tools/perf. Написано-то красиво, но вот логика размазана по всем файлам. Это помимо того что прекрасные программизды решили таки сделать киллер-фичу юникс-систем: никогда не говори какой из аргументов не нравится, тупо показывай ошибку. Как результат, сижу с gdb и смотрю почему «perf stat -e cycles -G my -C1» не работает. Только даже с gdb пока не понял потому что условие выхода и сам выход в разных местах. И эти люди нам пишут ядро...

Кстати, раз уж я эту тему начал: я хочу убить авторой fdisk за то что fdisk -l от обычного юзера тупо выходит без ошибок и без результата. Этож как надо было обдолбаться чтобы такое придумать. Правило программиста номер 1: если произошла ошибка падай рано, падай громко.

man bash, раздел BUGS, первая строчка :).

Ага. Давай еще вспомним Ъ-расшифровку аббревиатуры EMACS - «eight Megabytes And Constantly Swapping».

а вот, кстати, хороший вопрос каким должен быть нормальный шелл.

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

это полумеры.

возможно, но это был бы большой шаг вперёд. Глядишь, и systemd бы не появился (которые я теперь не люблю).

Когда я вспоминаю установочные скрипты слакваря на bash+dialog мне хочется рыдать. Кстати, кто ещё кроме меня пытался их читать? Незабываемая простыня, что-то в духе чтения configure, только есть подозрение что писали руками (надеюсь что это не так).