если считать началом становления советской ИТ-школы период 40-60 гг.

Я извиняюсь конечно, но и что там было ? Советская вычислительная техника того времени - это вооружение в войсках сегодня. Масса разных (конструктивно и программно) вычислительных машин. При отсутствии конкуренции распылять на все бабки было проблемой. В других странах конкуренция определила лидеров и в 70х мы их и скопировали. Но инноваций в отечественном ИТ не было никогда. Ну кроме Брусенцова и его «Сетуни»

Я извиняюсь конечно, но и что там было ?

Я тоже извиняюсь за вопрос, каким местом вы читаете? Я же русским по белому написал:

началом становления

На-ча-лом, понимаете?

А зачем использовать UTF-8?

а зачем использовать KOI8-R? Что тебе даст использование устаревших вещей и технологий? Только не надо рассказывать что в уникоде текст занимает больше месте, это правда глупо

Лишь для запуска продукции Oracle, которая не поддерживает FreeBSD из ревности.

запускать оракл под фряхой, как впрочем под любой неподдерживаемой системой, можно только just for fun, потому что применять такое в продакшене невозможно из за отсутствия поддержки или будучи не в своем уме

чаво?
за день управиться можно

ifconfig в бзд vs ifconfig/ip/iwconfig/tc в линуксе

Я нихрена не понял, каким боком это к стабильности. Ну, кроме того, что бсдёвый ifconfig многократно дописывался и расширялся, в отличие от линуксового набора, которые вполне себе стабильны и неизменны.

Oss->alsa в linux vs oss во freebsd

Ты немного сократил сказочку. Не oss->alsa vs oss, а oss->alsa vs один oss (цельнотянутый из линукса, к слову)->другой oss->третий oss->ишшо один oss->oss4 (который, лол, под линукс вышел на год раньше). Звуковую подсистему в бсде лихорадило больше 10 лет.

Метания с udev/hal и devd во freebsd

Поэтому в бсде то паника при вытыкании флешек, то «В auto_master добавлен новый тип сопоставления -media, позволяющий автоматизировать подключение внешних накопителей CD и USB» © 2016

Про rps — хорошая вещь, но актуальна скорее для плат без поддержки апаратных очередей.

аппаратные очереди обычно не работают с qinq, не работают с пппое фреймами и прочим не-ип траффиком, и т.п.

Но по тону разговора я уже понял, что вы не любите BSD.

в тех случаях что я с ней сталкивался, она оставила стойкое ощущение недоделанности и окаменелости, требующей для тривиальных вещей особо шершавого напильника и таинств с бубном вокруг sysctl. иначе - там все печально, к примеру у одного прова жалких 400 мбит жевалось тремя (!) пптп серверами с mpd. и меньше нельзя, потому то как только на сервере появляется более 300 абонов, по их словам, сервер просто вешается. сетевки - какой-то pci интел. после перевода всего этого бардака на линукс остался один-единственный тазик с загрузкой около 10% при включенном power management'е...

а уж об обновлении одного отдельно взятого пакета в бзде - вообще молчу. попробуйте на необновлявшейся 7.х как-нибудь обновить mpd к примеру :)

инновации были. хотя - да, весьма мало, т.к. КПД всех этих НИИ был весьма низким - в них люди преимущественно работу работали, а не разрабатывали продукт.

не годится она трафик молотить в промышленных объемах, когда трафика эдак 10+ гбит. надо лезть в sysctl, что-то там настраивать по обрывочным сведениям, сохраненным адептами для грядущих поколений, и не факт что при этом оно будет нормально работать. линь же - просто работает искаропки.

КПД всех этих НИИ был весьма низким - в них люди преимущественно работу работали, а не разрабатывали продукт.

В НИИ вообще-то разрабатываю концепции, способы достижений чего-то. Например, продукта. Если НИИ станут разрабатывать только коммерческий продукт, науке очень быстро наступят кранты. Конечный продукт может быть разработан в «дочке» при НИИ. Но это уже другая песня.

На днях в ЖЖ прочёл заметочку, что якобы Пень-3 - это обрезанный Эльбрус какой-то там. Я не очень-то верю в написанное, пока сам не увижу, но в качестве наглядного примера сойдёт: успех Интела в синтезе науки, производства и финансов; проблема Эльбруса в отсутствии этого синтеза. То есть имеется только наука, но денег нет, производственных площадок тоже нет. Или недостаточно, что, в принципе, неважно.

Проблема советских ИТ были ещё и в кадрах. Допустим, нужно 150 математиков, а страна могла дать только 100. И в постановщиках задач тоже.

strace это аналог truss.

Я уже долго ищу, наваял небольшой скрипт для dtrace чтобы перехватить один лишь exec() с параметрами, но срабатывает оно не всегда, видимо в момент обработки буффера dtrace, стек процесса уже испорчен. Так же если уменьшать буффер - видно что буффера могут молча теряться, а мне нужен 100% перехват.

Примером не поделишься, а то я что-то не припомню такого.

Во фре есть кошерный dtrace из соляры, насколько он там кошерный другой вопрос.

lvm-тормоза

fxd и не благодари!

Примером не поделишься, а то я что-то не припомню такого.

Да, конечно, вот мои костыли:

#!/usr/sbin/dtrace -C -s

#pragma D option quiet

proc:::exec-success
{
printf("\nEXECNAME: %s\n", execname);

this->isx64=(curproc->p_flag & P_LP64)!=0;
#define SELECT_64_86(x64, x86) (this->isx64 ? (x64) : (x86))
#define GET_POINTER(base, offset) (user_addr_t)SELECT_64_86(*(uint64_t*)((base)+sizeof(uint64_t)*(offset)), *(uint32_t*)((base)+sizeof(uint32_t)*(offset)))

this->ptrsize=SELECT_64_86(sizeof(uint64_t),sizeof(uint32_t));
this->argc=curproc->p_argc;

this->isClean=SELECT_64_86(1, (curproc->p_dtrace_argv==(uregs[R_SP],sizeof(uint32_t),sizeof(uint32_t))));
this->argv=(uint64_t)copyin(curproc->p_dtrace_argv,this->ptrsize*this->argc);

/* printf("%s with args:%d (%p, %p)\n",execname, this->argc, curproc->pdtraceargv, uregs\[R_SP\]); */

printf("EXEC: %s ", (0 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,0)) : "");
printf("%s ", (1 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,1)) : "");
printf("%s ", (2 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,2)) : "");
printf("%s ", (3 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,3)) : "");
printf("%s ", (4 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,4)) : "");
printf("%s ", (5 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,5)) : "");
printf("%s ", (6 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,6)) : "");
printf("%s ", (7 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,7)) : "");
printf("%s ", (8 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,8)) : "");
printf("%s ", (9 < this->argc && this->isClean) ? copyinstr(GET_POINTER(this->argv,9)) : "");
printf("\n");

#undef GET_POINTER
#undef SELECT_64_86
}

brkn и благодарить не за что

Ух ты прикольная штука этот dtrace :) На просторах интернета нашел такое:

dtrace -n 'proc:::exec-success { trace(curpsinfo->pr_psargs); }'

Почитал в документации про: curpsinfo->pr_psargs: initial command line arguments

Мне кажется это может быть оно. ;)

А на какой версии это было? У меня другой опыт был с 10Gb, как ни странно. :) На linux у нас и балансер свой, и патчи для снятия залипухи, итд... FreeBSD (9 или 10?) просто прокачала траффик. =)

Ну вот даже, пример. По умолчанию часто в affinity стоят ffff..ы. Или что-то похожее (например, соответствует какой то NUMA). Так вот в этом случае, все прерывания лягут на 1-й проц этой битовой маски. Грубо говоря, по умолчанию, в большинстве случаев ты получаешь все прерывания на 1 проц. В лучшем — на первые 8 процов (карты типа ixgbe и с новейшим ядром). На самом деле для админа это неочевидность — установив FFFF я неявно ожидаю, например, любой из этих процов. Но это не так. И главное, где документация? Ворох хаутушек (часто, противоречащих)?

Ну ладно, это все лирика. Надеюсь не все линуксоиды ненавидят бздю. :)

P.S. про irqbalance не надо — мы его изучили достаточно хорошо ;) Пользуйтесь http://birq.libcode.org

Ну в смысле, не совсем параметры вызова exec, но это аргументы процесса, который был вызван execом — по идее для твоих задач может подойти.

Ух ты прикольная штука этот dtrace :) На просторах интернета нашел такое:

Для рисования красивых графиков загрузки сервера - вообще отличная, сам юзаю) Но увы не для целей точного трейса.

trace -n 'proc:::exec-success { trace(curpsinfo->pr_psargs); }'

Туда я и лез изначально, но там было только имя бинари без параметров. Причем даже если бы были, места там под это зарезервировано крайне мало, что не удивительно, иначе бы эвенты весили бы много и он бы не был таким быстрым. Вот ради добычи параметров и пришлось поднапрячься.

Как там с DRM/KMS в случае Intel?

Еще раньше в Bsd был изощренный своп и ОММ киллер. А в линуксе «своп не нужен».

Думаю, ноги из С растут. Ну или Битрикса

KOI8-R совсем не устарела.

Только не надо рассказывать что в уникоде текст занимает больше месте, это правда глупо

Это если универсальность приоритетнее используемых ресурсов. А если наоборот? Если универсальность совсем не нужна, и совсем не хочется расставаться с каждым дополнительным байтом почём зря в т.ч. и потому, что это отражается на времени обработки данных? И это не говоря ещё о том, что однобайтные кодировки предсказуемы в отличие от юникода, в котором все символы занимают разное кол-во байт в диапазоне не менее чем 1-6, и это ещё не упоминая про модификаторы. Без предварительной обработки строк юникода с ними мало что можно сделать, а строки однобайтных кодировок уже готовы к обработке - можно спокойно гонять байты руками без необходимости привлечения разных странных неведомых юникодных функций и сущностей.

На виртуалке без свопа процессы часто вываливаются с killed: out of swap space. Здорово.

Воистину костыли, видать такая реализация, ибо в соляре

dtrace -n 'proc:::exec-success { printf("%s",curpsinfo->pr_psargs); }' 

Воистину костыли, видать такая реализация, ибо в соляре работает как задумано. Хмм, посмотрел на os x, тоже не кажет аргументов, странная петрушка.

Увы, и даже если бы работало как в соляре - это бы не спасло. Малый фиксированный запасенный размер под строку. А не фиксированный размер - это надо в хипе выделять строку в ядре, потом где-то освобождать, все сложно становится. И это только exec(), для многих других сисколов вообще ничего не предусмотрено.

извини конечно, но это какая то высосанная даже не из пальца причина

Для кого как. Зачем напрягаться и учить особенности работы с юникодом в Си, если можно не напрягаться и продолжать юзать KOI8-R? Тем более если среди используемых машин есть Raspberry Pi с объёмом RAM не более чем 0,5 гига, а в используемом PSF шрифте только 256 символов (в т.ч. из за ядерного жёсткого ограничения в 64 Кб на шрифт).

А что для вас причина? Будем терять память и скорость просто потому что можем? В том же far manager для никсов все переводится сначала в utf32, с такими строками хоть работать нормально можно, но это далеко не все проблемы решает. utf вообще нельзя обрабатывать без знания на каком языке эта строка, и подводных камней там еще хватает.

Поэтому в бсде то паника при вытыкании флешек

Вы недавно из схрона выползли? Не сильно там запаршивели? Из чистого любопытства: как сейчас смотреть на солнышко?

Давно капитаном работаешь?

utf вообще нельзя обрабатывать без знания на каком языке эта строка

Алло, болезный.

Здесь и сейчас в программах внешние интерфейсы - только utf8. Угу - обрабатывть внутри себя через wchar_t.

Здесь и сейчас в программах внешние интерфейсы - только utf8

Что? Вот внутри glibc юникод - это да. Все остальные неюникодные кодировки определены в нём как конкретные наборы юникодных символов. От этого никуда не деться, да. А вот между софтом можно передавать текст в любых кодировках. А там уже всё зависит от софта. Если софт работает только с wchar_t, то он unicode only, да. Но, основной серьёзный консольный софт читает $LANG и в «char *», а потому спокойно работает как с юникодом так и с неюникодными кодировками.

В смысле малый, что ты под этим подразумеваешь? Сколько выделишь под буфер, столько и будет, если не выделять, то будет динамический. Вот тебе выхлоп 'man ls'

