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

P>Это старый апп удаляется и ставится целиком новое или столько весят именно обновления?

Если Вы про Android, то в нем приложение всегда хранится в одном файле APK, при обновлении старый удаляется, заменяясь новым. Все остальное, что может лежать в подкаталогах /data/app — продукты оптимизации (библиотеки для целевой платформы, распакованные из APK, предкомпилированные фрагменты кода и т.п.).

P>если целиком замена то могу понять, а если апдейт только то ощущение программисты не парятся над оптимизацией и думают, что железо решит все вопросы производительности

Из каких соображений Вы согласны это понять? Чтобы содержать сотню мегабайт функциональных кода/данных, да еще в упакованном виде, приложение должно иметь весьма богатую функциональность. Если там преобладает код, оно должно уметь решать большое (сотни-тысячи) весьма сложных задач; если преобладают данные — демонстрировать много изображений высокого разрешения, или видео хотя бы минут на десять. Если приложение ничего из этого не делает, значительная (обычно бОльшая) часть его кода/данных являются избыточными, ненужными.

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

P>если целиком замена то могу понять, а если апдейт только то ощущение программисты не парятся над оптимизацией и думают, что железо решит все вопросы производительности

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

P.S. Лучше б уже приспособили к этому делу системный веб-бровсер, чем каждому свой таскать...

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

Pzz>Почему, интересно, kernel hell не возникает?...

Потому что ваш kernel по сложности и рядом с UI не стоял. Это та правда, которую трудно принять любителям мифов о формошлёпстве.

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

Pzz>Ну вообще-то, тут надо не изолировать зависимости, а следовать стандартам. Делатели веб-сайтов с этим худо-бедно справляются...

У меня был баг, когда один браузер отображал один элемент не по стандарту. Я долго ленился его пофиксить. И дождался, что после обновления браузера всё пофиксилось в нём. Вот такие дела у нас с веб-стандартами. В 2022 году.

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

Если некоторые разработчики включают полную реплику браузера, значит имеют причины.

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

A>>Косяк тут со стороны Гугла, где работают "лучшие программисты". Кто раздул Хромиум экспоненциально?

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

Ну так он раздувается не от честного труда. А от того, что туда тащат всё подряд.

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

Pzz>Я думаю, конкретно в этом месте им всё равно.

Здравствуйте, peer, Вы писали:
P>Заметил в последнее время, что апдейт любого приложения типа пятерочка весит 100+мб.
P>а когда таких приложений на телефоне много тенденция пугает.

Именно поэтому я не пользуюсь приложениями. Каждый банк, каждый магазмн, каждая занюханная шарага втюхивает своё приложение. Которое при весьма ограниченной функциональности имеет несоразмерный объём. "Если каждому давать — поломается кровать". Если на каждый чих ставить отделное приложение, никакого телефона не хватит. Приложение должно быть одно, и оно есть, называется браузер. Если что-то нельзя сделать через браузер — тем хуже для них, как клиента они меня потеряли.

недавно разбирали состав apk в этой теме https://rsdn.org/forum/flame.comp/8722169?tree=tree

Автор: undo75
Дата: 01.04.24

У них действительно много всякого функционала понапихано и нативные библиотеки под несколько архитектур.

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

P>а когда таких приложений на телефоне много тенденция пугает.

это криворукие разработчики. Почему телега весит 5мб а сраный интернет банк 300+мб?

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

Pzz>>P.S. Лучше б уже приспособили к этому делу системный веб-бровсер, чем каждому свой таскать...

A>Это безопаснее и позволяет избежать browser hell.

Почему, интересно, kernel hell не возникает?...

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

Ну вообще-то, тут надо не изолировать зависимости, а следовать стандартам. Делатели веб-сайтов с этим худо-бедно справляются...

A>Косяк тут со стороны Гугла, где работают "лучшие программисты". Кто раздул Хромиум экспоненциально?

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

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

Я думаю, конкретно в этом месте им всё равно.

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

Pzz>Лучше б уже приспособили к этому делу системный веб-бровсер, чем каждому свой таскать...

