>>6689202
Это часть философии Apple. Огромное количество привычных для Windows и Linux вещей (да хотя бы команда Вырезать в контекстном меню файлового проводника или кнопка Вверх между Назад и Вперед там же) либо напрочь отсутствуют, либо для активации требуют манипуляций с командной строкой.

Чем меньше в операционной системе меню, переключателей и опций -- тем меньше она фрустрирует потенциального покупателя, и тем охотнее он предпочитает купить машину с такой системой. Звучит абсурдно, но работает безупречно.

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

Две с половиной программы действительно позволяют менять в себе язык независимо от системы, но в остальных случаях (99%) -- нет. Никто на такое заморачиваться не станет, есть неписаный закон и все ему следуют.

Для добавления в macOS общепринятых в Linux и Windows удобств существует масса плагинов и расширений как бесплатных, так и с ценником в районе $5...$10. Кому нужно, тот купит или скачает крякнутую версию с торрентов. Абсолютное большинство пользователей Mac терпят все как есть, просто потому что не знают, что в других ОС может быть удобнее.

Раньше кнопки в углу любого окна в MacOS работали, как в винде: закрыть, свернуть, развернуть (просто расположены в левом верхнем углу окна, а не в правом) А в правом верхнем углу располагалась четвертая кнопка в виде стрелки, которая позволяла развернуть окно не просто на полный экран, а еще и вытолкнуть все панели задач, статусбары, часы и т.п. за пределы экрана. Оставалось только одно программы на целый монитор. Очень помогало, когда нужно было сконцентрироваться на работе.

Потом в Apple через соцопросы узнали, что 88% пользователей macOS пользуются только кнопками Закрыть, Свернуть и Развернуть, а Развернуть На Полный Экран почти не используют, и мало кто знает для чего эта стрелка на противоположной стороне окна.

И вот в очередной версии macOS привычная кнопка Развернуть начала работать, как Развернуть На Полный Экран. А Развернуть На Полный Экран -- исчезла. Пытаешься развернуть окно -- заодно лишаешься панели задач и вообще всего-всего, как будто в браузере нажал F11.

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

У Apple спросили, зачем все испортили. А в Apple ответили: мы узнали, что наш чудесный функционал Развернуть На Полный Экран почти никем не используется, а ведь он позволяет повысить продуктивность работы на 8% и снизить стресс от лезущих отовсюду нотификейшенов на 3%. Поэтому мы решили переучить наших пользователей на то, чтобы пользоваться Развернуть На Полный Экран как можно чаще.

Следом, конечно, спросили: а нельзя было оставить Развернуть На Полный Экран отдельной кнопочкой в заголовке окна, подвинув ее на одну сторону к трем остальным, или там Разворачивать На Полный Экран по комбинации клавиш с клавиатуры при нажатии на Развернуть, а обычное нажатие мыши оставить с привычной функцией Развернуть?

И в Apple ответили: но тогда мы никогда не переучим наших пользователей как можно чаще Разворачивать На Полный Экран вместо того, чтобы просто Разворачивать, и это противоречит нашему новому видению философии Apple что отныне Разворачивать На Полный Экран -- основной подход, а просто разворачивать -- комплиментарный.

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

Закончилось выходом славной программы Moom. Да, Развернуть по прежнему разворачивает на полный экран, зато при наведении курсора на саму кнопку Развернуть вылезает поп-ап в котором еще можно выбрать: развернуть просто, развернуть на левую половину экрана, на правую, на четверть, по кастомному лекалу и т.д.

Очень удобно. Но нет, просто максимизировать окно по нажатию на Развернуть нам уже никогда не дадут: либо через комбинацию клавиш на клавиатуре, либо терпеть "режим F11" с пропажей всех панелей и виджетов.

>>6706063
Когда открываешь хром после перезагрузки компа, практически все вкладки висят в сессии лишь формально, а загрузка данных в RAM (из кэша, из интернета) начинается только когда потревожишь одну из вкладок, открыв ее. Поэтому смысл OneTab не вполне понятен -- типа, держать на виду недавно открытые вкладки, при этом не открывая их? Ну так история Chrome ровно тот же функционал предоставляет. Я постоянно ей пользуюсь, чтобы открыть какую-то страничку, которую открывал 12 часов назад или 2 дня назад.

Другое дело, что порой реально используешь 105000 вкладок и всем им нужен RAM.

> Lubuntu 16.04 LTS + zRam.

Ты похож на теоретика. А у нас на работе целый парк некромашин был в некоторых объектах уровня СТАДИОН или ОБЩЕЖИТИЕ где то 1024 Мб RAM, то 1536. DDR2.

И вот там в ход шла именно лубунта. Где 14.04, где 16.04. Она жрала после перезагрузки метров 600 памяти только на процессах, а реально ей нужно где-то 1200. Ни про какой веб-серфинг речи не шло... А разгадка простая -- лубунта работает на очень жадных до памяти фреймворках, точнее ее графическая оболочках.

В условиях малого объема RAM / слабого CPU проще всего накатывать Phoenix OS или иной Android for x86. Вкладочки и многозадачность там уже давно есть, а вот быстродействие и потребление памяти не в пример лучше, чем на десктопе. Потому что разработчики под Android вынуждены считаться с маломощным железом, а разработчики под десктоп ничего не оптимизируют и не будут, т.к. в противном случае их сожрут конкуренты, которые вложат те же человеко-часы в выпуск следующей версии браузера/игры/etc.

Всякие MS Office от винды отлично уже работают под Wine for Android, уже не говоря о том, что и нативных офисов хоть жопой жуй.

> zram

Уже давно не нужен. Проблема со zram была в том, что он как бы ставил тебя перед неудобным выбором: сколько нужно выделить памяти под процессы (свободная RAM), а сколько -- под compressed ram cache (собственно zram)

С одной стороны, неиспользуемые в текущий момент страницы памяти каких-нибудь богом забытых вкладок в хроме при помещении в zram ужимались аж до 8 раз, и в принципе туда им и дорога.

С другой стороны, zram отъедал жизненно важную свободную RAM, вызывая бесконечные дергания страниц из zram в process memory и обратно. А каждое такое телодвижение давало нагрузку на CPU.

Еще приходилось выбирать -- при чтении сжатых страниц из zram в process memory собственно discard'ить их из zram или оставлять там. Если дискардить -- оперативно освобождалось место в zram для более актуальных данных, но если все те же данные необходимо было снова поместить в zram -- приходилось лишний раз ужимать заново. А ужатие съедало циклов CPU гораздо больше, чем разжатие.

Если не дискардить -- резкая экономия CPU, но zram терял смысл. Он забивался ужатыми страницами по самое горло и никогда уже оттуда их не сливал, а тупо ждал cache hits. Почему так получалось? Zram -- не более чем одно из swap-устройств. Пока в свопе на HDD еще есть свободное место, zram так и будет с умным литсом держать в себе всякое старье, если не поставлен флажок discard upon decompression -- удалять страницу, если поступила инструкция разжать ее и отдать в область памяти процессов. Получалась абсурдная ситуация -- своп на HDD пашет как вол, zram ни хрена не делает и только отбирает память.

В случае со слабыми машинами -- проверено на моем опыте -- CPU вставал раком при любом варианте, т.к. даже сжатие/ужатие LZ4 на некрокомпах взъебывало их сильнее, чем запись/чтение неужатых данных на HDD.

Сейчас в ходу https://en.wikipedia.org/wiki/Zswap за что следует благодарить в первую очередь зафорсивших его включение в ядро разработчиков Android.

Zswap позволяет вместо прямой отправки данных в своп, сжимать их тем же LZO/LZ4 и сохранять в особой динамически выделяемой области в RAM. Иными словами, свободная RAM у тебя начинает использоваться как некий предбанник для свопа, куда складируются в ужатом виде все страницы памяти, к которым долго не было обращений. Если места под этот склад вдруг начинает не хватать -- ужатые страницы отправляются в своп на ПЗУ, а если наоборот появляется много свободной RAM -- ужатые страницы из свопа на ПЗУ начинают кешироваться в RAM.

Короче, это тот же zram, только не играющий в перетягивание каната со свопом на ПЗУ, а дополняющий его. Причем с абсолютно подвижной резиновой границей между кэшем zswap в памяти и областью RAM, отведенной под память процессов.

Аналог в macOS -- compressed memory, появившаяся где-то в 2012/2013 году, хотя принцип zswap был в линуксе описан и испытан еще раньше, просто в мейнстримовый функционал ядра он попал лишь много лет спустя, как оно обычно и случается.