Опубликован выпуск операционной системы MenuetOS 1.53, разработка которой ведётся полностью на ассемблере. Сборки MenuetOS подготовлены для 64-разрядных систем x86 и могут быть запущены под управлением QEMU. Сборка системы занимает 1.4 МБ и сформирована в виде образа дискеты и iso-образа для записи на CD (поддерживается запуск в VirtualBox). Исходные тексты проекта Menuet64 распространяются под ограничивающей лицензией, требующей согласования любого использования в коммерческих целях, а Menuet32 под лицензией GPL...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61732
Зачем сабж, если есть Kolibri?
ЖЫРНОТА. KolibriOS основана на сабже.
вот где жирнота> Сборка системы занимает 1.4 МБ
> Сборка системы занимает 1.4 МБДа ладно тебе? Операционок размером с флом с гуем на этом глобусе не так уж много. В стародавние времена на флопик с GUI умещался еще - ну разве что QNX. Там правда как я понимаю для этого было нефиговое сжатие и распаковка в RAM.
Правда, QNX это все ж забавнее было. Честная правильная многозадачка, чуть ли не с реалтайм гарантиями. Правда, ее пафосная графическая система (Photon чтоли называлась) - была сама по себе, ни с чем не совместима - и учитывая лицензирования, оказалась никому кроме ее авторов не нужна. Так в общем то и скопытилась эта штукенция.
QNX запускал с дискеты в то время на реальном железе, как и сабж. QNX была всего лишь демкой, которая не умела ничего от слова совсем по сравнению с минуетом.
Ага, а данная ОС умеет...что?
Наверное умеет то, что указано в названии.
> QNX запускал с дискеты в то время на реальном железе, как и
> сабж. QNX была всего лишь демкой, которая не умела ничего от
> слова совсем по сравнению с минуетом.Я тоже запускал. И насколько я помню, она вполне себе умела - подцепляться к сети, и чуть ли не браузер простенький запускать.
Дрова ессно были далеко не на все железо. И цеплять внешние диски не умело. Но для 1.44 мега так то довольно неплохо. И графическая система - марки хрен заклинишь. Можно что угодно делать с ос, а графон прет как влитой, векторная анимаха в фоне даже не дергается. Это вам не винда 95, и прочие дерганые xorg, да...
PicoBSD была еще
Так я и спрашиваю, зачем сабж теперь нужен.
> Так я и спрашиваю, зачем сабж теперь нужен.Потому что колибриводы неосиляторы. И в 64 бита смогут когда рак на горе свиснет.
Тут встречный вопрос - зачем нужна Колибри с раковой лицухой?
> Так я и спрашиваю, зачем сабж теперь нужен.MenuetOS НЕ НУЖЕН потому что закрытая проприетарщина, в отличие от опенсорсной KolibriOS (которая и умеет больше)
> MenuetOS НЕ НУЖЕН потому что закрытая проприетарщина, в отличие от опенсорсной KolibriOS
> (которая и умеет больше)А где она больше умеет?
Колибри даже в 64 бита не может, потому что слямзить код смогли, а вот в 64 бита.. тут уже надо мозги иметь, это не лицензию перебивать в файлах.
Т.е как минимум по битности Колибри умеет меньше в 2 раза.
А вы запустите их обе (можно в виртуалке) - и увидите, что в опенсорсной KolibriOS намного больше и полезных программ и драйверов! А то что нет 64 битов - скорее, просто не захотели: ведь такая эффективная ОС никогда не скушает больше 4 гигов оперативки, да и разрабатывать потом под 64 бита менее удобно. К тому же MenuetOS, будучи проприетарщиной - изначально мёртвый проект который умрёт со своим создателем, в отличие от опенсорсной KolibriOS которая жива и будет жить
> А то что нет 64 битов - скорее, просто не захотелиАхаха, лол.
я_тоже_так_могу,_но_не_хочу.jpeg> изначально мёртвый проект который умрёт со своим создателем
Если продукт имеет смысл, то он не умрет даже будучи проприетарным.
> создателем, в отличие от опенсорсной KolibriOS которая жива и будет жить
Если она будет жить как сейчас... то это не жизнь, а так - догнивание без каких либо перспектив и развития.
Если автор MenuetOS - страшный жадина и ни с кем не делится исходниками, то в момент смерти этого жадины проект MenuetOS обречён, да и развиваться при его жизни он будет ужасно медленно т.к. этому жадине нужно тратить время на еду/сон/семью/работу и прочие биопроблемы. В то же время, KolibriOS лишён этих недостатков - и в него то и дело прилетают коммиты от совершенно разных людей, только за прошедшие сутки два коммита было (в отличие от)
Дизассемблер решает проблему недоступности исходников программ на ассемблере
Документаций полно. Скорей проблема в том что прийдётся мудохаться с уже с 2 target'ами, безплатно. Автор Menueta это тоже ниасилил забив на 32bit: "Menuet32 v0.86b, 02.09.2019"...
> Дизассемблер решает проблему недоступности исходников программ на ассемблереКак видно на примере Колибри, не решает. Им ещё нужно уметь пользоваться. Это помимо того, что исходник на асме внезапно для экспертов принципиально отличается от дизассемблерного листинга: метки, макросы и т.д.
> ЖЫРНОТА. KolibriOS основана на сабже.Правильно, нинужна, т.к. KolibriOS под православной GNU GPL, а сабж под какой-то ограничивающей лицензией, заставляющей общаться с какими-то непонятными рандомами с рандомным же результатом их решения разрешать ли тебе зарабатывать или нет?!
1) GPL к Православию не имеет никакого отношения, нечего тут юродствовать;
2) GPL это просто подстава, тут можно оч.долго разжовывать, но достаточно того что она оч.мутна и в добавок на нерусском языке, и что, в ней запрещенно ...запуск ЛЮБОГО не GPL ПО, реально (сам Торвальдс даже как то лживо высрал что можно, фактически потому что ему так хочется - чтобы не ухудшать её популярность).
3) Это даже не считая того что к свободе в ч.н.закрывать код - она не имеет никакого отношения, лишь типично паразитирируя на слове свобода. Вот даже в пример тут часто приводят что Likux_kernel более масштабен чем *BSD но, игнорируя факт массового нарушения GPL Торвальсом уже и в драйверах... и тот факт что не будь Linux kernel - *те же самые люди* расширяли бы *BSD семейство, т.е.это такой конкурент паразит на реально свободном ПО, тут в ч.н.ОС.А, ещё же есть вопрос сертификации, в ч.н.линуксов, для госприменения - прикрывание фиговым листочком, - которые явно никто не проверяет на зловредность, так зачем тогда она нужна! сужу по даже просто мега забагованности(вплоть до порчи шрифта со времнем работы, или авто-перезагрузки при загрузки с LiveCD ~из-за появления BADBLOCKов там из-за критинизма не выключенности swappinga, в ч.н.жружими всю память браузерами, туда; да что там при смене видеорежима зависания часто) сертифицированных... линуксов.
1) Имеет. Прямо противоположное.
>ЖЫРНОТА. KolibriOS основана на сабже.Да не, это нормальный коммент. Точно такие же есть под каждой новостью про OpenOffice.
Ага! А вин11 основана на мсдос.
Нет, то линейка w9x/wME. Эти на wNT.
Тут не совсем правда, kolibri основана на сабже, когда сабж развился медленно или был заброшен (в моей памяти такая информация), после чего разработчик снова занялся проектом, и вроде как перенёс некоторые наработки из kolibri, если не все...
Тырить из KolibriOS у него (судя по changelog'у Menuet) не особо получается - слишком уж "разветвились" друг от друга
Колибри это форк минeтa.
> Колибри это форк минeтa.Этот форк уже давно живёт своей жизнью и под лицензией здорового человека, в отличии от 64битной версии сабжа.
Зачем ты, если есть другие люди, и таких как ты полно? Зачем твой коммент?
Единственная нормальная ос на ассемблере.
> Единственная нормальная ос на ассемблере.Проприетарщина не может быть "нормальной". Лучше пользуйтесь опенсорсной колибри
Очень легко получить исходники проприетарного софта написанного на ассемблере. Дизассемблер наше всё
Не воруй!
Ага, а комментарии нейросеть напишет.
Так и в обычных исходниках не всегда есть комментарии. Если у софта открыты исходники, то это вообще не гарантия того что в его исходиках есть хоть один комментарий и что исходники сможет легко понять кто-либо отличный от их авторв
Зачем возиться с дизассемблингом проприетарного Menuet'а - искать бекдоры, традиционно присутствующие во многой проприетарщине? Лучше уж пользоваться опенсорсным аналогом "Колибри" вместо поедания кактуса
уже пишет, вон зайди на ютуб, и оставь комент под любым довольно старым видео с >1к коментов, прилетит ответ если в коменте будет непонятное выражение для ИИ. Хорошо срабатывает с сокращениями. Бот тупо задант вопрос, а что вы имели ввиду под этим. Будешь дураком если ответишь на этот комент (не мой именно, а на ютубе).
Куча ос на ассемблере и одна полудохлая на "системном" расте. Требую назвать причину. Время пошло.
Разработчики заняты пропагандой что их проект на расте
ОС на ассамблере это удивительно.
Дизассемблируй линукс и будет у тебя линукс на ассемблере.
Будет на дизассемблере: без меток, макросов и прочего.
> Будет на дизассемблере: без меток, макросов и прочего.Можно использовать objdump -S и получите желаемое :)
>> Будет на дизассемблере: без меток, макросов и прочего.
> Можно использовать objdump -S и получите желаемое :)Метка в ассемблере - это любое именованное значение, а не только адрес, и не только экспортируемый/импортируемый.
Макрос в ассемблере - это такая штука, которая при трансляции может сгенерировать 1000 опкодов, например.
> Метка в ассемблере - это любое именованное значение, а не только адрес,
> и не только экспортируемый/импортируемый.
> Макрос в ассемблере - это такая штука, которая при трансляции может сгенерировать
> 1000 опкодов, например.А в сях я даже таблицы констант макросней заполнить могу. И чего? Некие части вон того в -S таки - будут. Если конечно у вас сорец есть :)
Наивный анон ни разу не пробовал собирать дизассемблерный код.
>> Метка в ассемблере - это любое именованное значение, а не только адрес,
>> и не только экспортируемый/импортируемый.
>> Макрос в ассемблере - это такая штука, которая при трансляции может сгенерировать
>> 1000 опкодов, например.
> А в сях я даже таблицы констант макросней заполнить могу. И чего?
> Некие части вон того в -S таки - будут. Если конечно
> у вас сорец есть :)А сгенировать .jpg путём трансляции .c файла можешь? Ну вот и я не понял, зачем ты это написал.
https://github.com/microsoft/MS-DOS
> занимает 1.4 МБ и сформирована в виде образа дискетыПризнавайтесь, некроманты и некрофилы, у кого еще остался работающий флопповод?!
на 3.5, 5 или 8 дюймов?
8 дюймовые считались самыми надёжными из-за низкой плотности записи. И без шуток используются даже в Пентагоне по сей день.
Уже лет 5 как перешли на ссд. С разморозкой.
посмотри как ПО загружают в самолеты, туда заминетили/эмуляторы не подпускают
Посмотри как данные в баллистические ракеты загружают. Там уже пять лет нет дискет там ссд.
Где посмотреть?Тема на чем они хранят данные для своих МБР и прочего ЯО мне очень интересна. У пентагона требование гарантии 50 лет хранения данных, минимум на что они могут пойти 20-30 лет гарании.
Что они сегодня используют? Возьму себе этот диск в комп если ценник подойдёт.
> Что они сегодня используют? Возьму себе этот диск в комп если ценник
> подойдёт.Им там данных поди - и мегабайта не надо. Много ли координаты и проч занимают?! Себе в комп вы такое можете из SPI флешек собрать. А то что мизерная емкость, скорость, с злой ценой за мегабайт - ну и что? Зато 20+ лет хранить будет, а может и 50, спеки читайте.
Под 30 лет и кассеты с магнитной плёнкой обеспечат, больше уже специальные материалы плёнки понадобятся.Пожалуйста, 20 терабайт на кассету. А вот флешкам особого доверия нет, да, скорее всего, и потеряют данные при эми ударе. Устойчивость к излучениям отдельный фактор, плёнка с кодами коррекции выглядит понадёжнее.
Не смог освоить физику? Оберни свою флешку в медную фольгу и никакой Эми тебе не страшен. Только ударная волна.
Флешки так же как и обычные SSD-диски по немногу саморазряжаются... если периодически не подключать(читал что, рекомендованно не реже раз в полгода!),
т.е.когда храня на них BkUp'ы или просто с редким использованием.Косвенно и винчестерные HDD "саморазряжаются" в таких же условиях - посредством появления BADBLOCKов и невозможности вовремя автообнаружить и автопереместить данные.
Магнитная пленка может хранить большие масивы данных до 500 лет. Но ценник на оборудование заоблачный. Если даже купите, то это будет 1 девайс на всю страну и если в него попадёт метеорит, то данные не прочитаете. Магнитная плёнка ужастно неудобна в использовании, только на длительный бкап. BD M-DISK на 100Mb для использования и то удобнее, правда создать исошки и нарезать болванки посложнее будет.
Из каких материалов сделана эта плёнка? Помимо плёнки конечно есть много деталей, как в оборудовании для чтения, так и в самих кассетах, которые могут (и будут) разрушаться со временем. 30 лет в идеальных условиях хранения заявлено (что может бт преувеличением и условия должны быть действительно идеальные). Обычные неорганические BD обещают 50. M-disk конечно хорошая вещь, но это диски, и они мало данных позволяют сохранить и мало подходят для архивации. Значительный недостаток.
Тут ещё оказалось, что линзы в бытовом оборудовании тоже органические и разрушаются довольно быстро, поэтому, купить про запас может и не получиться. С дисками одни проблемы, можно использовать, только если совместимые приводы продолжают выпускать.
https://www.opennet.dev/opennews/art.shtml?num=53383Извеняюсь, заявлена гарантия хранения данных на ФОТО лентах (аналоговый) в 500-1000 лет, а также 500-1000 лет гарантии на оборудование для его считыания; https://www.piql.com/introducing-our-new-piqlreader/ ценник очень дорогой.
Диски с кварцевого стекла на 7TB, цифровые, размер CD, ценник на диски и привод теже - обещают гарантию хранения данных в десятки или даже сотни тысяч лет: https://www.microsoft.com/en-us/research/project/project-silica
Обещать - не значит жениться...
Как по вашему они их проверяли?........А, вот обычные более менее фирменные CD/DVD - проверенно что, до 20-30 лет тянут, на удивление, при аккуратином использовании/хранениии.
Проверяют технологиями ускоренного старения. В каждой лаборатории свои проверки и результаты разные.У меня есть обычные DVD, где фирма на упаковке обещает гарантию хранения данных - 100 лет.
> посмотри как ПО загружают в самолеты, туда заминетили/эмуляторы не подпускаютПростите, а кого таки - "заминетили"? Сказали А - скажите и Б! :)
>...туда заминетили/....Что, простите?!..
Дай пруф о переходе пентагона на SSD!8 дюймовые гибкие диски они используют из-за их гарантии в 50 лет. А современное производство дает только ~5лет гарантии сохранности данных.
> Дай пруф о переходе пентагона на SSD!
> 8 дюймовые гибкие диски они используют из-за их гарантии в 50 лет.
> А современное производство дает только ~5лет гарантии сохранности данных.Пусть откроют для себя M-DISC уже наконец. xD
M-DISC - хорошо разрекламирован.
1. Где купить в РФ?
2. Тесты на 1000 лет проведены в США. Французы не увидели принципиальной разници между органической (пластмасса) и минеральной (камень) основой. Обычные DVD, BD могут дать гарантию 100 лет.
3. Прошивка привода хранится на SPI Flash, UEFI прошивка системной платы так же SPI Flash, который и 5 лет хранения данных еле тянет. Так что есть угроза, что до чтения OS с M-DISC дело может и не дойти...
> 3. Прошивка привода хранится на SPI Flash, UEFI прошивка системной платы так
> же SPI Flash, который и 5 лет хранения данных еле тянет.
> Так что есть угроза, что до чтения OS с M-DISC дело
> может и не дойти...SPI flash если он не совсем гунявый, специфицирован обычно лет на 20-50... и это "минимуму" и при жестких условиях.
Ононы спецификациии своих DEXP на QLC в 240 ГБ теребонткают (кстати, и они куда выносливей, чем кажется).
> Ононы спецификациии своих DEXP на QLC в 240 ГБ теребонткают (кстати, и
> они куда выносливей, чем кажется).Ну вот нет - там ячейки мизерные, заряда мало, а QLC к утечкам куда критичнее. И если его на несколько годков бросить без питания - вот тут может наступить конкретный облом. К выносливости это отношения не имеет, только утечкам заряда.
Но в SPI NOR каком - ячейки большие, жирные, 1 уровень на ячейку, утечек минимум. И там гораздо более приличные параметры, число перезаписей и проч, если от нормальной фирмы.
Ну вряд ли там сейчас NOR. Но микросхемы всё равно дубовые по сравнению со сверхъёмким хз-скольки-слойным флешем на SSD.
Образование не позволяет тебе пользоваться Гуглом? https://www.cnews.ru/news/top/2019-10-21_yadernyj_shchit_ssh...
Его не сложно найти, учитывая, что их пихали в компы вплоть до 2010 года, и уже тогда ими никто не пользовался, стояли и не изнашивались. Имею несколько приводов абсолютно рабочих и гору дискет. Дискеты все давно размагнитились и данные которые были на них утеряны, но при свежем форматировании работают как новые.
> Дискеты все давно размагнитились и данные которые были на них утеряны,
> но при свежем форматировании работают как новые.Что за бред? У меня есть эн вполне читающихся древних дискет.
Подтверждаю, у меня 3.5" дискеты до сих пор читаются.
Тут всё довольно сложно. Зависит от того, на чём, на что писалось и на чём читается. Хорошие дискеты вербатим на хорошем дисководе (есть у меня) уверен, что прочитаются. Но не у всех остались хороши е дисководы с микролифтом.
> не изнашивались. Имею несколько приводов абсолютно рабочих и гору дискет. Дискеты
> все давно размагнитились и данные которые были на них утеряны, но
> при свежем форматировании работают как новые.А почему у меня откопаная дискета с какими-то дровами от мыши - читается?
Видимо, потому что тeбe это приснилось? А во сне бывает даже то, что не бывает.
> Признавайтесь, некроманты и некрофилы, у кого еще остался работающий флопповод?!У меня в системном блоке есть на 3.5", не подключён правда, т.к. материнку сменил давно и там разъёма такого уже нет.
Кстати, в нулевых с этого дисковода как раз запускал MenuetOS, работало.
>> занимает 1.4 МБ и сформирована в виде образа дискеты
> Признавайтесь, некроманты и некрофилы, у кого еще остался работающий флопповод?!Образ дискеты можно легко вставлять в опенсорсный БИОС coreboot+SeaBIOS - и грузить его оттуда без физического "щупания"
Есть шесть штук, 3.5 1.44, четырёх моделей, от 92 до 2004 года, все рабочие даже в 2М. Самовывоз. Дорого.
Да запросто. И даже внешние, с usb. Лежат рядом с пачкой модемов)
Сколько Вам вешать в килограммах?
Firefox на MinuetOS не фейк?
Это хвалёная сетевая прозрачность иксов, последнее предложение.
Наверное, он запущен на хвостовом linux, а тут только отрисовка по X11. Но могу ошибаться.
> Наверное, он запущен на хвостовом linux, а тут только отрисовка по X11. Но могу ошибаться.Нет, ты не ошибаешься. Маргинальная фиговина на ассемблере врядли осилит накодить POSIX в объеме потребном для запуска ЭТОГО, да еще со всеми либами и системными ифейсами. Люди столько не живут.
Не самая плохая идея — поднимать по кacтрированному микролинyпсу в изолированной среде на приложение, а интерфейс пробрасывать через Х. Должно быть безопаснее.
> Не самая плохая идея — поднимать по кacтрированному микролинyпсу в изолированной
> среде на приложение, а интерфейс пробрасывать через Х. Должно быть безопаснее.Я просто виртуалки подымаю. Без использования протокола X для этого. X и безопасность вообще рядом не живут. Особенно в парсинге их протокола и рядом. Думается небольшой парсер virtio - не только быстрее, но и куда секурнее кроме всего прочего.
Но гораздо удобнее, если окошки программ из виртуалок отображаются на десктопе хостовой ОС, как родные. Ага, благодаря X11.
> Но гораздо удобнее, если окошки программ из виртуалок отображаются на десктопе хостовой
> ОС, как родные. Ага, благодаря X11.Это все прекрасно - но и не секурно, и работает с чебурашьей скоростью. Virtio нормально относится к какому-нибудь 1080p в ютубе. А иксы столько вообще прожуют без суперсервера, и чтоб не было тиринга и затыков?
Видеопотоки разжимает плейер, запущенный в гостевой ОС виртуалки. Тут уж сколько вы ей ресурсов выделили (сколько кодеку ресурсов достанется), так у вас и получится или не получится 1080р или, там, 4K. Протокол тут не причём, он готовую картинку пересылает.
Видеопотоки уже лет двадцать разжимает видеокарта.
Аноним изобрёл QubesOS.
Или Genode.
На изображении (скриншот) видно, что окно браузера в другом окне. Есть кнопки управления окном браузера и есть кнопки управления окном, в котором запущен браузер.
дык фф и так отрисовывает их сам при этом говоря wm, чтобы шапку не рисовал
много лет успешно борюсь с этой дурью
Похоже на простой скриншот.
Нет, это x server. Ниже уже кинули ссылку с пруфом
Нашёл перейдя по ссылке к новости
https://board.flatassembler.net/topic.php?t=23229
"I programmed a simple X-window server for 1.49.50."Один ассеблерщик уделал всех участников священной войны против Wayland.
Да плевать, что он там за огрызок Иксов сделал - Wayland уг только тем что дропает в линукса поддержку кучу в.а./ПК.
Всем:
Вот тут автор жалуется что его ограбили
https://board.flatassembler.net/topic.php?t=22194
- это он случаем не про Kolibry или кто то код закрыл - никто не в курсе?
У кого там есть аккаунт - может спросите? И если всё же Kolibry - носом его тыкнуть в GPL, а иначе можно хотя бы возмущения послать к тем кто закрыл чтобы открывали.
А, то не только на рiдненьку Ukraine - так ещё и на Kolibry высер получается...
Ville, автор MenuetOS, закрыл 64-х разрядную версию из-за конфликта с кем-то из "сообщества", кто хотел много от MenuetOS, но писать умел в основном на форумах https://board.flatassembler.net/topic.php?p=176207#176207Мне откровенно лень вникать в этот конфликт, а тем более отвлекать Ville лишними вопросами. Считаю Ville в своём праве на основании:
1. Не припоминаю на wasm.ru обсуждений, а там так или иначе отмечались все, кто умел кодить на асме.
2. На месте "автора" Колибри, будь я соавтором MenuetOS, а не советчиком, пошёл бы на принцип и отдизасмил M64, после чего причесал бы сорцы до удобочитаемого вида -- действительному соавтору это существенно проще прочих, поскольку достаточное понимание уже есть до реверса.А вообще, пример Колибри очень хорош - его можно показывать всем, кто верует в магическую силу форков, якобы они сами собой начнут жить, когда автор развивать перестанет. Живёт оно в прошлом веке и в оправданиях "32 бита хватит всем".
Запустите свежую версию KolibriOS - и вы увидите что (кроме пресловутой 64-битности) она уделывает MenuetOS по всем фронтам. в KolibriOS больше и полезных программ и драйверов, да и активность в репозитории куда выше. Такое чувство что сюда набежали фанбои MenuetOS или любители проприетарщины... Пора понять, что проект MenuetOS неизбежно загнётся, как только его единоличный создатель потеряет к нему интерес или не сможет продолжать его из-за "биопроблем" - а всё потому что злостный проприетарщик-жадина зажимающий исходники
Перед тем как называть 64-х разрядность "пресловутой", советую открыть книжку по асму и почитать, сколько в этом режиме добавили регистров общего назначения и какие появились режимы адресации. Может быть, удастся сделать неожиданное для себя открытие: на асме AMD64 очень приятно кодить и он существенно лучше годится для обучения, чем IA32. Вот это практические применение этих ОС, если бы у людей был хоть какой-то интерес к асму.А активность...
"На этой странице представлены ночные сборки дистрибутива — это означает, что они всегда содержат самые последние изменения в системе и потому могут быть нестабильны."
Kolibri 0.7.7.0 – 13/12/2009
...правильнее называть имитацией бурной деятельности. При этом авторы не учитывают тот факт, что железо для ОС не выпускается примерно со времён релиза пятнадцатилетней давности. Если не считать всякие Curie, на которых Колибри вряд ли работает.
>А активность...Полноценного релиза действительно давно не было, но ночные сборки постоянно публикуются.
>>А активность...
> Полноценного релиза действительно давно не было, но ночные сборки постоянно публикуются."...потому могут быть нестабильны."
15 лет при таком количестве активных нет релиза -- проект мёртв.
фактически KolibriOS уже давно как перешла на "rolling-release" модель разработки - и, разумеется, все качают последний билд этого месяца (август 2024) со страницы Downloads, вместо отрытого вами старья из 2009. С тех пор было сделано несколько тысяч коммитов, и KolibriOS 2024 vs 2009 - это как небо и земля. При этом, KolibriOS успешно запускается на моём относительно свежем ПК (4 ядра 16 гигов и т.д.) благодаря стараниям сообщества и работает бОльшая часть оборудования, без шутокP.S. я не разрабатываю на ассемблере и вообще скорее пользователь а не разработчик, но даже для меня очевидно что 64-битный кодинг сложнее чем 32-битный, как минимум потому что тебе придётся держать в голове 64-битные значения и всё будет "широким и неудобным"
> фактически KolibriOS уже давно как перешла на "rolling-release" модель разработки - и,"...потому могут быть нестабильны."
> разумеется, все качают последний билд этого месяца (август 2024)
Утверждение ложно. Я не качаю.
> Пора понять,
> что проект MenuetOS неизбежно загнётся, как только его единоличный создатель потеряет
> к нему интерес или не сможет продолжать его из-за "биопроблем" -
> а всё потому что злостный проприетарщик-жадина зажимающий исходникиПочитал твои сообщения. 4 раз встретилось "жадина". Надеюсь, у тебя хватит смелости представиться, кто ты и какова твоя роль в Колибри. Извиняться за хамство в адрес человека, чьим трудом вы пользуетесь, не прошу: у таких как ты отсутствует стыд и совесть. И имей ввиду, что твои "прогнозы" очень похожи на проекции собственных страхов.
Скажем так, я очень люблю опенсорс, ценю его 4 свободы (почитайте Столлмана) и очень не люблю проприетарщину - отчасти поэтому я и нахожусь на этом замечательном форуме. Поэтому добрых слов от меня в адрес какой бы то ни было проприетарщины вы не дождётесь: и неважно, исходит она от старательного (но жадного) одиночки или от огромной корпорации. Но у корпораций хотя бы есть отмазка, почему их продукты проприетарные - юзеров удобнее доить; а здесь же, когда продукт бесплатен но проприетарен, мы видим поведение вроде "собаки на сене". Сколько вот было замечательной фривари скажем под MS-DOS - и вся она "померла" вместе с её создателями зажавшими исходники. Такая же судьба очевидно ждёт и MenuetOS, и негоже даже тратить на неё своё время - пользуйтесь лучше Kolibri у которой гарантировано будущее благодаря опенсорсности
> Скажем так, я очень люблю опенсорс, ценю его 4 свободы (почитайте Столлмана)Подтвердишь делом? Дашь ссылку на свои сорцы под GPL? Мой опыт показал, что болтовня фанатов ничего не стоит - это обычные халявщики-потребители.
>>собственного X-сервера, написанного на ассемблереТо где то разработчики хоронят Х-сервер, типа если в его исходниках разббирпться, то столько не выпьют.. А кто то, вот, переписал на ассемблер. :)
> То где то разработчики хоронят Х-сервер, типа если в его исходниках разббирпться,
> то столько не выпьют.. А кто то, вот, переписал на ассемблер. :)Это еще что. Они вон там денег пытаются хотеть за все это великолепие, если оно 64-битное. С своим зародышевым POSIX'ом, и, вот, графикой на грани издыхания.
Это выглядит примерно как если я возьму гирю, буду бегать с ней на десятый этаж и обратно, за@#$сь в край - и скажу что раз грузчикам таскавшим рояли и диваны платят, то и мне денег должны отсыпать. А то что это таскание гири никому не надо, и пользы нет - ну и что?! Я ж за#$%лся не меньше этих?! Так что извольте! :)
Ну почему же нет пользы? Тренировка сердечно-сосудистой системы, избавление от избыточной массы тела. Вот это и есть вознаграждение.
> Ну почему же нет пользы? Тренировка сердечно-сосудистой системы, избавление от избыточной
> массы тела. Вот это и есть вознаграждение.Ну так это польза - для того кто бегал. А денег ему за это врядли кто даст.
Так он не переписал, а с нуля написал, и упрощённую реализацию. Противники Wayland тоже бы так могли. Гипотетически. :)
Как и сторонники.
А, вообще переписывание на ассемлер - не приведёт к ускорению, по кр.мере без желания *тратить время* на оптимизацию под самый древнючий HW. Тот же Menuet и K. тут примеры ...лагерров на ассемблере. Для примера, никто из них и близко не запустится на первых 32битных процах, даже если им добавить хотя бы несколько десятков-сотен MB вместо 2-4MB на 386 или 8-16MB на 486/iP1, а если и запустится то очень тормозно но, раз не тестируют - наверняка и не запустится.
А сторонникам Wayland зачем писать ещё один X11?
Выглядит неплохо, но бессмысленно. Я был фанатом ассемблера в детстве. Сейчас я осознал, что gcc копилит код намного оптимальнее, чем это сделал бы человек. А если нужны ассемблерные вставки - то extended asm к вашим услугам.
> Выглядит неплохо, но бессмысленно. Я был фанатом ассемблера в детстве. Сейчас я
> осознал, что gcc копилит код намного оптимальнее, чем это сделал бы
> человек. А если нужны ассемблерные вставки - то extended asm к
> вашим услугам.Кодеки таки используют асм или intrinsics - и таки это сильно разгоняет их. Но целиком на асме такую штуку это конечно мазохизм.
При том они еще и денег хотят. Но врядли кто за ЭТО еще и денег насыпет. Ладно бы они там еще на ассемблере писали фирмварь мелкого МК и это позволило бы чип подешевле взять, но у 64-бит компа даже BIOS - жирнее этого и смысл там экономить на спичках?!
Ну раз очередной ихперд с опеннета так решил, денег точно не дадут.
Бинарь с хеллоувротом на гэ цэ цэ будет больше чем вся эта ОС. Что полностью опровергает твои догадки касаемо "намного оптимальнее".
Причина скептицизма?
Человек объективно расписал по фактам, причем тут ваш скептицизм
Game.exe - 6144 байт. Написано на GCC 13. Просто надо знать волшебный ключик -nostdlib.
Отключи libc
И как это поможет генерировать более чистый код без огромного количества мусорных мнемоник?
Западло тут не в размере, а в оптимизациях под мультискалярноть.
Другое дело что у каждой архитектуры и т.б.производителя Ц.П. - оптимизация д.б.разная(а не в стиле средней температуры по полате), а с этим проблема - из-за их всех количества... Потому делают только под самую последнуюю - только этим залагивая все ранние архитектуры, а тогда вопрос - нафиг она тогда нужна?!...
И собственно просто д.б. а то я помню в OpenWC++ 1.9, последняя оф.версия, глянул
- а, она там заключалась фактически в выключении оптимизаций под 386 и 486 оптимизации операции умножения методом сдвигов, т.е.ухудшения обратной совместимости с процами ценой укорения на максимум пару тактов её.
А, судя по мега-лаганутости совремнного ПО и т.б.игр компиляторы - реально всё тормозней и тормозней, притом что нагло пиарят обратное. Это и не удивительно учитывая что производители основных компиляторов: Intel и MS - заинтересованных в скрытом затормаживании ПО для учащения обновлений, но вот то что и линуксы/GCC уже просто дико тормозят на сколько то древних ПК и просто дичайше свопятся(из-за невероятно позорной реализации свопинга... мне этот свопинг на LiveDVD - просто броско невыносим, и т.б. знаю как должен работать свопинг при сколько то вменяемой реализации) - позор их авторам.
> Бинарь с хеллоувротом на гэ цэ цэ будет больше чем вся эта
> ОС. Что полностью опровергает твои догадки касаемо "намного оптимальнее".Э? У меня вся фирмвара собраная этим gcc подымавшая камень с ноля и писавшая это все менее кило была. При том что оно даже "startup" само себе косплеило.
Т.е. дело уж точно не в GCC - а для работы с GPIO он генерит код не хуже того что я бы и на асме соорудил. Только куда читаемее - и абстракции я сделал НАМНОГО круче. Скажем 1 integer однозначно указывает и порт, и пин. Но его пре-декодирование делается макросней, в компилтайме, так что с одной стороны удобно ("универсальный и однозначный дескриптор пина в SoC"), с другой очень эффективно (все сложные моменты макросня считает заранее, это код не портит).
Именно ассемблерный код GCC генерит намного оптимальнее. Оверхед там по другим причинам, и если мы пишем что-то посложнее helloworld, то с ростом объёма кода перестаёт иметь значение.
> Бинарь с хеллоувротом на гэ цэ цэ будет больше чем вся эта
> ОС. Что полностью опровергает твои догадки касаемо "намного оптимальнее".$ cat hello.c
#include <stdio.h>int main()
{
printf("Hello world!\n");
}$ gcc hello.c -O2 -o hello -nostdinc -isystem ~/src/Уссури/include/ -static -nostdlib
$ ./hello
Hello world!$ ldd hello
не является динамическим исполняемым файлом$ strip hello
$ du -b hello
13152 helloОптимизации рано проводить, потому так много.
Не умеете - не беритесь. Если уже мы все равно пишем все на асме без рантайма - то можно выкинуть вообще все и писать под голое API.#include <Windows.h>
static const char HelloWorld[] = "Hello world!";
int Main()
{
DWORD Written;WriteConsole(
GetStdHandle(STD_OUTPUT_HANDLE),
&HelloWorld,
sizeof(HelloWorld),
&Written,
nullptr
);return 0;
};Program.exe - 3584 байт.
И то такой размер только из за выравнивания секций в PE файле. Если бы винда не материлась бы на file-alignment=1, то размер был бы 925 байт. Ну и это еще с заголовками и без упаковки.
> Не умеете - не беритесь.Читать я умею достаточно. И HelloWorld в контексте GCC понимаю как классический пример на Си для наиболее распространённой здесь ОС. Даже printf() не заменял ради экономии на puts(), что бы соответствовало канону.
>[оверквотинг удален]
> WriteConsole(
> GetStdHandle(STD_OUTPUT_HANDLE),
> &HelloWorld,
> sizeof(HelloWorld),
> &Written,
> nullptr
> );
> return 0;
> };
> Program.exe - 3584 байт.Поскольку здесь задействована таблица импорта, то и на GCC с glibc получится сравнимо. Самое печальное для такого соревнования: от kernel32.dll так просто не избавиться, поскольку потребуется инициализировать crss, а шлюз в Linux можно вызвать и напрямую.
> И то такой размер только из за выравнивания секций в PE файле.
> Если бы винда не материлась бы на file-alignment=1, то размер был
> бы 925 байт. Ну и это еще с заголовками и без
> упаковки.Если сравнивать размер кода, то заголовки и вспомогательные секции можно не учитывать, но мне достаточно было обнулить наброс "будет больше чем вся эта ОС".
Вопрос был в том, что если мы и так пишем все с 0, то можем ли мы избавится от лишнего груза, который генерит компилятор и получить голый ассемблерный код? Ответ - можем. Причем без геммора с такими вещами как распределение регистров. Я писал когда то на асме. Я знаю, что это такое. Больше не об алгоритме думаешь, а о том, что в какой регистр положить. Ну на 64х битах с этим конечно попроще. Но на 32х битах геммора много. Да и другие фишки тоже на месте. Нужны ассемблерные вставки, которые гладко интегрируются в код? Есть такие. Нужны обработчики прерываний? Есть. Что еще нужно то? Это конечно не хелло ворлд под DOS, который весит 20 байт. Но все равно неплохо. А заголовки это необходимость. Без них не будет гибкости. Стоит все равно понять одну истину. Какой бы маленький не был EXEшник, но если мы пишем под защищенный режим - все равно в памяти все будет выравнено на границы страниц. Так что лучше не парится насчет выравнивания и заюзать вместо этого упаковку.
С исходным утверждением ветки я и не спорю. Даже несмотря на то, что вручную оптимизированный по размеру асм может оказаться вдвое компактнее выдачи компилятора Си - цена за это окажется несоизмеримо высока (в т.ч. и ущерб скорости). Всего лишь показал, что "опровержение" с фантастическим примером хеллоуворта на гэ цэ цэ оторвано от реальности раз эдак в 100.
> $ gcc hello.c -O2 -o hello -nostdinc -isystem ~/src/Уссури/include/ -static -nostdlib
> Оптимизации рано проводить, потому так много.А со своим printf() для микроконтроллеров, на основе xprintf от Сhan, linux бинарник получился 3.3 кб. :)
>> $ gcc hello.c -O2 -o hello -nostdinc -isystem ~/src/Уссури/include/ -static -nostdlib
>> Оптимизации рано проводить, потому так много.
> А со своим printf() для микроконтроллеров, на основе xprintf от Сhan, linux
> бинарник получился 3.3 кб. :)С соответствующей стандарту printf засада в том, что функции с va_start инлайнятся не очень, потому обработчики лишних спецификаторов остаются.
>> Оптимизации рано проводить, потому так много.
> А со своим printf() для микроконтроллеров, на основе xprintf от Сhan, linux
> бинарник получился 3.3 кб. :)А с минимальной инициализацией своим же кодом и только упрощенным "print" в uart - бинарник менее кило. При том что там вся инициализация.
> uart - бинарник менее кило.На stm32, около 80 байт было, с частично выброшенной таблицей векторов.
> Выглядит неплохо, но бессмысленно. Я был фанатом ассемблера в детстве. Сейчас я осознал, что gcc копилит код намного оптимальнее, чем это сделал бы человекА почему GCC не соптимизирует KDE так чтобы они помещались на дискету вместе с системой?
Во-первых, у менуэта есть хоть 1% функциональности KDE?
Во-вторых, зачем?
> Во-первых, у менуэта есть хоть 1% функциональности KDE?Панель есть, программы запускать может, какие ещё функции от DE используются каждый день?
> Во-вторых, зачем?
Ну, если утверждается что якобы может опитимизировать лучше человека, то почему бы не оптимизировать?
>какие ещё функции от DE используются каждый день?Вы на документик в файловом менеджере стали, просмотр. А он бац, и открыл его прям у себя в окошке. Потому что, Kpats, файловый менеджер использовал часть возможностей Okular для просмотра документа.
Это не совсем про DE, я и в XFCE использовал Krusader, а он на kdelibs.
ФМ как раз (почему то)часть DE в линуксах. Иногда переносимо.
Другое дело что, видел что DE с WM из линуксов - даже DOSу прикрутили, т.б.сюда можно, но никому не нужно, мин. ибо будет не на асме и не своё и скажут очередной линукс, не круто типа.
Программы запускать ещё MS-DOS мог.
Прозрачность с размытием фона, скругление углов, 3D-анимации... без этого вообще невозможно юзать DE.
Вы описали 100% ненужных функций. Работе они не способствуют, а лишь увеличивают нагрузку на систему или сеть(если удаленно работать).
>> Выглядит неплохо, но бессмысленно. Я был фанатом ассемблера в детстве. Сейчас я осознал, что gcc копилит код намного оптимальнее, чем это сделал бы человек
> А почему GCC не соптимизирует KDE так чтобы они помещались на дискету
> вместе с системой?Потому что Qt.
Ну ок, а Гном?
Потому что GTK+. Никто там не ставил задачу получить малый размер исполняемых файлов на выходе.
> gcc копилит код намного оптимальнее, чем это сделал бы человекТу же мульку нам пихают сейчас, только "оптимальным" объявлен ИИ. Результаты соответствующие.
На нынешнем витке развития, ИИ достиг плато своих возможностей, эйфория прошла, многие кричали, что за эти два года напишут код, который перевернет все что уже есть, но итог оказался вполне ожидаем
>разработка ядра которой ведётся полностью на ассемблере.
>Сборки MenuetOS подготовлены для 64-разрядных систем x86 и могут быть запущены под управлением QEMU.Зато на ассемблере.
>Исходные тексты проекта Menuet64 распространяются под ограничивающей лицензией, требующей согласования любого использования в коммерческих целях
Получите минуэт.
Бесполезная вещь.
Полезно для демонстрации того что ПО можно писать так что оно не потребляет 100500 памяти.
Соглашусь. Это разновидность спорта, то есть работа чисто ради рекорда.
Я смотрел КолибриОС, не придумал как её можно использовать. В качестве ОС для устаревшего аппаратного обеспечения не подходит. Настолько вещь в себе.
Ну да, проект больше чисто творческий, как демки для демосцены.
> Полезно для демонстрации того что ПОнадо писать на C для обеспечения сборки на разных процессорных архитектурах: ARM, RISC-V, ...
А кто сказал, что не потребляет? Памяти она ест как раз изрядно, для такого проекта. На виртуалке пришлось 640 МБ выделить А выглядит как GEOS, которому хватало 640 КБ.
За счет чего такие аппетиты у такой малютки?
За счёт ассемблера, очевидно.
Без прозрачных окошек хватило 512 МБ.
На ноутбуке с 512 КБ и двумя дисководами по 720 КБ я даже зарабатывал деньги написанием софта (копейки, конечно, а вот на сабже какие перспективы?).
> За счет чего такие аппетиты у такой малютки?За счёт разницы в разрядности, изоляции процессов, поддержки прозрачности окошек и прочего.
> Полезно для демонстрации того что ПО можно писать так что оно не потребляет 100500 памяти.Ну ладно, ну вот допустим. Потужились и наколбасили там убогих окон. И быстрее на 2% чем сишко. Но это же х86!!! Воо тут афтар попал в просачок - это как раз та самая, то есть платформа на которой размер не главное
Это не про 64-х битный MenuetOS, который в отличии от КолибриОС с её возможностью работы с 8 МиБ ОЗУ, может не запуститься на системе с 512 МиБ ОЗУ.
Где найти 64-х разрядную систему с 512 метрами ОЗУ?
Ранние версии КолибриОС как и 32-х битный MenuetOS требовали значительно больше ОЗУ для своей работы, чем сейчас. Потом сообщество оптимизировало до менее 8.
Я не понимаю, что может столько памяти занимать у 64-х битного Menueta. 98 винда столько не требовала и даже вин2000. Если я не ошибаюсь значительно более функциональная 64-х битная winxp могла работать на 256 МиБ.
Понимать надо, что автору банально незачем заморачиваться вопросом "меньше 512 Мб", поскольку он не имеет смысла, соответственно не должен учитываться при проектировании карты памяти.
Я отвечал всего лишь на этот комментарий:
Полезно для демонстрации того что ПО можно писать так что оно не потребляет 100500 памяти.Это не про Menuet.
64-х битный Menuet это не демонстрация того, что ПО можно писать так что оно не потребляло бы 100500 памяти.
Menuet не потребляет 100500 памяти.
Ваше мнение тут гораздо более бесполезное.
Моё мнение не бесполезно, оно отображает реальное положение дел.
> Моё мнение не бесполезно, оно отображает реальное положение дел.Да, положение дел таково, что эксперты не видят отличие мнимых величин от реальных.
>> Моё мнение не бесполезно, оно отображает реальное положение дел.
> Да, положение дел таково, что эксперты не видят отличие мнимых величин от
> реальных.Специально для таких экспертов в стандарте тип Complex сделали :). Там вы таки - будете их отличать!
> Из недавних изменений в MenuetOS выделяется включение а поставку мультимедийного проигрывателя MPlayer,Удивительно, проект развивается с нулевых, добавляют новое ПО и всегда укладываются в 1.4МБ. Как можно было 20 лет добавляя фичи не велезти за пределы этого объёма? o_O
PS: а что у них сайт так странно в ширину распёрло?
Тоже слежу за проектом с нулевых. Впервые узнал о нем из журнала хакер. Запускал в то время на реальном 4 пентиуме с дискеты. Разработчик из Финляндии кстати, как и Линус.
> Впервые узнал о нем из журнала хакер.Аналогично, узнал из Компьютерры ))
Журнал Хард энд софт. Оттуда узнал.
Журнал Chip
Журнал ][ak3p.
Луркоморье.
Одни фичи удаляют другие добавляют. Вот и влезает.
на современных десктопах одна иконка приложения весит больше 1Мб
шрифты тоже немаленькие (примет, эмодзики!)а тут - никакой графики почти, и минимум функционала
> Проектом также развивается собственный X-серверлицо тех, кто говорит что вяленый это протокол, а реализаций много, в отличие от единственной реализации иксов, представили?
Ты свои прочитал? Развивается, развивается, Карл.
>> Проектом также развивается собственный X-сервер
> лицо тех, кто говорит что вяленый это протокол, а реализаций много, в
> отличие от единственной реализации иксов, представили?Это протокол. Но таки - протокол согласования, грубо говоря, буферов видяхи. Это не совсем точное описание, но в первом приближении - так.
Совершенно не отменяет возможность делать что-то типа RDP или что там кто хотел из этого. А кому надо может майнтайнить иксы и запускать менуэты, это разумеется топовый юзкейс, чтоб ради него себе графическую систему изгадить :)
А если б она набрала комьюнити как арч например... И бегали бы по комментах мамкины админы и доказывали что у них все работает и не потребляет ресурсов
В целом могли бы прикрутить какой-нибудь RDP и приторговвывать рабочей средой. Если там будет нормально работать браузер, то в целом в комплекте с тонким клиентом вполне сносно, но тут нужно договориться с каким-то датацентром что бы заморочились. В целом если сделают какой-нибудь облачный клиент и пару программ для редактирвоания текста, то вполне возможно, что можно использовать как SaaS.
Так это одна из заявленных целей данного проекта (тонкие клиенты и всякого рода терминалы).
> Так это одна из заявленных целей данного проекта (тонкие клиенты и всякого
> рода терминалы).Мелкий линух туда, имхо, запихать и дешевле будет, и поддерживать будет сииииильно больше всего. Пока там кто на ассемблере драйвер накорябает, а в лине он 10 лет уже как был.
А реально если надо - можно урезать в какойнить десяток мегов. Но обычно нафиг не надо ибо на 64 бит железе такие объемы ни о чем. А самая ссаная SD карта, например, которая у меня сохранилась - это 128 мегов. Ну не с флопаря же мне грузиться, право? :)
Извините, но Вы в защищенных тонких клиентах разбираетесь, как заяц в тригонометрии.
Для корпоративного тонкого клиента НЕ НУЖНО поддержка кучи железа, запись на флешку и прочие рбшечки.
НЕ НУЖНО поддерживать кучу программ, включая Доту и танчики.Защищенный корпоративный тонкий клиент должен поддерживать исключительно своё аппаратное обеспечение, на котором он запускается.
Защищенный корпоративный тонкий клиент должен поддерживать только оду-единственную программу для запуска сессии VDI или графического терминала.
Потому что люди на работу приходят работу работать, а не развлекаться и фигней страдать.
Если запилят полную поддержку линух программ то будет бомба.
Но если портируют на arm, то уже будет хит
В мечтах портируют. Там же 1.4 мегабайта х86 ассемблера.
> Если запилят полную поддержку линух программ то будет бомба.
> Но если портируют на arm, то уже будет хитУ ассемблера есть небольщая подстава - для этого надо его целиком заново переписать. Собственно поэтому и появился си :)
И автор МенуэтОС об этом прекрасно знает.
Учитывая, что ARM-ассемблер не предназначен для ручного написания нинасколько, в отличие от x86…
Всё конечно хорошо, но судя по новостям, развитие 32-битной ветки прекратилось.
Со всеми этими проектами на асме, которые влезают на дискету, есть одна проблема.Они представляют собой прототип, а не рабочую ОС. Примерно 5% от того, что нынче умеет ОС общего назначения.
Если начать добавлять функциональности, то размер начнёт расти, но самое главное в другом. Начинает расти сложность разработки, в результате после достижения уровня примерно в 30-35% от "обычных" ОС, проект падает под собственным "весом".
Как верно заметил коллега выше, именно поэтому и придумали С.
Проблема этих ОС на асме такова: один человек сел и написал, а сотня других упаковывает исходники в пакеты и добавляет трендовые сеты иконок. Последним жизненно необходимо превентивно что-то заявить по этому поводу, что бы не возникало неудобных вопросов.
> Проблема этих ОС на асме такова: один человек сел и написал, а
> сотня других упаковывает исходники в пакеты и добавляет трендовые сеты иконок.
> Последним жизненно необходимо превентивно что-то заявить по этому поводу, что бы
> не возникало неудобных вопросов.Было бы круче если программист вместо программирования - занимался бы какой-то рутиной по заворачиванию своего результата жизнедеятельности в пакет и прочими иконками?
>> Проблема этих ОС на асме такова: один человек сел и написал, а
>> сотня других упаковывает исходники в пакеты и добавляет трендовые сеты иконок.
>> Последним жизненно необходимо превентивно что-то заявить по этому поводу, что бы
>> не возникало неудобных вопросов.
> Было бы круче если программист вместо программирования - занимался бы какой-то рутиной
> по заворачиванию своего результата жизнедеятельности в пакет и прочими иконками?Делать на постоянной основе вручную работу, что автоматизируется - значит расписаться в своей профнепригодности. Естественно, программист не будет таким заниматься. Потому та сотня роботов в обязательном порядке набросит на программиста: он программирует, да ещё и прототипы, а значит не тем занят.
Установи RebeccaBlackOS уже сейчас и получи МинетОС бесплатно!
Смешно...
is a Debian-based live distribution which can be used to run Wayland desktop session...
и очевидно потому ... отказывается от поддержки 32-битных процессоров...
Хостится на sf net - бонусом держите вставку вирусни.
Но, даже просто как для линуксов - НИЧЕГО интересного.
Я вот недавно видел какой то линукс: 1) весь в контейнерах; 2) поддерживающий КУЧУ(>2) типов репозиториев; о чём заявленно на главной странице; 3) даже глстраница на английском:(
- никто не знает название? (ссылка потерялась, да и не понравился чем то, но концепция верна)
P.S.
Так же, видел когда Linux сборку - ~на x86 ассемблере, вопрос тот же.
Наверно это был Qubes, но вам бы посоветовал поставить Windows 11 с ИИ-Recall фичей.
Ах хороша) Вася накидал туда и вейландов и de и весь набор деталек лего от всех игрушек)
menuet, от pas menus – маленькие шаги) – старинный французский парный танец. Размер трехдольный – ¾. Темп умеренныйа не то что ты думаешь)