Конструкция прикольная, но что если битовый поток начинается с двух нолей? Еще к недостаткам я бы отнес использование непредсказуемого числа раз popcount при кодировании, тем более что не везде эта операция аппаратно ускорена. И невозможность заранее быстро оценить сколько займет закодированное значение, это тоже бывает важно при расчете “стоимости” хранения, когда есть выбор как кодировать.
p.s. например есть же всякие дельта коды, которые по сути гамма, у которых экспонента тоже закодирована гамма кодом - вполне себе похожие конструкции получаются.
Линкер и так выбрасывает неиспользуемое. Просто например, поддержка исключений - она либо есть везде, либо ее нет нигде, поэтому чтобы выбросить всю поддержку надо пересобрать значительную часть runtime библиотеки, вот и получается “еще один вариант”. Ну и так со многими вещами. И даже если вы нигде не используете какую-то возможность языка, это не значит что ее не использовали авторы библиотеки и таким образом она и попадает в код исполняемого файла, к тому же всегда можно попросить линкер объяснить зачем он потащил какой-то объект в код.
В итоге для всех упомянутых версий 15.2.0, 13.1.0, 10.3.0, 4.9.2 получаем стабильные 3,50 КБ (3 584 байт)
Если достаточно поиграться опциями и отключить исключения например, то у меня тот же файл выдает уже 2560 байт именно на g++. Чтобы сделать меньше надо сливать секции уже, что в случае gnu ld не так тривиально как для msvc link: надо аккуратно править скрипты линкера.
Вы можете спросить, ну а зачем компилятор сует обработку исключений в код, если из кода очевидно, что никаких исключений не предвидется? Ответ прост: специально никто ничего не сует, просто вариант runtime библиотеки один - и он на все, даже самые тяжелые, случаи. Потому что иначе пришлось бы иметь два варианта библиотек - для исключений и без них. И два варианта кажутся ерундой, но потом кто-то скажет, а мне не нужно utf8, а кому-то rtti, а кому-то потоки не нужны, а кому-то еще не нужна поддержка новых фич процессоров ну и т.д. и число вариантов билиотек устремляется к тысячам, а это банально никто не сможет поддерживать. Так что придется смириться с тем, что runtime библиотека обычно есть в паре-тройке вариантов покрывающих 97% всех программ и да, размер этой библиотеки обычно приличный, ну а для оставшихся экзотических вариантов придется выкручиваться самостоятельно.
Вообще оценивать размер исполняемого файла по очень простой программе - странно и не очень правильно. Для простых программ, где по какой-то причине важен размер, годятся все вышеуказанные ухищрения вплоть до переписывания на асемблере, потому что программа простая и это сработает. Но программы бывают и сложные. И вот интересно было бы сравнить качество кодогенерации, там где это действительно важно - во всяких узких местах, циклах, при операциях которые можно параллелить и т.д. И размер кода там конечно имеет значение, потому что раздутый код не лезет в кэши и нарушает локальность. По своему опыту могу сказать, что качество кодогенерации в целом растет, но библиотеки очевидно растут в размере на порядки быстрее. Современные runtime библиотеки, например, поддерживают какой-нибудь utf8, который добавляет довольно много кода, но если вам это не нужно - в сети есть варианты и без этого, ну или как решение можно собрать программу более старым компилятором со старой версией.
Идея выглядит прикольно, но почему бы не пойти дальше и полностью перейти на клиент-серверную архитектуру? Т.е. изначально разделить продукт на части: 1. клиент - интерфейс оболочка для взаимодействия с пользователем (GUI/TUI, поддeржка всяких расширений терминалов, X11/wayland и т.д.), 2. основная серверная часть-планировщик, которая рулит всеми асинхронными параллельными операциями и взаимодействует с клиентом(ами), включая возможность делать это по сети, и с плагинами/скриптами, если надо работает с повышенными правами, 3. выносная микросерверная часть для сценариев embedded/slow link/etc. т.е. без планировщика и поддержки плагинов, но тоже с возможностью взаимодействия по сети с основным сервисом по ssh/telnet/serial port (эта часть опциональна).
Телефоны, в которых все разблокировано и соответственно можно легко вырезать и добавить (пропатчить) системный софт можно пересчитать по пальцам. Увы, но тенденция такова, что “открытых” моделей становится все меньше и меньше с каждым годом. И даже те модели, которые ранее можно было разблокировать, спустя некоторое время, когда они теряют актуальность, становится нельзя, хотя казалось бы по логике должно быть наоборот (отдельное фи например “риалми” и подобным лавочкам). А без разблокировки большая часть манипуляций очень сложна или невозможна.
«USB-флешки теряют данные так же, как SSD» — и да, и нет.
Так получается, что флешки - это вообще ужас-ужас? Ведь умного контроллера там нет, значит они теряют данные постепенно даже если ими пользуются. Износ флешки тоже понять сложно, там зачастую никаких smart'ов нет. Ну и долго хранить на них точно ничего нельзя, ведь подключение к компу все равно ничего не исправит. Правильно?
Насколько это надежно работает с SSD/Flash? Там ведь просто запись чего попало не гарантирует, что все сектора будут реально затронуты, потому что есть резервы. Есть ли какие-нибудь исследования?
Сначала ввели подписывание прошивок и их компонентов только своими секретными ключами, исключив возможность собрать или модифицировать большую часть компонентов (я не против подписей, я против невозможности использовать свои). Потом свели почти на нет возможность разблокировки и сответственно даже установки каких-либо сторонних прошивок. Теперь сведут почти на нет возможности установки стороннего софта. Со стороны гугла и крупных вендоров это выглядит как логичный шаг по закрытию платформы, этим путем они постепенно идут уже много лет.
p.s. huawei увы играет в те же игры, разблокировки там изначально нет например, так что их система по сути ничем не отличается, просто они еще не догнали гугл.
Если вам нравится сама идея своей ОС, позвольте дать совет. Забудьте на время про загрузчики, bios, драйвера и даже про видеокарту. Это огромный объем работ, который практически невозможно полноценно сделать одному. Может когда-нибудь ИИ поможет, но пока и от него толку мало в этой части. Драйвер для nvidia под вашу ОС он вам не напишет, хотя загрузчик может и сможет написать. Начните с базовых вещей. Что делает практически любая неспециализированная ОС? Распределяет и управляет ресурсами: памятью, вычислительными мощностями, временем, привилегиями (доступом), энергопотреблением и т. д. Плюс имеет некую структуру для хранения и управления всем хозяйством, например через файлы (тогда это файловая система), или через что-то другое. И вот эти базовые вещи можно спокойно писать на любом выбранном языке, практически под любую неспециализированную архитектуру и отлаживать эти алгоритмы прямо как обычные программы. Я имею ввиду: систему управлением памятью, планировщик задач, файловую систему, систему прав и доступа, межпроцессное взаимодействие, синхронизация, систему управления временем и прочее. Это само по себе довольно интересно, здесь до сих пор делаются многие улучшения, которые потом идут в реальные ОС, и отлаживать это не так сложно, как драйвера под редкие железки.
Так а почему именно C++ да еще без макросов? Про это ни слова, особенно в контексте именно ОС, а не обычных программ. В статье написано какими плюшками языка можно пользоваться, но почему выбран именно C++ например?
Архитектурные решения и почему они важны
Это же не архитектурные решения, а просто технические моменты. А вот про архитектуру ОС у вас почти ни слова, кроме абстрактной фразы про "будет писать монолитное ядро с HAL". Хотелось бы подробностей. Почему монолитное ядро, например?
мы своими руками разберёмся в основах, поймём, как устроены операционные системы изнутри
ОС это ведь не столько работа с "железом" (которое очень разнообразно и его стараются отделить в подсистему условных драйверов), сколько точный менеджмент ресурсов: процессоров, памяти, времени, привилегий и т.д. Вот с этого стоило бы начать на мой взгялд, и главное эти алгоритмы гораздо проще тестировать в обычной среде и не надо возиться с загрузчиками и QEMU.
А если ssd подключен, но смонтирован как read-only в течении многих лет, данные на нем деградируют или контроллер сам сектора переписывает периодически тратя ресурс?
Пользуясь случаем хочу отблагодарить авторов far2l за все их усилия по продвижению far в мир linux/macos/unix - сам пользуюсь на регулярной основе не только на рабочих машинах, но и на серверах. Для полноты картины можно еще упомянуть наличие форка [https://github.com/shmuz/far2m/] far2m - это как far2l только с поддержкой lua из far3, кому-то может зайти вместо (или вместе с) far2l.
Карты же векторные, почему бы не сделать цвета разных элементов (таких как дороги те же) настраиваемыми. Для дневной и ночной темы разумеется. И еще размеры шрифтов тоже настраивамемыми - было бы вообще хорошо.
Однако большая ёмкость в основном используется для хранения драйвера Wi-Fi
А чего ограничиваться только драйвером wifi? Когда уже запихнут простенький линух наконец? Очень бы помогло и при установке любых систем и тем более при восстановлении разных сбоев. Объем уже позволяет вроде. Простые сборки тоже есть.
Ситуацию с iOS не знаю, но в android штатного нет, а из предложений - только фильтр на базе vpn, что выглядит коряво, хотя бы потому что нельзя запустить второй vpn (кто-то решил, что подключенный vpn может быть только один). Поставить более полноценный сторонний firewall можно только на рутованный аппарат.
Конструкция прикольная, но что если битовый поток начинается с двух нолей? Еще к недостаткам я бы отнес использование непредсказуемого числа раз popcount при кодировании, тем более что не везде эта операция аппаратно ускорена. И невозможность заранее быстро оценить сколько займет закодированное значение, это тоже бывает важно при расчете “стоимости” хранения, когда есть выбор как кодировать.
p.s. например есть же всякие дельта коды, которые по сути гамма, у которых экспонента тоже закодирована гамма кодом - вполне себе похожие конструкции получаются.
Линкер и так выбрасывает неиспользуемое. Просто например, поддержка исключений - она либо есть везде, либо ее нет нигде, поэтому чтобы выбросить всю поддержку надо пересобрать значительную часть runtime библиотеки, вот и получается “еще один вариант”. Ну и так со многими вещами. И даже если вы нигде не используете какую-то возможность языка, это не значит что ее не использовали авторы библиотеки и таким образом она и попадает в код исполняемого файла, к тому же всегда можно попросить линкер объяснить зачем он потащил какой-то объект в код.
Если достаточно поиграться опциями и отключить исключения например, то у меня тот же файл выдает уже 2560 байт именно на g++. Чтобы сделать меньше надо сливать секции уже, что в случае gnu ld не так тривиально как для msvc link: надо аккуратно править скрипты линкера.
Вы можете спросить, ну а зачем компилятор сует обработку исключений в код, если из кода очевидно, что никаких исключений не предвидется? Ответ прост: специально никто ничего не сует, просто вариант runtime библиотеки один - и он на все, даже самые тяжелые, случаи. Потому что иначе пришлось бы иметь два варианта библиотек - для исключений и без них. И два варианта кажутся ерундой, но потом кто-то скажет, а мне не нужно utf8, а кому-то rtti, а кому-то потоки не нужны, а кому-то еще не нужна поддержка новых фич процессоров ну и т.д. и число вариантов билиотек устремляется к тысячам, а это банально никто не сможет поддерживать. Так что придется смириться с тем, что runtime библиотека обычно есть в паре-тройке вариантов покрывающих 97% всех программ и да, размер этой библиотеки обычно приличный, ну а для оставшихся экзотических вариантов придется выкручиваться самостоятельно.
Вообще оценивать размер исполняемого файла по очень простой программе - странно и не очень правильно. Для простых программ, где по какой-то причине важен размер, годятся все вышеуказанные ухищрения вплоть до переписывания на асемблере, потому что программа простая и это сработает. Но программы бывают и сложные. И вот интересно было бы сравнить качество кодогенерации, там где это действительно важно - во всяких узких местах, циклах, при операциях которые можно параллелить и т.д. И размер кода там конечно имеет значение, потому что раздутый код не лезет в кэши и нарушает локальность. По своему опыту могу сказать, что качество кодогенерации в целом растет, но библиотеки очевидно растут в размере на порядки быстрее. Современные runtime библиотеки, например, поддерживают какой-нибудь utf8, который добавляет довольно много кода, но если вам это не нужно - в сети есть варианты и без этого, ну или как решение можно собрать программу более старым компилятором со старой версией.
Идея выглядит прикольно, но почему бы не пойти дальше и полностью перейти на клиент-серверную архитектуру? Т.е. изначально разделить продукт на части: 1. клиент - интерфейс оболочка для взаимодействия с пользователем (GUI/TUI, поддeржка всяких расширений терминалов, X11/wayland и т.д.), 2. основная серверная часть-планировщик, которая рулит всеми асинхронными параллельными операциями и взаимодействует с клиентом(ами), включая возможность делать это по сети, и с плагинами/скриптами, если надо работает с повышенными правами, 3. выносная микросерверная часть для сценариев embedded/slow link/etc. т.е. без планировщика и поддержки плагинов, но тоже с возможностью взаимодействия по сети с основным сервисом по ssh/telnet/serial port (эта часть опциональна).
Телефоны, в которых все разблокировано и соответственно можно легко вырезать и добавить (пропатчить) системный софт можно пересчитать по пальцам. Увы, но тенденция такова, что “открытых” моделей становится все меньше и меньше с каждым годом. И даже те модели, которые ранее можно было разблокировать, спустя некоторое время, когда они теряют актуальность, становится нельзя, хотя казалось бы по логике должно быть наоборот (отдельное фи например “риалми” и подобным лавочкам). А без разблокировки большая часть манипуляций очень сложна или невозможна.
Так получается, что флешки - это вообще ужас-ужас? Ведь умного контроллера там нет, значит они теряют данные постепенно даже если ими пользуются. Износ флешки тоже понять сложно, там зачастую никаких smart'ов нет. Ну и долго хранить на них точно ничего нельзя, ведь подключение к компу все равно ничего не исправит. Правильно?
Насколько это надежно работает с SSD/Flash? Там ведь просто запись чего попало не гарантирует, что все сектора будут реально затронуты, потому что есть резервы. Есть ли какие-нибудь исследования?
p.s. когда уже такую штуку для телефонов сделают?
Сначала ввели подписывание прошивок и их компонентов только своими секретными ключами, исключив возможность собрать или модифицировать большую часть компонентов (я не против подписей, я против невозможности использовать свои). Потом свели почти на нет возможность разблокировки и сответственно даже установки каких-либо сторонних прошивок. Теперь сведут почти на нет возможности установки стороннего софта. Со стороны гугла и крупных вендоров это выглядит как логичный шаг по закрытию платформы, этим путем они постепенно идут уже много лет.
p.s. huawei увы играет в те же игры, разблокировки там изначально нет например, так что их система по сути ничем не отличается, просто они еще не догнали гугл.
Если вам нравится сама идея своей ОС, позвольте дать совет.
Забудьте на время про загрузчики, bios, драйвера и даже про видеокарту. Это огромный объем работ, который практически невозможно полноценно сделать одному. Может когда-нибудь ИИ поможет, но пока и от него толку мало в этой части. Драйвер для nvidia под вашу ОС он вам не напишет, хотя загрузчик может и сможет написать.
Начните с базовых вещей. Что делает практически любая неспециализированная ОС? Распределяет и управляет ресурсами: памятью, вычислительными мощностями, временем, привилегиями (доступом), энергопотреблением и т. д. Плюс имеет некую структуру для хранения и управления всем хозяйством, например через файлы (тогда это файловая система), или через что-то другое. И вот эти базовые вещи можно спокойно писать на любом выбранном языке, практически под любую неспециализированную архитектуру и отлаживать эти алгоритмы прямо как обычные программы. Я имею ввиду: систему управлением памятью, планировщик задач, файловую систему, систему прав и доступа, межпроцессное взаимодействие, синхронизация, систему управления временем и прочее. Это само по себе довольно интересно, здесь до сих пор делаются многие улучшения, которые потом идут в реальные ОС, и отлаживать это не так сложно, как драйвера под редкие железки.
Теперь к началу холиваров будут привлекать ИИ. Так может пусть уж ИИ весь холивар и сгенерирует? И выжимку из него, как обычно его и просят?
Между операторами давно уже слово на букву О: олигополия.
Телефоны с перебиваемыми имеи слегка подорожают. Хотя бы потому что позволят экономить время и деньги.
Так а почему именно C++ да еще без макросов? Про это ни слова, особенно в контексте именно ОС, а не обычных программ. В статье написано какими плюшками языка можно пользоваться, но почему выбран именно C++ например?
Это же не архитектурные решения, а просто технические моменты. А вот про архитектуру ОС у вас почти ни слова, кроме абстрактной фразы про "будет писать монолитное ядро с HAL". Хотелось бы подробностей. Почему монолитное ядро, например?
ОС это ведь не столько работа с "железом" (которое очень разнообразно и его стараются отделить в подсистему условных драйверов), сколько точный менеджмент ресурсов: процессоров, памяти, времени, привилегий и т.д. Вот с этого стоило бы начать на мой взгялд, и главное эти алгоритмы гораздо проще тестировать в обычной среде и не надо возиться с загрузчиками и QEMU.
А если ssd подключен, но смонтирован как read-only в течении многих лет, данные на нем деградируют или контроллер сам сектора переписывает периодически тратя ресурс?
Ну опять "дефицит низкооплачиваемых высококвалифицированных кадров".
Пользуясь случаем хочу отблагодарить авторов far2l за все их усилия по продвижению far в мир linux/macos/unix - сам пользуюсь на регулярной основе не только на рабочих машинах, но и на серверах. Для полноты картины можно еще упомянуть наличие форка [https://github.com/shmuz/far2m/] far2m - это как far2l только с поддержкой lua из far3, кому-то может зайти вместо (или вместе с) far2l.
Карты же векторные, почему бы не сделать цвета разных элементов (таких как дороги те же) настраиваемыми. Для дневной и ночной темы разумеется. И еще размеры шрифтов тоже настраивамемыми - было бы вообще хорошо.
А чего ограничиваться только драйвером wifi? Когда уже запихнут простенький линух наконец? Очень бы помогло и при установке любых систем и тем более при восстановлении разных сбоев. Объем уже позволяет вроде. Простые сборки тоже есть.
Ситуацию с iOS не знаю, но в android штатного нет, а из предложений - только фильтр на базе vpn, что выглядит коряво, хотя бы потому что нельзя запустить второй vpn (кто-то решил, что подключенный vpn может быть только один). Поставить более полноценный сторонний firewall можно только на рутованный аппарат.