я почему и подчеркнул две первые операционки, потому что они не реальные, не исследовательские. На самом деле они не просто рабочие, они даже коммерческие и под них очень много софта и потдержка старого железа очень богата. Просто они уже мертвые, их потдержка прекращена, но это не помешает им нормально работать на старом компьютере. К примеру OS/2 была прототипом семейства операционок windows nt (windows nt, windows 2003, xp, vista, 7). Некоторые даже пользуются os/2 досихпор и не жалуются. Вот вам совет: если на старый комп нужна шустрая операционка, то OS/2 если нужна нативная потдержка windows приложений или BeOS если не нужна, но вы хотите действительно шуструю и безотказную ос.
Мне казалось, что подобные ОС находятся всетаки ближе к исследовательским проектам, нежли к чему-то, что можно реально использовать. Например, вопрос о поддержке оборудования очень актуален.
Также они отличаются своей безотказностью.
Действительно, как может отказать то, что не работает. ;-)
Ну йо-моё. Можно хоть на этом сайте не писать новости подобного характера. Ну по тематике open-life.org совсем не подходит. Даже на оффтопик нормальный не подходит. И к посту прикрепили тег «порно» — это вообще…
Удалите, пожалуйста, данный топик. И извините за критику.
Да, по скорости поиска по коммитам и кодовой базе гиту просто нет равных. Собственно одна из причин гит-зеркала кода реактоса — возможность поиска в реальном времени.
Советую для старых компьютеров использовать операционки на микроядрах (BeOS, OS/2, minix, syllable, amigaOS). С этими операционными системами в на медленном оборудовании не заметите разницы, как если бы работали на современном. Также они отличаются своей безотказностью.
Кстати, акции интернет-компании Baidu Inc. после официального объявления Google планов о пересмотре политики работы в Китае и возможном закрытии офисов компании, выросли в стоимости на 11%. Уже второй раз за месяц (первый раз стоимость акций возросла на 15%).
А акции Google упали в цене (что логично) на 1.8%
У меня фактически две БД. Грубо говоря, БД неких настроек (не шибко большая, но запросы к ней идут сложные), и БД архива, куда идет непрерывная запись довольно большими темпами, причем на каждую такую запись нужно сделать хитрую выборку из БД настроек и из этой же БД архива. Т.е. новые данные преобразовываются на основе настроек и на основе последних данных из архива (для скорости хранятся отдельно), по этой причине последовательность записи в БД должна строго сохраняться. Из-за такой особенности обычное разделение потока данных по нодам с отложенной синхронизацией БД не проходит.
К данным архива как раз можно применить горизонтальную кластеризацию, но даст ли это какое-то преимущество? Т.к. моя проблема не в тяжести запросов, а в их количестве и взаимосвязанности, ну и само собой архивная БД имеет огромные объемы + нагрузка от пользователей, которые как раз делают тяжелые запросы в архив.
Удалите, пожалуйста, данный топик. И извините за критику.
P.S. Сейчас :)
А акции Google упали в цене (что логично) на 1.8%
К данным архива как раз можно применить горизонтальную кластеризацию, но даст ли это какое-то преимущество? Т.к. моя проблема не в тяжести запросов, а в их количестве и взаимосвязанности, ну и само собой архивная БД имеет огромные объемы + нагрузка от пользователей, которые как раз делают тяжелые запросы в архив.