Re: Плоды веб-прогресса
От: vsb Казахстан  
Дата: 06.05.20 19:11
Оценка: +3
Всё новое это хорошо забытое старое. IE 6 only сайты видимо уже забыли, а я помню.

А так да, так и есть. Хром это новый IE. Если под ним работает, остальное уже по остаточному принципу. Ещё Safari проверяют, хоть там и процент небольшой, но у них обычноо денег много, поэтому они интересны. Фаерфокс никому не интересен, там только гики. Если в программистах такого гика не затесалось, так и будет получаться. Про graceful degradation, когда без новых возможностей страница будет отображаться настолько хорошо, насколько возможно, уже все забыли. По сути это money-oriented development, всё оценивается с точки дохода, а не с философской или идеологической точки зрения.
Отредактировано 06.05.2020 19:14 vsb . Предыдущая версия . Еще …
Отредактировано 06.05.2020 19:13 vsb . Предыдущая версия .
Re[7]: Плоды веб-прогресса
От: sharez  
Дата: 13.05.20 09:58
Оценка: +2 :)
Здравствуйте, Евгений Музыченко, Вы писали:

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


Мы все сами подписались на то, что IT наша жизнь.
Быть в потоке и постоянно грести — одно из свойств такой карьеры.
Всё же это лучше, чем уходить каждый день в один и тот же забой.
Предлагаю с мужеством перенести эти невыносимые тяготы IT-бытия.
Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 06.05.20 06:48
Оценка: +2
Недавно обнаружил, что на странице успешного завершения заказа (Thank You Page) странице у 2Checkout не отображается лицензионная информация. Написал им, они признали ошибку, через некоторое время сообщили, что исправили ее. Проверяю в свежем Chrome — отображается, проверяю в Firefox ESR 52.9.0 — не отображается. При этом в FF и сама страница, и весь процесс покупки выглядят совершенно адекватно — у покупателя нет ни малейшего повода заподозрить неладное. Vendor Dashboard в этой же версии тоже работает прекрасно.

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

Блин, на таком фоне даже как-то неловно критиковать службы поддержки за то, что первым делом предлагают перезапустить браузер, очистить кэш, попробовать другой браузер и т.п. Если вроде бы профессиональные веб-программеры ваяют такое для обработки онлайн-покупок...
2checkout avangate thank you заказ покупка лицензия лицензионная
Re: Плоды веб-прогресса
От: sharez  
Дата: 06.05.20 19:04
Оценка: +2
А если подумать, каков масштаб проблемы?

1. Сколько пользователей подвержено проблеме?
Выходит, 0.25% где-то (FF 52 и старее).
https://caniuse.com/usage-table

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

2. Да и какому проценту юзеров вообще нужно читать лицензию?
Да не читает их никто. Максимум людей интересует FAQ по лицензии: что можно, а что нельзя — это может быть только на сайте.
Те, кому реально нужна лицензия — попросят, тут вообще нет проблемы, о первом таком нуждающемся вы бы уже знали.

3. Насколько эта проблема критична?
Она вообще не критична: ссылка на лицензию есть на сайте (на котороый отправляется ссылка) или в программе, или программа ссылается на сайт, где она есть.


Итого: ну баг и баг. Минорный-преминорный. Из-за чего сыр-бор?
Re[7]: Плоды веб-прогресса
От: Lazytech Ниоткуда  
Дата: 11.05.20 09:03
Оценка: 16 (1)
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот любопытства ради поставил FF 76.0.1 в виртуалке. Открыл с новья пять типичных на сегодня вкладок. Он на это отожрал гиг. Мой мозг отказывается это понимать. Я даже близко не представляю, что нужно курить, чтобы делать такой код. Даже если плюнуть на привычные в 52.9 плагины, я не могу заставить себя этим пользоваться.


Я правильно понял, что флажок «Использовать рекомендуемые параметры производительности» снят и количество процессов отображения содержимого уменьшено до 1? Если нет, см. подробности по ссылкам ниже.

https://support.mozilla.org/en-US/kb/performance-settings?as=u&utm_source=inproduct

https://support.mozilla.org/ru/kb/parametry-proizvoditelnosti-brauzera-firefox?as=u&utm_source=inproduct
Re[3]: Плоды веб-прогресса
От: sharez  
Дата: 08.05.20 10:56
Оценка: 4 (1)
Здравствуйте, Lazytech, Вы писали:

