Почему Ubuntu требует много памяти?

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

вин2000server выкинул она с samba не справлялась заменил на debian3.1 он ещё в дополнение почту тянул

Так винда для таких экстримов и не создавалась. В ней то и графика неотключаемая, вроде как.

Но и для дебиана это разве что самый старт, причем первые секунды. Я так в 2010 генту чисто по приколу на старте с графикой доводил до 110мб (при этом одна вкладка фф тогда уже жрала столько же). А тот же тиникор в 16мб легко вмещался в том же году.

Но толку, если это сферическое в вакууме? Начинаем работу и каждая утилита начинает разрастаться. Уже через пару минут он будет жрать в 10 раз больше при реальной работе.

плачущего смайлика не хватает, деградируем

Я к тому, что эти погони за мегабайтами - херня из под коня.

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

получайте максимум cli

Хотеть! Хотеть!11
Есть чо?

Конечно есть. Я все свои утилиты делаю изначально как cli, а потом для юзеров сверху прикручиваю гуй. Никому еще нахер не сдался твой cli. Ну вот вообще никому и никогда. Это видимо не так весело, как кажется изначально. Хотя мне командами как то удобнее.

Вопрос в зал. Теоетисский.
Раз код/данные пухнут в оперативке без появления функционала (телеметрию отложим в сторону пока), значит такие данные должны хорошо сжиматься. Zram или такое как справляется?

Великолепно справляется. Пока у меня на ноуте было 8гб озу - лютейшая беда с этим была. Zram стал просто спасением.

Ну пусть автор ставит дебиан, раз он считает, что убунту неадекватно потребляет ресурсы. Наверное что-то действительно выиграет, но никак не на порядок. 256Mb, это не про десктоп. Был у меня AntiX (i486), он кушал 80Mb сразу после запуска графического окружения (fluxbox), полностью урезанный, никаких капсов и ссшд и прочих сервисов, даже вроде гтк не ставил, сейчас для 32-битного уже:

256 MB RAM is recommended minimum for antiX

Я его, автора, поддерживаю, но ресурсы съедаются не просто так.

В Windows XP работало всё тоже самое на 64 мб

А были времена когда 640 КиБ всем хватало...

Так и я о том же. Смысл в оптимизации если она не требуется? Я вот тоже нежно люблю Ассемблер, но пишу в итоге на Java. Нет, конечно приятно выжать из железа всё, что можно, и ещё чуть-чуть. А перекладывать байтики из регистра в регистр - совсем неземной кайф. Но времени уходит - нафиг такое… Побаловаться - можно. Но хоть что-то серьёзное, то тут уже Ассемблер отпадает… Оптимизация, там где она не требуется - напрасная потеря времени в никуда. Если облако стоит дешевле, чем время на оптимизацию, то нафиг её. Если пользователь хочет фичастый гуй, пусть жирный и неповоротливый, и готов для этого потратится на железо, то смысл пихать ему cli?..

безгуевая бамжара отжирает 1,8 гига ?? на старте ??

У меня, сразу после старта (правда в автозапуске vpn и ноды скрытосетей), Manjaro в Кедах 1.9GiB сжирает. Но вот на серваке, где естественно графического окружения нет, всё тоже самое, на той же Manjaro с тем же ядром, отжирает только 850MiB.

Прямо сейчас моя Ubuntu 22.04.5 жрёт 8.6GB оперативной памяти при запущенном FF с открытыми 13-ю табами + Spotify, Telegram, менеджер паролей, терминал и Steam. Не знаю много это или мало, но до сих пор двух DDR4 планок по 32GB мне хватает.

Никогда не смотри на требования, смотри на реальное потребление. ХР кстати практически невозможно пользовааться если голая система не использовала хотя бы 120Мб оперативки. 64М это если пожертвовать звуком и видеодрайвером.

Ах, да, конкретно убунту - возможно они напсали 4Гб из за своего некогда прогрессивного лайв-установщика.

https://www.linuxatemyram.com/

Прежде чем учетверять объём надоб ыло бы поинтересоваться а что он там делает что ему мало. Ну ладно, согласен, 1 это слишком да и в 2Гб еле шевелится, но при 3Гб уже можно сёрфить и не чувствовать недостатка, ну если не ронять сразу кучу вкладок в фон.

Используй Qt4, а лучше tQt

Красиво и удобно было сделано ещё во времена ХР. Кто заставлял разработчиков ожирять графику в ~4-10 раз - загадка. Функциональнее она точно не стала. Красивей - однозначно нет. У меня абсолютно идентичный psi в версии qt4/armhf работает в 10-15Мб после того как всё лишнее провалится в своп, а он же, но на qt5/arm64 - 80М если слегка пошевелится, и до 200М из за утечек памяти после месяца аптайма. И это чисто косяк тулката.

