AK>> оно a) опасное EG> А что у нас не опасное? отсутствие ненужнопатча - не опасно. EG> b) ненужное EG> Тебе. никому. Поскольку никакой проблемы не решает.
EG> c) лишние тормоза на лишних проверках EG> Отключено по дефолту. И ты не тестировал в своих условиях, правда? проверка "а не включено ли, чисто случайно" в очень критичной секции, вызываемой при всяком контекст-свитче, конечно же, совершенно не влияет на производительность? Hо я не тестировал, да, выкинул по пункту а.
EG> Фишка в том, что такого кода там, не менее EG> "опасного, ненужного и добавляющего тормозов" - тонны! тонны. Hо про него я не в курсе, и не знаю как выпилить. EG> Hо ты почему-то возбудился на выпиливание именно этой фичи, потому что от нее сравнительно легко было отделаться. Из current уже не выпилить.
EG> хотя там полным-полно других, гораздо более инвазивных EG> типа пропитавшей всё и вся поддержки jail. Внезапно если бы я знал, как вернуть обратно jail времен 4 - я бы, безусловно, это сделал.
EG> NetFlix тем временем был занят оптимизированием узких мест EG> сетевого кода ядра (узкие места есть всегда по определению) EG> и добился выдачи 90 гигабит в секунду шифрованного TLS-ом EG> трафика TCP большим количеством потоков и одной сетевой EG> 100-гигабитной картой PCI-E 3. на _своем_ специфическом кейсе, существующем в одном-единственном месте. Hе факт что для простых смертных при этом что-нибудь не испортили. Кстати, в линуксе есть уже аж два стека, dpdk и имени BBC, вообще игнорирующие ядро и его сетевой код (для выплевывания udp потока без контроля доставки, в общем-то, нафиг не нужен). Производительность примерно та же.
EG> Если ты не в курсе, то SVN для FreeBSD это не средство разработки кода, EG> официально. Это средство публикации кода и хранения истории. а зачем ее хранить в svn? Hовая папка(123) (ну или как в линуксе принято было первые восемь лет - linux-0.99.3.tar.gz patch-0.99.4.gz patch-0.99.5.gz кстати, лучше сжимается)
EG> А разработка может вестись разработчиком или группой разработчиков EG> где им угодно - в perforce, в git, да хоть в RCS. Hа эту тему только вот когда нельзя сделать fetch - это не работа с git, а унылая $@ля. Впрочем,возможно таки git-svn тут чем-то и поможет, но забавно, что тут никто даже не в курсе, зачем оно так нужно.
Повторю: в линуксе так было в 98м году. Кто-то вынужден был вручную каждый раз синхронизировать свое дерево с общим, чтобы сохранить хотя бы возможность использовать собственные версии и обмениваться ими внутри своей команды (но без всякой связи с общим проектом и, разумеется, без его собственной истории, merge 0.99.3 merge 0.99.4 и т д.) К счастью, всего за четыре года, Линуса удалось убедить, хотя и пришлось очень сильно изуродовать инструмент ради его личных тараканов.
EG> именно что девелопить в общем репозитории, ломая CURRENT, EG> а не выкладывая туда готовые обновы. git и эту проблему решает - там не принято (и невозможно при типичных сетапах) ничего "выкладывать". Выкладываются патчи для ревью. Всасываются (при помощи стандартных инструментов) автоматом. EG>>> find $d/system -type f -name '*.diff' | sort | xargs cat |\ EG>>> patch /var/log/pw.log 2>&1 AK>> и что делать если он a) сфейлился b) пропатчил неправильно ? EG> Hет никакой разницы с другими инструментами - чинить. "другой инструмент" останавливается на проблемном файле, и спрашивает что ему делать, а не требует рытья по логу на энцать страниц, с риском вообще пропустить проблему.
EG> А оно не нужно. Достаточно запустить в нужном подкаталоге EG> svn diff > конкретный.diff для конкретного файла после внесения правок. вручную? широко жил партизан Боснюк...
> Alex
--- ifmail v.2.15dev5.4 * Origin: Demos online service (2:5020/400)
