https://slinkov.ru/openforum/vsluhforumID3/88926.html Спустя две недели с момента выхода ядра 3.8 (http://www.opennet.ru/opennews/art.shtml?num=36153), Линус Торвальдс закрыл окно приема изменений для ядра Linux 3.9 и выпустил (https://lkml.org/lkml/2013/3/3/147) первый кандидат в релизы (3.9-rc1). В анонсе отдельно отмечается интеграция в ядро поддержки двух новых архитктур - metag и arc, а также большое число улучшений, связанных с архитектурой ARM. Около 60% всех внесённых в ядро изменений касаются драйверов устройств (драйвера для GPU, сетевая подсистема, staging, pinctrl, звуковая подсистем и т.п.).<br><br><br><br>Наиболее заметные (http://www.phoronix.com/scan.php?page=news_item&px=MTMxNTA) изменения (https://lwn.net/Articles/539179/) в ядре 3.9:<br><br><br><br><br>- Ряд исправлений и улучшений в F2FS (http://www.opennet.ru/opennews/art.shtml?num=35667), достаточно быстрой файловой системе, ориентированной на Flash-накопители;<br><br>- Экспериментальная поддержка (http://www.opennet.ru/opennews/art.shtml?num=36011) RAID5/6 в файловой системе Btrfs, улучшение работы со снапшот https://slinkov.ru/openforum/vsluhforumID3/88926.html#102 Tue, 12 Mar 2013 14:55:55 GMT А я всё жду когда в новых ядрах исправят зависания про подкючении-отключении сетей.<br> https://slinkov.ru/openforum/vsluhforumID3/88926.html#101 Sat, 09 Mar 2013 09:35:58 GMT &gt;&gt; Зачем нам 2K?И Sparc Enterprice M8000 вполне подойдёт.По причине известных телодвижений <br>&gt; По причине известных телодвижений сдается мне что на спарки почти все забили. <br>&gt; А кто кроме собственно оракла должен суетиться с поддержкой оных? Кто-то <br>&gt; еще что-то выпускает массово на данном проце?<br><br>Эльбрус :)<br> https://slinkov.ru/openforum/vsluhforumID3/88926.html#100 Thu, 07 Mar 2013 09:15:09 GMT &gt; Тестовый сервер одного заказчика.<br>&gt; Подобный же сервер вполне по нагрузочной способности заменяет SF25k в полной набивке <br>&gt; (18 Uniboards USIV+ 1.8GHz/32Gb) под Oracle DB. И что характерно, при <br>&gt; значительно меньшей стоимости поддержки, меньшем энергопортеблении и габаритах.<br>&gt; Так что вполне себе замена Hi-END.<br><br>Как прикажете масштабировать RDBMS на таких тазиках?<br><br><br> https://slinkov.ru/openforum/vsluhforumID3/88926.html#99 Thu, 07 Mar 2013 07:55:46 GMT &gt; Не это не то, он имеет ввиду машины где много CPU на <br>&gt; одной плате, а не супер компьютеры, по сути кластера из плат <br>&gt; по 2 проца на плате.<br><br>Ну например вот:<br><br>--- cut ---<br># uname -a<br>Linux test.xxx.xxx.xx 2.6.32-279.22.1.el6.x86_64 #1 SMP Sun Jan 13 09:21:40 EST 2013 x86_64 x86_64 x86_64 GNU/Linux<br><br># free<br><br> total used free shared buffers cached<br>Mem: 264516352 12463988 252052364 0 302292 4585652<br>-/+ buffers/cache: 7576044 256940308<br>Swap: 52428792 0 52428792<br><br># cat /proc/cpuinfo&#124;grep ^processor&#124;wc -l<br>80<br><br># cat /proc/cpuinfo<br><br>processor : 0<br>vendor_id : GenuineIntel<br>cpu family : 6<br>model : 47<br>model name : Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz<br>stepping : 2<br>cpu MHz : 1064.000<br>cache size : 30720 KB<br>physical id : 0<br>siblings : 20<br>core id : 0<br>cpu cores : 10<br>apicid : 0<br>initial apicid : 0<br>fpu : yes<br>f https://slinkov.ru/openforum/vsluhforumID3/88926.html#98 Wed, 06 Mar 2013 15:08:09 GMT &gt;&gt; Кто-то еще что-то выпускает массово на данном проце?<br>&gt; Фуджики баловались.<br><br>Более того, M8000 это фуджица и есть.<br> https://slinkov.ru/openforum/vsluhforumID3/88926.html#97 Wed, 06 Mar 2013 15:07:28 GMT Слово "притащить" в отношении фуджи m8000 доставляет.<br>Он чуток больше тонны весит.<br> https://slinkov.ru/openforum/vsluhforumID3/88926.html#96 Wed, 06 Mar 2013 00:09:46 GMT Фэйспалм ты галимый, покажи фотку материнки Супердома иль ИВМ X- П-арх <br>Холодильники там слотовые, тот же блейсервак только провода короче. <br>Материнка на 32 проца, как раз высотой с этот холодильник. <br> https://slinkov.ru/openforum/vsluhforumID3/88926.html#95 Tue, 05 Mar 2013 20:32:06 GMT Ядро уже внутри очень хорошо разделено, но поставляется одним пакетом во избежание проблем, о которых я упоминал ранее.<br><br>GLIBC и GCC не нужны во время старта ядра, поэтому их включать нет смысла. Но например часть графической подсистемы включили, что позволяет изменить разрешение до запуска init.<br><br>&gt; будет ли ядро стандартизировано ?<br><br>API будет меняться всегда, если идет активное развитие. Другое дело, что без особой необходимости его лучше не ломать.<br><br>Дабы пользователи не ощущали проблем из-за изменений в API, API делится на две части, внутреннее и внешнее. Внешнее относительно стабильно и меняется редко, внутренне меняется часто, но нужно оно только драйверам. А так как драйвера идут вместе с ядром, то любое изменение в API происходит с одновременным изменением _всех_ драйверов которые использовали измененную часть API. Также можно не беспокоится об обратной совместимости - новые драйвера не могут быть использованы со старым ядром. Соответственно код драйверов получается гораздо компактней и проще, та https://slinkov.ru/openforum/vsluhforumID3/88926.html#94 Tue, 05 Mar 2013 19:13:23 GMT Не, не и ещё раз не ... не согласен. Потому что должен быть некий стандарт для функций с которыми оперируешь, если быть точным то это API. Если он стабилен и/или можно узнать какие функции вызывать можно и с какими аргументами (вспоминаю Спраустрапа) - то дорога в долгожители открыта настеж. Ежели нет - то ни о какой стандартизации и речи быть не может. Посему - раз не делают, значит не могут. Причины обсуждать не буду. И будут пухнуть архивы с ядрами как на дрожах. <br>А мне вот интересен другой вопрос - если Линус уйдет, будет ли ядро стандартизировано ? Будет ли раздел на собственно ядро, ФС и Сетку, Драйвера и Безопасность? Гениальность ядра не в том что оно пухнет от релиза к релизу, а в его открытости. А если что то большое работает как единое целое - то внутри есть что то поменьше, которое можно абстрагировать от большого, дать ему самостоятельность. <br>Мне так сдается, что это вопрос времени. Ведь ядро не таскает с собой библиотеку glibc и GCC, а вполне мог бы. И это было бы печально. <br>