Доступен новый значительный релиз операционной системы NetBSD 8.0 (http://www.netbsd.org/releases/formal-8/NetBSD-8.0.html), в котором реализована очередная порция новых возможностей. Для загрузки подготовлены (ftp://iso.netbsd.org/pub/NetBSD/iso/8.0/) установочные образы размером 730 Мб. Релиз NetBSD 8.0 официально доступен в сборках для 58 системных архитектур (http://www.netbsd.org/ports/) и 16 различных семейств CPU.
Отдельно выделены 8 первично поддерживаемых портов, составляющих ядро стратегии развития NetBSD: amd64, i386, evbarm, evbmips, evbppc, hpcarm, sparc64 и xen. 49 портов, связанных с такими CPU, как alpha, hppa, m68010, m68k, sh3, sparc и vax, отнесены ко второй категории, т.е. ещё поддерживаются, но уже потеряли актуальность или не имеют достаточного числа заинтересованных в их развитии разработчиков. Один порт (acorn26) включён в третью категорию, в которой размещены неработоспособные порты, претендующие на удаление, если не найдётся заинтересованных в их разработке энтузиастов.Ключевые улучшения (http://www.netbsd.org/releases/formal-8/NetBSD-8.0.html) NetBSD 8.0:
- Переработанный USB-стек с поддержкой USB3;
- Встроенная в ядро система микширования звука;
- Обеспечение (https://www.opennet.dev/opennews/art.shtml?num=46073) повторяемых сборок, позволяющих убедиться, что распространяемые бинарные файлы собраны из предоставляемых исходных текстов и не содержат скрытых изменений;
- Задействование по умолчанию механизма защиты памяти W^X (Write XOR Execute или PaX MPROTECT), суть которого в том, что страницы памяти процесса не могут быть одновременно доступны на запись и исполнение. Таким образом, код может быть исполнен только после запрещения записи, а запись в страницу памяти возможна только после запрета исполнения. Механизм W^X помогает защитить приложения в пространстве пользователя от типовых атак, осуществляемых через переполнение буфера, в том числе от переполнений стека (записанный за пределы буфера код не может быть исполнен). Защита активирована для ELF-файлов для архитектур i386, amd64, evbarm, landisk и pmax;
- На архитектурах i386, amd64, evbarm, landisk, pmax и sparc64 включена по умолчанию рандомизация адресного пространства (ASLR) при сборке;
- На архитектурах i386, amd64, arm, m68k, mips, sh3 и sparc64 по умолчанию исполняемые файлы собраны в режиме MKPIE (position independent executables);
- Добавлен драйвер с реализацией сокетов для шин CAN;
- Добавлена утилита ipsecif для настройки VPN;
- Часть сетевого стека избавлена от глобальной блокировки и помечена как MP-safe. В ядро добавлена опция NET_MPSAFE;
- Повышена стабильность и производительность подсистемы журналирования мета-данных (WAPBL);
- Добавлена защита от атак Meltdown, Spectre (v2, v4) и LazyFP (https://www.opennet.dev/opennews/art.shtml?num=48775);- Добавлена поддержка набора инструкций SMAP (Supervisor Mode Access Prevention), который позволяет блокировать доступ к данным в пространстве пользователя из привилегированного кода, выполняемого на уровне ядра;
- Добавлен загрузчик для систем с UEFI;
- Добавлены новые драйверы: nvme (SSD-накопители), iwm (Intel Wireless AC7260, AC7265, AC3160), ixg (X540, X550), ixv (Intel 10G Ethernet), bta2dpd (Bluetooth Advanced Audio Distribution Profile);- Обновлены версии сторонних компонентов GCC 5.5 с поддержкой Address Sanitizer и Undefined Behavior Sanitizer,
GDB 7.12,
GNU binutils 2.27,
Clang/LLVM 3.8.1,
OpenSSH 7.6,
OpenSSL 1.0.2k,
mdocml 1.14.1,
acpica 20170303,
ntp 4.2.8p11-o,
dhcpcd 7.0.3,
Lua 5.3.4.
URL: http://www.netbsd.org/changes/#netbsd80
Новость: https://www.opennet.dev/opennews/art.shtml?num=49003
В фряху что-то из этого перекачует?
Кочует обычно в обратную сторону
Вы заблуждаетесь, процесс абсолютно двунаправленный.
FreeBSD/OpenBSD/NetBSD - слишком много. И кто знает сколько еще *BSD существует во Вселенной. Какой же выбрать?
Спроси Apple, Nintendo, juniper или Sony.
>Спроси AppleOS X/Darwin, XNU, исторически микроядро от проекта Utah Math, уже сильно переделанное, только куски от BSD, также сильно перелопаченные, очень многие библиотеки те же самые что и в дистрибутивах Linux.
Тут сказать, что по объему кода раз в 10 больше использовано кусков Linux "операционной системы".Но тут другой вопрос, что такого что _копию_ кода используют в гражданских коммерческих целях, особенно когда это _прямо и ясно_ оговорено публичной офертой при публикации этого кода?
На самом деле, MacOS постоянно тащит код из FreeBSD. И kernel и userland.
>На самом деле, MacOS постоянно тащит код из FreeBSD. И kernel и userland.Для самых сообразительных повторю:
---
Но тут другой вопрос, что такого что _копию_ кода используют в гражданских коммерческих целях, особенно когда это _прямо и ясно_ оговорено публичной офертой при публикации этого кода?
---
>Для самых сообразительных повторю:Что такого что компании использует в гражданских коммерческих целях копии кода FreeBSD, и при этом важно надувают щёки позиционируя себя как главные лица в IT индустрии?
>Что такого что компании использует в гражданских коммерческих целях копии кода FreeBSD,
> и при этом важно надувают щёки позиционируя себя как главные лица в IT индустрии?Вторая часть предложения есть твоя пафосная фантазия.
Люди работают, ведут дело, создают продукты, на основании ранее созданных знаний.
Тебе это, судя по тексту, неведомо.
>>Для самых сообразительных повторю:
> Что такого что компании использует в гражданских коммерческих целях копии кода FreeBSD,
> и при этом важно надувают щёки позиционируя себя как главные лица в IT индустрии?В смысле, что такого что гугл много лет пользовался кастомными версиями пингвина для раб. станций, но открыть их решил только недавно? Или его же "inhouse" FS и ядро с разными добавками для всего парка гугло-серверов, ведь гугл так - мелкая лавочка?
Или вы о мобильной версии пингвина, с логотипом железного ведра c глазами, там тоже речь о паре фирмочек с их копеечными прибылями?
А ведь еще есть какая-то мелкая лавочка Tesla, вот уже 5 лет открывающая наработки в ядро - тоже ведь ничего не зарабатывают.
>В смысле, что такого что гугл много лет пользовался кастомными версиями пингвина для раб. станций, но открыть их решил только недавно? Или его же "inhouse" FS и ядро с разными добавками для всего парка гугло-серверов, ведь гугл так - мелкая лавочка?
>Или вы о мобильной версии пингвина, с логотипом железного ведра c глазами, там тоже речь о паре фирмочек с их копеечными прибылями?
>А ведь еще есть какая-то мелкая лавочка Tesla, вот уже 5 лет открывающая наработки в ядро - тоже ведь ничего не зарабатывают.Ага понял. Как инноваторы они - никто. Как айтишники они - никто. Мы закроем глаза на то что они без зазрения совести копируют чужой код. Они же богатые компании, им можно.
>на то что они без зазрения совести копируют чужой код.---
Разрешается повторное распространение и использование [алгоритмов] как в виде исходного текста так и в двоичной форме, с модификациями или без, при соблюдении следующих условий:
---Как тебя не замучила совесть при установке Linux дистрибутива?
Люди же работали, им необходимо есть, оплачивать счета, оплачивать свою жизнь, обеспечивать детей.А ты нахаляву, чужой код, и наверняка ни цента не перевел разработчикам?
> Ага понял. Как инноваторы они - никто. Как айтишники они - никто.
> Мы закроем глаза на то что они без зазрения совести копируют
> чужой код. Они же богатые компании, им можно.А вот и неожиданно массово в ста(н)е перепончатых встречающаяся способность нудеть по поводу соринок в чужих глазах, при этом усерднейше не обращая внимания на свои …
> OS X/Darwin, XNU, исторически микроядро от проекта Utah Math, уже сильно переделанное, только куски от BSD, также сильно перелопаченные, очень многие библиотеки те же самые что и в дистрибутивах Linux.И тем не менее, Apple регулярно шлёт фидбеки и патчи в BSD.
>И тем не менее, Вася из 6 "б" тоже регулярно шлёт фидбеки и патчи в BSD.Исправил. А если серъезно, то компании лучше всего умеют засорять чужой код.
Чтобы не страдать, предлагаю покопаться в сорной куче Linux ;)
Часть usb-стека вроде позаимствованна для обновления стека фряхи. Насколько большая - не в курсе (если сильно интересно - пырьтесь в сорцы, ищите по NetBSD). Остальное или свое, или же сайд-разработчики подсистем сами добавляют (как например недавний мерж Xen PVHv2 Roger Pau Monne из Citrix)
> Переработанный USB-стек с поддержкой USB3Ну и ну.
Дополню мысль> Добавлен загрузчик для систем с UEFI;
>Дополню мысль
>> Добавлен загрузчик для систем с UEFI;Надо понимать, каждый анонимус лично написал 3 по загрузчика с UEFI и 4 стека USB3 для 2 операционных систем.
Ваши слова звучат примерно так: Как вы смеете критиковать жигули! Соберите сначала свой двигатель, а потом уже смейте мнение высказывать!
Разобрать и собрать двагатель жигулей не представляет большой сложности.
> Ваши слова звучат примерно так: Как вы смеете критиковать жигули! Соберите сначала
> свой двигатель, а потом уже смейте мнение высказывать!Во-первых: "тут нету X! Фу!" на критику как-то не тянет. Учитывая непричастность анонов к реализации юсб-стека или UEFI в <favorite OS>, выглядит не умнее натужного бахвальства ябловодов.
Во-вторых, если уж продолжать дурацкие аналогии, то:
Да, правильно! Даешь наконец равноправие для всех на технических ресурсах!
Доколе на этих пережитках темных нетикеттовских веков мнение тех, кто и капот своей бибики толком не открывал, будет менее ценным, чем мнение автомехаников или каких-то там инжинеров?! Так же нельзя, ведь так неправильно! Это дискриминация!
>Ваши слова звучат примерно так: Как вы смеете критиковать жигули!Так это не критика, ибо содержит ноль анализа.
Это банальное хамство из подворотни.
У вас какая-то удивительная способность писать глупости и вовлекать в ваш поток глупостей стороннюю аудиторию. Сами привели аналогию с жигулями, сами же ее и жуете. Нет, аналогия с жигулями тут как бы вообще не подходит. Скорее уж, если сравнивать по качеству кода и уровню инженерных решений, жигуль тут Linux. С UEFI же просто все, видите ли, сейчас фичу пилят если она кому-то нужна (т.е. реальный пользователь NetBSD хочет реальный UEFI-загрузчик), реально понадобилась - добавили (и да, с точки зрения правильного распределения небольшой девелопмент-тимы проекта это гораздо эффективней, запиливания-выпиливания devfs в Linux). Ну и второе, вопрос, а с чего вы взяли что к лично вашим желаниям должны прислушиваться разработчики NetBSD, если вы систему не используете, фичареквесты не делаете, т.е. не имеете к системе никакого отношения. Вот наверное сначала как бы начните принимать в нем участие, а потом высказывайте свое безусловно важное мнение самим разрабам.
"Если вам не понравился наш продукт, верните его, и мы вернем вам деньги, которые вы за него заплатили"
Меня также впечатлила поддержка экстентов в ext4.
58 арх систем!
О
Ф
И
Г
Е
Т
Ь
Не архитектур, а целевых систем -- посмотрите наконец http://www.netbsd.org/ports/#ports-tier2 своими глазами :)
уйди с этого сайта
Какие есть варианты обработки OOM в NetBSD?
Ровно один вариант - malloc ноль возвращает, когда память в системе закончилась ^:)
Очень православно, очень по-бздуновски! а почему не завезли оверкоммит?
Чтоб не завозить ООМ? :-)
Отсутствие ООМ не предотвращает фризы.
И?
с netbsd вы знаете все 3 программы, которые работают в userspace как свои пять пальцев. На этапе разработки хватит и кода ошибки malloc
> Очень православно, очень по-бздуновски! а почему не завезли оверкоммит?То ли дело праволапчатое забивание на ту же проверку результата malloc, как в тех же г(н)омолибах?
Помню, в багтикете ушлые любители костылей и подпорочек аргументировали тем, что из-за овекамита результат всегда будет позитивным (и упадет оно только когда решит действительно задействовать эту память), а значит на проверку можно забить.
Л-Логика!
>Помню, в багтикете ушлые любители костылей и подпорочек аргументировали тем, что из-за овекамита результат всегда будет позитивным (и упадет оно только когда решит действительно задействовать эту память), а значит на проверку можно забить.+много.
причем процесс грохается по bus сигналу от ядра, и не делает корректную остановку и/или обработку ситуации.
например berkeley db после такого через одну можно удалять, ибо невосстановимо.
и так далее."повбивав бы"
> а значит на проверку можно забить.Линукс ваш новый стандарт, а не какой-то там замшелый posix!
Вот бы в линуксе так.
если что - в линуксе ТАК было - примерно во времена libc4, традиционная реализация malloc через sbrk.
Но в какой-то момент все же было замечено, что это немножк неэффективно на железе новее 80го года выпуска, где памяти не "128K слов". (если что, free и, вероятно, прочие bsd долго и с мучениями копировали эту затею. По дороге поломав к чертям setrlimit - чинили лет десять, по-моему, еще и не дочинили. Линуксный, понятно, никто и не чинил, works as intended)
overcommit пришел чуть позже, когда оказалось, что по другому просто не получается - из-за чудесатого buffer cache и особенностей proactive свопа, никто на самом деле никогда и не знает, сколько у системы доступно памяти (тем более - сколько будет в момент, когда память все же понадобится).
Эту какашку *bsd копировать не стали, попутно поимев некоторый геморрой с портированием выращенных в линуксе якобы-переносимых конструкций (посмотрите на ужас ужасный по имени devel/libublio в портах)
>если что - в линуксе ТАК было - примерно во времена libc4, традиционная реализация malloc через sbrk.
>Но в какой-то момент все же было замечено, что это немножк неэффективно на железе новее 80го года выпуска, где памяти не "128K слов". (если что, free и, вероятно, прочие bsd долго и с мучениями копировали эту затею.Занятно написано, но хрень полная и безграмотная.
NetBSD UVM, 1998
http://chuck.cranor.org/p/diss.pdfFreeBSD 1.1.5, 1994 man 3 brk
https://www.freebsd.org/cgi/man.cgi?query=brk&apropos=0&sekt...
--
NAME
brk, sbrk -- change data segment size
DESCRIPTION
The brk and sbrk functions are historical curiosities left over from ear-
lier days before the advent of virtual memory management.FreeBSD malloc (3) revisited, Poul-Henning Kamp, 1998
http://phk.freebsd.dk/pubs/malloc.pdf
Там есть ссылки на публикации
Где и в каком состоянии был Linux kernel вместе с malloc(9) в то время, могу подсказать.Например, многопоточность в glibc malloc (ptmalloc2) была реализована только в 2006, то есть лет на 8 позже NetBSD/FreeBSD
https://sploitfun.wordpress.com/2015/02/10/understanding-gli.../
History: ptmalloc2 was forked from dlmalloc. After fork, threading support was added to it and got released in 2006. After its official release, ptmalloc2 got integrated into glibc source code. Once its integration, code changes were made directly to glibc malloc source code itself. Hence there could be lot of changes between ptmalloc2 and glibc’s malloc implementation.
> где и в каком состоянии был Linux kernel вместе с malloc(9) в то время, могу подсказать.да там же и был, идея mmap'ать /dev/zero посетила всех, видимо, примерно из общего источника.
98й - это уже давно libc5, с mmap и sigsegv'ами (и с неработающим rlimit)
И да, расскажите-ка, в каком году у вас его починили?
>И да, расскажите-ка, в каком году у вас его починили?Ты общаешься с группой лиц? =)
Тогда группа лиц тебе эксклюзивно советует: Google can help youЕй лениво писать тому кто упоpото не намерен читать тексты по ссылкам.
в тексте по ссылкам нет ни слова о поломанном setrlimit. Если ты ничего не понял - примени к себе свой собственный совет, или не строй из себя эксперта.
>в тексте по ссылкам нет ни слова о поломанном setrlimit.Правильно, потому что никто не "ломал". Шла разработка.
Только у пафосных скаутов кто-то что-то ломает, бросает, делиться-не делиться, и прочее.
Ты что-то вычитал, и
>или не строй из себя эксперта.
строишь из себя пафосного "эксперта", "слоника-в-домене"
На деле несешь сущий бред.
>группа лиц тебе эксклюзивно советует: Google can help you
В отличие от линуксового «у нас ООМ, надо срочно у кого-нибудь отнять память, чтобы продолжить работать», BSD просто реагируют на ситуацию по POSIX-стандарту (а точнее по C), возвращая нулевой указатель и как вариант кидая системный сигнал, при этом обработка ООМ проще, потому что система заранее имеет свой объём личной памяти, который используется для работы и которым она делиться не будет; т.е. чтобы не было аппаратного ООМ, достаточно просто по старинке не отдавать всю память.
>как вариант кидая системный сигналКакой именно?
Так раньше было, сейчас в нетке для этого используется UVM.
http://netbsd.net/docs/kernel/uvm.html
> Так раньше было, сейчас в нетке для этого используется UVM.там нет overcommit, в смысле линукса - то есть oom killer не нужен.
Но есть ньюанс, да - в результате sigsegv прилетает тогда, когда в линуксе программа спокойно бы отработала. Причем необязательно он прилетит самому прожорливому - он прилетит тому, кто сожрал "интеллигентский кусок". null же вернется только если попросить памяти заведомо больше, чем ее в принципе могло бы быть при полном отсутствии других процессов.
>Но есть ньюанс, да - в результате sigsegv прилетает тогда, когда в линуксе программа спокойно бы отработала.Че? "спокойно бы отработала"? Мальчик, ты откуда?
Ты гарантируешь что финансовые данные при это будут достоверными, а менеджер баз данных не грохнется и не превратит данные о твоей зарплате в дерьмо?
Результат malloc(3) надо проверять. И вписывать обработку ситуации malloc() == 0
А то ужк выросли чудаки, которые не напрягают свой ценный мозг на наличие ресурсов в системе.А по некоторым стандартам во встраиваемых системах malloc() вообше не используют. Ни явно, ни опосредовано. Ибо нехрен.
еще один "немальчик", не в теме совсем, но лезущий со своим ценным мнением?> Результат malloc(3) надо проверять.
хоть обпроверяйся - там в современных системах (и, оказывается, даже netbsd - современная) - никогда не будет 0.
А памяти при этом может и не оказаться, вот сюрприз-то, да?данные будут достоверными - пока будут вообще. А потом прилетит sigbus или sigsegv - в принципе, можешь даже попытаться их обработать, и корректно завершиться (других вариантов нет). Если твой "менеджер таз банных" при этом просто грохается - ну поздравляю, пора менять софт 80х годов.
>> Результат malloc(3) надо проверять.
> хоть обпроверяйся - там в современных системах (и, оказывается, даже netbsd -
> современная) - никогда не будет 0.
> А памяти при этом может и не оказаться, вот сюрприз-то, да?* * *
Эх любо, братцы анонимы, любо,
Любо, братцы, анонимом быть,
Пускать ветры прям в лужу,
О всяки пруфах не тужить!
* * *# rctl -h
user:restricted:vmemoryuse:deny=1024M/process
user:restricted:memoryuse:deny=512M/process
user:restricted:swapuse:deny=1024M% uname -rs;whoami && cat test.c && ./test|tail
FreeBSD 11.2-STABLE
restricted
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>#define MB (1024*1024)
#define PSIZE 4096
int main(void){
size_t sum = 0;
char *ptr;
for (size_t i=0;;i++) {
if ((ptr = malloc(MB)) == NULL) {
perror("Err:");
exit(EXIT_FAILURE);
}
for (size_t j = 0;j < (MB-PSIZE-1); j += PSIZE) ptr[j] = 0;
sum += MB;
printf("allocated: %zu MB\n", sum/MB);
}
return EXIT_SUCCESS;
}Err:: Cannot allocate memory
allocated: 497 MB
allocated: 498 MB
allocated: 499 MB
allocated: 500 MB
allocated: 501 MB
allocated: 502 MB
allocated: 503 MB
allocated: 504 MB
allocated: 505 MB
allocated: 506 MB
> О всяки пруфах не тужить!и главное - нихрена не понимать, о чем был разговор.
тогда в качестве "пруфа" сойдет любой бред.
>> О всяки пруфах не тужить!
> и главное - нихрена не понимать, о чем был разговор.
> тогда в качестве "пруфа" сойдет любой бред.Главное, пафосно заявить, что никто ничего ни#рена не понимает и вообще, все есть бред (и не забыть проставить плюсики с минусиками).
Звиняйте, но с тем же пафосом и апломбом кое-кто совсем недавно рассказывал о преимуществах null-terminated строк и об эффективности работы с ним современных (и не очень) процессоров.
https://www.opennet.dev/openforum/vsluhforumID3/114847.html#88
Так что в недопонимание сказанного вами по причине непризнанной гениальности вас - верится мало.
А вот в "особое видение художника" пополам с "не знал, а потом и забыл" – вполне.
>данные будут достоверными - пока будут вообще.Бля... ладно, разжую.
#define A_SIZE 1024
uint *dst;if ((dst = malloc(A_SIZE) > 0) {
bcopy(src, dst, A_SIZE);
} else {
/* handler */
}
Если malloc() всегда не ноль, но памяти так и не выделено, то где херакнется алгоритм?Или как вызвать прерывание в хост систему из гостевой по случаю спекулятивного malloc(), "слушай, дорогой, ты меня поспи совсэм, пока память в натуре не появиться"?
И где у разработчика есть шанс построить более надежный алгоритм?
> Бля... ладно, разжую.зачем ты мне это разжевываешь? Разжевывай разработчикам всех операционных систем середины 90х, они ж тyпые, они ж не знали этой великой тайны.
> И где у разработчика есть шанс построить более надежный алгоритм?
там где он знает, как устроена система и подстелил соломки. man 2 signal ?
ну да, не очень красивый получается код, но, вообще-то, если честно - память в современных системах кончается совсем не потому, что ее забили с помощью bcopy ;-)
И чаше всего проблема даже вовсе не в том, что ее на самом деле не хватило.
>зачем ты мне это разжевываешь?что показать твою великую компетентность
>если честно
а если соврать как обычно?
>память в современных системах кончается совсем не потому, что ее забили с помощью bcopy
а как? магией?
# size /bin/sh
text data bss dec hex filename
153647 1748 9560 164955 0x2845b /bin/shвыясни что такое bss, data, heap, stack, как они используются
в вычислительной машине, в частно при вызове функций
и больше не ипи моск =)
> что показать твою великую компетентностьпока что ты показываешь только свою великую некомпетентность.
>>память в современных системах кончается совсем не потому, что ее забили с помощью bcopy
> а как? магией?да, малыш, для тебя это магия.
пока ты дpoчишь на свои "великие знания" на уровне устаревших на двадцать лет букварей, реальное устройство памяти в современных системах прошло мимо тебя.
> реальное устройство памяти в современных системахА можно кратко или ссылку? Я-то тоже ещё по Мюллеру да современникам читал, даже не по профессору.
удали интернет себе
Чеусов, поздравляю! :)
А ему еще не надоело?
Насколько помню, он сейчас с линуксом на ноутбуке живёт. Что там у него с бздёй случилось - не знаю.
уйди, ты всех задолбал своей рожей
Почему так много весит?
NetBSD-7.1.2-amd64.iso (376MB)
NetBSD-8.0---amd64.iso (716MB)
Прогресс не стоит на месте. В 2 раза больше полезных программ.
ftp> ls
150 Accepted data connection
-rw-r--r-- 1 101 7777 104 Jul 18 00:15 MD5
-rw-r--r-- 1 101 7777 302 Jul 18 00:15 SHA512
-r--r--r-- 1 101 7777 229742592 Jul 18 00:15 boot-com.iso
-r--r--r-- 1 101 7777 229742592 Jul 18 00:15 boot.iso
226-Options: -l
226 4 matches total
ftp> pwd
Remote directory: /.m/mirrors1e/ftp.netbsd.org/pub/NetBSD/NetBSD-8.0/amd64/installation/cdrom
ftp>
> USB-стек с поддержкой USB3
> Добавлен загрузчик для систем с UEFI
> Добавлены новые драйверы: nvme (SSD-накопители)
> [ntfs@brix ~]$ date +%Y
> 2018
Дурак! USB3 там 100 лет был, это ПЕРЕРАБОТАННЫЙ usb3-стек.
Ну по тексту звучит так, что usb 3.0 добавился только в переработанном стеке. Если он был до этого, то зачем об этом упоминать в release notes?
Есть ли смысл использовать NetBSD, если есть Linux и FreeBSD?
Конечно же нет.Смысл всегда в конечной цели: посмотреть кинцо, побегать в игори, похостить сайты с поддержками новомодных CMS. И желательно за недорого (а время потраченное на установку и настройку тоже стоит денег).
И желательно все это на современном оборудовании.
Раздался одинокий и ленивый выстрел с господствующей высоты врага. Пуля со вкусом чвакала воздухом на своём неспешном пути к дренажной системе канализации повстанцев.
> Раздался одинокий и ленивый выстрел с господствующей высоты врага. Пуля со вкусом чвакала воздухом на своём неспешном пути к дренажной системе канализации повстанцев.Поделись грибочками
малолетки
> Конечно же нет.
> Смысл всегда в конечной цели: посмотреть кинцо, побегать в игори, похостить сайты
> с поддержками новомодных CMS. И желательно за недорого (а время потраченное
> на установку и настройку тоже стоит денег).И какова же конечная цель затраченного окошкофилом (аноним помнит все!) времени на высказывание сего, несомненно для кого-то очень-очень ценного мнения?
В любой непонятной ситуации - устанавливай!
есть ли смысл играть в футбол, если есть шашки?
А есть вообще смысл?
>>Добавлен драйвер с реализацией сокетов для шин CAN;Вот это не понял совсем. CAN в ядре зачем?
Because we CAN
>Вот это не понял совсем. CAN в ядре зачем?Вот представь себе real time обработку прерываний по сообщению/ошибке от контроллера CAN, на 78 соседей по шине, и не в ядре.
У меня другой вопрос, что с этим делать далее. Буду посмотреть.
В ядре RT ? Я возможно крайне старый.
> В ядре RT ? Я возможно крайне старый.Значит я старее. Ибо помню такую разную хрень.
Да и бо большому счету, ядро всегда real time, ибо живет по таймеру, вопрос в планировании-scheduler'е.Ибо как иначе обработать несчастные 2-3 CAN mailbox и ошибки передачи по шине?
Есть варианты? =)
Нетка используется на встройках, станках и машинках — а там CAN де-факто стадарт.
странно, зачем она там используется, разве что у того кто её туда поставил мозги застыли на уровне конца девяностых. Во всяком случае это не её целевая группа, посмотрите на список поддерживаемых архитектур - железо конечно разное, но практически всё по типу PC и workstations, соответственно и приоритеты у разработчиков. А то что CAN прикрутили - так оно и персоналкам иногда нужно бывает, даже и без реалтайма, элементарно для мониторинга.
> но практически всё по типу PC и workstationsмодули на x86 часто используются в индустриальных контроллерных сборках.
понятно, x86 GPU во встраиваемых системах, без магии, для тебя это будет удар, но это так.
> разве что у того кто её туда поставил мозги застыли на уровне конца девяностых.
да, именно на опеннет отмечаются специалисты по массовым индустриальным квантовым компьютерам.
погугли индустриальные предложение, много узнаешь о тех у кого "мозги застыли на уровне конца девяностых"
>Вот это не понял совсем. CAN в ядре зачем?https://www.kernel.org/doc/Documentation/networking/can.txt
Тут доходчиво объясняют.
Там вроде уже ReactOS 4.9 вышла..