Сколько оперативной памяти нужно в 2017?

встроенную в ядро консоль

это как? в двух словах, для Ъ, если не сложно

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

Ко-ко-кто сказал «оптимизация» ?))

Казачье на Сях написано! Так не честно! Тут тебе люди про Языки говорят! Которые с IDE-и рефакторингом!

это как? в двух словах, для Ъ, если не сложно

Тут всё элементарно. В исходниках современного ядра есть директория drivers. Внутри ядерные драйвера. Среди них есть директория tty. Это драйверы терминала. Там есть ещё поддиректория serial для того, чтобы работать с аппаратным терминалом, который подключен через COM порт. А рядом с ней есть поддиректория vt, которая содержит реализацию виртуального терминала. Главным файлом является файл vt.c, который содержит реализацию ядерного виртуального терминала, которая изначально была написана Линусом Торвальдсом в 1991-1992 годах. Эта реализация может работать в голом ядре, и предоставлять юзеру полноценный текстовый терминал без необходимости задействования чего бы то ни было ещё. Начиная с 1997-го года эта ядерная консоль умеет работать поверх драйверов для фреймбуфера самого ядра же. Со временем фреймбуферовские драйвера дополнились подсистемой KMS, которая предоставляет ядерные видеодрайвера с видеоускорением (как минимум, 2D). Сюда же входят современные драйвера для видео intel и nouveaufb для видеокарт NVidia.

https://en.wikipedia.org/wiki/System_console
почему пример про резчика стекла не может на тебя повлиять? почему?
вселенная не зародилась в момент написания Торвальдсом ядра.
как и IT, как и терминология.

Дополнительные прилагательные, которые помогают уточнять о чём речь, никому употреблять не запрещено. Виртуальные консоли/терминалы могут быть самыми разными. Реализаций море. Но, в ядре есть только одна реализация.

Вот в мире той же FreeBSD можно проще. Там две реализации. И там можно называть конкретную реализацию по имени: syscons или vt (ранее известная также как newcons).

от 16 гигов и более

А что плохого в старых стандартах? В том что софт будет весить по 1-5 мб и работать супер быстро?

Плоха цена этого. Сравни софт 20-летней давности и современный. Небо и земля, что в плане функционала, что в плане скорости разработки. Я мог писать на WinAPI месяцы то, что сейчас на React+Electron напишу за неделю.

Мне сегодня смешно вспомнить что у меня когда-то было 3,5 болванки CD-R, на которые впихивался ВЕСЬ необходимый мне софт, и 2 с личными данными. Если мне кому-то нужно было бросить какую-то прогу, то на модеме 56к оно кидалось хоть в сколько-нибудь приемлемые временные рамки. Я конечно хочу прогресса, но не так себе я его представлял.

Пока железо прогрессирует, так и будет. Когда прогресс железа остановится, тогда и прогресс требований софта остановится. Скорость одного потока процессора, например, остановилась лет 5 назад, с тех пор улучшения крайне незначительные. Цена оперативной памяти, кажется, тоже остановилась. А вот в области жёстких дисков и многопроцессорности прогресс ещё не остановился. Ну и энергоэффективности, хотя мне это не интересно.

Конечно 64+ Гб! Скайнету нужно больше нейронов!

Повседневные «домашние» и «офисные» задачи - 1,5 гига достаточно всегда.

Игры - уже 8. Полёт фантазии дизайнеров остановить трудно.

Но неужели на ЛОРе столько людей, перед которыми стоят задачи действительно требующие 8+ гигов?

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

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

тяжёлый GUI софт и тяжёлый медиа контент

А вот тут не соглашусь. Тяжёлый и сложный GUI можно уместить и в малой памяти. Гимп, автокад, фотошоп - совершенно не простые, но gui у них вполне укладывается в 100Мб. Медиаконтент? Воспроизведение требует довольно скромно памяти. fullHD видео с битрайтом 20М+ ? 100-150М, хотя тут уже заложено 800% запаса от минимально достаточного.

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

