| 1.3, AlexAT (ok), 18:24, 21/10/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– |
 >>> Добавление в tmpfs поддержки дисковых квот для защиты от переполнения /tmp, /dev/shm, /run/user/$USER отдельным пользователем.
Да.
>>> Использование 64-разрядных PID-идентификаторов по умолчанию.
Да!
>>> Вариант файловой системы в стиле unionfs или возможность слияния нескольких точек монтирования (union mount).
ДА!!!
Остальное под вопросом. В частности "управление подкачкой" и "уведомление о завершении любого процесса" - потенциальные дыры.
| | |
| |
| |
| 3.17, СуперАноним (?), 21:54, 21/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>>> Использование 64-разрядных PID-идентификаторов по умолчанию.
>Да!
Нахрена? Неужели на одной машине может быть одновременно более 4 млрд. процессов? Даже на кластере трудно представить столько.
| | |
| |
| 4.19, AlexAT (ok), 21:57, 21/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>>>> Использование 64-разрядных PID-идентификаторов по умолчанию.
>>Да!
> Нахрена? Неужели на одной машине может быть одновременно более 4 млрд. процессов?
> Даже на кластере трудно представить столько.
Нет, но неповторяемость идентификаторов при частой смене тысяч процессов типа pppd очень удобна.
| | |
|
|
|
| 1.12, Аноним (-), 20:04, 21/10/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– | |
>Уведомление, когда завершается произвольный процесс, не только дочерний
Моя мечта - утилита killwait, которая бы не просто отправляла сигнал процессу, но и дожидалась его завершения.
| | |
| |
| 2.16, Аноним (-), 21:49, 21/10/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –2 +/– | |
>Моя мечта - утилита killwait, которая бы не просто отправляла сигнал процессу, но и дожидалась его завершения.
#!/bin/bash
#killwait
kill -9 $1
sleep 1
| | |
| |
| |
| |
| 5.25, Аноним (-), 00:10, 22/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– | |
> Может попробовать помониторить /proc?
Может просто стоит признать, что
>Уведомление, когда завершается произвольный процесс, не только дочерний.
нужная штука?
| | |
|
| |
| |
| 6.35, Аноним0 (?), 02:10, 23/10/2011 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
боюсь плюсануть, т.к много текста про бсд, совсем неуместного. а вот то что сигналы надо обрабатывать, а не херней страдать с килами и слипами (которые выглядят крайне глупо) хочу подчеркнуть.
| | |
| |
| 7.41, Аноним (-), 06:00, 23/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Все там уместно. Тема как озаглавлена? Список возможностей, которых не хватает Линуксу. Вот и было сказано, чего ему не хватает. Ну и что в нем неправильно - сюда же.
| | |
|
| 6.42, AlexAT (ok), 14:09, 23/10/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– | |
>>> Все нормальные юниксы передают их через стек. И только в Linux почему-то
Потому, что доступ к регистрам быстрее доступа в память. А регистров на современных процах полно. Особенно на не-x86. И на x86_64. И только "нормальные юниксы" этого не учитывают, каждый вызов жертвуя пропускной способностью кеша и памяти.
>>> Заставляя приложение все время сохранять и восстанавливать регистры и терять кучу циклов на это
Зачем? Компилятор настолько туп, что не может оптимизировать доступ к регистрам?
>>> и увеличивая вероятность возникновения ошибок.
Можно пояснить, чем разница в расположении данных "увеличивает вероятность"?
>>> Хотя регистры все равно в стек сохраняются. Зачем этот ДОС-овский маразм нужен?
Есть хитрость - в ряде случаев можно ничего не сохранять.
| | |
|
|
|
|
|
| |
| 2.54, Аноним (-), 13:53, 24/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
aufs как раз является "вариантом файловой системы в стиле unionfs". Но в ваниле таких ФС нет и не будет, Торвальдс в свое время высказался достаточно жестко.
| | |
|
| 1.21, Андрей (??), 23:31, 21/10/2011 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– |
"В механизм нотификации fanotify..."
Да, и монтирование - это изменение! Плиз, добавьте! Каких только "выстрелить себе в ноге" не наёдёшь, чтобы мониторить такую вещь как монтирование!
| | |
| |
| 2.33, Аноним (-), 15:02, 22/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> 7. Хотя бы примитивный искусственные интеллект с предсказаниями для SMP-балансировщика,
> чтоб после 500 раз форков апача он уже понимал,
> что каждый 50-й надо сразу форкать
> на новый процессор/ядро, а не ждать пока ядро загрузиться
> до 101%
И тут внезапно шиндошс, глюки, маты админов, что что-то работает не так, как ожидалось и тп.
| | |
| 2.36, Аноним (-), 03:34, 23/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>Мечты.
>0. Верните /dev/XOR
> ...
Pavlinux, ты реально крут. Очень надеюсь что пожелания уже успел отправить девелоперам. Я уверен, что если и kernel-хакеры не реализуют все или какую-то часть, то ваши пожелания, как минимум, получать широкую огласку, что увиличивает (потенциально) щансы на улучшения. Ну а если у вас есть напористость - то вполне можете завести дискуссию и остаивать необходимые пунткы. То что вы понаписали сильно может улучшить ядро. Это очень хорошо.
| | |
|
| |
| |
| |
| 4.43, Аноним (-), 14:32, 23/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Как просто открывался ларчик. Кстати, если 4 гектар мозгов не хватает на какую-то сборку, я бы всерьез подумал о качестве всего мемори менеджмента в ядре. Как-то фиговато-вато-этово это выглядит. Чай, не Оракл собирать.
| | |
| |
| 5.57, Aquarius (ok), 06:05, 25/10/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 > Как просто открывался ларчик. Кстати, если 4 гектар мозгов не хватает на
> какую-то сборку, я бы всерьез подумал о качестве всего мемори менеджмента
> в ядре. Как-то фиговато-вато-этово это выглядит. Чай, не Оракл собирать.
а почитать внимательнее если?
речь идет о tmpfs, то есть об использовании памяти в качестве контейнера для того, что принято называть виртуальным диском
| | |
|
|
| 3.47, Аноним (-), 23:55, 23/10/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– | |
> ZRAM?
Это пожатый рамдиск, а не тмпфс. Хотя при использовании зрам в случае, если не будет хватать памяти, то данные tmpfs будут улетать на него и, соответственно, сжиматься.
| | |
|
|
|
