Doug Barton опубликовал (http://lists.freebsd.org/pipermail/freebsd-rc/2005-November/...) патч для подсистемы RC скриптов FreeBSD. Патч позволяет скриптам в каталогах /usr/local/etc/rc.d, /usr/X11R6/etc/rc.d выполняться в соответствии с rcorder и вносит некоторые другие изменения. Патч скорее всего будет включён в состав FreeBSD 6.1-RELEASE.Jason Evans в списке рассылки freebsd-current@ предложил (http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-...) новую реализацию malloc в libc. Как он сообщает, его реализация изначально разрабатывалась многонитевой для SMP систем.
Poul-Henning Kamp предложил (http://lists.freebsd.org/pipermail/freebsd-current/2005-Nove...) к тестированию патч, который по его словам значительно уменьшает время переключения контекста. На его машине тест дал 23% прирост скорости.
Michael Butler предложил (http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-N...) патч для ATA подсистемы, вносящий некоторые изменения и устраняющий ряд ошибок.
Wojciech A. Koszek предложил (http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-...) патч, позволяющий указать альтернативный конфигурационный файл для devd.
Патч (http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-...) от Nate Lawson, устраняющий проблемы с ACPI для некоторых ноутбуков, приводящие к зависанию системы при получении информации о батареях.
URL: http://lists.freebsd.org/pipermail/freebsd-rc/2005-November/...
Новость: http://www.opennet.me/opennews/art.shtml?num=6537
интересные-то интересные.вот только в следующий релиз войдут, скорее, два самых незначительных -- на rcorder (все-таки, на мой взгляд, у авторов rcNG в лице команды NetBSD был подход красивее -- там речь шла просто о том, чтоб не плодить сущности, кроме /etc/rc.d) и devd (большинству людей он как козе баян).
что malloc, что ata-raid патч (еще раз -- в новости это не оговорено -- именно ata-raid, а не ata) -- их надо тестировать. учитывая, что 6.1 не за горами, вряд ли они успеют в нее. но, если я верно понимаю, в шестой ветке мы их увидим.
а вот с phk'шным патчем пока неясно ничего, судя по рассылке, стемящихся его потестить пока не очень много.
>>> - на rcorder (все-таки, на мой взгляд, у авторов rcNG в лице команды NetBSD был подход красивее -- там речь шла просто о том, чтоб не плодить сущности, кроме /etc/rc.d)А на мой взгляд у FreeBSD более красивое продолжение идеи. Весь дополнительный софт должен быть в /usr/local.
> Весь дополнительный софт должен быть в /usr/local.Сам софт (binary executable, скрипты, файлы с данными и т.д.) имеет смысл поместить в /usr/local; я бы перенёс туда же /var/db/pkg. Но вот настройки (в т.ч. стартовые скрипты, определяющие, будет ли запускаться та или иная программа) надо помещать в /etc. А уж данные (типа сайтов Апача или кэши Сквида) надо выносить из /usr в /var, /tmp или /home.
Доказательство: представим себе, что раздел /usr смонтирован read-only, что заметно усиливает безопасность. Или что раздел /usr рас'share'н по NFS для нескольких машин (тоже read-only).
>А на мой взгляд у FreeBSD более красивое продолжение идеи. Весь дополнительный
>софт должен быть в /usr/local.софт должен быть в /bin и /sbin и как максимум - /usr/bin, /usr/sbin
и контролироваццо пектным менеджером.
Иначе начинаеццо бардак. "в системе один sendmail, в портах - другой". Или про gcc то же самое.
При наличии базовой (несносимой) системы происходит перерасход места и общее повышениние беспорядка в системе.
Ну нафига мне gcc-2.95 в базе и портовый 3.4.4 - оба сразу, если я давно перешел на 3.4.4?? И притом, что этот 2.95 никак документированно и корректно не вынести. Бардак....
>софт должен быть в /bin и /sbin и как максимум - /usr/bin,Такая организация называется помойкой (извините, свалкой язык не поворачивается назвать).
Одна из наиболее симпатичных в BSD вещей, это /usr/local.
> Иначе начинаеццо бардак. "в системе один sendmail, в портах - другой"
Вам никто не мешает отключить установку sendmail при сборке системы, тогда sendmail будет только один, в /usr/local
On further investigation, I'd failed to notice (doh!) that rdp->toggle
isn't preserved between requests and that one unobvious side-effect of
the original code is that it does slightly better than my patched
version .. <sigh>. I'll rework this and see if I can make it do better,