PS пинг на localhost не проверял, в воскресенье сделаю все что Вы порекомендуете (в позитивном направлении))) ).
i Уведомление от модератора serzh-z Детали - https://bugzilla.kernel.org/show_bug.cgi?id=12309
Модератор: /dev/random
i Уведомление от модератора serzh-z Детали - https://bugzilla.kernel.org/show_bug.cgi?id=12309
и да - с каких пор наличие в ванили говорит о том что проект заслуживает внимания? о_О03 April 2008. Initial release.
megabaks писал(а): ↑24.09.2010 03:37в ядро много чего не включают
сколько существовал до включения в ядро compcache например?
в 2007-ом он уже был!
а bfq первое упоминание (на старом сайте) только 2008-ойи да - с каких пор наличие в ванили говорит о том что проект заслуживает внимания? о_О03 April 2008. Initial release.
( ) писал(а):Slo-Tech
Who is Linux Kernel developer you really respect? Also, don't you think that Linux needs some serious reogranisation in handling security incidents and security development in general (see many regressions in the code). Something like Microsoft's SDL maybe... What do you think about SDL anyway.
Brad Spengler
I have a lot of respect for Microsoft's attention to security, given how large of a company they are and how many people their software affects. It's a whole different security ball-game when you have the huge binary software eco-system of Windows, implementing security features while maintaining application compatibility. It's easy to gloss over how difficult of a job that is.
Linux definitely needs some central leadership/organization for security. The developers are fixing issues they know are security relevant, but they don't notify anyone (including vendors). Select vendors get notification of certain security issues, leaving smaller vendors/distros out. Upstream basically does their best to make the job of vendors difficult, and each vendor has to duplicate effort because nothing is organized. The official policy of "a bug is just a bug" hurts all Linux users. That said, some notable improvements were the addition of sparse, various hardening to functions that were constant attack vectors (getsockopt, write(), copy_*_user). They're often overly concerned about performance at the expense of security; but the couple cycles they lost on checking for negative lengths in write() for instance has saved them countless times.
Я ни разу за последние годы не наблюдал этой проблемы. Возникла она после последней замены винта для /home. Вывод о том, что нужно выяснять, чем этот винт так плох, напрашивается сам...
Таки взялся за винт, наконец: забекапил всё и переразметил с началом раздела в 2048 секторе (до этого выравнивал иначе, но, как оказалось, ошибся немного). Ну просто очень сильно полегчало. Ранее всё зависало на 30 секунд в тот момент, когда даже, скажем, RSSOwl начинал обновлять новости и переписывать свою базу. Сейчас же - всё сносно работает при "dd if=/dev/zero of=test bs=1M count=5000".
serzh-z писал(а): ↑26.09.2010 16:31megabaks
В продолжении темы: если контроллер и накопитель поддерживают NCQ, то включать для них умный программный планировщик В/В не имеет смысла. В моём случае - правильное выравнивание раздела на накопителе с 4 Кб секторами и переключение на NOOP решило почти все проблемы (небольшие подвисания, при синтетических тестах по нагрузке на диск, всё же остались, но они несущественны) с зависаниями GUI, с которыми мучался с конца весны. =)
Вах! Как категорично... Ну да ладно, не буду разубеждать.
У меня нет свопа. Приплыли.