на главнуюВсе эхи SU.HARDW.PC.MEDIA
войти ?

Перенос с HDD на SSD

От Eugene Muzychenko (2:5000/14) к Ivan Novikov

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


Привет!

21 Jul 17 17:27, you wrote to me:

IN> я вижу только текущий хром и текущий файрфокс, например, которые
IN> писаны на С. и вижу, например, the bat, который не течёт, поскольку
IN> написан на паскале.

А насколько ты разбираешься в C и Pascal, чтобы усматривать в этом причинно-следственную связь, а не банальное совпадение? :) Если что, там методы работы с динамической памятью совершенно одинаковые, только синтаксис различается.

В браузерах течет прежде всего из систем исполнения кода на JS, а не из кода самого браузера. Это еще один признак того, что исполнение стороннего кода в браузере - однозначное зло.

IN> поэтому у меня вырабатывается простая логическая цепочка: С -> кривой
IN> код -> утечки

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

IN> чтобы не плодить сущностей в виде разных версий документов.
IN> получил файл, исправил, отослал обратно - там его получили под тем же
IN> именем.

Лучше всего это работает как раз на самом нижнем уровне совместимости, поддерживающем реально (а не гипотетически) используемые в документе сущности. Для текстовых документов большинству юзеров по уши достаточно формата RTF или MS Word 95, а в новых форматах новые ворды сохраняют с единственной целью - побудить юзеров почаще обновлять офис (то есть, платить MS). С другим софтом дело обстоит примерно так же.

EM>> Если нужна совместимость, то и писать нужно в совместимых
EM>> форматах (например, в RTF).
IN> в нём кроме самой примитивной разметки документа нет ничего.

А что нужно-то? Сколько в сотне навскидку взятых из сети текстовых документов найдется элементов, непредставимых в RTF, и внесенных в документ осознанно, а не автоматически вордом?

IN> а электронные таблицы в чём прикажешь сохранять "для совместимости"?

В Excel 95, согласно рекомендациям. :)

EM>> Тот же VirtualBox можно считать "приличным пакетом"? :)
IN> там работу с USB и загрузкой через PXE допилили хоть?

Загрузкой через PXE я никогда не пользовался (и для чего может понадобиться ее регулярное использование в VM?), а с USB там были проблемы лет десять назад.

EM>> Он почему-то не пухнет, хотя функциональность все время растет.
IN> да не сильно растёт, по сравнению с той же вмварью.

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

IN> я его рассматриваю как бесплатную виртуалку для "по-быстрому
IN> чего-нибудь сделать"

Чего тебе там не хватает по сравнению с варью для индивидуальной работы?

EM>> Да и VmWare Workstation за десять лет увеличилась в дисковом объеме
EM>> меньше, чем вдвое,
IN> это мало?

Учитывая, что процентов восемьдесят этого увеличения ушло на поддержку всяческих Unity и т.п. - довольно мало.

IN> дык, и фотошоп, в таком случае, увеличился в два раза - CS3 весил 600
IN> мегов, нынешний - 1.2 гига. а уж там-то функционал вырос многократно.

Осталось понять, какой именно функционал в CS3 требовал шестисот мегов. :) Ибо все, к чему прикасается адоб, до того растет очень медленно, а с момента покупки адобом начинает распухать бесконтрольно.

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

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

EM>> Это все прекрасно и очень удобно, но это не должно делаться в
EM>> _браузере_.

IN> а чего нет-то?

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

IN> сейчас браузер - окно наружу. зачастую - единственное.

Окно - это хорошо. А что слили все говно в браузер - плохо.

IN> для каждой задачи отдельное приложение городить?

Зачем? Hехай будет отдельно умеренно функциональный браузер с предсказуемым поведением, и отдельно - среда для исполнения произвольного кода, открытая для любого говна. Идеологически это подобно разделению понятий "документ" и "исполняемая сущность", безо всяких уловок вроде исполняемых внутри документа скриптов или макросов. Открывание документов практически полностью безопасно, а исполнение полученного извне кода - по определению опасно. Вот и нехай каждый выбирает, что ему удобнее.

А когда функциональность обычного информационного (без свистелок и перделок) сайта будет укладываться в "интерактивную разметку" - у сайтостроителей появится стимул делать сайт именно для браузера, а не для среды исполнения. Hынешнее же отсутствие границ провоцирует наворачивание программного кода там, где вполне можно было бы обойтись разметкой.

IN> кстати, это тоже было.
IN> можно вспомнить лотус, где всё в одной программе живёт.
IN> а до этого досовский фрэймворк (не помню как звали)

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

Всего доброго!
Евгений Музыченко
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
Или коротким

FGHI-url этого письма: area://SU.HARDW.PC.MEDIA?msgid=2:5000/14+59724082