LINUX.ORG.RU

Loss32 — проект дистрибутива с реализацией Win32

 , ,


1

3

Проект Loss32 развивает дистрибутив, который сочетает в себе ядро Linux и графическое окружение, основанное на Windows-совместимых компонентах. Компоненты используются из Wine и ReactOS.

Ключевым отличием от ReactOS является отказ от идеи использования ядра Windows NT в основе и использование подхода, близкого к Android (в котором также используется ядро Linux для вышеуказанных целей, но не используются такие компоненты, как Systemd, утилиты GNU, Wayland/X11, менеджеры пакетов и т.п), позволяющего добиться большей аппаратной совместимости по сравнению с оригинальным проектом.

В качестве композитного менеджера используется Mutter, среда рабочего стола базируется на приложениях и библиотеках Win32, таких как explorer.exe и shell32.dll.

Сайт проекта

Подробности (ycombinator.com)

>>> Подробности (OpenNet)



Проверено: hobbit ()
Последнее исправление: unfo (всего исправлений: 6)
Ответ на: комментарий от wandrien

Ой, моя плохо-плохо думай. :) Я тыкал туда, но не на иконку, а на всю полосу. И оно не работало.

PcheloBiaka
()
Ответ на: комментарий от James_Holden

Это лучший на свете двухпанельник (с моей точки зрения). Но с точки зрения «ассоциации истинных двухпанельщиков» это не трушный, а наоборот блоатварьный. Хотя открыл я Крусадер, и на меня как вывалилось всё… Нет, жить можно, конечно, но запускать стоит только когда очень надо. Дольфин няшка (а Конкуерор, вот уж мультипанельник был, вот там сила была… но он уже не торт)

PcheloBiaka
()
Ответ на: комментарий от PcheloBiaka

Хотя открыл я Крусадер, и на меня как вывалилось всё…

Открою страшную тайну: в КДЕ всё такое. Для стороннего наблюдателя «как вывалилось всё» начинается сразу после загрузки плазмы (хотя я только скрины смотрел, но мне хватило).

bread
()
Ответ на: комментарий от bread

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

А крусадер выглядит как любой двухпанельник. Если видел один, ты видел их все. И кеды тут не при чём

PcheloBiaka
()
Ответ на: комментарий от PcheloBiaka

Просто нужны они редко

Кому как, я практически живу в mc. Но скорее благодаря user menu, а не из-за панелей. На лоре кстати хейтят таких неосиляторов консольки. Какой уж там крузадёр, вообще шапками закидают.

bread
()
Ответ на: комментарий от wandrien

А инженер, человек с профильным образованием.

Быть инженером не значит быть обязанным страдать. У нормального инженера есть современное оборудование, делающее решение задач более эффективным и удобным.

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

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

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

Все же, те, кто профессионально работают с инженерными системами/пишут программы/считают модели etc. пользуются вещами у которых есть клавиатура и да, с драйвером в ядре как правило. А то, что в потребительском сегменте распространены калькуляторы, ребят за мейнфреймами не сильно волнует.

recei
()
Ответ на: комментарий от tiinn

Мне ВСЕ диски нужны, чтоб я их мышкой кликать мог.

А я не хочу для этого снимать руку с клавиатуры и хвататься за мышку. Хочу прямо с клавиатуры и переключать. Я понимаю когда мышка используется для всякого рисования-черчения, но использовать ее для переключения дисков также странно как клавиатуру для черчения.

watchcat382
()
Ответ на: комментарий от PcheloBiaka

двухпанельники - классная вещь. Тогда когда они нужны. Просто нужны они редко.

И я даже соглашусь,что именно ДВУХпанельники не очень часто нужны. Куда чаще полезная деятельность происходит в ОДНОМ каталоге. И вот чем его на экран отобразить в удобном виде? Работать в командной строке и постоянно дрочить ls - не вариант. Текущее содержимое каталога надо видеть без дополнительных действий для этого и оно не должно постоянно уползать за верхний край экрана. И надо иметь возможность проделывать с ним часто востребованные действия нажатием функциональных клавишь. Просмотр по F3 как наглядный пример,причем то чем именно смотреть должно выбираться автоматически в зависимости от файла. Нужен некий «однопанельник» с примерно теми же возможностями что у двухпанельников и командной строкой внизу - как у них же,на случай когда преднастроенных действий по кнопкам не хватает и надо сделать что-то особенное(запуск чего-то с особыми ключами как пример). Да, знаю что в mc можно одну панель на всё окно раздвинуть но он всё-таки не является полноценной gui программой и поэтому ограничен в своих «выразительных способностях». А вот чем его заменить - так и не знаю. И чтобы замена не была особо монстрообразной.