L>Здравствуйте, sharez, Вы писали:


S>>Броузер-то действительно старый. Если человек не обновляет броузер, забил на безопасность, то он не тот человек, который попросит лицензию (вероятно он купил не тот софт, которому она вообще нужна, он мог не знать даже, что покупает не продукт, а лицензию).


L>Судя по некоторым комментариям в исходном коде страницы www.2checkout.com, разработчики непонятно зачем пытаются поддерживать IE8, который вышел лет на десять раньше, чем Firefox 52.9.0 ESR.

L>
    <!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
L>    <!--[if lt IE 9]>
L>    <script src="/assets/js/html5shiv.js"></script>
L>    <script src="/assets/js/respond.min.js"></script>
L>    <![endif]-->

L>Или я что-то не так понял?

Запрета нет на поддержку IE 8 нет.
Сколько лет этому коду?
Когда-то IE 8 был актуален.

Кстати, именно этот код идёт в примерах ко многим библиотекам.
Даже в Bootstrap такое было. Тупо скопировали из примера или создали проект из шаблона.
Если этот код выбросить, то что-то поломается у 0.01% наиболее отсталых и неплатежеспособных юзеров в интернете. У них и без этого половина интернета не работает.
Re[6]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 08.05.20 13:56
Оценка: +1
Здравствуйте, sharez, Вы писали:

S>Лучше иметь нормальную форму покупки для 99% пользователей, чем кизяки мамонта, поддерживающие всех 100%.


Когда относительно свежие функции необходимы для придания форме этой самой нормальности — согласен. Но что такого "нормального" в той форме 2Checkout? Я там не вижу ничего, требующего для реализации возможностей хотя бы пятилетней давности. Это как поставить условие наличия C++20 для сборки стандартного "Hello, world!".

S>Пример: Windows & Office. До сих пор можно открыть документ из Word 95 и даже запустить софт оттуда (но уже не весь).


А еще можно открыть простой текстовый файл. Сколько сотых процента от всех ресурсов требуется для поддержки этой возможности?

S>ваш софт запустится на Mandriva Linux десятилетней давности?


Под Linux не пишу, а тот софт, что не использует возможностей, специфичных для NT, запустится даже на Win95. Из того, что под NT, бОльшая часть запустится под Win2k. До прошлого года у меня минимальной поддерживаемой версией была XP, теперь — семерка. И мне это не стоит практически никаких усилий, поскольку я делаю в первую очередь функциональность.

S>FF 52 просто небезопасен, чем больше будет проблем у таких юзеров, тем быстрее они обновятся, и им же будет лучше.


Ну так и вываливали бы сразу сообщение: "ваш браузер небезопасен, работать на нем не будем". Но на эту небезопасность им плевать, важнее приделать какие-то невидимые рюшечки.
Re[9]: Плоды веб-прогресса
От: Gt_  
Дата: 11.05.20 09:14
Оценка: -1
ЕМ>Мне, честно говоря, на все перечисленное глубоко насрать. Для меня браузер — средство в первую очередь просмотра информации с интернет-ресурсов. То, что мне попутно навязывают еще и среду для исполнения навороченных веб-приложений, мне категорически не нравится.

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

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


ЕМ>Окститесь, один поток на все закладки был лет пятнадцать назад, если не больше.


вранье.

ЕМ> А не понимаю я прежде всего того, зачем для отображения несложной страницы используются сотни мегабайт памяти. Если Вы считаете себя компетентным в этом вопрос — разъясните, только с цифрами, а не абстрактно.


тут программист нужен. он поймет разницу.
Re[13]: Плоды веб-прогресса
От: Gt_  
Дата: 11.05.20 16:25
Оценка: -1
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Gt_, Вы писали:


Gt_>> Memory cost for various scenarios (which largely depend on what part of firefox code need to be initialized/used in the process — XPCOM, etc)

Gt_>> Memory overhead for a Process on Win10 x64 appears to be circa 7-10 MB (Private) for a process with minimal XPCOM inited, IPC, etc. The GPU process (which also loads GPU drivers, etc) is on the order to 20MB, and anecdotally the GMP process uses on the order of 10MB, which is in line.

ЕМ>Так на сарае тоже известно что написано. Да только вместо обещанных 100 (20 x 5, и это максимум) Мб оно в многопроцессном режиме жрет на 500 Мб больше.


