zram это частично перекроет проблему с нехваткой оперативы
Зато усугубит проблему с производительностью и без того хилого Целерона. Еще неизвестно, что хуже - лаги во время переключения между программами или тормоза во время их работы.
Алексей Черемисин, тайлы, имхо - это для тех, кто хочет и имеет свободное время все сделать под себя.
К производительности это имеет весьма перпендикулярное отношение. Поскольку затраты на DE, если в нем не перегрузили отображение спецэффектами - пренебрежимо малы на фоне, скажем, браузера.
diyorhay, Юнити, насколько мне известно, тяготеет к Шарпу и вообще кромешно-подоконно, интересоваться им под Линуксом - это героически преодолевать искусственно созданные проблемы.
Если Пых и Питон еще только изучаются, с ними можно работать и в умном редакторе типа geany, например. Тормозить там нечему. HTML и CSS - тем более.
Василий Банников, я сравнениями не маялся, у того же менеджера стоят оба, потому что у Wildberries, например, такое кэширование, что смены картинки в карточке на одном и том же браузере не дождешься, как ни отключай кэш. Но это уже совсем оффтоп.
Василий Банников, и как вы себе представляете участие в коммерческой разработке человека, задающего такие вопросы?
Если воспринимать это как "современный офисный компьютер", то это Windows 11, Chrome с какой-нибудь облачной CRM, MS Office, и какой-нибудь очередной корпоративный месседжер на основе electron (всё одновременно)
Или Xubuntu, Firefox (в котором, в частности, открыто окно CRM), LibreOffice, Pidgin, Viber и за всем этим - мой подопечный менеджер по маркетплейсам, например. Без каких-либо теорий.
Впрочем, диски в офисе действительно в основном сменены на SSD. Это однозначно окупается, HDD тормозят даже больше, чем сотрудники ;)
Василий Банников, для какой разработки? Кем принято?
Любому студню, еще не открывшему учебник, по 6 ядер и непременно SSD? Чтобы курсик по питончику не лагал?
Право, давайте не обобщать.
Я себе 8 гиг до 16 нарастил меньше тех 5 лет назад. При том, что мне и виртуалки требовались, и под Андроид с IOS писал...
Летающее железо - это удобно. Это даже обосновано, если работает профи, для которого лаги критичны (ну, и при работе которого они вообще возникают). Но никаких катехизисов про "вот это устарело" и "уже 5 лет назад принято" - нет, это просто личный опыт. Возможно, внутримкадный ;)
VasyaID, сдалось мне вас убеждать.
Я просто прекрасно помню, как сам писал на машинах и подобной, и худшей конфигурации.
Никаких революций, кроме прорвавшегося жора памяти у IDE, с тех пор не случилось.
VasyaID, к вашему заявлению про "только для такой же древности".
Для современного офиса, получается, можно.
В принципе, если это С++ и, скажем, Code::Blocks - да, вполне реально.
Dmitry Roo, решаемые установкой AS постарше и подключением смарта вместо эмулятора.
Но вы взялись додумывать за ТС то, чего он не говорил, да еще и оторвались от реальности.
Посмотрите, какие вопросы задает ТС. Ну какой тут, на хрен, Андроид?
Drno, а ТС где-то написал, что у него гипер-проект, требующий убер-железа?
Судя по наивности вопроса, его задачу - хелловорлды - и это железо на ближайший год кроет, как бык овцу.
Такой формат - это частный случай "красивого" отображения конкретно сотового номера.
В базе номера следует держать без всяких красивостей, иначе их затрахаешься искать, например.
А оформить уже полученный из базы номер "красиво" можно буквально, совершенно в ЧЕМ УГОДНО.
GaalSpear, дык при таком объеме они просто по теории вероятности непременно содержат общие подстроки для небольших N. Даже внутри одной строки.
Надо все-таки искать частности и вычленять, что именно интересует. Иначе в решении перемножаются терабайты на терабайты, и привет суперкомпьютерам.
Зато усугубит проблему с производительностью и без того хилого Целерона. Еще неизвестно, что хуже - лаги во время переключения между программами или тормоза во время их работы.