Complexity hides insecurity

[vitus_wagner]

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

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

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

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

Comments

[vitus_wagner]

Так С и Паскаль это языки того уровня. на которых ядра и надо писать.

Кстати, заметим что stdcall конвенция в API Windows осталась с тех времен, когда ядро Windows было написано на Паскале. Потом его где-то по-моему к 3.0 переписали на С, но неродная конвенция вызовов API осталась до сих пор.

Ядро MacOS по-моему тоже было изначально на Pascal-е.

То есть соревнование между C и Pascal на этом поприще было честным и поначалу Pascal лидировал.

Опять же, существует тренд по выносу драйверов в Userspace. Я уже как-то писал, что "гони микроядро в дверь, оно влезет в окно". Не стал Линус в начале 90-х делать микроядро, погнался за тактами, так что мы сейчас имеем?
libusb, tun/tap, fuse. Файловые системы можно в userspace, драйвера usb-устройств можно, сетевые драйвера можно. Во FreeBSD кстати, нет ядерного драйвера Bluetooth PAN. А нафига, если оно прекрасно через tap работает.

[mc6312.livejournal.com]

> fuse
...с адовыми тормозами...

[ramendik]

Это да, но тогда сделать бы и прослойку для доступа любой к графической карте? Чтобы проприетарные драйверы могли не требовать встраивания в ядро и тем самым не создавать лицензионных проблем (userspace Линус считает настолько отделённым, что GPL не действует). Опять же их тогда можно будет рестартовать при глюках, заплатив лишь перерисовыванием экрана или в худшем случае падением X-сервера, а не системы.

А так - да, хорошо, в Паскале, каким он был в критический момент, не хватало требуемых для ядра средств. Но почему тогда в юзерспейсе пошли косяком монстры? C++/COM - вообще без комментариев, он меня и отпугнул от программирования. В параллель развивался Unix, но там был то Си в хвост и в гриву (а совсем не только в ядро), то абсолютно непредсказуемый и сложный на ровном месте shell, то потом perl, поощряющий obfuscated code чуть ли не нарочно.

Из всех этих нечитаемых наборов я могу понять, пожалуй, почему занял прочное место regexp. Там за write only мы получаем "быстро сделать со строкой ровно то, что надо, при условии что везде правильно попали". Но почему ТАК выглядит всё остальное?

[allter]

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

[allter]

P.S. А прослойку для доступа к графической карте уже пишут - wayland. Хотя, по-моему, и X11+DRI достаточно для этой цели.

[vitus_wagner]

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

[ramendik]

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