Не, лучше б в каждой системе таки родили виртуальную машину-исполнитель под такой код, а бровсеру оставили бровсерово.

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

P>Заметил в последнее время, что апдейт любого приложения типа пятерочка весит 100+мб.

Плеймаркет умеет качать дифф и поэтому обновление весит довольно мало. Рустор же такое не осилил и качает всё целиком. Я в основном от него вижу 100Мб+ обновления

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

P>Заметил в последнее время, что апдейт любого приложения типа пятерочка весит 100+мб.

Я тут месяц ждал, пока мобильное приложение фитнес-клуба починили.
Так что если оно много весит, это не такая проблема. Лишь бы работало!
Я тут ФедОру поднял на ноутбуке с 2Гб памяти. Правда через некоторое время пришлось память до 4Гб увеличить.
А новые смартфоны уже идут с 12Гб оперативки (у меня такой).
Хранилище — 256Гб. Процессор многоядерный.
Так чего им ужиматься? Будут использовать новейшие фреймворки.
Я думаю, скоро Андроид заменит десктопные ОС, потому что уже многие приложения существуют только для Андроида и для веба.
Андроид в отличие от Виндоус открытый, работает на широком спектре устройств.
К примеру, уже стационарные проигрыватели музыки оснащают Андроидом.
Планшеты с Андроидом уже по разрешению почти как мониторы.
Operating System Market Share Worldwide https://gs.statcounter.com/os-market-share

Android 43.86%
Windows 27.97%
iOS 17.8%
OS X 5.64%
Unknown 1.96%
Linux 1.44%

Здравствуйте, Явь-истъ, Вы писали:

ЯИ>Здравствуйте, peer, Вы писали:

P>>Заметил в последнее время, что апдейт любого приложения типа пятерочка весит 100+мб.

ЯИ>Я тут месяц ждал, пока мобильное приложение фитнес-клуба починили.

world class?

а то офигел, когда базовые вещи не работают: внес деньги на тренировки и не видно баланса текущего.

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

Pzz>P.S. Лучше б уже приспособили к этому делу системный веб-бровсер, чем каждому свой таскать...

Это безопаснее и позволяет избежать browser hell.

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

Косяк тут со стороны Гугла, где работают "лучшие программисты". Кто раздул Хромиум экспоненциально? Что мешало форкнуть системно ветку, опирающуюся на функционал Андроид для всякой хрени типа медиа-декодирования? Под виндой они делают это специально, чтобы порвать её изнутри, как Чужой Хищника. Но под Андроид — это уж объясняется только их квалификацией.

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

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

Мне больше нравятся мелочи, которые, тем не менее, становятся частью стандартов. Тут уж на стажёра не спишешь.

Например, в файле site.manifest в формате json есть поле sizes, которое требует строки вида 192x192.

Нуштозайоптваюмать. Это же json!!! Сделайте width: "192", height: "192". Сделайте шорткат size (без s) для квадратов (там подразумеваются квадраты). Но парсинг строки (wxh) из формата разметки данных... Я, конечно, видел и не такое в некоторых проектах, но не в стандарте описания КАЖДОЙ веб-страницы.

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

Pzz>Ну вообще-то, тут надо не изолировать зависимости, а следовать стандартам. Делатели веб-сайтов с этим худо-бедно справляются...

Вот ещё кое-что, что бесполезно понимать, а надо просто знать. А для этого надо было вариться в соответствующих технологиях последние 20+ лет.

Когда Майкрософт ещё делал свой webview (Trident), он у них был компонентным. Абсолютно всё было представлено в виде COM-интерфейсов: ДОМ, стили, скрипты и что там было ещё. Ты грузил через Navigate() страницу, а потом делал с ней что хотел. Вызывать нативный код из скриптов? Или скрипт из нативного кода? Менять ДОМ? Повесить нативный хендлер на любое событие? Ответ: да, всё да. При помощи молотка и такой-то матери ты мог даже создать свой тип узлов.

Этим интеграционные качества майкрософтовского webview не исчерпывались. Ты мог сделать инспектор, и ходить по любым окнам в системе. Любых приложений. И присоединяться к их ДОМу!!! На этом сайте есть статья и демонстрационный проект, полуркай. Если у тебя есть винда и софт к ней более, чем десятилетней давности, может даже найдёшь, сколько окон в системе у тебя до сих пор тридентовские.

