Общаемся обо всём!

[RXL]

https://club.shelek.ru/viewart.php?id=181

[Алексей++]

Aether, в Qt окна любой формы делаются, а , значит, винапи это тоже сумеет

[Aether]

Спасибо, пытаюсь разобраться.

[Aether]

У RXL скоро ДР? Можно будет поздравлять? Или рано?

[RXL]

Поздравлялка тут: https://forum.shelek.ru/index.php/topic,6817.0.html
Что-то давно я никого не поздравлял.

[Aether]

Занимательное видео посмотрел, как делают радиолампы в условиях мастерской:
https://www.youtube.com/watch?v=EzyXMEpq4qw

[Aether]

Недавно задумался над словами господина Dale по поводу диапазона экспоненты у чисел с плавающей запятой, действительно, сам диапазон довольно велик, и 8 бит у чисел одинарной точности уже покрывают массу задач. Но главное не в этом, я задумался: "А что если нужно расширить диапазон?" Так вот, не обязательно конструировать полностью программное FPU. Вынос лишь старшей части "дополнительной" экспоненты в отдельное слово позволяет использовать всё тот же аппаратный FPU, но с программными оговорками. Небольшие наброски дали представление, что скорость при таком подходе не пропадает напрочь. В общем, всё больше убеждаюсь, что наличие даже слабого FPU в составе МП замечательно.

[RXL]

Либо что есть и быстро, либо все, что хочу и медленно. Все сразу нет.
Для чисел произвольной точности есть готовые библиотеки.

[Aether]

У нас была ещё одна тема, которую я как-то между делом пропустил. В ходе рассуждений был выдвинут тезис, что отказ от аппаратных прерываний означает невозможность управления чем-либо с синхронизацией. Я тут немного не соглашусь. Я считаю, что развитие механизма DMA способно преодолеть этот момент. Суть в том, что не обязательно прерывать поток, чтобы обработать поступившие от устройства данные, лучше подождать конец кванта потока, и только тогда принять решение нужно ли что-то обрабатывать. При малых квантах и буферах у устройств задержки будут не больше, чем в классическом подходе. Зато не нужны ни порты, ни прерывания всех видов, кроме одного - переключения задач. Таким образом, МП невозможно задёргать частыми вызовами, нет необходимости расстановки приоритетов, и много чего ещё. А может я и не прав?

[Qulac]

Aether, вроде есть процы для железок без механизма прерываний.

[Aether]

Я тему просто приподнимаю, мало ли у кого что будет интересного рассказать по этому поводу.

[RXL]

Заменить прерывания могут очереди: очередь поступающих данных и очередь событий. Планировщик проверяет очередь событий и вызывает соответствующие драйвера, которые обрабатывают свои очереди данных. Лаг зависит от частоты переключений и для ряда устройств не подойдет. Скажем, для дисковых устройств - норм, для потоковых обработок - норм, для транспортной сети - может быть плохо.

[Aether]

... , для транспортной сети - может быть плохо.

Почему?

Я думаю, самая большая нагрузка идёт на видеоканал:
1366 х 768 х 24 бит х 60 Гц = 1510686720 бит/с = 1,5 Гбит/с

По сравнению с сетью на 100 Мбит/с.

Собственно, многое решает и режим кооперации за ресурс между потоками. Лаг будет всегда, вопрос лишь в его размере. Я специально отделяю МП от МК, в котором прерывания обязательны для задач реального времени.

[RXL]

Это поток. Медленная реакция плоха для коммутации.

[Aether]

Это поток. Медленная реакция плоха для коммутации.

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

Если использовать прерывание при приёме пакета, то всё равно придётся ждать обработку из рабочего потока. А если обрабатывать в обработчике прерывания, то это может оказаться долго и часть пакетов будет ждать где-то в дороге или буфере.

Не знаю, в обоих вариантах само время обработки останется неизменным - полезная работа, вопрос лишь в зерне квантования и накладных расходах. Потери на переключение контекста при приходящем когда угодно прерывании может внести весомую долю.

[Sla]

На момент выполнения основного потока прерывания можно отключать

Но если данные прерывания критичны, и их нельзя проигнорировать, то они ставятся в очередь (как ее организовать уже другой вопрос, вплоть до отдельного девайса)

Кроме того, есть прерывания аварийные, Например датчик помехи перед режущим инструментом etc