Бери сдутую сборку и 32бита. Будет и на 1Гб шевелиться, но чисто сама, без софта.

Казалось бы, если пара часов работы програмиста позволит экономить милион раз по 5% от новой планки оперативки...

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

Подожди, все уже 20 лет как пользуются конструкторами готовых решений. Чем готовое решение 2005 года хуже готового решения 2025 года (кроме того что в 2025 году оно не поддерживает темы оформления)?

Казалось бы, если пара часов работы програмиста позволит экономить милион раз по 5% от новой планки оперативки…

Там же дело не только во времени работы программистов, но и во времени выпуска программного продукта, что стоит уже гораздо больше, чем время программистов, особенно когда сроки горят. Поэтому, на оптимизацию тратят время либо по остаточному принципу, либо когда уже «прижало», и без неё не обойтись. Кроме того, оптимизация программ может приводить к их усложнению, и, соответственно, к увеличению расходов на поддержку. А на последнюю уходит ~90% бюджета в жизненном цикле приложения. Соответственно, можно предполагать, что во время поддержки сумма, в моменте затраченная на оптимизацию, вырастет в 10 раз.

Но нельзя же до бесконечности увеличивать объём говнокода, выполняющего простейшее действие.

меньше 40мб (php+mysql+apache+samba)

Врёти.

А во времена MS-DOS 640 килобайт хватало каждому.

вот тут-то ты и ошибаешься

Debian 12 256 MB

Это чтобы установщик запустился в принципе. С GNOME оно никак особо не будет отличаться от других дистрибутивов, включая Ubuntu.

Windows XP 64 MB

Это только первая версия до сервиспаков, и даже в ней у тебя будет «Блокнот» свопиться.

Windows 10 1 GB

«Блокнот» в свопе.

Ubuntu 24.04.2 LTS 4 GB

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

Прихожу к выводу

…что в 2025 году абсолютный минимум памяти для компьютера, который должен что-то делать — 16 Гб. Для новых рекомендуется не менее 32 Гб.

И только странные линуксоиды (не путать с пользователями Linux) продолжают считать, сколько сотен(!) мегабайт памяти у них потребляет десктоп без приложений. У вас в жизни более важных дел нет?

Красиво и удобно было сделано ещё во времена ХР.

Это называется «синдром утёнка».

У вас в жизни более важных дел нет?

Есть. Надо ещё посчитать сколько после установки занято места на диске.

xp и сервиспаками ставили с подкидной планкой, потом резали загрузку кучи говнища и вполне ползала под 64мб.

Но нельзя же до бесконечности увеличивать объём говнокода, выполняющего простейшее действие.

Может до бесконечности и нельзя, но можно до того объёма, выполнение которого в облаке, обойдётся дешевле чем все потери при его оптимизации. Пока что, стоимость облачных вычислений позволяет увеличивать объём говнокода. И конца этому не видно…

Ну так сиди на линуксе, который был во времена winxp, какие проблемы?

xp и сервиспаками ставили с подкидной планкой, потом резали загрузку кучи говнища и вполне ползала под 64мб

Я понимаю, что можно и не такое, но практический смысл от меня ускользает. У меня в первом домашнем компьютере было 512 Мб, и это было неплохо для XP SP2 (и я тогда ещё не жалел сил и времени на отключение ненужного, как мне казалось, барахла). В следующем был уже гигабайт, и вот здесь уже явно стало комфортно, можно было не закрывать лишние программы. Как там дальше, не сильно в курсе, поскольку больше Windows не использовал дома.

А кто говорил о домашнем, на работе вполне практиковалось, что было из железяк, на том и работали

Это называется универсальный движок тем, позволяющий реализовать любое оформление. А в Висте ещё и эффекты с анимациями подъехали и там уже было возможно вообще всё, по крайней мере в теории. А паралельно с этим уже существовал Беррил/Компиз фьюжин и gtk2/qt3/qt4, и вот там было возможно абсолютно всё и было нереально найти железо ,которое этого не тянуло хотя бы на минималках.

И да, синдром утёнка это видимо когда ты привык брать gnomecolorchooser и собирать свою собственную тему gtk2 из 3-х других, одну из которых приходилось тянуть в Дебиан из Минта.

При чем тут конструкторы готовых решений? Ты сам что нибудь писал хотя бы 10к+ строк? Любой простейший проектик.

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