Как будто этого мало, ещё ты мог сослаться из атрибутов и CSS на системные цвета (GetSysColor) и градиенты.

Но и это ещё не всё! Майкрософт плотно интегрировала в свой webview вообще всё, что у неё было. Например, DirectX. Это делалось через progid. Затем из этого всего выросло такое CSS-свойство, как filter. Это во времена, когда даже шейдеров не было! Шейдеров не было, а ты уже декларативно мог обесцветить картинку для UI или стилизовать её (список доступных стилизаций был огромен), если только пользовался их webview.

Что сделал Google, когда пришёл со своей ОС и своим webview? Он сказал: мы вам открыли исходники, и какой ещё открытости вам надо? Не устраивает что-то — форкайте.

Все и форкают.

Вот в этом и кроется причина того, что вам трёхсотметровые апдейты теперь постоянно прилетают. Только не все это понимают. А не понимают, потому что мало знают.

Почему Гугл так себя ведёт — или они злые, во что ты не веришь ("Я думаю, конкретно в этом месте им всё равно."), или просто корпоративная культура настолько низкая, что до Майкрософта 90-х им срать и срать.

И последнее. Я смотрю, тут у многих смех без причины прорезался. Если кто-то хочет сравнить сложность взаимодействия приложения с webview и с kernel'ом...

>Почему, интересно, kernel hell не возникает?...

...пусть выбирает метрику. Любая пойдёт. Количество типов объектов. Общее количество разновидностей этих типов. Количество разных способов выполнить задачу. Количество подходов. Что угодно.

Здравствуйте, Евгений Музыченко, Вы писали:

A>>ваш kernel по сложности и рядом с UI не стоял.

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

Извини меня, вопрос стоял, почему нет kernel hell, а browser hell есть. Причём тут квалификация? Тут роялит именно количество "различных типов, элементов, связей между ними и подобного" — всего того, где обновления программ и центрального компонента могут круто поднасрать друг другу.

Но то, что ты начал с вопроса о метрике — как говорит молодежь, МОЁ УВОЖЕНИЕ!

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>Лучше б уже приспособили к этому делу системный веб-бровсер, чем каждому свой таскать...

ЕМ>Не, лучше б в каждой системе таки родили виртуальную машину-исполнитель под такой код, а бровсеру оставили бровсерово.

Такая виртуальная машина называется веб-бровсером. А вот вакантное место чисто веб-бровсера ничем не занято. Да и вряд ли будет, потому что сайты, увы, рассчитывают именно на виртуальную машину с дополнительной функцией веб-морды.

Здравствуйте, Евгений Музыченко, Вы писали:

Pzz>>Там неплохой код, но там НЕОБОЗРИМЫЕ ПРОСТОРЫ этого самого кода.

ЕМ>В котором, чем дальше, тем меньше разбираются сами разработчики.

Забыл сказать. На гуглохромовском коде ломается ctags — такая незамысловатая относительно программка, котодая строит для vim-а индекс для быстрого перехода по идентификаторам. Долго жужжит, а потом падает.

vs-code не ломается (пока еще?).

Pzz>>сложность рендерера настолько велика, что его надо гонять в контейнере

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

На примерегуглохрома хороша видна разница между open source и свободным програмным обеспечением.

Открыты ли исходники гуглохрома? Безусловно. Можно ли воспользоваться свободой, и, скажем, форкнуть его и на его основе создать новый бровсер? Нет, не потянете (в лучшем случает, потянете какую-то примочку к нему, но бровсер так и останется гуглохромом, пусть и с неродной мордой).

Заметил в последнее время, что апдейт любого приложения типа пятерочка весит 100+мб.
а когда таких приложений на телефоне много тенденция пугает.
Это старый апп удаляется и ставится целиком новое или столько весят именно обновления?

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

P>Это старый апп удаляется и ставится целиком новое или столько весят именно обновления?
Это же zip, открой да посмотри чего там сколько.