[Aether]

На момент выполнения основного потока прерывания можно отключать

Тут суть в альтернативном решении и его праве на жизнь.

Кроме того, есть прерывания аварийные, Например датчик помехи перед режущим инструментом etc

Станок обладает инерцией, поэтому, даже если электроника среагирует вовремя, он проедет в зависимости от конструкции от десяток миллиметра до нескольких сантиметров. В основном то, что я видел в качестве страховки, было сделано как независимый механизм.
В металлорежущих станках применяются фрикционные муфты и гидравлические демпферы на осях. При ударе масло из демпфера сбрасывается через предохранительный клапан, и за это время удар смягчается, но заготовке и инструменту обычно кранты. Зато остаётся цел станок.
В столярном производстве на циркулярных пилах применено другое решение: когда палец случайно касается диска замыкается цепь и специальный одноразовый механизм вбрасывает в диск алюминиевую вставку. Вставке капец, диску тоже и иногда шпинделю - гнётся его опора. А вот палец у рабочего остаётся на месте.

[Sla]

В любом случае это прерывание основного потока. Это то что я хотел сказать.

[Aether]

Что еще надо?

Нормальная поддержка графики на уровне ядра, а не в виде посредников типа Xorg.

Кстати, столкнулся с проблемами при установке Linux на свой ноут: Arch со своим базовым ядром вообще работать не захотел, Ubuntu при установке работал стабильно, а вот потом начались дикие вылеты. На виртуальной машине в Windows работает стабильно, правда без графики. Конечно, я далеко не эксперт, но в этом как раз проблема Linux - приходится разбираться больше, чем большинству пользователей других распространённых ОС.

[RXL]

Сам Убунту не ставил, только пользовался. И на ноуте, и на десктопе. Стабильность отменная.
Один момент: если в обновлении прилетят новые графические драйвера, после лучше перезагрузиться.

[Finch]

Aether, А зачем на серверах графика? Так что, я например не вижу смысла ее заводить в ядро. Раньше был принцип. Программа должна выполнять только одно действие. Но должна выполнять его на отлично. Швейцарские армейские ножи не приветсвются. У них много функционала, но нифига не удобно им пользоваться.

[RXL]

Убунта - десктопный дистрибутив. Для серверов подходит Debian.

[Aether]

Aether, А зачем на серверах графика?

А вот как раз таки наоборот и получается: в попытке сделать универсальное решение пожертвовали удобством. Так или иначе, а пользователь общается с ПК через HMI, современным языком, и это обычно связка из монитора и манипуляторов - клавиатура, мышь. Отсюда следует, что графику придётся поддерживать всем, и Linux не исключение с его framebuffer-ом, просто с уклоном в текстовый режим, однако, зачем остановились на достигнутом и устроили этот геморрой?

Если Вы хотите использовать удалённый доступ к ПК, то лучше для этого применять отдельную программу, хотя я уже давно не сомневаюсь - серверы нужно обслуживать не по сети, а очно: с индивидуальным HMI или на основе переключателей.

Если есть желание сэкономить на энергопотреблении видеосистемы, то стоит подумать над тем, как распознать отключение монитора и вовремя отключить обработку кадров.

[darkelf]

Прошу прощения, что вмешиваюсь, но у некоторых серверов, которые установлены в стойки, может не быть, ни монитора, ни клавиатуры и мышки, вообще. И, думаю, таких серверов скорее всего даже и большинство. Для таких серверов вполне хватает обычного удалённого доступа по ssh и обычного текстового редактора, без красивой графики соответственно. Что, впрочем, не отменяет возможности, правда в последнее время весьма поломанной в современных графических средах типа GNOME или KDE, запустить графическое приложение на том-же сервере, с выводом окна на машину клиента (это является штатной функциональностью системы X Window) - и для этого приложения тоже не надо видеокарты, а нужна только сетевая карта, через которую команды на отрисовку примитивов будут отправлены на машину клиента.

По своему опыту могу сказать, что бывают сервера, к которому не приходится приближаться ближе, чем на 700 километров.

[Aether]

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