прости чувак, но ты туповат для беседы. в тексте говорится о минимальных цифрах.
Re: Плоды веб-прогресса
От: vladrsdn http://vvh-ru.blogspot.com/
Дата: 06.05.20 08:16
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Если вроде бы профессиональные веб-программеры ваяют такое для обработки онлайн-покупок...


да какие профессиональные, самые дешевые индусы наверно им это ваяли.
http://vvh-dev-ru.blogspot.com — Трудовые будни шароварщика http://vvh-ru.blogspot.com — Блог об оффлайне
Re[2]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 06.05.20 13:31
Оценка:
Здравствуйте, vladrsdn, Вы писали:

V>да какие профессиональные, самые дешевые индусы наверно им это ваяли.


Тогда кому ваяют профессиональные, и как их отличить?
Re[3]: Плоды веб-прогресса
От: sfsoft Россия  
Дата: 06.05.20 18:23
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Тогда кому ваяют профессиональные, и как их отличить?


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

P.S. Мне вот тут
Автор: sfsoft
Дата: 21.04.20
, кстати, обратное доказывают.
Отредактировано 06.05.2020 18:24 sfsoft . Предыдущая версия .
Re: Плоды веб-прогресса
От: L.K. Марс  
Дата: 06.05.20 18:45
Оценка:
ЕМ>за исключением полного отсутствия важной части страницы

Важной для кого? Задача регистратора — показать сумму платежа и формочку для ввода номера карты. Ну и получить процент с транзакции. А насчёт лицензий пусть покупатель разбирается с продавцом софта.

Вообще, лицензию можно показывать на своём сайте, и уже оттуда перенаправлять покупателя на сайт регистратора.
Re[2]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 07.05.20 02:12
Оценка:
Здравствуйте, L.K., Вы писали:

LK>Важной для кого?


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

LK>Задача регистратора — показать сумму платежа и формочку для ввода номера карты. Ну и получить процент с транзакции. А насчёт лицензий пусть покупатель разбирается с продавцом софта.


А что гарантирует регистратору отсутствие оттока и покупателей, и вендоров в результате таких вот косяков?

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


Как именно это будет работать при использовании регистратора, если код у регистратора кривой?
Re[2]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 07.05.20 02:45
Оценка:
Здравствуйте, sharez, Вы писали:

S>1. Сколько пользователей подвержено проблеме?

S>Выходит, 0.25% где-то (FF 52 и старее).

В случае использования голого HTML/CSS такой подход можно было бы считать допустимым. Но там же сплошь JS. Это как если бы писалась обычная нативная программа под некую ОС, использовала относительно новую особенность (например, флаг) без проверки того, что ОС ее должным образом понимает, и в более старых версиях это приводило бы к неявному нарушению поведения.

S>Броузер-то действительно старый. Если человек не обновляет броузер, забил на безопасность, то он не тот человек


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

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


Это уже какие-то рассуждения из области чистой философии.

S>2. Да и какому проценту юзеров вообще нужно читать лицензию?


"Лицензионная информация" — это ключи, приватные ссылки и т.п. Instant Fulfillment.

S>Итого: ну баг и баг. Минорный-преминорный. Из-за чего сыр-бор?


Я опять все пропустил, и вместо корректного кода нынче считается правильным разрабатывать минимально глючный?
Re[2]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 07.05.20 03:01
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>IE 6 only сайты видимо уже забыли, а я помню.


Я хорошо помню и просто IE-only сайты середины 90-х.

vsb>Про graceful degradation, когда без новых возможностей страница будет отображаться настолько хорошо, насколько возможно, уже все забыли.


Именно поэтому я и предлагаю разграничивать веб-страницы (ресурсы, предназначенные главным образом для получения информации) и веб-приложения (ресурсы, предназначенные главным образом для выполнения действий). Graceful degradation в полной мере относится только к информационным ресурсам, поскольку лучше получить часть информации, чем ничего. Приложение же обязано работать либо правильно, либо никак, поэтому к ним этот подход должен применяться только в контролируемом виде — перед использованием функции приложение обязано убедиться, что она доступна.
Re[3]: Плоды веб-прогресса
От: Sharowarsheg  
Дата: 07.05.20 03:08
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

S>>Итого: ну баг и баг. Минорный-преминорный. Из-за чего сыр-бор?


ЕМ>Я опять все пропустил, и вместо корректного кода нынче считается правильным разрабатывать минимально глючный?