Да, типичное домашнее «посмотреть что нибудь»:

root@raspberrypi:~# free -m
             total       used       free     shared    buffers     cached
Mem:           926        889         36         37         12        163
-/+ buffers/cache:        713        212
Swap:        12699        231      12468
root@raspberrypi:~# swapon -s
Filename                                Type            Size    Used    Priority
/dev/sda1                               partition       12595196        0       -1
/dev/zram0                              partition       102396  55060   10
/dev/zram1                              partition       102396  24136   10
/dev/zram2                              partition       102396  84580   10
/dev/zram3                              partition       102396  73748   10
root@raspberrypi:~#

Из них 223М это okular и 140М это жирнолис.

Хотел сказать, что 1-2GB. Но потом подумал и понял, что не каждый захочет заморачиваться с поиском и освоением легкого (и в то же время функционального) софта. Поэтому наверное все такие 4-6ГБ.

Небо и земля, что в плане функционала

Вот скажем explorer.exe во время NT5 и сейчас делает одно и тоже. Минимальные косметические изменения в плане функционала при полной перестройке дизайна. Явный регресс от нормального такого автомобиля до самолёта с паровой машиной вместо двигателя. Зачем переделывать хороший инструмент только потому, что он недостаточно современно выглядит и написан не та том?

что в плане скорости разработки. Я мог писать на WinAPI месяцы то, что сейчас на React+Electron напишу за неделю.

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

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

Я мог писать на WinAPI месяцы то, что сейчас на React+Electron напишу за неделю

А потом оказывается, что то что написано за месяцы работает потом долго и счастливо, а то что написано за 1 неделю потом нужно в 3 раза больше времени исправлять, чем то что писалось месяцы. Даже в онеме «New Game» уже упомнили об этом.

Когда прогресс железа остановится, тогда и прогресс требований софта остановится

никогда не остановится. Всё равно придумают что-то ещё.

Цена оперативной памяти, кажется, тоже остановилась

не остановилась. Она всё дешевеет, очень сильно. Просто обёмы требуемой памяти сильно увеличились, потому и выглядит как будто дороже. я 2 плашки по 8 гб кингстон 2400 МГц купил за 80 баксов.

У меня один хром 8 кушает.

На 4 гигах кодю и ваще никаких проблем. Правда, периодически запускаю отдельный сервак с 6 гигами оперативы для всяких бэкендов под докером. Короче, 8 гигов хватит всем.

оперативной памяти нужно столько сколько её умеет процессор!

где вариант ответа: максимально возможное?

свободной оперативы не бывает!

У знакомого историка комп с 256 Мб ОЗУ, он пишет тексты в LibreOffice, сканирует архивы, печатает документы и т.д. Больше туда ОЗУ не доустановить, а менять комп он не видит смысла, ему хватает.

Либра, кстати, довольно тормозная. У меня старенький ноут 1.6 гц, с двумя гигами на борту, проворачивает эту либру с трудом. В пустой таблице ставишь значение и оно появляется с некоторой задержкой. OpenOffice 4 в этом отношении рулит.

Мне 8 маловато, если честно. Занимаюсь в основном 2d графикой.

Имею 16 гигов, иногда чувствую нехватку еще 8 гб.

macOS, Gotland, datagrip, webshtorm, xen, docker и ещё много чего

Откуда пошла эта дебильная мода писать 2к17? Нахрена заменять ноль буквой?

Видимо эта мода от того же деграданта, который заменяет единицу восклицательным знаком :D

без необходимости задействования чего бы то ни было ещё

И ты на малинке в голом терминале, просто на ядре? Как это выглядит? просто загрузчик грузит ядро, без системы инициализации и прочего? А как ты картинку видишь? Или ты по аппаратному через uart? Где почитать? Любопытно )

Видимо эта мода от того же деграданта, который заменяет единицу восклицательным знаком :D

2к!7

Ты устарел, ща всякие Atom на хром движке в моде.