Попробуй сделать приложение, которое будет использоваться практически неопределенным числом народа на разных ОС и через годик-два поймешь суть проблемы и что она нерешаема сейчас. Проще поставить доп планку ОЗУ.

Вот возьмем для примера луа5.1 и ютф8. В луа5.1 просто не существует ютф8. Его утилиты не знают что это. Есть готовая либа для работы с ютф8 на 46.2кб. Из них 32.7кб, к слову, это таблица с символами типа:

	["𐐜"] = "𐑄",
	["𐐝"] = "𐑅",
	["𐐞"] = "𐑆",
	["𐐟"] = "𐑇",
	["𐐠"] = "𐑈",
	["𐐡"] = "𐑉",
	["𐐢"] = "𐑊",
	["𐐣"] = "𐑋",
	["𐐤"] = "𐑌",
	["𐐥"] = "𐑍",
	["𐐦"] = "𐑎",
	["𐐧"] = "𐑏",

Остальное логика работы. Учет всех вариантов, крайних случаев итд.

Вот смотри. Допустим, я избавился от этой «жирной» либы и переписал себе нужное:

local utf8_pattern = "[\1-\127\194-\244][\128-\191]*"
function utf8myLen(s)
    return select(2, s:gsub(utf8_pattern, ""))
end

local strbyte, strlen, strsub = string.byte, string.len, string.sub

-- Определяет количество байт, занимаемых UTF-8 символом
local function utf8charbytes(s, i)
    local c = strbyte(s, i)
    if c > 0 and c <= 127 then
        return 1
    elseif c >= 194 and c <= 223 then
        return 2
    elseif c >= 224 and c <= 239 then
        return 3
    elseif c >= 240 and c <= 244 then
        return 4
    else
        error("Invalid UTF-8 character at position " .. i)
    end
end

-- Извлекает подстроку из UTF-8 строки с оптимизациями
function utf8mySub(s, i, j)
    if type(s) ~= "string" then
        error("bad argument #1 to 'utf8sub' (string expected)")
    end
    if type(i) ~= "number" or type(j) ~= "number" then
        error("bad arguments #2 and/or #3 to 'utf8sub' (numbers expected)")
    end

    local bytes = strlen(s)
    local startChar, endChar = i, j
    local charPositions -- Таблица для кэширования позиций символов при необходимости

    -- Обработка отрицательных индексов и вычисление длины
    if i < 0 or j < 0 then
        charPositions = {}
        local len = 0
        local pos = 1
        while pos <= bytes do
            local charBytes = utf8charbytes(s, pos)
            len = len + 1
            charPositions[len] = pos -- Сохраняем позицию символа
            pos = pos + charBytes
        end
        -- Корректируем индексы
        startChar = (i < 0) and (len + i + 1) or i
        endChar = (j < 0) and (len + j + 1) or j
        -- Ограничиваем endChar до максимума и корректируем startChar
        endChar = math.min(endChar, len)
        startChar = math.max(startChar, 1)
    end

    -- Проверка невалидных границ
    if startChar > endChar then
        return ""
    end

    -- Поиск байтовых позиций
    local startByte, endByte
    if charPositions then
        -- Используем кэшированные позиции
        startByte = charPositions[startChar]
        local endPos = charPositions[endChar]
        endByte = endPos + utf8charbytes(s, endPos) - 1
    else
        -- Стандартный поиск
        local currentChar = 0
        local pos = 1
        while pos <= bytes do
            local charBytes = utf8charbytes(s, pos)
            currentChar = currentChar + 1
            if currentChar == startChar then
                startByte = pos
            end
            if currentChar == endChar then
                endByte = pos + charBytes - 1
                break
            end
            pos = pos + charBytes
        end
    end

    return strsub(s, startByte, endByte)
end

Я сделал лучше? Я теряю весь китайский, например, все что не кириллица и не латиница. Теряю все крайние случаи там итд.

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

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

И не только про время. Насколько размножатся баги во всем этом. В итоге мы опять придем к разожравшимся проектам, но у каждого будет свой зоопарк, несовместимый с соседями. И снова стандартизация, снова общие инструменты. И вот, мы на старте. Где и были.

Это называется универсальный движок тем, позволяющий реализовать любое оформление

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

И да, синдром утёнка это видимо когда ты привык брать gnomecolorchooser и собирать свою собственную тему gtk2 из 3-х других, одну из которых приходилось тянуть в Дебиан из Минта.

Вот делать нечего было :) Правда, я тоже когда-то делал свои темы для WM, пилил conky и т.п. Сейчас меня устраивает дефолтная Adwaita в GTK3/4.