watchcat382
()
Ответ на: комментарий от bread

я практически живу в mc.

Аналогично.

Но скорее благодаря user menu, а не из-за панелей.

Именно! И user menu, и действия, повешенные на нажатие enter в зависимости от типа файла, и то что на функциональных кнопках висит.

хейтят таких неосиляторов консольки.

Я всегда спрашиваю «осиляторов» как они предлагают отображать на экране содержимое текущего каталога. Ежеминутно дрочить ls - абсолютно не вариант. Особенно если в каталоге достаточно много файлов. Чтобы совершить хоть какое-то действие с файлами - мне надо их видеть. А мне предлагают держать в памяти (своей) текущее состояние рабочего каталога и периодически его там «обновлять» с помощью очередного ls. У меня и без того есть что в памяти держать.

watchcat382
()
Ответ на: комментарий от X512

безопасную и надёжную архитектуру с драйверами в пространстве пользователя.

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

watchcat382
()
Ответ на: комментарий от watchcat382

А я не хочу для этого снимать руку с клавиатуры и хвататься за мышку. Хочу прямо с клавиатуры и переключать.

Такая опция в винде тоже имеется. Вот только, забиндена на Alt+F1 или Alt+F2, а в линуксе конкретно с этим сочетанием всё тяжко.

tiinn ★★★★★
()
Ответ на: комментарий от tiinn

Alt+F1 или Alt+F2, а в линуксе конкретно с этим сочетанием всё тяжко.

Если не говорить про голую консоль, а хотябы про Иксы - то у них всё нормально с любыми сочетаниями кнопок. Еще и отдельно передается событие нажатия и событие отпускания. Так что есть всё необходимое чтобы делать хорошее управление с клавиатуры. Основная беда в том, что в большинстве стандартных виджетов в обычно используемых библиотеках оно по умолчанию НЕ сделано хорошим, а авторы софта ленятся дописывать (или не знают как).

watchcat382
()
Ответ на: комментарий от PcheloBiaka

Кстати, вот удачный пример сочетания удобства командной строки и отображения состояния текущего рабочего каталога: https://lagovskiy.ru/posts/norton-commander-1/02.png Уверен что многие из программистов старой школы это видели в действии. Странно что до сих пор никто не сделал такое в линуксе,естественно с использованием возможностей современного GUI,а не в текстовом режиме как там на картинке.

watchcat382
()
Ответ на: комментарий от watchcat382

Не понял что ты имеешь в виду. Не вижу что тут такого чего стоит держаться? одновременно три вида предоставления одной и той же информации? Я прямо сейчас нажал в Дольфине на папочку «Документы», сбоку появилась инфа о количестве папок/файлов в ней и пр. Захотел, разделил окно и у меня слева одни папочки, а справа зашёл в Документы и вижу её содержимое и на боковой панели вижу информацию и предпросмотр (включая проигрывание видео и аудиофайлов) и инфа, например разрешение картинки и частота кадров и права файла и пр. Что я неимоверно теряю не глядя в нортоноподобный интерфейс, хоть с гуём хоть без?

PcheloBiaka
()
Ответ на: комментарий от PcheloBiaka

Не понял что ты имеешь в виду.

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

вижу информацию и предпросмотр (включая проигрывание видео и аудиофайлов) и инфа, например разрешение картинки и частота кадров

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

Вообще, Долфин неплохая программа в смысле функциональности. Но очень уж монстрообразная. Если я у себя попытаюсь сделать apt-get install dolphin то получу запрос на установку аж 109 пакетов. Как-то многовато на мой взгляд для файлового менеджера. И сразу возникают опасения что и куда там попытается «интегрироваться» и что при этом в поведении системы поменяет (читай-испортит). Ну и когда я однажды пробовал Долфин пощупать(правда это давно было) - мне показалось в нем неудобно сделаным управление с клавиатуры. Может просто из-за непривычности. Так-то и в нортоноподобных далеко не всё сделано эргономично, просто к их управлению все давно привыкли. Но и хвататься ежеминутно за мышь при всего лишь операциях с файлами - что-то никакого желания не возникает. Это примерно как предложение использовать для рисования клавиатуру.

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

Для справки у так называемого модульного или гибридного ядра по прежнему единое адресное пространство для модулей/драйверов ядра и любой код может испортить память всего ядра.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

У пространства ядра по определению единая память

Именно про это я и говорил.

Для защиты от этого придумали микроядро где драйверы и сервисы работают в отдельных адресных пространствах и не могут портить память друг друга.

Именно так и надо делать если хотеть защиты от глюков драйверов. Но уж точно не драйверы железа в юзерспейсе.

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

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Именно так и надо делать если хотеть защиты от глюков драйверов. Но уж точно не драйверы железа в юзерспейсе.

Это одно и тоже. Несколько адресных пространств бывают только режима пользователя. Нескольких адресных пространств режима ядра не бывает. У микроядерных ОС драйвера работают в режиме пользователя.

Однако это уже будет не линуксовое ядро. Придется писать какое-то новое.

Не обязательно. У ядра Линукс уже есть инфраструктура чтобы писать драйвера в пространстве пользователя. Например интерфейс VFIO для написания драйверов PCI устройств в пространстве пользователя. Или libusb, которая позволяет делать драйверы устройств ввода в пространстве пользователя.

X512 ★★★★★
()
Ответ на: комментарий от X512

Нескольких адресных пространств режима ядра не бывает.

В общем случае неоднозначное утверждение. Линукс ведь не только на интеле работает. Поэтому что считать «режимом ядра» - вопрос дискуссионный.

Или libusb, которая позволяет делать драйверы устройств ввода в пространстве пользователя.

Этим даже я пользовался для взаимодействия со своими микроконтроллерными поделками. И именно поэтому поделки всегда включал в другую шину usb, не в ту где клава. Благо что на используемой для экспериментов плате такая возможность есть. Ибо в процессе отладки поставить шину раком - раз плюнуть.

watchcat382
()
Ответ на: комментарий от watchcat382

В общем случае неоднозначное утверждение. Линукс ведь не только на интеле работает. Поэтому что считать «режимом ядра» - вопрос дискуссионный.

Очень даже однозначное. На актуальных платформах есть только одно адресное пространство ядра и несколько адресных пространств пользователя (плюс аппаратная виртуализация, но это уже другая история). Платформы с несколькими кольцами защиты уже не актуальны и было показано, что кольца защиты x86 между пользовательским и гипервизором можно взломать и в результате там можно делать всё тоже самое, что и в кольце гипервизора. Современные ОС используют только два кольца.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

Платформы с несколькими кольцами защиты уже не актуальны

Это x86 не актуально?

кольца защиты x86 между пользовательским и гипервизором можно взломать

Разговор был не про взлом. Взломать много чего можно. Это не значит что не надо использовать. Это значит что надо пинать процессоростроителей чтобы исправили. С практической точки зрения куда важнее защита от глюков и ошибок в драйверах, чем от взлома.

Современные ОС используют только два кольца.

Можно подумать что «современные» ОС (это наверно линукс которому 35 лет?) являются образцом технического совершенства. Говорили ведь как раз о том что драйверы в одном адресном пространством со всем прочим ядром - это плохо. По уму надо бы не только драйверы железа но и например сетевой стек отделить чтобы какой-нибудь переполнение буфера не приводило к падению всего, как это в старых виндах случалось не один раз.

А два кольца в линусе - это сделали в целях переносимости на те архитектуры где больше нету. На простые ARM например. В линуксе когда его делали переносимым не только это упростили. Например переключатель задач - исходно он использовал аппаратные возможности x86, как собственно и должно быть. Но потом, в целях переносимости решили что и программное решение сойдет. Пруф: https://habr.com/ru/articles/438042/ И ничего хорошего в таком подходе нет. Операционная система по определению должна максимально использовать аппаратные возможности железа. А еще молодой (в то время) финский студент то ли не разобрался то ли поленился разобраться с сегментным механизмом в x86 и теперь мы имеем невозможность делить адресное пространство процессов на сегменты и использовать аппаратную проверку корректности «дальних» (far) вызовов функций и аппаратную проверку границ массивов (ну хотябы переполнения стека). Хотя под дос-экстендерами и то и другое работало и я даже под них писал когда-то.

watchcat382
()
Ответ на: комментарий от watchcat382

Разговор был не про взлом. Взломать много чего можно. Это не значит что не надо использовать. Это значит что надо пинать процессоростроителей чтобы исправили. С практической точки зрения куда важнее защита от глюков и ошибок в драйверах, чем от взлома.

Процессоростроители уже давно забили на сегменты и кольца защиты. Они сейчас есть чисто для галочки чтобы всякие MS DOS и Windows 95 всё ещё запускались. Они больше не оптимизируются и не исправляются. В новых процессорных архитектурах больше не делают сегменты ли больше двух колец защиты.

X512 ★★★★★
()
Ответ на: комментарий от watchcat382

Сверху - список файлов, внизу - командная строка,причем не в виде одной строки как в mc,а в виде окошка на несколько строк что удобно если надо увидеть результат работы команды или сообщение об ошибке.

эээ… Вот у меня в Дольфине же внизу консоль. Я там могу команды задавать, смотреть dmesg всякие… Что не так?

Вообще, Долфин неплохая программа в смысле функциональности. Но очень уж монстрообразная. Если я у себя попытаюсь сделать apt-get install dolphin то получу запрос на установку аж 109 пакетов.

Тут сразу две проблемы:

  1. Всё что я описал умеет делать добрая половина линуксовых ФМ. Дольфин я привожу только как пример на котором работаю и который знаю. 2)Вторая проблема - перестаньте уже все считать сколько пакетов притянет та или иная программа. Вы вручную каждый пакет собираете вручную разгребая зависимости, или за вас это делает пакетный менеджер? Не понравится, просто удалить и удалить неиспользуемое. Пакетный менеджер всё почистит. А по размеру - любой современный хэлоуворлд-проект (на питоне с его venv, или растоманский, на пхп, да много их, да тот же докеропроект) переплюнет все кеды вместе взятые. Это не отменяет, конечно, переусложнённость кед, но вы экономите на спичках. В любом случае, Дольфин, Кате со всеми потрохами разбросаными по сотне пакетиков - это всё равно меньше Pycharm и прочего. Не занимайтесь ерундой.
PcheloBiaka
()
Ответ на: комментарий от X512

Процессоростроители уже давно забили на сегменты и кольца защиты.

Сначала на надежность вычислений забили программисты. Потом и процессоростроители. Я бы не сказал что это что-то хорошее.

В новых процессорных архитектурах

Это каких? Они вообще есть - новые? Именно архитектуры? Пока что всё сколько-нибудь распространенное делается на идеях чуть ли не из 80х годов. Число транзисторов на кристалле растёт, а вот производительность увеличивается на единицы процентов в год. https://habrastorage.org/r/w780/getpro/habr/upload_files/1ed/406/7df/1ed4067df13292eb93e1895388ca5730.png При этом список найденых ошибок и в софте и в железе исправно продолжает пополняться.

больше не делают сегменты ли больше двух колец защиты.

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

watchcat382
()
Ответ на: комментарий от watchcat382

Потом и процессоростроители. Я бы не сказал что это что-то хорошее.

Ничего не забили. Сама по себе модель с одним адресным пространством ядра и несколькими адресными пространствами пользователя полностью надёжна с математической точки зрения. В дополнительных кольцах или сегментах просто нет необходимости.

Если вы можете придумать модель лучше – предлагайте. Пока не придумали.

X512 ★★★★★
()
Ответ на: комментарий от PcheloBiaka

Вот у меня в Дольфине же внизу консоль.

Не знал что он так может. Я его видел в примерно том же виде как на картинке в Википедии: https://upload.wikimedia.org/wikipedia/commons/6/6d/Dolphin_(file_manager)_21.04.1_screenshot.png Никакой консоли там небыло.

Всё что я описал умеет делать добрая половина линуксовых ФМ.

Значит вы можете назвать еще хотябы один с возможностью сочетания окна со списком файлов и окна консоли. Софта в линуксе ОЧЕНЬ много поэтому «перещупать» все варианты крайне затруднительно. Для того на форуме и обмениваемся опытом.

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

С чего бы вдруг? Это ведь мне потом разбираться в том что от чего зависит и на что влияет.

за вас это делает пакетный менеджер?

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

Пакетный менеджер всё почистит.

Про все пакетные менеджеры не скажу, но вот конкретно apt любит оставлять «хвосты». К счастью обычно в виде лишь пустых каталогов которые почему-то не может удалить, но бывает и в виде файлов которые считает используемыми. Видимо виновато не всегда корректное прописывание зависимостей в пакетах если оно делается каким-нибудь автогенератором.

А по размеру - любой современный хэлоуворлд-проект (на питоне с его venv, или растоманский, на пхп, да много их, да тот же докеропроект) переплюнет все кеды вместе взятые.

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

это всё равно меньше Pycharm и прочего.

Зачем мне Pycharm дома? Особенно учитывая что я не испытываю никакого восторга от Питона и тем более не имею желания на нем писать. Вы бы еще предложили на каком-нибудь вижуал бейсике самовыражаться:)

Не занимайтесь ерундой.

Я не на работе(вообще не работаю), а вы не мой начальник. Соответственно позвольте мне самому решать что считать «занятиями ерундой», а что нет. Лежать на диване и не делать ничего - скучно. Вот и нахожу себе всякие интересные (для меня) занятия. Например копание в линуксе. Хотя наверно можно купить Мак и «просто пользоваться». Но это СКУЧНО.

watchcat382
()
Ответ на: комментарий от X512

В дополнительных кольцах или сегментах просто нет необходимости.

Это нам внушают что «в колбасе необходимости нет» (С)советская классика.

Сама по себе модель с одним адресным пространством ядра и несколькими адресными пространствами пользователя полностью надёжна с математической точки зрения.

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

Если вы можете придумать модель лучше – предлагайте. Пока не придумали.

Её уже давно не только придумали те,настоящие, инженеры которые проектировали 80386, но и реализовали в кремнии. И все интеловские процессоры включая самые последние-модные всё это поддерживают. Надо лишь использовать,а не заменять программными затычками (см. статью выше про «эволюцию» переключателя задач в линуксовом ядре). Но нынешним программистам тупо ЛЕНЬ разбираться в возможностях железа, они исповедуют принцип «тяп-ляп и в продакшн». Это не только к ядру относится, а к абсолютному большинству софта. Я уже выше писал что операционная система должна по максимуму использовать возможности железа.

Кстати, языки для надежного программирования тоже уже давно созданы (Ada). Можно взять совершенно бесплатно и официально и использовать. Более того - я не только видел компилятор Meridian ADA который умел использовать аппаратные возможности x86 (под дос-экстендером), я даже писал на нем в начале 90х. То есть техническая возможность сделать такой компилятор не только есть, она была реализована. Более того, GCC генерирует код именно в виде отдельных сегментов. А сваливает их в одну общую кучу - линкер. Кстати, формат elf поддерживает «многосегментные» программы. Это используется кое-где в микроконтроллерах. Виноват ли сам линкер или его настройки (ld script) - тут сказать затрудняюсь. Во всяком случае при полностью ручном написании этого скрипта под конкретную программу - многосегментный elf-файл создать можно. Но в линуксе он не загрузится - ни ядро и системный загрузчик такое не умеют.

watchcat382
()
Ответ на: комментарий от watchcat382

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

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

(см. статью выше про «эволюцию» переключателя задач в линуксовом ядре). Но нынешним программистам тупо ЛЕНЬ разбираться в возможностях железа

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

X512 ★★★★★
()
Ответ на: комментарий от watchcat382

Никакой консоли там небыло.

Современные программы имеют множество режимов. Они могут многое, только надо включить то, что именно пользователь хочет. В дольфине и боковые панели переключаются и на панель инструментов можно добавить кнопок и консоль включить и двухпанельным сделать и включить и отключить семантику. Когда много функционала, то многое можно менять. Просто надо не бояться выползать из раковины :) Это не кнопомский Наутилус, или как он теперь называется.

Значит вы можете назвать еще хотябы один с возможностью сочетания окна со списком файлов и окна консоли

На вскидку xfce-шный Thunar может. lxde-шный… как его… забыл, может. Feh, по моему тоже может, давно не тыкал. Гномий Наутилус не может. Но в него можно добавить плагин и тогда будет висеть неотключаемая консоль. Но гномики на то и гномики, там весь софт такой.

С чего бы вдруг? Это ведь мне потом разбираться в том что от чего зависит и на что влияет.

По секрету - кдешный софт (и его библиотеки) ни на что кроме себя не влияют. Это не так работает. И руками разгребать в любом случае это не надо. Во всех пакетных менеджерах есть функция удаления неиспользуемых иблиотек. Если поставил поиграться, а потом удалил программу, то зависящие от неё библиотеки так и удаляют. Только про Slakware не знаю.

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

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

Хотя наверно можно купить Мак и «просто пользоваться».

А можно просто ногу отстрелить :) Зачем е из крайности в крайность? Просто принять, что обратно джина всепожирания уже не засунуть. Все жрут немерянно. И кеды тут даже не в первой десятке.

PcheloBiaka
()
Ответ на: комментарий от X512

Так не делали даже во времена, когда сегменты были актуальны в x86.

Не только делали, я даже лично это делал. И это работало. Хотя я соглашусь с тем,что в России начала 90х мало кто занимался программированием под дос-экстендеры в которых это можно было задействовать. Но это именно российская специфика. Тот экстендер который использовал я (нелегально конечно) стоил около $600. И это значит что его за такие деньги покупали.

65536 сегментов, что мало для современных реалий

Более чем спорно.

если каждый массив в отдельный сегмент класть.

С трудом представляю себе программу которая использует 65535 именно отдельных массивов. К тому же никто не принуждает именно каждый массив класть в отдельный сегмент. А только те, переполнение которых наиболее опасно. Это в первую очередь те в которые поступают данные откуда-то снаружи программы, не подконтрольные программисту. Главное чтобы была возможность это сделать, а как ее использовать это уже головой думать надо. Хуже когда возможности нет вообще.

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

Вот именно что ТОГДА это было правдой. И возник устойчивый миф. Если немного покопаться то выяснится что медленно это было на первых 386 где сегментные регистры не кэшировались поэтому их приходилось загружать аж из RAM. Внешнего кэша на тех платах тоже небыло. Уже на поздних 386 платах появился внешний кэш,позволяющий сэкономить обращения к RAM,а на 486 и совсем быстрый, встроенный в проц. А миф о медленности - остался.

А сейчас весь этот аппаратный функционал сделан чисто для галочки

Это вам инженеры-разработчики Интела сказали? Про «для галочки»?

работает медленно.

Разговор не о скорости,а о надежности. Вон если линуксовому ядру выключить средства противодействия spectre и meltdown то тоже быстрее работать будет. Только почему-то обычно НЕ выключают. У вас вот в командной строке ядра mitigations=off стоит?

watchcat382
()
Ответ на: комментарий от PcheloBiaka

На вскидку xfce-шный Thunar может.

Опять же - если погуглить скриншоты то выглядит он типично плюс-минус также как и Dolphin: https://commons.wikimedia.org/wiki/File:Thunar-1.6.2.png На первых нескольких страницах гуглокартинок мне не попался НИ ОДИН его скриншот с консолью. (как кстати и для Долфина). И, кстати, Thunar не требует установки сотни пакетов,а всего лишь 14.

Но тут возник так сказать «попутный» вопрос: если содержимое отображаемого каталога меняется то умеет ли Thunar отслеживать изменения и самостоятельно перерисовывать отображение? Ядро не запрещает, inotify в линуксе есть. Это та возможность которой лично мне не хватает в mc. Если в Thunar это есть то консоль можно запустить и отдельно. Вобщем - есть повод поэкспериментировать. Заодно посмотреть как там с клавиатурным управлением.

кдешный софт (и его библиотеки) ни на что кроме себя не влияют.

А у меня вот нет такой непокобелимой уверенности в этом.

И один калькулятор на электроне займёт больше всех кед.

Калькулятор-то на электроне ЗАЧЕМ? Тут даже на приказ начальника-дурака сослаться не получится ибо ему всё равно какой калькулятор.

оказывается электронов теперь тоже надо держать несколько.

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

Хотя наверно можно купить Мак и «просто пользоваться».

Зачем е из крайности в крайность?

Почему крайность? Техника от Эппл традиционно считается даже тут на ЛОРе самой прогрессивной. Насколько это сейчас так - не знаю. В те времена когда я выбрал Линукс (30 лет назад) цены на Маки были абсолютно не адекватны в сравнении с Интелом.

Сейчас десктоп от Эппла из начала 2010х годов можно купить тысяч за 20 на Авито. Насколько оно лучше обычного компа за те же деньги - сказать затрудняюсь, личного опыта пользования нет. Специально уточню что я говорю о сравнении удобства пользования, а не «голой» вычислительной мощи, которая обычным человеком редко востребована, тем более дома.

Просто принять, что обратно джина всепожирания уже не засунуть.

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

Все жрут немерянно. И кеды тут даже не в первой десятке.