dtrace -n 'proc:::exec-* { printf("%d %d %s",pid, ppid, curpsinfo->pr_psargs); }'
dtrace: description 'proc:::exec-* ' matched 2 probes
 CPU     ID                    FUNCTION:NAME
   0   5613         exec_common:exec-success 1331 1330 /usr/bin/preconv -D latin-1 /usr/share/man/man1/ls.1
   0   5613         exec_common:exec-success 1337 1329 sh -c /usr/bin/less -ins /tmp/mptQ8Qcd
   0   5613         exec_common:exec-success 1337 1329 /usr/bin/less -ins /tmp/mptQ8Qcd
   1   5613         exec_common:exec-success 1329 1155 man ls
   1   5613         exec_common:exec-success 1333 1330 geqn -T ascii
   2   5613         exec_common:exec-success 1332 1330 gtbl
   2   5613         exec_common:exec-success 1335 1330 /usr/bin/env LC_ALL=en_US.UTF-8 /usr/bin/grotty -c
   2   5613         exec_common:exec-success 1335 1330 /usr/bin/grotty -c
   3   5613         exec_common:exec-success 1330 1329 sh -c cd /usr/share/man; /usr/bin/preconv -D latin-1  '/usr/share/man/man1/ls.1
   3   5613         exec_common:exec-success 1334 1330 /usr/bin/env LC_ALL=en_US.UTF-8 /usr/bin/gtroff -E -T ascii -mandoc
   3   5613         exec_common:exec-success 1334 1330 /usr/bin/gtroff -E -T ascii -mandoc
   3   5613         exec_common:exec-success 1336 1329 sh -c trap '' 1 15; /usr/bin/mv -f /tmp/mptQ8Qcd /usr/share/man/cat1/ls.1 2> /d
   3   5613         exec_common:exec-success 1336 1329 /usr/bin/mv -f /tmp/mptQ8Qcd /usr/share/man/cat1/ls.1

В смысле малый, что ты под этим подразумеваешь? Сколько выделишь под буфер, столько и будет, если не выделять, то будет динамический. Вот тебе выхлоп 'man ls'

Попробуй вызов с >256 длинной параметра, или очень длинное имя бинари. Если прокатит - значит опять различия реализации.

До меня только сейчас дошло, что за ересь ты написал про потерю буферов и порчу стеков, подумай ещё раз.

А ты думаешь он затормозит все наблюдаемые процессы, пока прога юзающая dtrace API обрабатывает буфер? Такого кода просто нет, не успел сформировать\обработать - досвидания. dtrace нивкоем разе не будет тормозить наблюдаемые процессы, этим он и хорош в плане построения графиков загрузки. Покрайней мере на bsd так, как проверять я уже написал - уменьшай (-b) размер буфера пока не начнет проявляться потеря при загрузке. При очень большой загрузке или просто случайно очень редко - проявляется и без уменьшения.

Давно капитаном работаешь?

ждешь когда вакансия освободится?

Жду, когда ты читать научишься.

Разочаровала

Разочаровала 11-я ветка.

Выпиленный и поставленный из портов LLVM/Clang не смог собрать очередной образ мира из исходников, когда сломали libcrypt, devctl. Чё-то рассинхронизировалось внутри системы настолько, что впору переустановить из дистрибутива, чем разбираться что где порвало. Ядро и порты собираются/обновляются, а мир - Х.

Юникод-то по-умолчнию к консоли прикрутили?

Да. Теперь плюёмся в ee от гречки.

utf вообще нельзя обрабатывать без знания на каком языке эта строка

Алло, болезный.

Здесь и сейчас в программах внешние интерфейсы - только utf8. Угу - обрабатывть внутри себя через wchar_t.

Заквотили про необходимость знания, а отвечаете про интерфейсы и wchar_t. Про необходимость знания то согласны? Или вы все корректно отрендерите без него? Функцию интерфейса в студию, которая только utf8 и не std::wstring. Вот именно что внутри wchar_t, и если это не хранение интерфейсных строк полученных извне, а реально обработка - то почему бы не оптимизировать в однобайтную? Например за раздувание базы в 4 раза на ровном месте, когда это гарантированно не нужно по рукам давать надо.

Жду, когда ты читать научишься.

тогда выходит ты эпичный слоупок

Нет, выходит, что ты банальный дислект.

В НИИ вообще-то разрабатываю концепции, способы достижений чего-то. Например, продукта. Если НИИ станут разрабатывать только коммерческий продукт, науке очень быстро наступят кранты.