Почему Ubuntu жрёт 4 Гига?

Потому что её нужно правильно приготовить

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

Да я всё понимаю, разработка софта это такое непостижимое искуство для избранных, но почему эти нерешаемые проблемы решались 20 лет назад просто между делом?

Я сделал лучше? Я теряю весь китайский, например, все что не кириллица и не латиница. Теряю все крайние случаи там итд.

Вопрос: Зачем ты используешь Lua 5.1 для вывода неподдерживаемого в ней текста?

И все прочие подобные вопросы: почему текст рисуют через canvas, почему дёргают гпу для отрисовки рямоугольников с текстурами если цпу делает это быстрее, зачем производить интерпретацию css-кода при каждом запуске приложения если можно использовать svg и т.д. и т.п.

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

О боже, у них получится какой нибудь QT4, летающий на Raspberry Pi 3 и работающий на Пи1!

Я прекрасно знаю почему появились и усложнялись фреймворки. Но они продолжили жиреть, но перестали давать какие нибудь преимущества в функционале. Сама идея написать приложение на электроне была и есть бредом сумасшедшего, а сделать это так, чтобы приложение было ещё и одноплатформенным... Это уже за гранью! Только на андроиде 3/4 приложений сейчас такие.

И не только про время. Насколько размножатся баги во всем этом.

Чтобы багов было меньше, надо прекратить изобретать новую модную прослойку к каждому сезону и поддерживать LTS-выпуски. По крайней мере для тех задач, которые были прекрасно решены уже 10-15-20 лет назад.

Ибо GNOME и systemd. Ставь Debian с SysVInit, голая консоль на 64 битах жрет 40-50 МБ, на 32 битах — 20-25 МБ.

Но вот на серваке, где естественно графического окружения нет, всё тоже самое, на той же Manjaro с тем же ядром, отжирает только 850MiB.

Как??? Что у тебя там запущено???

предполагаю, что Дебьян так же.

Нет, 90-100 из-за ненужнод. Без него в районе 50.

…что в 2025 году абсолютный минимум памяти для компьютера, который должен что-то делать — 16 Гб. Для новых рекомендуется не менее 32 Гб

Нет, гига большинству здесь за глаза хватит, у меня с телегой, паленкой и опенбоксом на 64 битах всё в него влезает, хотя самой ОЗУ у меня 8 гигов, без телеги и на 32 должно жрать +- 350, а можно паленку и выкинуть, а с пересборкой ядра без лишностей (я его собрал для себя, но запорол конфиг) будет жрать 60-70 МБ. У меня Slackware, если что.

Это называется «противодействие т. н. Великому Прогрессу (не путать с прогрессом)».

Великому Прогрессу (не путать с прогрессом)

Это отсылка к высказыванию Адама Смита про разделение труда? :)

Разработка софта это просто навык. Как любой другой. Ты не соберешь шкаф, если не брал никогда в руки шуруповерт. Ты тем более не разработаешь его с нуля.

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

Я использую то, что доступно. Если бы мне был доступен луа5.3 или питон или раст, я бы использовал их..возможно. Но мне доступен луа5.1. Иногда приходится работать тем инструментом, что есть.

Ничего не знаю про канвас и css - не работал. Видимо есть причины.

Ну конечно у них получится Qt4, летающий на расбери. Через 10 лет. Жирный как Qt4 обычный и тормозящий, как Qt4. А если не жирные и не тормозящий, то похожий внешне на помет Билла Гейтца и без нужных функций. Если ты не видишь пользы, но фреймворки жирнеют, это лишь значит, что ты не понимаешь что в них добавлют и зачем - это некомпетентность. Предоставь это профессионалам.

Понимаешь, недостаточно изобрести палку копалку и все. Она легкая, да, удобная, да. Но может к ней примотать камень? Будет тяжелее, нужно работать, но вдруг и польза будет, а?

Да хрен с ними с окнами, когда строки перестанут причинять боль? уж пол века как любимая пытка для погромистов :)))))))))))

Вся работа с информацией это песня. Это поэзия. Это лучшее, что есть в программировании в принципе. И каждая веха развития всего этого прекрасна сама по себе. Все остальное прикручивается к информации сбоку на самом деле.

Просто не все это понимают. Тут тоже навык нужен, как и во всем другом. Не понимают сути работы с информацией и думают, что это все сложно. А это просто разные методы, градации. И у них есть свои достоинства, недостатки.

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

Какая пафосная хрен, лови печеньку, заслужил ;)