Да, причём давно уже. Корректный код — вообще довольно недостижимая штука ещё с древних времён. А так вообще, если расписать затраты времени на обеспечение совместимости с конкретным браузером в расчёте на одного пользователя, то сразу становится видна вся экономика.
Re[2]: Плоды веб-прогресса
От: Lazytech Ниоткуда  
Дата: 07.05.20 03:42
Оценка:
Здравствуйте, sharez, Вы писали:

S>Броузер-то действительно старый. Если человек не обновляет броузер, забил на безопасность, то он не тот человек, который попросит лицензию (вероятно он купил не тот софт, которому она вообще нужна, он мог не знать даже, что покупает не продукт, а лицензию).


Судя по некоторым комментариям в исходном коде страницы www.2checkout.com, разработчики непонятно зачем пытаются поддерживать IE8, который вышел лет на десять раньше, чем Firefox 52.9.0 ESR.
    <!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
    <!--[if lt IE 9]>
    <script src="/assets/js/html5shiv.js"></script>
    <script src="/assets/js/respond.min.js"></script>
    <![endif]-->

Или я что-то не так понял?
Re[4]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 07.05.20 04:18
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>Корректный код — вообще довольно недостижимая штука ещё с древних времён. А так вообще, если расписать затраты времени на обеспечение совместимости с конкретным браузером в расчёте на одного пользователя, то сразу становится видна вся экономика.


Я о другом. Например, многие реализации *printf корректно обрабатывают передачу nullptr для %s, подставляя что-нибудь вроде "(null)". Но я нигде не видел, чтобы за код, не проверяющий передаваемый указатель, не били бы по голове (максимум), или хотя бы относились к нему снисходительно (минимум). Если такая особенность замечена — она безусловно считается ошибкой, и притом грубой, даже если бы за последние десять лет не было выпущено ни одной реализации, падающей на nullptr.

Ну как тут в очередной раз не подчеркнуть принципиального различия между веб-страницами и веб-приложениями, которого большинство упорно не хочет признавать?
Re[5]: Плоды веб-прогресса
От: Sharowarsheg  
Дата: 07.05.20 04:23
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

S>>Корректный код — вообще довольно недостижимая штука ещё с древних времён. А так вообще, если расписать затраты времени на обеспечение совместимости с конкретным браузером в расчёте на одного пользователя, то сразу становится видна вся экономика.


ЕМ>Я о другом. Например, многие реализации *printf корректно обрабатывают передачу nullptr для %s, подставляя что-нибудь вроде "(null)". Но я нигде не видел, чтобы за код, не проверяющий передаваемый указатель, не били бы по голове (максимум), или хотя бы относились к нему снисходительно (минимум). Если такая особенность замечена — она безусловно считается ошибкой, и притом грубой, даже если бы за последние десять лет не было выпущено ни одной реализации, падающей на nullptr.


Я может чего не понял, но я за много лет ни разу не проверял никакие указатели, и ничего, все довольны. Упадёт, тогда разберёмся.
Re[6]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 07.05.20 05:38
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

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


То есть, в Вашем коде конструкции, подобные "p == nullptr" или "p != nullptr" полностью отсутствуют?

S>Упадёт, тогда разберёмся.


Каким образом разбираетесь?
Re[7]: Плоды веб-прогресса
От: Sharowarsheg  
Дата: 07.05.20 06:59
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


ЕМ>То есть, в Вашем коде конструкции, подобные "p == nullptr" или "p != nullptr" полностью отсутствуют?


Есть, конечно, например, там где нужно найти ровно один объект, соответствующий критерию. Там, естественно, приходится проверять. В других местах нет. Не передавай нуль, там где не надо, да и проблем не будет. Чай, не ядро пишу. Потому что как только начинаются всякие такого рода проверки, непонятно, где заканчивать. Например, ну, хорошо, проверим нуль. А теперь, проверять ли, что у ASCIIZ строки в конце есть нуль? Или пусть лучше падает уже? Или, скажем, если в массиве нужно заполнить сколько-то элементов, может ли число элементов быть нуль? А если да, то указатель на массив может быть нуль или нет? Я предпочитаю не плодить вот это всё заблаговременно, а решать по мере поступления.

S>>Упадёт, тогда разберёмся.


ЕМ>Каким образом разбираетесь?


