Перенос с HDD на SSD
От Eugene Muzychenko (2:5000/14) к Ivan Novikov
В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)
Привет!
24 Jul 17 20:53, you wrote to me:
IN> сишное протекание - притча во языцех
Hету в C протекания, нету. :) Там управление динамической памятью полностью в распоряжении программиста, язык никак не может ни способствовать протеканию, ни бороться с ним. Hо в C/C++, по той же причине, можно легко контролировать любые утечки - если этого где-то не делают, то виноват уж точно не язык. :)
А вот в языках, где динамическая память управляется автоматически, программист зачастую принципиально не может обнаружить утечек, поскольку у него нет доступа к распределению, и остается либо делать спецтесты, чтобы уличить разработчиков языка в косяках, либо ждать, пока они признают это сами.
Вообще, невозможно сделать память без утечек, пока к ней имеется общий доступ. Чтобы гарантированно избавиться от любых утечек, нужно любую временную активность (например, страницу) заворачивать в отдельный процесс, с предоставлением собственного адресного пространства, и при закрывании прибивать целиком. Вроде как в каких-то браузерах такое применялось. Тот же Firefox умеет разделять рендеринг и показ между процессами, но не пользуется этим активно.
EM>> В браузерах течет прежде всего из систем исполнения кода на JS,
IN> но он же интерпретатор.
И что? Он должен динамически выделять память по запросам программ, и сам следить за ее освобождением.
EM>> Для текстовых документов большинству юзеров по уши достаточно формата
EM>> RTF или MS Word 95,
IN> ну, это ты не суди по нашим "уверенным пользователям ворда" которые
IN> знают только две кнопки: "Save" и "Print"
Hу так расскажи, чего современному пользователю может не хватать в формате файлов Word 95. :) Там, по-моему, из систематически используемого сейчас, нет только гиперссылок.
EM>> а в новых форматах новые ворды сохраняют с единственной целью -
EM>> побудить юзеров почаще обновлять офис (то есть, платить MS).
IN> окстись! этому формату уже десять лет. с той поры четыре версии офиса
IN> сменилось, а формат нет.
Значит, не придумали пока, что туда еще засунуть. :)
IN> всякий софт развивается, появляются новые фичи. их надо как-то
IN> сохранять в проекты. естественно, что на старом софте, где такие фичи
IN> отсутствуют, такие файлы не обязаны открываться.
Там, где ведется систематическая разработка, обычно или обновляют софт везде, или устанавливают правила совместимости форматов. Проблемы с открыванием в разных версиях чаще возникают в диких сообществах, где это не контролируется.
IN> всё остальное - картинки-графики-таблицы с разметкой (RTF не умеет в
IN> обтекание), колонтитулы и нумерация страниц нормальная, списки,
IN> заметки и, самое главное - история правок.
Все перечисленное прекрасно записывается в RTF. Вообще, сложно представить нечто такое, чего невозможно было бы туда записать, ибо RTF - теговый формат.
IN>>> а электронные таблицы в чём прикажешь сохранять "для
IN>>> совместимости"?
EM>> В Excel 95, согласно рекомендациям. :)
IN> чьим?
Майкрософтовским, данным еще в незапамятные времена.
EM>> Загрузкой через PXE я никогда не пользовался
IN> ну вот опять - я мне не надо, и так всё работает.
Так не только мне. Сколько виртуальных машин из сотни нужно загружать через PXE?
EM>> (и для чего может понадобиться ее регулярное использование в
EM>> VM?),
IN> не поверишь - для отлаживания этой самой PXE загрузки по сети
Этим занимается 70% всех пользователей виртуальных машин? Или хотя бы 30%? :)
IN> ещё год назад я пробовал - кривизна была на месте.
IN> вайфайный усб в гостевом линухе работать не желает, в отличие от
IN> вмвари.
А в том гостевом линуксе все в порядке? Гостевую винду не пробовал?
EM>> У вари функциональность уже давно растет преимущественно в
EM>> сторону совместной работы, кластеров и подобного.
IN> да, только не в player и workstation версиях, которые тоже пухнут.
В Workstation как раз за последние десять лет напихали до фига "коллективных" фич.
EM>> Чего тебе там не хватает по сравнению с варью для индивидуальной
EM>> работы?
IN> вот хотя бы вышеперечисленных двух фич
Отладка PXE, как уже сказано, штука очень редкая. USB там в целом работает нормально. Отдельные глюки, само собой, возможны.
EM>> Осталось понять, какой именно функционал в CS3 требовал шестисот
EM>> мегов. :)
IN> а там две версии - 32 и 64-битные
И что, там примерно по триста мегов уникального кода/данных на каждую версию? :) Или, может быть, различается там от силы 20%, а все остальное тупо положено в двух экземплярах, чтобы не разбираться, какой куда идет? :)
IN> винда, устанавливаемая в виртуалке ставится сильно быстрее, чем на том
IN> же самом железе.
Hе замечал. Возможно, где-то пролезает кэширование, хотя и не должно.
IN> там же установка всех обновлений происходит быстрее. равно как и
IN> какие-нибудь жручие до файловых операций задачи (типа скриптов,
IN> например) быстрее исполняются в пробирке.
Hа это уже может влиять внутригостевая оптимизация, хотя я у себя, опять-таки, заметной разницы не замечаю.
EM>> Более того, та же варь по умолчанию честно транслирует
EM>> дисковые операции гостя в некэшируемые файловые операции хоста,
IN> уверен?
Абсолютно. Задай в Process Monitor фильтрацию по имени файла-контейнера диска, и посмотри флаги в последнем CreateFile (их может быть несколько при старте VM) - там будет "No Buffering" (FILE_FLAG_NO_BUFFERING). Я еще возмущался, почему это не управляется, ибо отключение позволило бы существенно ускорить работу VM.
IN> я вот ещё вижу, что дисковые пробирки, типа vmdk имеют структуру, зело
IN> отличную от просто диска и имеют всякие фичи типа sparse экстентов и
IN> compressed sparse экстентов.
Так это попросту отражение возможностей NTFS, чтобы не выделять на хосте пространства под незанятые области виртуального диска. Я, кстати, предпочитаю делать Flat VMDK, когда описатель диска лежит в одном файле, а собственно образ - в другом, чтобы можно было монтировать чем угодно и куда угодно.
IN> дык, хром и так каждое окно в отдельной песочнице запускает.
В отдельном процессе?
IN> да и как показывает практика, просто выполнение какого-то кода - не
IN> самая большая проблема по сравнению с тем же фишингом, например.
У хомячков - да. Hо при наличии мозгов фишинг можно контролировать, а для контроля исполнения к мозгам потребны еще и специальные знания.
Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)
--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Fox Tracks, Novosibirsk, Russia (2:5000/14)
Ответы на это письмо:
From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку
From: Username
Или коротким