конкретно по части вычислительных машин - именно в НИИ разрабатывались вычислительные машины как продукт. но получалось хеновато.

Конечный продукт может быть разработан в «дочке» при НИИ.

то, что называется «телега впереди лошади». не НИИ, обслуживающий потребности конкретного предприятия, а предприятие, придумывающее куда продукт этого НИИ можно применить.

На днях в ЖЖ прочёл заметочку, что якобы Пень-3 - это обрезанный Эльбрус какой-то там.

ну эта байка давно ходили, только про первый пентиум, якобы один из разработчиков эльбруса туда ушел и сам создал архитектуру. печаль в том, прототипы пней первых существовали еще до того, как этот разработчик ушел. но разве это останавливает конспиролухов :)

потом, чуть позже, эта же байка ходила про итаник. типа архитектура похожа. и пофиг, что VLIW-у сто лет в обед, и единственное что в эльбрусе придумали нового - переменная длина команд, чтобы хоть как-то скрыть убогость идеи VLIW-а с большим кол-вом исполнительных блоков (вторую часть этой убогости - конструктивную, выливающуюся в смешные частоты - так и не осилили поправить, ибо не правится оно в принципе, хрен 100500 исполнительных устройств на высоких чатсотах синхронизируешь).

а пень-3 от пня-2 практически ничем архитектурно не отличался. разве что блок SSE отрастил...

Проблема советских ИТ были ещё и в кадрах. Допустим, нужно 150 математиков, а страна могла дать только 100

исследовательское подразделение Интела в Израиле - всего 8 тыс.человек. сколько там среднестатистический НИИ имел персонала?

А на какой версии это было?

это не у меня было, «счастливые обладатели» страдали.

Ну вот даже, пример. По умолчанию часто в affinity стоят ffff..ы. Или что-то похожее (например, соответствует какой то NUMA). Так вот в этом случае, все прерывания лягут на 1-й проц этой битовой маски.

все правильно, прерывание падает на первый свободный в данный момент проц. т.е. - первый по списку.

И главное, где документация? Ворох хаутушек (часто, противоречащих)?

это вы про бздю? вот возьмем ipfw - где на него документация? скажите, как правильно - сначала ipfw nat X config, а потом заворот в него трафика через ipfw add NNN nat X, или наоборот? я столкнулся с тем, что на какой-то 9.х (9.0 или 9.1) натиться все начинало только после реинициализации ipfw, как оказалось - в основной массе хаутушек кривой порядок инициализации ната, нужно было поменять порядок выполнения правил. и по-моему, нужно сначала было завернуть трафик в правило ната, а потом уже это правило конфигурить.

а главное - никаких ошибок при этом, просто не натится и все. забыли прилепить вывод ошибок, бывает...

про nat не могу оценить критику. до сих пор хватало хендбука и манов, когда придется настраивать, тогда вспомню этот разговор. :)

насчет все правильно про маски. не совсем правильно. например, можно выбирать случайный свободный проц (в котором еще есть свободные входы idt). или по принципу round-robin. тогда и без настройки аффинити и кривого irqbalance будет хоть как то работать.

забавно. открыл man ipfw. и прямым текстом прочитал то, о чем ты пишешь:

First redirect all the traffic to nat instance 123:

ipfw add nat 123 all from any to any

Then to configure nat instance ...

итд с примерами. схемами. и вообще — приятно читать.

я вообще человек доверчивый, но по моему, это повод лишний раз укрепить свое теплое мнение о bsd. ты как и большинство хейтеров воспринимаешь bsd мозгом линукса. так не работает. переключись если сможешь и тебе откроется удивительный новый мир. :)

JunOS?

Можно считать, что естественная смерть проекта наступила. :-(

Не забывай про GPL vs BSD! Ведь именно из-за такой лицензии FreeBSD здравствует в проприетарных проектах Apple, Sony и Juniper. Подчеркиваю иронию: Free в несвободных проектах.

Там вроде, чуть выше этого моего сообщения об этом начинали говорить. ИЧСХ какие-то старпёры, а новое поколение лорОвцев вряд ли будет понимать о чём идёт речь.

Какая ирония ? Это GNU/GPL запрещает закрывать код, то есть ограничивает в свободе.