В моём городе проживает 142 тыс. человек, и как Вы понимаете у каждого из них как минимум 1 телефон, а у некоторых есть ПК, приставка и так далее. Также имеется несколько тысяч юридических лиц, которые содержат ПК для персонала и серверы бухгалтерии и прочей частной документации не публичного доступа. В силу ряда задач по обеспечению безопасности администраторы их контролируют очно, а не сидя у себя дома или в кафе. Таким образом, в городе имеется около 300 тыс. компьютеров потребителей плюс служебные серверы коммуникационных организаций, банков, которых на два или даже три порядка численно меньше, и которые могут быть организованы иначе. Вопрос стоит в подходе и предполагаемом сегменте. Когда-то вычислительное время было дорого, и сама мысль о ПК была сомнительной, поэтому расчёт был сделан на многопользовательский доступ, естественно удалённый. Однако, в современном виде большая часть вычислительных устройств индивидуальны в своём использовании.

Стратегия в Linux, к сожалению, сдерживает его же распространение, и это так и будет в районе до десятка процентов, которые держатся, скорее всего на антимонопольном законодательстве ряда стран.

Я хочу отметить, что мне не нужна красивая графика, окошки. Мне нужен стандартизированный подход к медиа выходу без привлечения сторонних средств. Предположим, в ядре будет модуль, нужен будет текстовый режим - ставим модуль (драйвер) и пользуемся, нужен графический режим - ставим и пользуемся, нужен семисегментный индикатор - пишем и пользуемся. Текущая реализация графики - это:
а) Затычка, опирающаяся на видеорежимы BIOS.
б) Затычка в виде fb.
в) Медленная и чужеродная Xorg.
В Windows мне тоже подход не по нраву, разделение GDI и DirectX тоже имеет те же корни, кроме того DX реализован так, что пользоваться им без дополнительных средств программирования накладно.

По своему опыту могу сказать, что бывают сервера, к которому не приходится приближаться ближе, чем на 700 километров.

Да, есть много решений для разных задач. Просто есть несоответствие стратегии свободного ПО и то, во что превращается реализация. Система обрастает дополнениями, но не ассимилирует их, поэтому усложняется и становится непрозрачной, а значит потенциально опасной, неконтролируемой.

И мне и Вам реализация ряда идей могла бы дать определённый комфорт.

[darkelf]

Я хочу отметить, что мне не нужна красивая графика, окошки. Мне нужен стандартизированный подход к медиа выходу без привлечения сторонних средств. Предположим, в ядре будет модуль, нужен будет текстовый режим - ставим модуль (драйвер) и пользуемся, нужен графический режим - ставим и пользуемся, нужен семисегментный индикатор - пишем и пользуемся. Текущая реализация графики - это:
а) Затычка, опирающаяся на видеорежимы BIOS.
б) Затычка в виде fb.
в) Медленная и чужеродная Xorg.
В Windows мне тоже подход не по нраву, разделение GDI и DirectX тоже имеет те же корни, кроме того DX реализован так, что пользоваться им без дополнительных средств программирования накладно.

Текущая реализация графики, тем не менее, не помешала завоевать сегмент смартфонов, где фирма Google сама реализовала такой графический интерфейс, который хотела. Так-же не мешает сейчас писать Wayland, который в перспективе должен заменить собой X Window System.

Касательно медленной и чужеродной Xorg - не уверен. Вот с упором на то, что X-ы медленные, попытались разработать новый Wayland. Недавно провели benchmark-и и поняли, что это новое, как-то не быстрее старого. По моему мнению у Wayland есть единственный плюс - т.к. он новый, то он меньше по размеру и там нет многих исторически накопившихся рудиментов, но с другой стороны - у него нет и определённых возможностей, которые исторически были и есть в X.

Сама архитектура графической подсистемы в виде X Window сложилась из-за того, что она должна была работать в разных ОС - до сих пор ещё живы системы семейства BSD - OpenBSD, FreeBSD, NetBSD, и даже появились новые - DragonFlyBSD, а до того было ещё куча других - HP-UX, Solaris, AIX, IRIX - и на всех них она работала. Даже, если не ошибаюсь, был её порт под QNX4 и до сих пор есть порт под Windows и OS X (в виде XQuartz). Соответственно от ядра ОС требовался минимум и каждая из групп разработчиков занималась своим делом:
- системные программисты писали ядра ОС (каждый в своей организации и зачастую без обмена наработками), которые предоставляли необходимый минимум не зависящий от железа;
- разработчики графики - свою графическую подсистему с внешним API;
- программисты от разработчиков аппаратного обеспечения (тоже каждый в своей организации) - часть графической подсистемы работающей с непосредственно железом (и не так, как сейчас - в виде драйверов, а в виде отдельных реализаций X-сервера, к которому была прикомпонована часть от разработчиков графики обеспечивающая внешний унифицированный интерфейс для прикладных приложений).