Здравствуйте, Евгений Музыченко, Вы писали:

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



P>>если целиком замена то могу понять, а если апдейт только то ощущение программисты не парятся над оптимизацией и думают, что железо решит все вопросы производительности

ЕМ>Из каких соображений Вы согласны это понять? Чтобы содержать сотню мегабайт функциональных кода/данных, да еще в упакованном виде, приложение должно иметь весьма богатую функциональность. Если там преобладает код, оно должно уметь решать большое (сотни-тысячи) весьма сложных задач; если преобладают данные — демонстрировать много изображений высокого разрешения, или видео хотя бы минут на десять. Если приложение ничего из этого не делает, значительная (обычно бОльшая) часть его кода/данных являются избыточными, ненужными.

я просто прошел состояние принятия, ведь если прийти так в компанию и начать говорить что это много для простого аппа, то начнутся аргументы
"у всех так в маркете\русторе", "у нас нет времени на оптимизацию, а бизнесу важны релизы, а объем это не скорость и на это можно забить". И таким образом превратится в критика который будет мозолить глаз всем.
я просто понял что сейчас никто не занимается оптимизацией и все проблемы затыкают что юзер железо увеличит.
поначалу мне, как человеку который работал с с++\mfc, было это дико видеть аппы 100+ мб, но потом я просто принял эту реальность.
Пугает, что попадешь так в команду где народ будет приниммать обычное приложение размером в 100+мб нормой. Получается прямо поколение меняется.
Как кстати с этим в Европе, тоже для них это норма 100+мб в любом простом приложении?

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

P>"... объем это не скорость ..."

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

P>мне, как человеку который работал с с++\mfc, было это дико видеть аппы 100+ мб

Ну, мне во времена MFC тоже было дико видеть приложения с простеньким интерфейсом и функционалом в несколько мегабайт, когда на голом WinAPI то же самое занимало в 3-5 раз меньше.

P>Пугает, что попадешь так в команду где народ будет приниммать обычное приложение размером в 100+мб нормой.

Тут важно не "принимать или не принимать", а уметь хотя бы примерно представлять соотношение функциональности и объема кода. Но большинство тех, кто называет себя "программистами", никогда не пыталось этого сделать. Это как если, грубо говоря, в кармане лежит несколько миллионов, которых завтра будет еще больше, и хочется по-быстрому накупить продуктов, то мало кто будет смотреть на ценники. Огурцы по тысяче за килограмм или молоко по семьсот за литр не будут вызывать дискомфорта, даже если смутно помнишь, что когда-то они стоили в десять-двадцать раз дешевле.

P>Получается прямо поколение меняется.

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

P>Как кстати с этим в Европе, тоже для них это норма 100+мб в любом простом приложении?

Так во всем мире так — посмотрите на то, лежит в Play Market для андроида, и на сайтах производителей — для десктопов. "Маленькое приложенив, всего 10-15 мегабайт".

Я как-то ворчал, что усложнение микросхем и увеличение количества элементов в них делает микросхемы только функциональнее, удобнее и экономичнее, а софт с усложнением, наоборот, только распухает и тормозит. Мне возразили, что даже распухающий софт все равно занимает все меньший и меньший физический объем, так что увидеть это распухание можно лишь специальными инструментами. Но ни фига подобного: работая с большинством сложных микросхем, можно и не подозревать, сколько элементов в нее упаковано, ибо все это согласованно работает внутри, а наружу торчит лишь вменяемое количество выводов, имеющих определенное функциональное назначение. А когда устанавливаешь в ОС вроде бы единичный, функционально обособленный пакет, он ведь почти никогда не остается таковым после установки. Даже если не распаковывается в десятки-сотни тысяч мелких файлов, как в десктопных ОС, а вроде бы формально остается цельным, как APK в андроиде, то почти всегда глубоко прорастает в систему, образует большое количество связей, которые неизбежно сказываются на производительности.

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

P>>если целиком замена то могу понять, а если апдейт только то ощущение программисты не парятся над оптимизацией и думают, что железо решит все вопросы производительности

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