В данном случае важно не то что жрут, а то что в моих задачах полностью отсутствует необходимость в их использовании.

watchcat382
()
Ответ на: комментарий от watchcat382

Опять же - если погуглить скриншоты то выглядит он типично плюс-минус также как и Dolphin:

… Как там говорят? Кто хочет, ищет способы это сделать, а кто не хочет ищет причины этого не делать. Кто я такой, чтобы лишать человека удовольствия не пользоваться ничем хорошим? Упрашивать я чтоли должен? Захотел бы, включил бы мозг и поставил хоть одно из тех приложений и попробовал что у него там в меню и какие у него опции и чего в настройках. но человеку хочется бесконечную жвачку жевать про то, что «в современном мире програмы не могут, а могли бы» и поминутно в раздумиях поправлять пенсне… Jedem das Seine.

А у меня вот нет такой непокобелимой уверенности в этом.

Сидит черепашка у лужи и размышляет: «вот если я туда ногу опущу, что будет? Может там кислота на самом деле? Может она мне ногу растворит? Как страшно. Или там плавают страшные трёхголовые акулы-мутанты? Ой как будет больно, если они мне ногу откусят. А не дай бог и вовсе в воду утянут и поминай как звали. Или там подводная лодка и меня враги утащат к себе в штаб и будут пытать? А я ведь и тайны никакой не знаю, обидно будет.» Проходит заяц, прямо по луже, шлёп-шлёп-шлёп. Черепаха в страхе вцепилась и рассказывает какие там ужасы могут быть. Спасти глупого хочет. А заяц говорит «чего тут бояться? Тут сантиметр глубины максимум, ничего тут нет!». А черепашка ответила:

А у меня вот нет такой непокобелимой уверенности в этом.

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

А может рискнуть всем и отправиться в это опаснейшее приключение и увидеть как выглядят программы своими глазами? Где наша не пропадала? :))

PcheloBiaka
()
Ответ на: комментарий от PcheloBiaka

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

Я даже больше скажу - Thunar у меня был, в комплекте Simply Linux когда я с ним пару лет назад экспериментровал с целью посмотреть что за зверь. Интересно же отечественный дистр пощупать. Но вот никакого упоминания о консоли в Тунаре - там небыло. Как минимум в главном меню ничего такого. Да вот сами посмотреть можете на видео подробный разбор что у него там в меню есть https://www.youtube.com/watch?v=1-dYXdBMAyg Если бы вы не сказали про консоль - мне даже в голову не пришло бы что она там вообще может быть. Впрочем - несколько сделаных только что запросов в гугл так и не прояснили вопрос где же там командная строка в Тунаре. Вы точно не ошибаетесь и она там есть? Это как же надо запрятать эту возможность что на нескольких страницах гугла нет НИ ОДНОГО скриншота с командной строкой?

Сидит черепашка у лужи и размышляет

Это всё философия. А мне интересен ответ на вполне конкретный технический вопрос - где консоль в Тунаре? Что надо нажать чтобы ее увидеть? Ну хотябы что спросить у гугла чтобы увидеть на скриншоте. Это на случай если вдруг в моем дистрибутиве его собрали с откюченной этой возможностью.

watchcat382
()
Ответ на: комментарий от watchcat382

Вы надеюсь в курсе, что поддержка сегментов в 64 битном режиме x86 (long mode) вообще удалена (кроме рудиментарной поддержки FS, GS для TLS которые работают как прибавление к адресу новых регистров FSBASE, GSBASE вместо использования таблицы сегментов)?

X512 ★★★★★
()
Ответ на: комментарий от X512

поддержка сегментов в 64 битном режиме x86 (long mode) вообще удалена

Я вообще-то везде уточнял что имел в виду именно классический х86, а не 64-битный. И недоиспользование его аппаратных возможностей линуксовым ядром.

watchcat382
()
Ответ на: комментарий от watchcat382

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

Важно что сейчас можно сделать. Микроядро точно можно сделать и они уже есть и использоваться.

X512 ★★★★★
()
Ответ на: комментарий от X512

32 битное ядро

Что плохого в 32-битном ядре? При использовании сегментного механизма у него ограничение аж в 128 Гб памяти при использовании PAE. Для абсолютного большинства применений достаточно с большим запасом. Я же говорю - инженеры Интела всё предусмотрели, проблема якобы ограничения памяти чисто программная, потому что всё в один сегмент запихали.

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

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

watchcat382
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.