Стратегия в Linux, к сожалению, сдерживает его же распространение, и это так и будет в районе до десятка процентов, которые держатся, скорее всего на антимонопольном законодательстве ряда стран.

Мне кажется, что тут дело в другом. Был Window - дружелюбный к пользователю. У него был недостаток - он был платный, но возможность варианта "альтернативного" лицензирования (проще говоря пиратства) нивелировала данную проблему. И был Linux - не очень дружелюбен к пользователю (точнее ходила такая шутка: Windows дружелюбен к пользователю, Linux тоже, только он выбирает с кем дружить). Как Вы понимаете - при таких раскладах у Linux-а для обычного пользователя не было никаких конкурентных преимуществ. При переходе на Windows 10 вообще те все "альтернативно" лицензированные копии практически легализовали. Сейчас, имхо конечно, больше останавливает не отсутствие графики в ядре ОС, а отсутствие большого объёма ПО под Linux. Причём какое-то ПО есть, но не многие захотят потратить время и переучиться для его использования, если мы говорим о домашних пользователях. У корпоративных пользователей есть проблемы с огромным количеством давно написанного специализированного ПО, который никто не будет переписывать под Linux.

Система обрастает дополнениями, но не ассимилирует их, поэтому усложняется и становится непрозрачной, а значит потенциально опасной, неконтролируемой.

К сожалению, как мне кажется, это свойство любой большой системы (а иногда и не очень большой) - не все новшества возможно легко интегрировать. Для полноценной интеграции может потребоваться переработать архитектуру и переписать огромное количество кода, возможно сломав совместимость с чьим-то ПО (например, переделав API), на что могут не выделить ни времени, ни ресурсов.

[Aether]

Так-же не мешает сейчас писать Wayland, который в перспективе должен заменить собой X Window System.

Пишут его уже десять лет где-то, но это тоже программа-сервер. Я не знаю детали его реализации.

Соответственно от ядра ОС требовался минимум и каждая из групп разработчиков занималась своим делом.

Вот, хочу я использовать в проекте плату с Linux на борту, ну или другой ОС, хочется взять книжку, почитать как его использовать и начать дело. Но по факту имею другое, если на ядро и базу Linux документация есть, то на вторичные компоненты её уже меньше, а при использовании вскрываются нюансы. То есть, должна быть стратегия, но пока до определённого момента хорошо, а потом каждый сам себе Бетховен. Это отталкивает, хотя к инструментарию претензий вообще нет, я помню как был рад, что Linux написан на "C" и в комплект сразу входит компилятор, справочник и так далее.

Как Вы понимаете - при таких раскладах у Linux-а для обычного пользователя не было никаких конкурентных преимуществ.

Сейчас всё больше юридических лиц у нас переходят на платный Windows Server, так как эксплуатационные затраты, связанные с использованием Linux, оказываются не то, что больше, а непредсказуемыми. То есть, нужно быстро найти человека на какой-то дистрибутив, а не тут-то было: либо очень дорого, либо приходит не специалист.

Хочу напомнить поговорку "время - деньги", пользователь, который тратит много времени на техобслуживание, тоже тратит как-бы много средств, просто их обычно не учитывают в публикациях.

Для полноценной интеграции может потребоваться переработать архитектуру и переписать огромное количество кода, возможно сломав совместимость с чьим-то ПО (например, переделав API), на что могут не выделить ни времени, ни ресурсов.

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

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

[Aether]

Давно хотел попросить господ из Израиля устроить ликбез по части налогового обложения в их государстве.

[Finch]

В чем именно?

[Aether]

Во-первых, есть ли аналогия с налоговой системой в РФ, например, разделение по сути общего налога с физического лица на раздельные части в виде НДФЛ и ЕСН? Каков общий процент, который физическое лицо платит в виде налога со своего дохода? Как облагается налогом юридическое лицо? Какие потери влечёт дарение?

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

Что-то много написал, но по большей части это сама суть интереса.