Pzz>P.S. Лучше б уже приспособили к этому делу системный веб-бровсер, чем каждому свой таскать...

В айфоне запрещено браузеры бандлить, там по-любому системный браузер будет. На размер как-то не особо влияет по-моему.

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

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

P>>если целиком замена то могу понять, а если апдейт только то ощущение программисты не парятся над оптимизацией и думают, что железо решит все вопросы производительности

Pzz>Чуть менее, чем любое такое приложение — это замаскированный веб-бровсер на основе гуглохрома.

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

Здравствуйте, Евгений Музыченко, Вы писали:

P>>Это старый апп удаляется и ставится целиком новое или столько весят именно обновления?

ЕМ>Если Вы про Android, то в нем приложение всегда хранится в одном файле APK, при обновлении старый удаляется, заменяясь новым.

Нет.
https://en.wikipedia.org/wiki/Delta_update#Google
https://chromium.googlesource.com/chromium/src/+/master/build/android/incremental_install/README.md
https://www.reddit.com/r/AndroidQuestions/comments/gj17ue/incremental_updates_on_play_store/fqjjuib/
https://topic.alibabacloud.com/a/android-apk-incremental-update_1_12_30733024.html

и так далее. Несколько методов. Намеренно выбирал только общеописательные ссылки.

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

N>https://en.wikipedia.org/wiki/Delta_update#Google

Насколько часто оно реально используется, и какой эффект дает? Сколько ни ставил/обновлял приложений, длительность обновления никогда заметно не отличалась от длительности первоначальной установки.

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

Pzz>P.S. Лучше б уже приспособили к этому делу системный веб-бровсер, чем каждому свой таскать...

Системные веб-браузеры — это лютый зоопарк, особено принимая во внимание китайские бренды.
Они погибнут это всё тестировать и поддерживать.

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

Pzz>>P.S. Лучше б уже приспособили к этому делу системный веб-бровсер, чем каждому свой таскать...

M>Системные веб-браузеры — это лютый зоопарк, особено принимая во внимание китайские бренды.
M>Они погибнут это всё тестировать и поддерживать.

Бывают андроиды без гуглохрома? Бывают iOS-ы без Сафари?

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

P>world class?

P>а то офигел, когда базовые вещи не работают: внес деньги на тренировки и не видно баланса текущего.
Ты ничего не понимаешь. Там его облака, докер, там есть AI. И написало его AI.

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

A>ваш kernel по сложности и рядом с UI не стоял.

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

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

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

A>Если некоторые разработчики включают полную реплику браузера, значит имеют причины.

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

Автор: Евгений Музыченко
Дата: 15.09 15:53

.

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

P>Заметил в последнее время, что апдейт любого приложения типа пятерочка весит 100+мб.
P>а когда таких приложений на телефоне много тенденция пугает.
P>Это старый апп удаляется и ставится целиком новое или столько весят именно обновления?

P>если целиком замена то могу понять, а если апдейт только то ощущение программисты не парятся над оптимизацией и думают, что железо решит все вопросы производительности

У меня десктоп телега влегкую выжирает 1-2 Гб ОЗУ. Вот где девелоперы разгулялись.
Вот как таких воспитывать?

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

A>вопрос стоял, почему нет kernel hell, а browser hell есть. Причём тут квалификация?

При том, что, если делать ядра будут те же, кто сейчас делает браузеры (и деньги получать за то же), а софт под ядра будут делать те же, кто сейчас делает веб-приложения, то kernel hell будет покруче любого browser hell.

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

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

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

На мой взгляд обвинять гугл в том, что кто-то его исходники расковырял, что-то на их основе сделал и оно получилось криво — не совсем правильно. Хотели бы действительно вставлять палки в колёса — закрыли бы исходники, с их долей рынка это вполне реально. Или релизили бы исходники в виде тарболла раз в год, как делают некоторые. Или лицензию поменяли бы на GPL, хе-хе. А так они делают то, что от них не требует каких-то существенных дополнительных усилий, а именно пишут браузер как считают нужным и просто отдают все исходники на публику. А что там эта публика с ними делает — это уже на совести этой самой публики.

Здравствуйте, Евгений Музыченко, Вы писали:

A>>вопрос стоял, почему нет kernel hell, а browser hell есть. Причём тут квалификация?

ЕМ>При том, что, если делать ядра будут те же, кто сейчас делает браузеры (и деньги получать за то же), а софт под ядра будут делать те же, кто сейчас делает веб-приложения, то kernel hell будет покруче любого browser hell.

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

Там неплохой код, но там НЕОБОЗРИМЫЕ ПРОСТОРЫ этого самого кода.

Если кто рассчитывает на какие-то гарантии надежности этого самого бровсеря, я бы на месте этих людей особенно бы не обольщался. СТОЛЬКО кода невозможно гарантированно избавить от ошибок (и сознательных закладок тоже).

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

Причем, заметим в скобках, контейнер ихний защищает ОС от бровсера, но никак не защищает JS в этом бровсере, который имеет доступ к разным достаточно чувствительным данным.

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

vsb>На мой взгляд обвинять гугл в том, что кто-то его исходники расковырял, что-то на их основе сделал и оно получилось криво — не совсем правильно. Хотели бы действительно вставлять палки в колёса — закрыли бы исходники, с их долей рынка это вполне реально. Или релизили бы исходники в виде тарболла раз в год, как делают некоторые. Или лицензию поменяли бы на GPL, хе-хе. А так они делают то, что от них не требует каких-то существенных дополнительных усилий, а именно пишут браузер как считают нужным и просто отдают все исходники на публику. А что там эта публика с ними делает — это уже на совести этой самой публики.

Там в основе этого гуглохрома — GPL-ный WebKit...

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

vsb>>На мой взгляд обвинять гугл в том, что кто-то его исходники расковырял, что-то на их основе сделал и оно получилось криво — не совсем правильно. Хотели бы действительно вставлять палки в колёса — закрыли бы исходники, с их долей рынка это вполне реально. Или релизили бы исходники в виде тарболла раз в год, как делают некоторые. Или лицензию поменяли бы на GPL, хе-хе. А так они делают то, что от них не требует каких-то существенных дополнительных усилий, а именно пишут браузер как считают нужным и просто отдают все исходники на публику. А что там эта публика с ними делает — это уже на совести этой самой публики.

Pzz>Там в основе этого гуглохрома — GPL-ный WebKit...

А в основе WebKit-а — KDE-шный KHTML

Но всё же сегодня эти движки уже можно считать никак не связанными.

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

Pzz>>Там в основе этого гуглохрома — GPL-ный WebKit...

vsb>А в основе WebKit-а — KDE-шный KHTML

Я в курсе.

vsb>Но всё же сегодня эти движки уже можно считать никак не связанными.

Я не понимаю, как можно с KHTML снять GPL-ную лицензию, если хоть строчка просочилась в гуглохром.

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

Pzz>>>Там в основе этого гуглохрома — GPL-ный WebKit...

vsb>>А в основе WebKit-а — KDE-шный KHTML

Pzz>Я в курсе.

vsb>>Но всё же сегодня эти движки уже можно считать никак не связанными.

Pzz>Я не понимаю, как можно с KHTML снять GPL-ную лицензию, если хоть строчка просочилась в гуглохром.

Я так понял, там LGPL. Она осталась.

Здравствуйте, Евгений Музыченко, Вы писали:

A>>вопрос стоял, почему нет kernel hell, а browser hell есть. Причём тут квалификация?

ЕМ>При том, что, если делать ядра будут те же, кто сейчас делает браузеры (и деньги получать за то же), а софт под ядра будут делать те же, кто сейчас делает веб-приложения, то kernel hell будет покруче любого browser hell.

Ясно. Я думал, разговор про квалификацию обращающихся к ядрам и браузерам. А думал я так потому, что всё, собственно, началось с того, что ТС поставил её под сомнение.

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

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

vsb>Ну вообще-то они и вправду не поддерживают приложения на базе браузера. Гугл выпускает хромиум. Всё остальное это уже придумки третьих лиц, которые этот хромимум раздербанили и вытащили оттуда нужные куски. Зачем гуглу поддерживать этих третьих лиц? Какой в этом смысл? Гугл официально поддерживает компонент WebView под андроидом.