Оффнись

объективно 8, с жиру 16

зачем опрос?

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

А вот для минимальной системы уже нужны init, bash,... и т.д.
В итоге получается как-то так:

> pstree
init-+-bash---screen---screen-+-bash---bash
     |                        |-bash---lynx
     |                        |-bash---pstree
     |                        |-3*[bash]
     |                        `-bash---irssi---{gmain}
     |-2*[bash]
     |-bitlbee---bitlbee---{bitlbee}
     |-klogd
     |-syslogd
     `-udevd

А зачем так жить?

результаты этого опроса точно будут отправлены ведущим тимлидам программистов Земли?

мне 32 гб мало, на компьютере занимаюсь в основном онанизмом.

у меня сейчас 3 компьютера с 64 мб, 2 компьютера с 128 мб, 1 с 192 мб, с 256 мб, с 1.5 гб и с 2.5 гб

сколько достаточно - не знаю :)

Пока 32 как раз хватает, 16и было бы мало. Jetbrain'овский IDE'шки очень много просят + хром отъедает прилично, если запустить пару серваков + пару виртуалок - то как раз до 32х и нужно. К всему вышеперечисленному еще удобно иметь большой tmpfs без свопа для сборки проектов.

На работе за руководством на маке весело наблюдать. Откроют пару Adobe продуктов (PS, Illustrator) и смотрят как у них из-за нехватки оперативы (я так понимаю 8gb) файловый менеджер перерисовуется по 5 секунд.

Затем, что так удобнее (всем удобно разное, да).

И то только с гигом свапа, причем вроде только если в 1 поток. На первой можно собрать в 1 поток докинув свапа 2 гига. Но очень медленно.

Затем, что так удобнее (всем удобно разное, да).

Ну вот в иксах можно в EVE online поиграть. Или посмотреть какой-нибудь фильм в 4k. А в ядерной консоли такое можно?

Видеопроигрыватели и спрайтовые эмуляторы (ZX Spectrum, NES, SNES, Sega Megadrive/Genesis,... etc) в ядерной консоли вполне работают.

Видеопроигрыватели

Через libcaca что-ли?

спрайтовые эмуляторы (ZX Spectrum, NES, SNES, Sega Megadrive/Genesis,... etc)

Так это ж старье.

Я собирал boost на Raspberry Pi 3 без подкачки. Во сколько потоков не помню.

Ну смотрите, крыса ест 300 метров, вместе с хромом и парой вкладок получается что то около гигабайта.
Так что да, жить с гигом оперативки в 2017 вполне можно, не сильно напрягаясь.
Но это самый минимум того, что нужно.

Через libcaca что-ли?

Нет. Через fbdev. Фреймбуфер - это текст поверх графики и графика поверх текста.

Так это ж старье.

Ну так те, кому нужно новьё, сидят в графических средах. Ещё можно собрать какой-нибудь prboom, и играть в DOOM I/II.

Нет. Через fbdev. Фреймбуфер - это текст поверх графики и графика поверх текста.

А, напрямую в drm. Ну, наверное тоже решение.

Ну так тем, кому нужно новьё, сидят в графических средах. Ещё можно собрать какой-нибудь prboom, и играть в DOOM I/II.

Можно, но ведь это действительно старье.

640 кб хватит всем

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

Смотря для чего. У меня 8, мне обычно хватает. Для некоторых задач и 4 хватит. Больше 16, как мне кажется, надо только если какие-то особо жручие вещи запускать, кучу виртуалок или что-нибудь такое.

И мне не нравится, когда софт пишут с расчетом «ну память сейчас дешевая, будет тормозить — пользователь докупит».

Где-то так и есть. Debian 9.1, xfce - 280 метров со старта, + ff - 700, + lo writer - 900. Гиг все таки мало, с двумя можно.

А где от 2 до 4?!

~ cat /proc/meminfo | grep MemTotal
MemTotal:       32799336 kB

Ммм…

Но ответил, что 16.