Pull to refresh
3
0

Ведущий инженер-программист (RTOS)

Send message

После белорусской хрени с посадкой самолёта - желающих повторять такой "подвиг" вряд ли много наберётся

Вспоминаются CNN и вагнеровцы.

Полностью согласен. Используем около 2х лет.

У нас на добавление ушло около 6 часов.

Нельзя отрицать того, что язык TeX создан нечеловеческим разумом. На это указывали мне два доктора наук

Коль скоро в одном тезисе уместились "нельзя отрицать" и "наук", то явно под "нечеловеческим разумом" подразумевается уфология. Извините, я по тех. наукам.

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

А вот при необходимости генерировать собственные tex- шаблоны с разным комплексным контентом приходит понимание того, что изобретательности ацких чертей нет границ.

Как и любой язык разметки, Latex, нужно учить. Нужно постоянно иметь по нему справочник под рукой

Да вы оптимист, батенька! Я бы даже сказал ОПТИМИСТИЩЕ!!!! Latex это не язык -- это секта. А вместо библии у нее гигатонны манов и доков на пакеты: https://ctan.org/pkg/:P

Хотя его ценность переоценить сложно. Черте сколько научных и технических проектов его использует. Сам из их числа, каюсь.

Прокомментирую увиденное по своему профилю, глядя вот на это:

https://github.com/SerenityOS/serenity/blob/master/Kernel/Graphics/Intel/NativeGraphicsAdapter.cpp

Самопальный графический <<стек>> в виде голого фрейм-буффера есть. Зрелость его по вменяемым меркам собственной графики близка к 0. Для Intel GPU есть поддержка ровно 1 контроллера 2006-2008 года. Драйверная модель статическая, чисто регистровая. Ни прерываний, ни аппаратного курсора, менеджмента памяти, никакого задела даже на 2D акселератор (а он там простейший, строк в 100 кода можно уложиться, если бы был VMEM-менеджмент, но...), масса fixme даже на 645 строк в мастере. Зато есть чтение EDID через GMBUS.

Посоны, видимо, глянули на размеры настоящих драйверов и решили забить в пользу VESA/int10 и UEFI mode-switcher-ов. Одним словом с драйверами вах.

У нас в стране чудесным образом укоренился четвёртый подход. Приобретение прав на исходный код коммерческого софта и его геромческое допиливание. Такими концептами у нас балуются многие конторы, которым хочется иметь ОС. так появился ОС Багет, например. И до сих пор в каком-то виде здравствует. Так появились и другие форки VxWorks, QNX,...

Про выводы о стоимости, вы, видимо, ответ другому человеку писали.

ОСРВ в моё время было базировано на Линуксе

Нет, это не так. Вторая ОС проприетарная QNX-based.

Не было бы open source'a - какая ОС бы крутилась на том же Эльбрусе?

Справедливости ради наивно на e2k работают 2 ОС: на ядре Linux от МЦСТ (включая Астру, Эльбрус ОС и др.) и проприетарная ОСРВ.

В режиме трансляции можно еще много напридумывать.

вроде бы это набор команд Intel, а архитектура у процов CISC

Нет. Архитектура процов Intel в прошлом IA-32, IA-64 и AMD64 сейчас.

Для наработки на отказ времени прошло все-таки еще слишком мало. Объективно перегрев положительно не может сказаться на компонентной базе. Исходя лишь из этих соображений должно стать лучше. Негативных ожиданий на протяжении 3х тематических статей на этом ресурсе высказано участниками не было. Лично меня это побудило на эксперимент в 10 ламп.

По статистике одного человека судить о чем-то будет все равно проблематично, слишком уж мал разброс случайных факторов.
По горячим следам купил в Леруа для попробовать несколько образцов 4000K из статьи:
Модификация
До:
image

После:
image


Вкрутил 2 одинаковые лампы (одна серия и дата) — слева модифицированная, справа оригинальная. Умозрительные наблюдения следующие, оборудованием не располагаю:
1. После 5мин работы лампу слева можно без дискомфорта тактильно ощупать, а вот лампа справа хорошо так обжигает у цоколя.
2. На глаз субъективно разницы в освещении не вижу. При фотографировании под разными углами картина уже интереснее:
В работе
image
Потому лишь последний и внедряется в линь в экспериментальном порядке. Буфер же тут не единственный дискуссионный момент.
Это неважно

Исключительно это и важно, поскольку компенсировать это невозможно.

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

А это компенсируется легко в исторически зарекомендовавших себя языках => процитированное есть исключительно ситуативная опциональная вкусовщина.
Что же до накладных расходов — они очень низки, и тем ниже, чем больше буфер.

Тут случаем нет ремарки вроде: «пока не пришел какой-нибудь garbage collector»?
И текущий size вы не знаете? Даже в рантайме? Как вы тогда понимаете, сколько там от заголовка, а сколько — от тела?

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

Думаю, что все это не так важно. Не вижу путей как тут должен компилятор в compile-time контролировать границы.

Я вообще начал с того, что непонятно, что вы считаете системным уровнем

Парой постов ниже отписался.
Компилятор, который вырежет эту инструкцию

… перестанет быть одним из самых востребованных.
Хороший вопрос, спасибо. Ответ зависит от того, что считать системой. Если программные системы — то и СУБД можно считать системным уровнем. Если говорить о программно-аппаратных системах, то я бы сказал, что всё, что выходит за прикладные интерфейсы ядра/драйвера — прикладной уровень. Про драйверный код ремарка не случайна, поскольку он есть в LLVM и отсутствует в GCC. Граница немного плавает.

В дискуссии я исхожу из второго подхода.
Последняя ремарка несколько нарушает исходную постановку вопроса. Как вы понимаете, я не специалист по ЯП с более строгими правилами типизации. Но разве низкоуровневый доступ к памяти и концепция сырого указателя в языках с контролем границ присутствует?

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity