IT в России и мире в реалиях мирового кризиса

«Лаборатория Касперского» нашла в Windows ранее неизвестную уязвимость, которая, предположительно, использовалась для проведения целевых атак по крайней мере двумя кибергруппировками — FruityArmor и недавно обнаруженной SandCat.
Сведения о бреши, получившей номер CVE-2019-0797, были переданы в Microsoft; соответствующий патч уже выпущен.
Данная уязвимость позволяет злоумышленникам получить доступ к сети или устройству жертвы. Для её использования был написан эксплойт, нацеленный на 8-ю и 10-ю версии Windows. Брешь в графической подсистеме для расширения локальных привилегий позволяет киберпреступникам получать полный контроль над атакуемым компьютером. Это уже четвёртый эксплойт нулевого дня, который был найден с помощью специальной технологии, разработанной «Лабораторией Касперского» и встроенной в большинство продуктов компании.
«Обнаружение этого эксплойта показывает, что такие дорогие и редкие инструменты по-прежнему представляют огромный интерес для кибергруппировок. Организациям нужны решения, которые могут защитить от подобных угроз. Это ещё раз подтверждает, насколько важно, чтобы представители индустрии кибербезопасности сотрудничали с разработчиками ПО. Поиск багов, ответственный подход к их раскрытию и быстрая подготовка патчей — лучшие способы оградить пользователей от уже известных и новых угроз», — комментирует Антон Иванов, антивирусный эксперт «Лаборатории Касперского».
Продукты «Лаборатории Касперского» детектируют уязвимость как HEUR:Exploit.Win32.Generic, HEUR:Trojan.Win32.Generic и PDM:Exploit.Win32.Generic.
«Лаборатория Касперского» рекомендует компаниям:

• как можно скорее установить патч Microsoft для исправления этой уязвимости;
  

Ссылка на патч

https://www.kaspersky.ru/about/press-releases/2019_kaspersky-lab-uncovers-windows-zero-day-exploited

Цитата: DarkRaider от 13.03.2019 13:28:15Скорость загрузки системы никак не влияет на её производительность. Это лишь показатель того, что вынесли в отложенную загрузку, а что оставили на прошлом месте.

Безусловно. Но тем не менее....
Есть одинаковые машины HP, они на выбор поставлялись с 7 и 8.  Поставки были растянуты и пришли и те, и те.
В общем, 8-ка реально и грузилась быстрее, и работала. Если бы не новое меню "...пуск....", то...
Возможно, это, конечно, частный случай, но тем не менее.

Цитата: sign от 14.03.2019 08:56:24Поставил на 7-ку Samsung V-NAND SSD 850. 
Загрузка стала очень быстрой.

Не буду этого делать.
Вопрос в том, что машины офисники, памяти по 4 гига. Это постоянный своп. Соответственно, это быстрый износ SSD и его выход.
Нафига мне гемморой?

Цитата: DarkRaider от 14.03.2019 13:07:53"Скорость работы операционной системы"  вообще понятие достаточно иллюзорное. По сути определяется минимально достаточным количеством аппаратных ресурсов расходуемых ОС для выполнения своей главной функции: запуск и управление ходом работы прикладных приложений. Собственно, чем больше ресурсов доступно для прикладного приложения, тем эффективнее работает операционная система.

Windows 8.1, в памяти VmWare висит. Папка Windows 20 Гб весит.
Системе почти 6 лет, программы ставились - сносились достаточно активно.
Не падала ни разу, как уже писал был опыт переноса системы с компа на Core 2 Duo на комп с Corei5 "на живую" - просто винчестер переставил. )
Так и живём.

Цитата: small__virus от 14.03.2019 10:10:26Не буду этого делать.
Вопрос в том, что машины офисники, памяти по 4 гига. Это постоянный своп. Соответственно, это быстрый износ SSD и его выход.
Нафига мне гемморой?

В домашних условиях ресурс не износить, если не задаваться такой целью. У меня старый Kingston в ноуте с такими же 5 гб озу, лет 7 ему точно, никогда не щадил его и скачивал/раздавал на нём торренты, он по прежнему исправен. Если с деньгами туго, можно и бу взять, как 3 кг говядины стоит. Или энтерпрайзы интеловые например, новые дорогие, а слегка бу уже норм, они неубиваемые. Одно повышение отзывчивости этого стоит.

Цитата: DarkRaider от 14.03.2019 20:51:11Теперь откроем Монитор ресурсов и прочитаем внимательно столбцы:
"Завершено" - объём виртуальной памяти зарезервированной ОС на процесса.
"Рабочий набор" - объём физической памяти используемый сейчас процессом. Он складывается из:
"Частный" - объём физической памяти используемый сейчас процессом, который не может быть использован другими процессами  +
"Общий"  - объём физической памяти используемый который может быть использован другими процессами, но сейчас используется этим.

Вопрос: сколько в итоге памяти занимает приложение?  500Мб из 8192? 1Гб из 16?
Зачем используется виртуальная память, если и 500 и 1000мб свободно влезают в оперативную целиком?  При этом этот процесс не 32битный и ограничения в 2.2Гб на процесс тут нету.
Зачем используется виртуальная память для процессов занимающих 4Мб памяти?
1 столбец "завершено" не бьётся с цифрами "Кэшировано", он в сумме сильно больше то есть это лежит не в оперативке, а реально на диске?
3 столбец "общий" тоже не бьётся с цифрами "Кэшировано", он в сумме меньше, то есть это и не динамическая память.

Ещё немного показометра:
Выгружаемая память ядра - 643Мб.  Известно, что "выгружаемая" - это та, что может попадать в своп, но неизвестно в свопе ли она сейчас.
Где эти 643мб?  По монитору складываем рабочий набор получаем 4.7гб из 5.2 "использующихся", следовательно память ядра включена в "используется", но в процессах не отображается?

Ах да!  64бита это же КРУТО!  намного круче чем 32! Правда, почему то, никто не думает, что одна и та же программа, при использовании 64битных переменных вместо 32битных начинает занимать в 2 раза больше памяти на одну и ту же работу.

5) Вот мы сейчас философствует о размере потреблённой ОС памяти, при том, что этот показатель тоже весьма косвенный. Опять же если только по этому судить, то хрюшка получится победителем со 117Мб всей потребляемой памяти чистой хрюшки, против 450-500Мб семёрки и 800Мб 8ки и 10ки. По хорошему надо сравнивать максимальный объём памяти выделенный прикладному приложению  системой при отключенном свопе(чёго то ДОС вспомнился, с борьбой за память ниже 640Кб) и общем объёме памяти в 2Гб.


6) Сконцентрировавшись на памяти, забыли о процессорном времени. Любимый показометр опять таки не даёт достоверной картины о том, какой процент ресурсов тратится на обеспечение работы самой ОС. Привычные 2-10% показометра - это нагрузка создаваемая службами и вспомогательными приложениям. Если при этом включить показатель "Вывод время ядра" будет частично видно сколько времени кушает ядро системы. Можно сравнить системы по количеству системных процессов и потоков минимально необходимых для обеспечения стабильной работы системы, это количество растёт от версии к версии.

Палегче ) Да, по памяти там немножко криво все. Но можно почитать, разобраться, и все сойдеться. Если хотите, могу на выходных написать псто, что на самом деле эти цифири значат, вольным переводом из мной уже упомянутой книги.  Теперь по поводу фактических несостыковок:
а) "одна и та же программа, при использовании 64битных переменных вместо 32битных начинает занимать в 2 раза больше памяти на одну и ту же работу" Это верно, если воспринимать дословно. Но вывод, что на 64битной ОС переменные вдруг становятся в два раза толще - неверный. Это не так, совсем. Переменные ж вообще дело не ОС, а погромиста Но я понимаю, о чем речь. О встроенных типах данных. Вроде int, long и т.д. Вот там влияние есть, но там все сильно сложнее. Таблицу размеров типов данных в винде х86 и х64 приводить не буду, ее можно легко нагуглить, если кому вдруг и правда интересно.
  К тому-же "занимаемая програмой" память - понятие комплексное. Возможен (и часто встречается) как случай, когда те же данные в памяти использует несколько приложений (процессов). Так же возможен и обратный вариант, когда ни в каких счетчиках процессов пары десятков гигабайт памяти нет, а она чем-то да занята. Все эта байда лезет из понятия "виртуальная память". А это, тащемта, одна из основных фишек винды. Ну и как вишенка на тортике: отображаемые файлы. Они попадают (тут боюсь на3.14здеть), но вроде прям в счетчик воркинг сета. Но не обязательно их страницы уже в памяти (грузятся они туда по классическому hard fault). Это штоб считалось нам веселее.
 Далее, "Привычные 2-10% показометра - это нагрузка создаваемая службами и вспомогательными приложениям.". Моя любимая тема  Тут все сложно, если пытаться в процентах мерять. На самом деле нет никаких процентов. И никогда небыло. На совести маркетологов, гори они в аду. Реальную "загрузку создаваемую" отображает в повершеле команда get-process. В секундах. Там тоже есть нюансы, но в общем случае это время, которое все треды процеса пребывали в состоянии running, т.е. исполнялись на каком либо из ядер.
Ну и самый смак: "Если при этом включить показатель "Вывод время ядра" будет частично видно сколько времени кушает ядро системы" - деза детектед. Этот показатель указывает, какую часть времени тред провел в режиме ядра. Например треды класических драйверов там проводят (почти)все свое время. Но (почти)любой тред туда переключатся хоть изредка. Бай дезайн. Как видим, к "ядру системы" (т.е. kernel, kernel executive, и windows subsystem (или lxss, или, ранее, posix даже)) сие отношение имеет чуть менее чем никакое. Определить, сколько времени процессора(-ов) заняло исполнение "системного кода" (написаного М$, а не васей) без помощи использования ETW-трасировок и отладчика  - я считаю, что и невозможно.

Обычно пятничные рассылки церта та еще печалька. Но даже в куче говна иногда попадаются брульянты На этот раз вот такое вот:

"Исследование троянца Belonard, использующего уязвимости нулевого дня в Counter-Strike 1.6"

https://news.drweb.r…lng=ru&p=0

Как страшно жидь, уже и в контру спокойно непошпилить

Цитата: DarkRaider от 14.03.2019 20:51:111) Не очень понимаю восторга о том что "за 6 лет не падала" и "после замены железа она взлетела". Это нормальное состояние, просто "при домашнем использовании" такие случае редки и вызывают приятное удивление. Если сталкиваться с подобными операциями переноса часто  - удивлять перестанут, причём это всё то же самое было начиная с XP и NT. Все эти системы при небольшой подготовке (в виде предварительного удаления драйверов) совершенно спокойно качуют по железу и даже по разным платформам, за редкими исключениями связанными с набором железа.

Я как раз о выделенном. ) В том-то и дело, что никакой подготовки не потребовалось. А ту же XP, например, без сноса драйверов чипсета Вы на другую мать не перенесете, с вероятностью процентов в 90.

Цитата: DarkRaider от 14.03.2019 20:51:112) По поводу падений - тоже никакой разницы  в надёжности не наблюдаю (за сотни компьютеров прошедшие со времён XP). Падения виндов самих по себе вешь редкая.  Львиная доля причин связана с тем, что на компьютере делается (прикладное ПО, вирусы, спектр задач), но втором месте разнообразные обновления чего либо (ОС, драйверов,приклада), на третьем - наличие аппаратных дефектов/проблем.

Фраза "частая установка/снос приложений" у меня в посте не просто так. )

Цитата: DarkRaider от 14.03.2019 20:51:11

Скрытый текст

3) По поводу показометра на картинке: да! он красив!

4) На деле -  начиная с Висты кардинально изменился принцип показометра. Теперь он страдает порядочной шизофренией показывая много разных цифр, которые ничего толком не обозначают. Попробую показать на своём примере:

Читаем. Всего 8Гб. Используется 5Гб. Доступно 3Гб из них 300Мв свободно 2800Мв занято динамическим кэшем (новая фича после хрюшки, типа я сама придумаю что бы ты мог запустить, а так же не буду очищать память после завершения уже запущенных программ, вдруг ты их ещё раз запустишь).
Показометр, нам говорит, что выделено 5Гб из 15 = включим в вывод помимо оперативки ещё и виртуальную!

Теперь откроем Монитор ресурсов и прочитаем внимательно столбцы:
"Завершено" - объём виртуальной памяти зарезервированной ОС на процесса.
"Рабочий набор" - объём физической памяти используемый сейчас процессом. Он складывается из:
"Частный" - объём физической памяти используемый сейчас процессом, который не может быть использован другими процессами  +
"Общий"  - объём физической памяти используемый который может быть использован другими процессами, но сейчас используется этим.

Вопрос: сколько в итоге памяти занимает приложение?  500Мб из 8192? 1Гб из 16?
Зачем используется виртуальная память, если и 500 и 1000мб свободно влезают в оперативную целиком?  При этом этот процесс не 32битный и ограничения в 2.2Гб на процесс тут нету.
Зачем используется виртуальная память для процессов занимающих 4Мб памяти?
1 столбец "завершено" не бьётся с цифрами "Кэшировано", он в сумме сильно больше то есть это лежит не в оперативке, а реально на диске?
3 столбец "общий" тоже не бьётся с цифрами "Кэшировано", он в сумме меньше, то есть это и не динамическая память.

Ещё немного показометра:
Выгружаемая память ядра - 643Мб.  Известно, что "выгружаемая" - это та, что может попадать в своп, но неизвестно в свопе ли она сейчас.
Где эти 643мб?  По монитору складываем рабочий набор получаем 4.7гб из 5.2 "использующихся", следовательно память ядра включена в "используется", но в процессах не отображается?

Ах да!  64бита это же КРУТО!  намного круче чем 32! Правда, почему то, никто не думает, что одна и та же программа, при использовании 64битных переменных вместо 32битных начинает занимать в 2 раза больше памяти на одну и ту же работу.

Зато и использовать можно не 4 Гига оперативки, и даже не 8.

Цитата: DarkRaider от 14.03.2019 20:51:115) Вот мы сейчас философствует о размере потреблённой ОС памяти, при том, что этот показатель тоже весьма косвенный. Опять же если только по этому судить, то хрюшка получится победителем со 117Мб всей потребляемой памяти чистой хрюшки, против 450-500Мб семёрки и 800Мб 8ки и 10ки. По хорошему надо сравнивать максимальный объём памяти выделенный прикладному приложению  системой при отключенном свопе(чёго то ДОС вспомнился, с борьбой за память ниже 640Кб) и общем объёме памяти в 2Гб.


6) Сконцентрировавшись на памяти, забыли о процессорном времени. Любимый показометр опять таки не даёт достоверной картины о том, какой процент ресурсов тратится на обеспечение работы самой ОС. Привычные 2-10% показометра - это нагрузка создаваемая службами и вспомогательными приложениям. Если при этом включить показатель "Вывод время ядра" будет частично видно сколько времени кушает ядро системы. Можно сравнить системы по количеству системных процессов и потоков минимально необходимых для обеспечения стабильной работы системы, это количество растёт от версии к версии.

Спокойствие, только спокойствие. )
Вы же сами заострили внимание на "сколько ОС оставляет ресурсов приложениям"? Я показал то, что наблюдаю в своей системе, и то что мы наблюдаем, показывает что особой разницы в объёме потребляемого на нужды ОС между 7 и 8.1 нет. Не согласны?

Цитата: DarkRaider от 15.03.2019 23:14:25Я стараюсь использовать точные формулировки и, в данном случае, меня надо понимать дословно, попробую объяснить почему:

1) "поддержка 64 бит" - это наличие в процессоре инструкций (операндов) способных обрабатывать 64битные параметры(регистры) за 1 такт.

2) Не существует "типов данных в винде". Типы данных - свойство машинного кода генерируемого компилятором. В случае жабы и дотнета - свойство виртуальной машины получающей на исполнение промежуточный код (и самого промежуточного кода). Но не стоит забывать, что задача такой виртуальной машины - преобразование промежуточного кода в машинный, так что в итоге всё равно упирается в аппаратную реализацию процессора (набор доступных операндов+размер регистров).

Да лааадно?
А тут о чем?
https://docs.microso…25d93e4ba2
Или тут?
https://docs.microso…ew=vs-2017

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

Цитата: DarkRaider от 15.03.2019 23:14:253) "Переменные ж вообще дело не ОС, а погромиста" (надеюсь погромист - оговорка по Фрейду?).

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

Цитата: DarkRaider от 15.03.2019 23:14:253) Переменные в программе - не что иное как выделенный участок в оперативной памяти строго заданного размера.
Память в винде жёстко выделяется из "общей кучи" (heap) на каждый процесс и поток. Не стоит заблуждаться - не типизированные языки программирования - отдают привилегию определения типа компилятору, который обычно выбирает максимально возможный вариант "чтобы всё влезло". И да, абсолютно все используемые в коде переменные - это кусок в выделенной процессу памяти.

Память какая? Под переменные? Или вообще? А как же VirtualAlloc? Так не обязательно из кучи, наверное, да?

Цитата: DarkRaider от 15.03.2019 23:14:254) "Вроде int, long и т.д. Вот там влияние есть, но там все сильно сложнее. " Тут нет никаких сложностей, раньше в большинстве компиляторов тип int занимал 16 бит, тип long 32 для 64 бит был отдельный (long long, int64). По мере схода с арены 16битных процессоров, программ и внедрения сначала 32, а потом 64битных инструкций, компиляторы меняли типы данных по умолчанию и сейчас "общепринято" int=32 бита, long=64.

Да, компиляторы и разницу в них я как-то упустил из виду. Но, вернемся к нашим баранам, написаное вами ведь не означает автоматического увеличения потребной памяти в 2 раза изза x64. Согласны?

Цитата: DarkRaider от 15.03.2019 23:14:255) Абсолютно все переменные в текущий момент времени исполнения - это ячейки памяти, соответствующего размера и целый тип long сейчас компилируемый будет занимать 64бита памяти на 1 переменную. Если код компилировать под win32 платформу с указанием типа long - будет по умолчанию использована длинна 32 бита. Одной и той же программы. Одного и того же компилятора. Одна и та же переменная ЦЕЛОГО типа будет занимать в 2 раза больше/меньше места в памяти в зависимости от платформы. Обратная сторона медали, если задано жёсткое соответствие типов и в программе строго прописан int32, int16,byte  - они будут занимать одинаковое количество  памяти для обоих платформ.

Я так понимаю, это означает, что никаких в 2 раза не будет и близко.

Цитата: DarkRaider от 15.03.2019 23:14:256) "К тому-же "занимаемая програмой" память - понятие комплексное".  Понятие вполне реальное если представлять какие типы где используются и на что указывают. Действительно, при компиляции программы под 64 бита - объём занимаемой ей памяти возрастает не вдвое потому, что в программах используется не только "длинные целые" типы данных, но их не мало, если учесть, что все указатели тоже становятся 64битными. Откуда, собственно, возможность использовать больше оперативки? Это возможность в качестве адреса указывать число превосходящее диапазон 32бит (2 147 483 647байт). Отсюда же взялось в 32битной системе ограничение 2.1Гб на один процесс. В остальном, "прекрасная маркиза" - всяческие виртуальные области, совместное использование памяти разными программами - это выверты арбитра памяти ОС в интересах "оптимизации себя любимого", ни одна программа об этом доподлинно не знает, что кусок её массива вдруг уехал в виртуальную память (своп). Скажу больше, совместное использование общей области памяти даже в рамках 1 программы, но параллельных потоков - это вполне приличный геморрой с возможным блокировками и прочими ухищрениями. Отдельная и интересная тема в программировании - синхронизация параллельных потоков.

Понятие да, реальное. Но комплексное Я в курсе за ограничение, откуда и почему оно. Тут спорить не буду. Считаете за выверты - ваше право. По мне так вполне внушающая и, внезапно, довольно надежно работающая технология.

Цитата: DarkRaider от 15.03.2019 23:14:257) К слову "64битное ускорение" - это яблоко с той же яблони.  Если раньше 1 операнд для обработки 1 числа диапазона 64 бит занимал 2 такта по 32(старший регистр и младший)  ввиду того, что аппаратно его инструкция была так реализована, то "потом" его научили  делать операцию за 1 такт со всем числом.

Термин "64битное ускорение" как-то прошел мимо меня. Удивительное рядом

Цитата: DarkRaider от 15.03.2019 23:14:25И тут всё тоже несколько неоднозначно. Что такое на самом деле "загрузка процессора"?  Каждое реальное ядро процессора, каждый такт выполняет 1 операнд с текущей частотой, на которой в данный  момент работает  ядро (современные процы могут менять частоту ядер и отключать их по мере надобности). Если (Turbo boost) не активен, то 4хядерный процессор на частоте 3ГГц выполняет 4*3*10^9 инструкций в  секунду. Всегда. В любом случае. Допустим в системе 100 процессов, 1000потоков(поток по сути  тот же процесс, только с контекстом безопасности наследованным от родительского процесса и от него же зависимый). Вся эта тысяча параллельных потоков с определённой частотой попадает на 4 ядра, переключением завидует арбитр управления задачами ОС(и это не диспетчер задач). Как показывает get-process, большую часть времени процессор "простаивает"? Но остановится реально он не может, он всё равно исполняет положенных 12*10^9 операндов за секунду. Что же происходит?  В свободное время он выполняет "пустую" инструкцию(nope).  Следовательно - реальная "нагрузка" это отношение команд nope на конвейре  ядра по отношению к общему числу операндов за единицу времени. Откуда его взять?  Да ни откуда. В процессорах нет аппаратных счетчиков нагрузки и все эти секунды и проценты - берутся из арбитра управления задачами ОС, так как именно он решает когда переключить ядро на какой поток и делает это по своим алгоритмам.  А посему - "они всё врут" если брать буквально.

Это все примерно так (только процессор не всегда "молотит", C-state'ы забыли, и паркинг, ага). Ну и хотплаг проца. Вот непомню, винда умеет в него или нет.

Цитата: DarkRaider от 15.03.2019 23:14:25Прежде чем словами кидаться, Вы, бы, любезный, изволили сначала ознакомится хоть с какой то информацией по вопросу что такое "режим ядра".
Начните с простого вики и хабра.

Когда осознаете - сами поймёте, что сморозили.

Ась? Я тащемта вроде в курсе, что такое "режим ядра", и чем он отличается от "Ядра операционной системы и служебных компонентов"(цитата неточная, бо по смыслу). Ничего вроде не сморозил. Ткните носом, если что.


Кстати, подсказка от "морозящего", про перенос платформ: разведка сообщает, что раньше у винды вроде бывали разные HAL'ы...
И еще, порылся в книжке на предмет "откуда брать "нагрузку"". В TCB есть поле, зовется cycletime, смещение 0х048. Тоже может врать, если треду не дали довыполняться до отмеренного ему времени (quantum), и выпнули на мороз,  но не сильно. Вот оттуда и считают, если по людски.

Цитата: DarkRaider от 15.03.2019 23:14:25Я стараюсь использовать точные формулировки и, в данном случае, меня надо понимать дословно, попробую объяснить почему:

3) ... Память в винде жёстко выделяется из "общей кучи" (heap) на каждый процесс и поток.

Каждый процесс в любой мультизадачной ОС (в том числе и в виндовсах) на x86_64, в режиме x64 получает в свое исключительное распояржение все адресное пространство, которое может в данном режиме адресовать процессор. Это до 2^{48} или 256 терабайт. Реально верхняя граница логического адресного пространства устанавливается загрузчиком – он просто в регистр указателя стека загружает максимальное значение адреса, выше которого располагается память, которую используют системные библиотеки, код которых выполняется в рамках данного процесса.  В линуксе, например, процессу в полное распоряжение отдается нижняя половина адресного пространства, что можно увидеть в отладчике, распечатав содержимое регистра rsp сразу после загрузки программы.
Поток никакой отдельной памяти не получает – все потоки, порожденные в рамках процесса, совместно используют логическое адресное пространство этого процесса. 

Цитата: Head790 от 14.03.2019 19:22:57В домашних условиях ресурс не износить,

Так то в домашних. Так еще там надо на параметры смотреть.
А я про рабочий. Там на 4 гигах запускают 1С, браузеры, ворд-эксель-аутглюк, иногда еще и оракловское приложение и кучу открытых папок. Оно в таких количествах им нафиг не надо, но вот все равно.
Правда, для меня до сих пор тайна великая есть, как офисный редактор текста может память жрать считанными гигабайтами. Вот чего туда напихать можно?...
А про то, что SSD в цене здорово упали за последние месяц-два - спасибо, в курсе. Дома лежит 240 за 1,8к.

Цитата: small__virus от 16.03.2019 09:29:20А про то, что SSD в цене здорово упали за последние месяц-два - спасибо, в курсе. Дома лежит 240 за 1,8к.

Пора переходить на следующее поколение )
У меня на домашнем компе стоит Samsung 970EVO в формате M2, скорость последовательного чтения 3.4ГБ/с

Цитата: pps от 28.02.2019 14:00:58Таки запрашивали разъяснения. Отдельно они не считаются российским ПО, а вот в составе Рэд, Альт, Роса и т.п. считаются. Так что можно пользоваться официально российским Либрой и Опенофисом, правда вышеописанные проблемы никуда не деваются.
 Плюс есть еще кое какие штучки типа:

А вот всяким системам документооборота нужны внедренные плюшки чтобы вставлять всякие красивости типа красивой штучки о том что документ электронный и написан и подписан ЭЦП и тому подобные приколы.

но вот свои собственные внедрения calc во writer вполне поддерживает.

Цитата: slavae от 16.03.2019 12:29:45Пора переходить на следующее поколение )
У меня на домашнем компе стоит Samsung 970EVO в формате M2, скорость последовательного чтения 3.4ГБ/с

Это все замечательно, но сакраментальный вопрос - а нафига?....
Как показывает практика, очередное повышение быстродействия чего либо приводит к появлению очередного болта, который забьют программисты на оптимизацию и появление новых проблем, которые из этого вырастут.
Я в принципе не наблюдаю задач, для которых в домашних условиях необходимо подобное быстродействие. Да там даже SSD SATA в большинстве случаев избыточен.

Цитата: vovbel от 16.03.2019 18:54:50...Шумит, если играть или смотреть видео в HD качестве...

А майнинг?

Цитата: small__virus от 16.03.2019 15:25:59Это все замечательно, но сакраментальный вопрос - а нафига?....
Как показывает практика, очередное повышение быстродействия чего либо приводит к появлению очередного болта, который забьют программисты на оптимизацию и появление новых проблем, которые из этого вырастут.
Я в принципе не наблюдаю задач, для которых в домашних условиях необходимо подобное быстродействие. Да там даже SSD SATA в большинстве случаев избыточен.

Банально комфортнее работать, например) Если один хард, и одновременно с него скачивать/раздавать торренты(а скорости уже не 10мбит/с), обрабатывать видео/фотографии(это тоже домашнее использование) или рубиться в новые модные игры, тормоза будут ощутимые. Даже с самым старым SSD этого нет или не так бесит. Современные винты меньше тормозам подвержены, но всё же. Неиспользование SSD сейчас скорее проявление жадности(как 4 ГБ ОЗУ в 2019 году в конторах) или ретроградства:) Это как с электростеклоподъемниками, усилителями рулей, кондеями в машинах, без них прожить можно, но с ними удобнее, или как с перфоратором, который можно заменить ручной дрелью, зубилами и кувалдами). А оптимизации ширпотребского ПО(игр например) особого внимания не уделяют, ибо игры - двигатель прогресса(один из главнейших факторов), если всё будет летать на старом железе, то мало кто станет новые железки покупать. Но ССД в любом случае оправданы.

Цитата: Sewer Endemic от 16.03.2019 19:28:23В принципе можно, но я уж привык выключать... После гибернации всё примонтированное по sshfs, конечно же, отваливается. Но комп думает, что оно ещё примонтировано, просто сервер временно не отвечает. На перемонтирование нужно время. На отмонтирование перед гибернацией тоже время какое-то уходит, так что и тут особой экономии времени не будет. Быстрее, чем "холодный" запуск с SSD, но не намного.

На Баше настрогать скрипт можно, или готовый переделать. И экономия появится.

Цитата: donbass.hellas от 16.03.2019 19:12:07А hibernate если делать?

Мсье знает толк в извращениях.

Цитата: Head790 от 16.03.2019 19:58:48Банально комфортнее работать, например) Если один хард, и одновременно с него скачивать/раздавать торренты(а скорости уже не 10мбит/с), обрабатывать видео/фотографии(это тоже домашнее использование) или рубиться в новые модные игры, тормоза будут ощутимые. Даже с самым старым SSD этого нет или не так бесит. Современные винты меньше тормозам подвержены, но всё же. Неиспользование SSD сейчас скорее проявление жадности(как 4 ГБ ОЗУ в 2019 году в конторах) или ретроградства:) Это как с электростеклоподъемниками, усилителями рулей, кондеями в машинах, без них прожить можно, но с ними удобнее, или как с перфоратором, который можно заменить ручной дрелью, зубилами и кувалдами). А оптимизации ширпотребского ПО(игр например) особого внимания не уделяют, ибо игры - двигатель прогресса(один из главнейших факторов), если всё будет летать на старом железе, то мало кто станет новые железки покупать. Но ССД в любом случае оправданы.

SSD на 10ТБ? если честно, то мои дети не внуки Рокфеллера.
SSD только для системного диска. Ось (винда или фря, без разницы). Данные на другом винте, обычном HDD . А долговременные данные на рейде домашнего сервера.

Цитата: olenevod от 16.03.2019 21:19:59SSD на 10ТБ? если честно, то мои дети не внуки Рокфеллера.
SSD только для системного диска. Ось (винда или фря, без разницы). Данные на другом винте, обычном HDD . А долговременные данные на рейде домашнего сервера.

Зачем 10ТБ? Такой объём хардов редко у кого встретишь в компе. Я на старом ноуте с 240 ГБ уживался, хард просто убрал, ибо нужды не было, зато шум исчез. Для системного, если без игр, вообще 64 ГБ с головой большинству хватит, ну или 120(на новом ноуте с Win10 + всё, кроме не относящегося к системе, 28 ГБ занимает, вместе подкачками и временными каталогами, всё для моей работы - +10ГБ, на харде только бэкапы держу). А хламовник можно на сервере или в облаках держать.