И мы все знаем, сколько в нём интерфейсов и колбеков (3.5).

vsb>На мой взгляд обвинять гугл в том, что кто-то его исходники расковырял, что-то на их основе сделал и оно получилось криво — не совсем правильно. Хотели бы действительно вставлять палки в колёса — закрыли бы исходники, с их долей рынка это вполне реально. Или релизили бы исходники в виде тарболла раз в год, как делают некоторые. Или лицензию поменяли бы на GPL, хе-хе.

Если бы они это сделали, появился бы новый проект браузера и публика бы орала как резаная

А так и сделать толком на его базе ничего нельзя, и исходники открыты, а жопа прикрыта. И выбор: форкай и терпи ненависть ("Заметил в последнее время, что апдейт любого приложения типа пятерочка весит 100+мб. [...] это нормально или пришло поколение некст в мобильную разработку?") или добро пожаловать на Flutter Удобно, наверное. Для Гугла.

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

Pzz>если под сложностью UI иметь ввиду именно сложность самого бровсера, то гуглохрому я внутрь заглядывал. Он, кажется, сложнее всей остальной операционной системы вместе взятой, включая ядро.

Я бы сказал, что он не столько сложнее, сколько навороченнее. То есть, вводит очень много сущностей, действий над ними, связей между ними, использует множество разных приемов (в том числе весьма продвинутых), но полагается-то он таки на ОС — развитую работу с файлами, защиту памяти, поддержку процессов и коммуникаций между ними, многопоточность и т.п. Если при разработке ключевых подсистем ОС регулярно встает задача "как это сделать так, чтоб работало и быстро, и надежно, но памяти требовало не чрезмерно, и концепций не поломало, и масштабировалось, и использовать было удобно?", то при разработке браузера задача обычно стоит "как бы показать говносайты чуть быстрее, и оставить хоть немного свободной памяти, и заодно объявить о новой модной фиче, которую вскоре начнут применять на говносайтах?".

Pzz>Там неплохой код, но там НЕОБОЗРИМЫЕ ПРОСТОРЫ этого самого кода.

В котором, чем дальше, тем меньше разбираются сами разработчики.

Pzz>Если кто рассчитывает на какие-то гарантии надежности этого самого бровсеря, я бы на месте этих людей особенно бы не обольщался. СТОЛЬКО кода невозможно гарантированно избавить от ошибок (и сознательных закладок тоже).

Дык, несомненно.

Pzz>сложность рендерера настолько велика, что его надо гонять в контейнере

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

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

Pzz>На примерегуглохрома хороша видна разница между open source и свободным програмным обеспечением.

Pzz>Открыты ли исходники гуглохрома? Безусловно. Можно ли воспользоваться свободой, и, скажем, форкнуть его и на его основе создать новый бровсер? Нет, не потянете (в лучшем случает, потянете какую-то примочку к нему, но бровсер так и останется гуглохромом, пусть и с неродной мордой).

Я бы сформулировал это так. На примере гуглософта (Хрома и Андроида) хорошо видна разница между open source и ОТКРЫТЫМ программным обеспечением.

Винды и тридент (ишак) никогда не были опенсорсны. Но поменять в процессе их работы можно было примерно всё. В части UI, по крайней мере. И на всё была документация, а где её не было, там в дело шёл Spy++ и антимонопольный комитет, который заставлял документировать недокументированное. А значит, винды и тридент были в некотором смысле открыты, в очень важном, прикладном, практическом смысле.

Можно ли вмешаться в работу Андроида и добавить свою иконку в заголовок? Да, берёшь АОСП, компилируешь и чтобы полюбоваться, ставишь образ в эмулятор. Потому что бутлоадер на твоём Сяоми никто не разлачивал! Исходники открыты, а поменять ничего нельзя.

То же самое относится и к хромиуму. Хорошо, когда дядя Гринблятт за тебя внёс всё, что надо. Но повесить свой С++ обработчик на ДОМ-евент... Ты же читал исходнички, как оно тебе, легко такое будет сделать в прикладном коде?