.NET очень удобная штука. Смотришь стек, и всё видно.
Re[8]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 07.05.20 16:02
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>Не передавай нуль, там где не надо, да и проблем не будет.


Так я и не передаю. Но я это умею делать только с помощью проверки на нуль. Научите избегать передачи нуля, не проверяя значение указателя — буду передавать без проверки.

S>как только начинаются всякие такого рода проверки, непонятно, где заканчивать. Например, ну, хорошо, проверим нуль. А теперь, проверять ли, что у ASCIIZ строки в конце есть нуль?


У меня такое ощущение, что кто-то из нас другого не понимает. У Вас нигде не используются функции вроде strchr/strstr, нет вызовов функций API, которые могут вернуть нулевой указатель?

S>>>Упадёт, тогда разберёмся.


ЕМ>>Каким образом разбираетесь?


S>.NET очень удобная штука. Смотришь стек, и всё видно.


В стеке все видно и без .NET. Меня интересует, что Вы делаете по результатам разбирательства.
Re[9]: Плоды веб-прогресса
От: Sharowarsheg  
Дата: 07.05.20 16:14
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У меня такое ощущение, что кто-то из нас другого не понимает. У Вас нигде не используются функции вроде strchr/strstr, нет вызовов функций API, которые могут вернуть нулевой указатель?


Эээ, нет. В .NET всякие .IndexOf() или .BinarySearch() возвращают integer, а не указатель.

S>>>>Упадёт, тогда разберёмся.


ЕМ>>>Каким образом разбираетесь?


S>>.NET очень удобная штука. Смотришь стек, и всё видно.


ЕМ>В стеке все видно и без .NET. Меня интересует, что Вы делаете по результатам разбирательства.


Нахожу ту ветку, где я забыл создать объект, и создаю его, наверное. Не то чтобы это очень часто было, мне даже трудо себе представить такое. Ну и в любом случае, если я пишу функцию (типа printf), которая будет получать объект, и этот объект действительно нужен (а не опциональный параметр, которые я не люблю и не пишу), то я не проверяю параметров. Сказано, требуется объект на входе, значит, будет объект. Если будет нуль, пусть падает.
Re[10]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 07.05.20 16:22
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>В .NET всякие .IndexOf() или .BinarySearch() возвращают integer, а не указатель.


Ко всем функциям WinAPI, возвращающим указатели, имеются шлюзы, бросающие исключения? А какая разница, проверять указатель или обрабатывать исключение?

S>Ну и в любом случае, если я пишу функцию (типа printf), которая будет получать объект, и этот объект действительно нужен (а не опциональный параметр, которые я не люблю и не пишу), то я не проверяю параметров. Сказано, требуется объект на входе, значит, будет объект. Если будет нуль, пусть падает.


Это как раз понятно. Мне интересно, как Вы избавились от всех без исключения источников нулевых указателей без единой проверки на нуль.
Re[11]: Плоды веб-прогресса
От: Sharowarsheg  
Дата: 08.05.20 00:09
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Ко всем функциям WinAPI, возвращающим указатели, имеются шлюзы, бросающие исключения? А какая разница, проверять указатель или обрабатывать исключение?


Для всех практических применений никакого винапи в .NET нету.

ЕМ>Это как раз понятно. Мне интересно, как Вы избавились от всех без исключения источников нулевых указателей без единой проверки на нуль.


WinAPI выкидываешь, переходишь к .NET, и сразу становится проще. Никаких источников нулевых указателей, кроме меня самого. Наверное, Java даёт что-то похожее тоже, но я не знаю, не пробовал.
Re[12]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 08.05.20 07:30
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>WinAPI выкидываешь, переходишь к .NET, и сразу становится проще. Никаких источников нулевых указателей, кроме меня самого.


.NET имеет обертки для всех без исключения функций WinAPI?
Re[3]: Плоды веб-прогресса
От: sharez  
Дата: 08.05.20 11:40
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>перед использованием функции приложение обязано убедиться, что она доступна.


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

Можно ли выполнить этот JS, или у пользователя 128Mb ОЗУ?
Есть ли у пользователя мышка?
...


И опять же всё упирается в ресурсы, которыми располагает разработчик.
У меня в приложении около сотни известных багов. Но им подвержены крохи от числа юзеров и эти баги не являются блокирующими, имеют обходные пути.
И когда встает вопрос — выполнить "дело чести" и потратить месяц для закрытия этих багов для 0.1% юзеров, или за этот месяц написать новый крутой функционал для 99% юзеров, я не делаю себе сепуку
Re[4]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 08.05.20 13:21
Оценка:
Здравствуйте, sharez, Вы писали:

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

