Complexity hides insecurity

[vitus_wagner]

Похоже, что желание создать нормальное Free Software, в смысле, такое, которое пользователь действительно свободен модифицировать, потому что способен понять, таки начинает у народа возникать.

Вот, например, Tomb, юзер-френдли инструмент для создания криптованных дисков, написанный на shell. Под лозунгом complexity hides insecurity.

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

Но в общем и целом подход вполне заслуживает внимания.

Comments

[otstavnov.com (from livejournal.com)]

Если заставить писать для всего, что есть в системе, привязки на языке X (в том смысле, в котором "утилита" является "привязкой" к шеллу), разумеется, ты можешь запустить исполнение чего угодно параллельно с односторонней передачей данных, если в X в принципе есть такие средства. Очевидная же вещь. (Менее очевидные и более смешные вещи будут при двусторонней передаче, на чем сценарные языки для GUI и ломаются).

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

[vitus_wagner]

Как только появляется слово "заставить", это сразу становится не про свободное что-то там.

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

[otstavnov.com (from livejournal.com)]

Я "заставить" имел в виду только в том смысле, в котором утилита может быть запущены родной конструкцией шелл. (пока Поттеринг rundll для GNU/Linux не придумал.) Мы просто не называем утилитой (ОС) то, что не может быть так запущено. Это логическое принуждение, а не введение какой-то несвободы.

По поводу второго: ты совершенно прав.

[vitus_wagner]

Идея заменить утилиты на что-то вроде модулей более строгого языка, была еще в Oberon-системе у Вирта. Не выстрелило. В принципе, подобным образом устроены всякие java-based среды, которые как раз выстрелили, в частности Android, ну и всякие WebLogic-и тоже. Только вот туда народ постоянно норовит напихать какие-нибудь более скриптовые языки вроде Clojure.
Потому что использовать для интеграции компонент язык уровня Java - довольно занудно. Недаром для Java понаписали такое количество IDE и прочих инструментов, пытаясь возложить на эти инструменты тот труд по автоматизации работы программиста, который должен выполнять язык.

Кстати, вот в python rundll есть. В смысле ctypes. Ну и в tcl (там оно по-моему ffiddl или как-то так называется).

Но вообще, похоже единственным серьезным кандидатом на роль "шелла для нелинейных (т.е. GUI) сред" является ECMAScript. Если только в нем заменить HTML DOM на что-нибудь более вменяемое...

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

[otstavnov.com (from livejournal.com)]

На сегодня я думаю, что ближайшим аналогом модели печатающего оператора и конвейеров в линейной среде для нелинейной среды может быть акторная (в том виде, до которого ее дотянули в эрланге или акке), а не недообъектная à la си++ и ява (остатки которой мне мерещатся в ява/ЭКМАскрипте, хотя я здесь могу просто ошибаться ввиду недоученности).

При этом я бы очень удивился синтаксису, обеспечивающему такую семантику и сопоставимому по фундаментальной простоте с шеллом. А некоторые моменты с безопасностью в акторной модели, действительно, решались бы (если бы акка не на JVM была реализована).

[ramendik]

Идея заменить утилиты на что-то вроде модулей более строгого языка, была еще в Oberon-системе у Вирта. Не выстрелило.

Аргумент от рынка, у тебя? Или я чего-то не понял?

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

[vitus_wagner]

Аргументы от рынка тоже имеют право на существование. Рынок - тоже клепка в бочке Либиха.