Что бы Вы хотели изменить/улучшить/убрать/добавить в UNIX-like системах? Прежде всего, интересует мнение системных программистов, и по поводу действительно основополагающих вещей.
C Linux напрягает то, что он выполнен в виде модульного моноядро. В условиях глючной периферии и закрытых дров это пугает. Пример: на днях после выхода из standby не захотела подниматься сеть. При попытке rmmod'a дровины сетевухи все повисло нафиг.
С minix напрягает упорная вера разработчиков в то, что она posix-совместима. Однако туева хуча posix-софта там не собирается напрямую, тот же Apache - необходимо портировать. Что они собсно и сделали. Лучше б posix дописали нормально, а не "портировали". Допишут - и дофига софта будет собираться нормально.
Ну тогда меня напрягают ламеры виндовозные, у которых указательный палец к мышке прилип =) А так почти все устраивает. А что не устраивает, всегда можно доделать ручками...
в юникс всё нравится, не нравится другое: последнее время все наровят куда не лень пихать ксмл, например, ivman, или как там его... ну не место этому там.
красота простых текстовых файлов заключается в том, что:
1) легко читаются
2) легко генерируются наколеночными скриптами
моё любимое правило Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
боюсь, что придёт время, когда у iptables появится ксмлный конфиг, у dhcpd, bind и xorg - тоже.
кстати об ксмле. то, что свг формат - это клсм, я знал, но посмотреть на него не было особого желания...
то я на днях поставил инкскейп, нарисовал пару линий и открыл сохранёный файл. о ужас:
<path
style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-
width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M -762.85714,-176.94643 C -353.11075,-235.48163 288.61176,1082.8014
103.5072,712.59227 C 84.150206,673.87828 62.0848,638.12071
35.766782,607.41635 C 29.870258,600.53708 95.151487,618.66971
133.81213,657.33035 C 161.18177,684.69999 198.06703,700.75185
203.33519,742.8972 C 204.02998,748.45544 160.11662,698.56973
123.11627,643.06921 C 97.918527,605.27259 76.837657,563.84675
53.593209,528.98008 C 26.446702,488.26032 122.49136,555.30311
128.4642,559.285 C 176.72915,591.46164 152.66148,519.55241
181.94348,484.41401 C 188.40854,476.65594 255.72707,553.48377
197.98727,569.98086 C 192.32855,571.59763 136.40612,493.32722
196.20462,493.32722 C 283.89427,493.32722 247.22382,646.1781
183.72613,569.98086 C 149.6884,529.13558 210.02118,507.08026
235.42276,536.11065 C 239.79755,541.1104 230.24619,522.94674
-762.85714,-176.94643 z "
id="path2362" />
зачем нужен ксмл, если raw данные кладутся в _аттрибуты_???
было бы не плохо, если бы после конфигурирования ядра, какой-нидь анализатор пробежался по конфигу и сказал: пацан, оно не загрузицо - у тя райзер модулем собран.
Очень не хватает концепции "ACL на каждую сущность", как в VMS. Не хватает возможности зажать верхний предел на количество i/o операций на таком-то устройстве такому-то процессу, не хватает возможности зажать верхний предел количества процессорного времени, и много чего еще.
Да ксмл - это большая помойка. Очень уж много у него возможностей и неоднозначностей, как, например, данные в аттрибутах или теле ноды. Но документацию я в DocBook предпочитаю писать - для этого ксмл в самый раз. SVG - изврат.
> Очень не хватает концепции "ACL на каждую сущность", как в VMS. Не хватает возможности зажать верхний предел на количество i/o операций на таком-то устройстве такому-то процессу, не хватает возможности зажать верхний предел количества процессорного времени, и много чего еще.
Спасибо за единственный коммент по делу в этом треде :)
С *BSD не знаком, скажу о Линукс: мне не нравится его поведение в граничных ситуациях и ситуациях сбоев. Например, глючное USB-устройство может подвесить всю подсистему USB, а попытка отмонтировать сбоящий USB-диск дает mount в состоянии D (т.е. неубиваемый). Вообще сбои устройств обрабатываются отвратительно - такое впечатление, что драйверопейсатели вообще не учитывают, что устройства могут работать неправильно. То же относится и к ФС: буквально вчера встретил глюк NFS - работа с репозиторием Mercurial на NFS-шаре вешала процесс намертво (то самое состояние D), его нельзя было убить никаким сигналом (опции монтирования - hard,intr). Из той же серии - включенный по умолчанию overcommit и прелести OOM-киллера. Ну, про убогость resource limits уже сказано...
Всё это производит удручающее впечатление, особенно в комплекте с биением пяткой в грудь о "надежной операционной системе". Ага, надежной... до первой ошибки.
ну во первых микроядро, во вторых наконец то довести идеологию "все это файл" до конца, ввести общий системный протокол для IPC, стандартизировать везде VFS.
Из более юзерского, двухмерный shell, иксы (точнее более грамотное подобие) как сервер микроядра...
>ну во первых микроядро, во вторых наконец то довести идеологию "все это файл" до конца, ввести общий системный протокол для IPC, стандартизировать везде VFS.
Получится ... Plan9 :) Едо добавлю убрать tty как анахренизмЪ, убить деление устройств на block и character ну и самое вкусное - per-process namespaces. Да, ещё, наконец то угробить привелегированного пользователя с uid=0
>Очень не хватает концепции "ACL на каждую сущность", как в VMS. Не хватает возможности зажать верхний предел на количество i/o операций на таком-то устройстве такому-то процессу, не хватает возможности зажать верхний предел количества процессорного времени, и много чего еще.
С таким подходом ... получится Оффтопег NT number two...
Как пользователю хотелось бы подобия ALT+TAB винды (чтобы без запуска ещё одного X сервера и т.д., а сразу) для полноэкранных программ. Имхо для X11 это сделать реально.
Хотелось бы получить возможность перетаскивать запущенное приложение с одного Х терминала на другой. Повертел libdisplaymigration, но без особого энтузиазма и результата...
Лично у меня была необходимость узнать в Linux использованное пользовательское время процесса - то, которое выдаётся командой "time <command> |grep ^user", только его было необходимо узнавать в _процессе_ выполнения дочернего процесса, а не по завершении. Соответствующая информация существует в /proc/<PID>/stat, но с двумя ограничениями: 1. точность - 0.01 секунды, было бы лучше 0.001 или даже 0.000001 2. необходимость парсить текстовый файл, в результате скорость опроса была ограничена.
Особенно раздражало 2. В BSD, например, эта информация можут быть получена вызовом системного вызова sysctl. Вообще, было бы здорово, если бы всё, что есть в /sys и /proc могло бы быть получени системным вызовом, более быстрым, чем чтение и парсинг текстовых файлов.
>Хотелось бы получить возможность перетаскивать запущенное приложение с одного Х терминала на другой. Повертел libdisplaymigration, но без особого энтузиазма и результата...
Это скорее к X-Window System вообще, а не к Linux в частности :)