S>

S>Можно ли выполнить этот JS, или у пользователя 128Mb ОЗУ?
S>Есть ли у пользователя мышка?
S>...


В данном случае набор тестов должен быть примерно таким:


А по факту используется примерно такой подход: "поскольку доля автомобилей без радиоприемника составляет лишь 0.x%, мы приняли решение вместо информационных табло передавать все сообщения по радио".

S>И когда встает вопрос — выполнить "дело чести" и потратить месяц для закрытия этих багов для 0.1% юзеров, или за этот месяц написать новый крутой функционал для 99% юзеров, я не делаю себе сепуку


Ладно, когда исправление бага требует сколько-нибудь серьезных ресурсов. Но мне почему-то кажется, что в обсуждаемом случае разработчики тупо воткнули в код какую-нибудь свежую свистелку, которая им показалась особенно красивой в контексте кода или отображаемой страницы. Подход типа "если появилось что-то новое — места себе не найду, пока не придумаю, куда применить".
Re[5]: Плоды веб-прогресса
От: sharez  
Дата: 08.05.20 13:30
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ладно, когда исправление бага требует сколько-нибудь серьезных ресурсов. Но мне почему-то кажется, что в обсуждаемом случае разработчики тупо воткнули в код какую-нибудь свежую свистелку, которая им показалась особенно красивой в контексте кода или отображаемой страницы. Подход типа "если появилось что-то новое — места себе не найду, пока не придумаю, куда применить".


Всё упирается в ресурсы и в их возврат деньгами.
Ресурсы нужны и на тестирование, когда идёт разработка новых фич.
Лучше иметь нормальную форму покупки для 99% пользователей, чем кизяки мамонта, поддерживающие всех 100%. Это окупается.
Везде, где это окупается, совместимость остается. Пример: Windows & Office. До сих пор можно открыть документ из Word 95 и даже запустить софт оттуда (но уже не весь).

P. S.: позвольте спросить, ваш софт запустится на Mandriva Linux десятилетней давности? А такие юзеры до сих пор есть.

P. P. S.: FF 52 просто небезопасен, чем больше будет проблем у таких юзеров, тем быстрее они обновятся, и им же будет лучше. Заработают на этом все. IE был на плаву так долго только потому, что все поддерживали только этот недоброузер. IE ушел — стало лучше и юзерам, и девелоперам.
Re[7]: Плоды веб-прогресса
От: sharez  
Дата: 09.05.20 10:26
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

S>>Пример: Windows & Office. До сих пор можно открыть документ из Word 95 и даже запустить софт оттуда (но уже не весь).


ЕМ>А еще можно открыть простой текстовый файл. Сколько сотых процента от всех ресурсов требуется для поддержки этой возможности?


Чуть менее, чем дохрена. Там устаревший бинарный формат, полностью отличный от их нового XML.
Там костылей половина кода. Легаси, велосипеды и в целом полная жесть, но таковы требования клиентов.
Они (MS) даже статьи писали, о том, как всё это реализовывалось и как они ели этот кактус.

Текстовый файл — не формат хранения данных, там нечего кодировать.
Дисклеймер: да, есть кодировка тексту, и эту проблему тоже решали стопицот лет, и, наконец, ни броузер, ни Windows-программы не показывают мне иероглифы в русскоязычном окружении. Тут опять же можно идти вплоть до расположения битов в байте, но это не зона ответственности вендора.
Re[13]: Плоды веб-прогресса
От: Sharowarsheg  
Дата: 10.05.20 23:06
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

S>>WinAPI выкидываешь, переходишь к .NET, и сразу становится проще. Никаких источников нулевых указателей, кроме меня самого.


ЕМ>.NET имеет обертки для всех без исключения функций WinAPI?


Мне не нужны все без исключения функции WinAPI. Для тех, которые мне нужны, есть обёртки.
Re[6]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.05.20 08:20
Оценка:
Здравствуйте, sharez, Вы писали:

S>P. P. S.: FF 52 просто небезопасен, чем больше будет проблем у таких юзеров, тем быстрее они обновятся, и им же будет лучше.


Вот любопытства ради поставил FF 76.0.1 в виртуалке. Открыл с новья пять типичных на сегодня вкладок. Он на это отожрал гиг. Мой мозг отказывается это понимать. Я даже близко не представляю, что нужно курить, чтобы делать такой код. Даже если плюнуть на привычные в 52.9 плагины, я не могу заставить себя этим пользоваться.

FF 52.9.0 на то же самое жрет 400 Мб. Тоже минимум на порядок больше, чем реально нужно, но рост в 2.5 раза за несколько лет, при полностью одинаковом внешнем виде подавляющего большинства страниц — это за пределами моего понимания.
Re[7]: Плоды веб-прогресса
От: Gt_  
Дата: 11.05.20 08:40
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, sharez, Вы писали:


S>>P. P. S.: FF 52 просто небезопасен, чем больше будет проблем у таких юзеров, тем быстрее они обновятся, и им же будет лучше.


ЕМ>Вот любопытства ради поставил FF 76.0.1 в виртуалке. Открыл с новья пять типичных на сегодня вкладок. Он на это отожрал гиг. Мой мозг отказывается это понимать. Я даже близко не представляю, что нужно курить, чтобы делать такой код. Даже если плюнуть на привычные в 52.9 плагины, я не могу заставить себя этим пользоваться.


ЕМ>FF 52.9.0 на то же самое жрет 400 Мб. Тоже минимум на порядок больше, чем реально нужно, но рост в 2.5 раза за несколько лет, при полностью одинаковом внешнем виде подавляющего большинства страниц — это за пределами моего понимания.


филолог что ли ? филологам часто бывает сложно понять как одинаково звучащие слова могу означать разные термины.
FF 52 на сколько помню было какашка, что работала в одном потоке и кривой жабаскрипт, совершенно не умела использовать видеокарту, там не было новых движков типа webasm. если тебе не понятно как изолированные контейнеры могут жрать в разы больше, чем один поток на все закладки — ты явно не своим делом занимаешься.
Re[8]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.05.20 09:03
Оценка:
Здравствуйте, Gt_, Вы писали:

Gt_>FF 52 на сколько помню было какашка, что работала в одном потоке и кривой жабаскрипт, совершенно не умела использовать видеокарту, там не было новых движков типа webasm.


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

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


Окститесь, один поток на все закладки был лет пятнадцать назад, если не больше. А не понимаю я прежде всего того, зачем для отображения несложной страницы используются сотни мегабайт памяти. Если Вы считаете себя компетентным в этом вопрос — разъясните, только с цифрами, а не абстрактно.
Re[8]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.05.20 10:57
Оценка:
Здравствуйте, Lazytech, Вы писали:

L>Я правильно понял, что флажок «Использовать рекомендуемые параметры производительности» снят и количество процессов отображения содержимого уменьшено до 1?


Нет, пробовал "искаропки". Спасибо, я что-то такое подозревал. Переключением на один процесс удалось ужать до 600 Мб. Но это, блин, тоже до хренища, на пять-то вкладок.

68.8.0 ESR годится для повседневного использования? ESR — чтоб не предлагал обновляться раз в неделю.
Re[10]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.05.20 10:58
Оценка:
Здравствуйте, Gt_, Вы писали:

Gt_>тут программист нужен. он поймет разницу.


"Ты не умничай, ты пальцем покажи". Надувать щеки я и сам хорошо умею.
Re[11]: Плоды веб-прогресса
От: Gt_  
Дата: 11.05.20 11:46
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Gt_, Вы писали:


Gt_>>тут программист нужен. он поймет разницу.


ЕМ>"Ты не умничай, ты пальцем покажи". Надувать щеки я и сам хорошо умею.


Measure the overhead of using Process Isolation:

Memory cost for various scenarios (which largely depend on what part of firefox code need to be initialized/used in the process — XPCOM, etc)
Memory overhead for a Process on Win10 x64 appears to be circa 7-10 MB (Private) for a process with minimal XPCOM inited, IPC, etc. The GPU process (which also loads GPU drivers, etc) is on the order to 20MB, and anecdotally the GMP process uses on the order of 10MB, which is in line.

https://mozilla.github.io/firefox-browser-architecture/text/0012-process-isolation-in-firefox.html

thread на таб лишь 2017 появились, с версии 54. т.е. до капотом с 52 версии вообще все изменилось. смотри в суть вещей, а не чего там внешне поменялось.
Re[12]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 11.05.20 15:58
Оценка:
Здравствуйте, Gt_, Вы писали:

Gt_> Memory cost for various scenarios (which largely depend on what part of firefox code need to be initialized/used in the process — XPCOM, etc)

Gt_> Memory overhead for a Process on Win10 x64 appears to be circa 7-10 MB (Private) for a process with minimal XPCOM inited, IPC, etc. The GPU process (which also loads GPU drivers, etc) is on the order to 20MB, and anecdotally the GMP process uses on the order of 10MB, which is in line.

Так на сарае тоже известно что написано. Да только вместо обещанных 100 (20 x 5, и это максимум) Мб оно в многопроцессном режиме жрет на 500 Мб больше.

Gt_>thread на таб лишь 2017 появились, с версии 54


С этой версии уже появилось разделение на несколько процессов.

Gt_>смотри в суть вещей, а не чего там внешне поменялось.


Вот я и смотрю на списки потоков в каждом из процессов. Что 52, что 68/76, создают по нескольку потоков при добавлении новой вкладки или каких-то действиях на уже открытых. Через полминуты простоя эти потоки уничтожаются. Так что ни единого потока на все вкладки, ни выделенного на каждую, там нет. Есть, скорее всего, динамический пул потоков, по которым распределяется работа.
Re[14]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 12.05.20 00:54
Оценка:
Здравствуйте, Gt_, Вы писали:

Gt_>прости чувак, но ты туповат для беседы.


А Вы чересчур хамоваты. Не договоримся.
Re[6]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 13.05.20 05:27
Оценка:
Здравствуйте, sharez, Вы писали:

S>P. P. S.: FF 52 просто небезопасен


Вот еще один P.S.: два года у меня не было проблем с 52.9, кроме этой потенциальной небезопасности. А после обновления до 68.8 ESR возникла реальная проблема: на большинстве страниц (в том числе и здесь) не работает звук. При этом значок динамика на вкладке появляется и исчезает, но звука нет. В YouTube звук есть. Если поставить другое устройство воспроизведения по умолчанию, на него звук идет, если вернуть основное — тишина. Я сам много программирую именно по звуку, и даже отдаленно не представляю, как можно написать код, чтобы он так себя вел.

А 68.8 ESR хочу потому, что это последний на сегодня ESR. Поставив обычную версию, я вместе с обновлениями безопасности буду получать обновления и интерфейса, и поведения,и ловить новые глюки. В совокупности это съест больше ресурсов, чем небезопасность.
Re[3]: Плоды веб-прогресса
От: Lloret  
Дата: 13.05.20 09:44
Оценка:
ЕМ>А что гарантирует регистратору отсутствие оттока и покупателей, и вендоров в результате таких вот косяков?

Например тот факт, что у других тоже не повидло с шоколадом, а такой же продукт вторичный? Так что куда лох-трусы в горох уважаемый покупатель денется...
Re[8]: Плоды веб-прогресса
От: Lazytech Ниоткуда  
Дата: 13.05.20 10:07
Оценка:
Здравствуйте, sharez, Вы писали:

S>Мы все сами подписались на то, что IT наша жизнь.

S>Быть в потоке и постоянно грести — одно из свойств такой карьеры.
S>Всё же это лучше, чем уходить каждый день в один и тот же забой.
S>Предлагаю с мужеством перенести эти невыносимые тяготы IT-бытия.

Я до последнего держался за Opera Presto, но увы. Перешел на Firefox не с первой попытки (UI откровенно не нравился). Прошло время, и привык. Даже обновляюсь, когда предлагают. За расширения (адд-оны) больше не держусь. Понял, что наносное это всё.
Отредактировано 13.05.2020 10:09 Lazytech . Предыдущая версия .
Re[8]: Плоды веб-прогресса
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 13.05.20 11:13
Оценка:
Здравствуйте, sharez, Вы писали:

S>Мы все сами подписались на то, что IT наша жизнь.

S>Быть в потоке и постоянно грести — одно из свойств такой карьеры.

Так эта гребля больше смахивает на то, что без "гр". Оно скорее похоже на бег по тонкому льду, без возможности остановиться на сколько-нибудь заметное время. Человечество столько тысяч лет стремилось к стабильности и предсказуемости, а современные IT в этом плане ничуть не лучше первобытной жизни, и маховик непрерывно раскручивается.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.