Комментарии 444
Рабочая железка как раз тот самый i7 и 16 гб оперативы.
Для тестирования используется c2d 2.0GHz и 2 гб оперативы.
Очень хочу, что б разработчиков хрома заставили тестировать так же.
Для тестирования используется c2d 2.0GHz и 2 гб оперативы.
Очень хочу, что б разработчиков хрома заставили тестировать так же.
Очень много разработчиков Хрома вообще тестируют его на Хромбуках, по сравнению с которыми ваш C2D — просто ракета.
Дело не в них, увы, а в разработчиках веб-сайтов. А им хоть какой ноут не дай, всё равно профилировать не будут.
Дело не в них, увы, а в разработчиках веб-сайтов. А им хоть какой ноут не дай, всё равно профилировать не будут.
То-то (почти) каждая новая версия каждого браузера требует больше памяти, чем предыдущая. Видно, у них какие-то особо заряженные хромбуки, с террабайтом ОЗУ, например. Процессор, при этом, и правда не всегда нужен сильно мощный, зато ОЗУ — сколько ни дай.
Вчера отдал детишкам старенький ноут из начала 2000 на XPшке еще.
Без проблем лазают в инет с последнего поддерживаемого хрома.
ОЗУ жрет не браузер, ОЗУ жрут сайты и бездумно установленные расширения.
Без проблем лазают в инет с последнего поддерживаемого хрома.
ОЗУ жрет не браузер, ОЗУ жрут сайты и бездумно установленные расширения.
Как по мне, если браузер для распарсивания того же сайта стал тратить больше памяти, то память тратит браузер, а не сайт.
А что «за эти годы» браузеры научились многим API, которые лично мне не нужны, но которые исправно занимают свою долю ресурсов — я лично бы предпочел вариант, когда эту поддержку можно было бы отключить, сэкономим мне ресурсы.
Понятно, что компы все быстрее, но — увы, если программа тяжелая, то процессор ее не спасет. Он будет крутить ее быстрее, но не мгновенно. Это как «кисель чуть жиже или чуть гуще, но не вода».
А что «за эти годы» браузеры научились многим API, которые лично мне не нужны, но которые исправно занимают свою долю ресурсов — я лично бы предпочел вариант, когда эту поддержку можно было бы отключить, сэкономим мне ресурсы.
Понятно, что компы все быстрее, но — увы, если программа тяжелая, то процессор ее не спасет. Он будет крутить ее быстрее, но не мгновенно. Это как «кисель чуть жиже или чуть гуще, но не вода».
А это интересно.
Есть сравнение с тратой памяти на одинаковых сайтах разными версиями хрома?
Или вы по «ощущениям» оцениваете?
Есть сравнение с тратой памяти на одинаковых сайтах разными версиями хрома?
Или вы по «ощущениям» оцениваете?
Я думаю он сравнивает, скажем, Хабр 10 лет назад и сейчас. И, действительно, Хром, открывая 10 лет назад страничку по адресу www.habrahabr.ru тратил гораздо меньше памяти… но ведь он тогда ни шрифтов не грузил, ни эмулятор TeX'а, ни многого другого!
Что меня больше всего поражает — что даже обычные люди понимают, что сапоги одной и тоже марки, купленные 10 лет назад и сегодня могут заметно отличаться по многим параметрам, но почему-то к сайтам — это не относится.
P.S. Ещё почему-то ещё ни от одного фаната подхода " если браузер для распарсивания того же сайта стал тратить больше памяти, то память тратит браузер, а не сайт" не слышал «вот взял я MS IE 6, зашёл на Хабр — и красота: памяти в 100 раз меньше нужно и вабче». Обычно всё жалобами на тяжёлую жизнь и ограничивается…
Что меня больше всего поражает — что даже обычные люди понимают, что сапоги одной и тоже марки, купленные 10 лет назад и сегодня могут заметно отличаться по многим параметрам, но почему-то к сайтам — это не относится.
P.S. Ещё почему-то ещё ни от одного фаната подхода " если браузер для распарсивания того же сайта стал тратить больше памяти, то память тратит браузер, а не сайт" не слышал «вот взял я MS IE 6, зашёл на Хабр — и красота: памяти в 100 раз меньше нужно и вабче». Обычно всё жалобами на тяжёлую жизнь и ограничивается…
Что меня больше всего поражает — что даже обычные люди понимают, что сапоги одной и тоже марки, купленные 10 лет назад и сегодня могут заметно отличаться по многим параметрам, но почему-то к сайтам — это не относится.
Люди отлично понимают не только это, но и то, что многим сапог модели 10 летней давности вполне достаточно.
Ещё почему-то ещё ни от одного фаната подхода " если браузер для распарсивания того же сайта стал тратить больше памяти, то память тратит браузер, а не сайт" не слышал «вот взял я MS IE 6, зашёл на Хабр — и красота: памяти в 100 раз меньше нужно и вабче». Обычно всё жалобами на тяжёлую жизнь и ограничивается…
Так мы бы, причитатели, запросто, если бы сайты имели, скажем, облегченную версию, которая шла бы на IE6.
Люди отлично понимают не только это, но и то, что многим сапог модели 10 летней давности вполне достаточно.… вот только в магазинах их не продают. А те, которые хранятся у бабушки в шкафу могут и рассыпаться в труху, если их надеть (неприятное такое свойство полиуретана).
С сайтами — та же история.
Так мы бы, причитатели, запросто, если бы сайты имели, скажем, облегченную версию, которая шла бы на IE6.Снова возвращаемся к вопросу о сапогах.
TeX я здесь не вижу, кастомный шрифт я вижу всего один, и без него я спокойно обошёлся бы. Как верстающий под IE8 заявляю, что хабр прекрасно мог бы работать и под IE8, если бы разработчики не ленились обеспечить соответствующую совместимость (возможно и под IE6 тоже, но под него пилить сайты слишком уж трудно, а под IE8 нормально, проверено на себе).
TeX я здесь не вижуПлохо смотрите, значит. Сделайте «view source» и найдите ссылку на cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/config/TeX-AMS_SVG-full.js?V=2.7.1
кастомный шрифт я вижу всего одинТем не менее он там есть. А может и не один (если вы TeX «не заметили», то могли и ещё чего-нибудь пропустить).
Как верстающий под IE8 заявляю, что хабр прекрасно мог бы работать и под IE8, если бы разработчики не ленились обеспечить соответствующую совместимостьА это точно увеличило бы посещаемость? А доход?
(возможно и под IE6 тоже, но под него пилить сайты слишком уж трудно, а под IE8 нормально, проверено на себе).Да заточить-то можно хоть под первую Мозаику, вопрос в соотношении расходов и доходов!
Плохо смотрите, значит. Сделайте «view source» и найдите ссылку на
И что? Можно запихать стопицот разных ссылок на самые разные скрипты — а вот прямо на этой странице где хотя бы одно реальное использование TeX?
Тем не менее он там есть.
А лучше б не был :)
А это точно увеличило бы посещаемость? А доход?
Да заточить-то можно хоть под первую Мозаику, вопрос в соотношении расходов и доходов!
То есть мы возвращаемся к упоминавшимся ниже говнокоду и лени программистов.
Почему все автопроизводители не делают мерседесов, и не продают их по цене жигулей? Наверное из-за говноинжиниринга и лени?
Кстати, именно оптимизации под старые IE скорее выглядят как говнокод.
Кстати, именно оптимизации под старые IE скорее выглядят как говнокод.
Почему оптимизации под IE-то, я пишу всё строго в соответствии с HTML5 и CSS3 и с парой полифиллов сбоку, доводящих IEшный жс до используемого мной подмножества ES5. (В полифиллах, может, и говнокод, но не пофиг ли, если они завёрнуты в <!--[if lt IE 9]>?)
Почему оптимизации под IE-то, я пишу всё строго в соответствии с HTML5 и CSS3
Скорее всего, вы ничего серьезного под IE не разрабатывали. Писать все строго по спецификации не поможет вам никак. Дело не в отсутствии современных фич, а в совершенно диких багах:
- абсолютно спозиционированный элемент не кликабельный без хака с background
- max-height ломается при использовании overflow
- fireEvent ломается при невыясненных обстоятельствах
Разработка под IE8 была немного похожа на лотерею. Никогда не угадаешь, какая комбинация стилей и Javascript сломается на этот раз.
Согласен с Вами. У меня правда с вёрсткой даже под IE8 были большие проблемы ввиду моего недостаточного скилла (хотя один большой сайт всё-таки идеально адаптировал в своё время). Но вот Хабр… Что там IE8. Сейчас проверял в Хроме 2012-ого года, так даже в нём вёрстка покорёжена очень сильно.
Только что сравнил потребление памяти Хромом версий 21 и 45 при открытии это страницы и прокрутки до середины. Разница колоссальная (хотя оба числа укладываются в разумные рамки).
Хром 21 (июль-август 2012), одно расширение установлено и активно, но ограничено другим доменом, на Хабре не используется: 2 процесса, первый 36-38 Мб, второй 168-173, возможно, при дальнейшем скроллинге вниз число бы возросло.
Хром 45 (август 2015), установлено 5-6 расширений, три активно, включая Adblock для YouTube (по идее, на Хабре не должен быть активен, хотя хз): 4 процесса прямо на старте после загрузки страницы, потребление — 22 Мб, 43 Мб, 139-180 Мб, и 190-213 Мб. Если выключить все расширения, оставив то же самое одно, что и в 21 версии — абсолютно ничего не меняется. Такие дела.
Правда, в 21-ом Хроме страница очень сильно покорёжена, и анимированная реклама справа не проигрывается. А ещё есть подозрение, что 40+ версии Хрома заранее кэшируют контент для ускорения прокрутки (причём с применением GPU, у меня часто например есть баг, что при смене активного окна на экране остаётся картинка окна Хрома, везде кроме панели задач, и приходится переключаться туда-сюда повторно), отсюда и возросшее потребление памяти (но и существенно более отзывчивый и быстрый скроллинг). С другой стороны — аппаратное ускорение не очень объясняет возросшее потребление RAM, так как в основном должна задействоваться память видеокарты, если я правильно всё понимаю.
Хром 21 (июль-август 2012), одно расширение установлено и активно, но ограничено другим доменом, на Хабре не используется: 2 процесса, первый 36-38 Мб, второй 168-173, возможно, при дальнейшем скроллинге вниз число бы возросло.
Хром 45 (август 2015), установлено 5-6 расширений, три активно, включая Adblock для YouTube (по идее, на Хабре не должен быть активен, хотя хз): 4 процесса прямо на старте после загрузки страницы, потребление — 22 Мб, 43 Мб, 139-180 Мб, и 190-213 Мб. Если выключить все расширения, оставив то же самое одно, что и в 21 версии — абсолютно ничего не меняется. Такие дела.
Правда, в 21-ом Хроме страница очень сильно покорёжена, и анимированная реклама справа не проигрывается. А ещё есть подозрение, что 40+ версии Хрома заранее кэшируют контент для ускорения прокрутки (причём с применением GPU, у меня часто например есть баг, что при смене активного окна на экране остаётся картинка окна Хрома, везде кроме панели задач, и приходится переключаться туда-сюда повторно), отсюда и возросшее потребление памяти (но и существенно более отзывчивый и быстрый скроллинг). С другой стороны — аппаратное ускорение не очень объясняет возросшее потребление RAM, так как в основном должна задействоваться память видеокарты, если я правильно всё понимаю.
В многозадачных ОС, использующих memory-mapped файлы и разделяемые библиотеки не так уж и просто посчитать потребление памяти группой процессов. Если один процесс потребляет 22 МБ, а другой — 43 МБ, то вместе они могут потреблять, например, около 49 МБ за счёт переиспользования страниц (например, кода).
Загрузите старую версию opera до смены движка и новую, основанную на chromium, как и гуглхром.
Если забыть про 3D-графику, проигрывание видео, то старая версия браузера значительно отличается по работе с большинством сайтов, но к сожалению становится все менее совместима с ними, а некоторые (например гугл) делают свои сайты специально не совместимыми, просто проверяя user agent.
Если забыть про 3D-графику, проигрывание видео, то старая версия браузера значительно отличается по работе с большинством сайтов, но к сожалению становится все менее совместима с ними, а некоторые (например гугл) делают свои сайты специально не совместимыми, просто проверяя user agent.
Они видимо ютубом не пользуются.
О, даа! Разработчики веб сайтов виноваты… нашли на кого свалить. 100 метров памяти на статическую страничку. Это раньше говорили, мол мне только для серфинга ноутбут, можно слабенький. А сейчас браузеры вообще основной пожиратель ресурсов.
На Envy x2 10, старый атом с 2 Гб оперативки. После отключения защиты от meldown одноклассники с блекджеком и флэшем работают в хроме. Что у вас с ним?
Похожей концепции придерживается фейсбук: раз в неделю заставляют всех пользоваться только 2G инетом, чтобы выявлять узкие места приложений.
А что фейсбуком вообще кто-то может пользоваться?
Это мобильную версию? Если бы ещё десктопную проверяли хотя бы на 2Mbit/s канале и на слабом железе…
Не заметил чтобы им это помогало.
Помогает. Фейсбук — единственное приложение, хоть как-то работающие на 2G. Остальные просто не подключаются даже. В наши дни, если в статус-баре светится E — это сигнал, что интернета нет.
Лично много времени пользовал ВК на EDGE (потому что в центре Питера 3G у Tele2 не работает блин нихрена, в отличие от). Думает дольше, но работает вполне нормально, даже менее качественные картинки качает для экономии трафика
Вам повезло.
У меня на Билайне ВК на 2G иногда случайно че-нить подгрузит, но обычно даже текстовые сообщения обновить не может.
У меня на Билайне ВК на 2G иногда случайно че-нить подгрузит, но обычно даже текстовые сообщения обновить не может.
Это проблема ВК или Билайна?) С Билайном вообще что-то не так: у них в метро 2G жутко глючил на моём телефоне, пока 3G не сделали года 3-4 назад. Работало нормально только на 3-4 станциях, и ещё на 2 — с тормозами. На остальных — вообще ничего не качалось…
Скорее всего на БС приоритеты для данных через 2G (да и 3G у Мегафона) скручены в ноль и всю полосу отдали под голос.
Телеграм тоже работает
Их бы лучше андроид-телефоном с 512 МБ оперативки и батареей на 1500 mAh заставляли пользоваться. Что они там в грёбаный клиент для социальной сети пихают, что он на 3 гигах еле ворочается и батарею ест как игра с 3D-графикой?
Зато история, как они не приняли в работу улучшенный интерфейс, который заставлял юзеров провести на сайте меньше времени за счет своей оптимальности, лично мне кажется правдоподобной. Сколько ни захожу, а каждый раз задумываютсь, они специально так все наворотили, или просто клинические идиоты.
У них противоположная задача по сравнению с Гуглом. Это Гуглу важно, чтобы вы провели как можно меньше времени у них на сайте (потому что вы тогда будете им чаще пользоваться и, соотвественно, увидите больше рекламы). А фейсбуку — ровно наоборот.
Та же история, что и с «выкладками» в супермаркетах, когда покупаемые каждый день вещи разбросаны по всему залу.
Та же история, что и с «выкладками» в супермаркетах, когда покупаемые каждый день вещи разбросаны по всему залу.
Ну я вообще-то именно об этом и писал. И писал к тому, что не верю в их тестирование на 2G своих клиентов — которые мало что жрут как не в себя, так еще и все утолщаются: вспомните историю, когда из отдельного мессанджера (которым можно было хоть как-то пользоваться) и отдельного приложения для соцсети сделали одно толстенное приложение, а отдельный мессанжер заблокировали.
Если они так заботятся о скорости, удобстве юзеров, о качестве связи, о батарее телефона — то я чего-то не понимаю.
Если они так заботятся о скорости, удобстве юзеров, о качестве связи, о батарее телефона — то я чего-то не понимаю.
Не обязательно старьё использовать. Можно запустить в виртуалке с ограниченными ресурсами.
Если надо радикально затормозить проц и не потерять многоядерность, то можно отключить кеш процессора, раньше это просто делалось в биос. Не уверен, правда, что хватит терпения дождаться загрузки виндовс, во временя XP минут 20 надо было ждать, правда, сейчас вместо ATA используетс AHCI, который в обход процессора работает и может помочь с файловыми операциями. Кто решится попробовать — отпишитесь :-)
хватит терпения дождаться загрузки виндовс, во временя XP минут 20 надо было ждатьПравильно ли я понимаю написанное, от включения компа до появления рабочего стола в ХР надо ждать 20 минут?
Как получены такие занимательные данные?
Да легко — достаточно ставить все подряд, на что в интернете натыкаешся. Примерно за неделю комп зсирается настолько, что только запуск служб из автозагрузки занимает минут 20… Запуск браузера (Первый) — до 10 минут.
Ситуация заметно усугубляется, если это ноут с хардом 5200rpm, «Атомным» процом и гигом оперы…
Ситуация заметно усугубляется, если это ноут с хардом 5200rpm, «Атомным» процом и гигом оперы…
Переключить IDE контроллер в режим PIO (без DMA), но с ним тормозить будет даже Windows 98 и не только при загрузке.
А что народ обсуждает в моём ответе? Я разьве не понятно написал ОТКЛЮЧИТЬ КЕШ ПРОЦЕССОРА в биос? Про 20 минут, я может и преувеличил, но прошло уже несколько лет, так что вспомнить тяжело, но точно помню, что хотел выключить компьютер после очень длительного ожидания подумав что не дождусь, при этом я знал что будет грузиться очень долго.
Кажется я понял за что минусы: пошёл замерять время и не обнаружил подобной опции в BIOS, видимо теперь это не так просто.
Зачем мне работать на плохом железе?
Есть целевое железо, на нём тестируется, я как разработчик тут вообще побоку. Придет таск — «у нас тормозит, надо разбираться почему» — буду разбираться. В остальном — не понятно чего вы от меня, как от разработчика, хотите.
Есть целевое железо, на нём тестируется, я как разработчик тут вообще побоку. Придет таск — «у нас тормозит, надо разбираться почему» — буду разбираться. В остальном — не понятно чего вы от меня, как от разработчика, хотите.
Это если у вас тестирование, аналитика и все-все разделено на узкие специальности.
А многие тестируют сами свои программы.
P.S.: свое тестирую на смартфоне за 3000 рублей и на нетбуке.
А многие тестируют сами свои программы.
P.S.: свое тестирую на смартфоне за 3000 рублей и на нетбуке.
Браузер Opera точно так же тестировали: релизную версию открывал кто-то из руководства на старом ноуте. Так что подход классный, рабочий, но не новый.
Кстати при веб-разработке сам использую: открываю страницу на нетбуке и убеждаюсь, что там не слайд-шоу.
Кстати при веб-разработке сам использую: открываю страницу на нетбуке и убеждаюсь, что там не слайд-шоу.
На самом деле действительно совершенно неясно — чего именно хотел автор.
Ёжику же ясно, что хороший, грамотный разработчик просто обязан выпускать вещь, которая занимает более-менее все ресурсы у типичного пользователя.
Просто потому, что если это будет не так, то другой разработчик, такой же технически грамотный, но лучше понимающий как работает рынок — выпустит продукт раньше и захватит рынок. А если нет рынка (продукт делается под заказ), то он выпустит продукт дешевле — и, опять-таки, получит плюсик в репутацию.
Никакого, вот совершенно никакого, отношения к тому какое железо есть у разработчиков это не имеет — банальная работа рынка и всё. Просто нет ни единой экономической причины делать что-то менее ресурсоёмким, чем это нужно, для того, чтобы потенциальный пользователь вообще смог это запустить
Ёжику же ясно, что хороший, грамотный разработчик просто обязан выпускать вещь, которая занимает более-менее все ресурсы у типичного пользователя.
Просто потому, что если это будет не так, то другой разработчик, такой же технически грамотный, но лучше понимающий как работает рынок — выпустит продукт раньше и захватит рынок. А если нет рынка (продукт делается под заказ), то он выпустит продукт дешевле — и, опять-таки, получит плюсик в репутацию.
Никакого, вот совершенно никакого, отношения к тому какое железо есть у разработчиков это не имеет — банальная работа рынка и всё. Просто нет ни единой экономической причины делать что-то менее ресурсоёмким, чем это нужно, для того, чтобы потенциальный пользователь вообще смог это запустить
Разве пользователь не пересядет на продукт конкурента, если конкурент вышел позже, но работает в 5 раз быстрее. А тормозной продукт, вместо того, чтобы выигранное время потратить на оптимизацию базовой функциональности, пилит фичи, которые 80% пользователям никогда не будут нужны, превращая продукт в монстр-комбайн.
Разве пользователь не пересядет на продукт конкурента, если конкурент вышел позже, но работает в 5 раз быстрее.Нет, не пересядет. Проверено. Привычки, настройки. Те несколько процентов, которые пересядут — погоды не сделают.
А тормозной продукт, вместо того, чтобы выигранное время потратить на оптимизацию базовой функциональности, пилит фичи, которые 80% пользователям никогда не будут нужны, превращая продукт в монстр-комбайн.Но при этом — большинство пользователей будет именно этот «монст-комбайн» использовать. Именно так. Wikipedia довольно неплохую статью на эту тему содержит.
В качестве примера: Adobe Reader vs Foxit Reader. Разница — примерно как вы сказали, куча фич, которые есть у Adobe Reader'а никому, кроме горстки пользователей не нужны.
Много вы видели бухгалтеров или секретарш, которые бы пользовались бы Foxit Reader'ом?
Да я думаю вы и сами можете примеров привести вагон подобных.
«Шкурки», красивые картинки и прочая мишура — иногда работают, иногда нет. Меньшее потреблебление ресурсов? Только там, где это напрямую выражается в деньгах.
То есть какая-нибудь база данных или web-сервер — могут на этом выехать, позволив купить VDS подешевле. Консьюмерское ПО… не видел ни разу.
Возможно есть какие-то краевые случаи, когда что-то оказалось настолько тяжёлым, что переход на что-то «более лёгкое и быстрое» позволил получить экономию и потому был произведён (что-то типа знаменитого переходя Мюнхена на Linux), но в общем и целом — рынок ПО они изменить не могут.
Может быть как раз переход с MS IE на Chrome сюда можно занести, но и тут я совсем не уверен, что очень уж много народу пересели именно из-за скорости, а не потому, что его на главной странице Гугла предлагали…
Примеры разутого ПО:
ACDSee, Nero, ReGet (ну ладно, он мог умереть естественной смертью), родной клиент ICQ, Windows Media Player (там кодеков мало, согласен), долгое время Kaspersky.
Некоторые экземпляры из этого списка канули в лету именно из за своей раздутости.
Кстати, Adobe Reader был компактным и шустрым где-то до 8-9 версии.
эээ… в сравнении с Фокситом тех же времен не был. Последний приличный Акробат Ридер был версии 5, штоле… Или даже 4.
А что не так с регетом? У него дистрибутив занимает пару мегабайт, качает и… всё, больше ничего (ftp-клиент тоже полезен — далеко не каждый сторонний может отдать ссылку с логином-паролем, а этот ещё и существующее подключение может использовать).
Там, конечно, куча настроек, но если нет хитрых ftp и прокси, то туда и лазать не надо.
Примеры разутого ПО:
ACDSee, Nero, ReGet (ну ладно, он мог умереть естественной смертью), родной клиент ICQ, Windows Media Player (там кодеков мало, согласен), долгое время Kaspersky.
ACDSee — пользуюсь до сих пор, хотя не часто. И не из-за раздутости ПО, а потому что все переехало в веб/соцсети. Nero — тут скорее смерть физических носителей, чем раздутость по. DVDrom не использовал уже лет 5. ReGet — в те времена, кто о чем услышал, тем и пользовался. Все мои знакомые сиделе на download Master. ICQ — некоректный пример. Сдесь как с телефонными операторами. Один ты аськой пользоваться не будешь, где сидят все знакомые там сидишь и ты. Windows Media Player — им вообще кто-то пользовался????
ACDSee
Последней версией?)
ICQ — некоректный пример.
Корректный, я как раз указал, что родной клиент. Начиная с какого-то момента родной клиент стал разбухать. Все или оставались на старом, или переехали на альтернативные клиенты.
Windows Media Player
Да, я пытался.
ACDSee пользуюсь до сих пор, начиная с времён DOS. Нет, не последней версией, ACDSee Pro 6, потому что это последняя версия, в которой минимальное пространство вокруг превьюшек. Sony RX100 он как не мог декодировать без дисторсии, так и не может. Плюс начиная с 7 или 8 версии сделали неудобный просмотр RAW: раньше всегда показывалась embedded превьюшка, и только когда переключаюсь в 1:1 то декодируется RAW, теперь же появился глобальный переключатель, позволяющий либо только превьюшку из RAW смотреть, либо всегда декодировать без отображения превьюшки.
WMP неплохой плеер. По крайней мере, красивый, начиная с версии 11. Помню, как был в восторге от нового дизайна ещё в 2006-ом году, когда с SP2 на XP WMP11 поставил :)
Да, он тяжеловат, но на современном железе это уже не проблема совершенно. Единственная к нему претензия — не умеет аудиодорожки корректно разделять (в версии 11 точно не умел).
Да, он тяжеловат, но на современном железе это уже не проблема совершенно. Единственная к нему претензия — не умеет аудиодорожки корректно разделять (в версии 11 точно не умел).
В копилку PDF-просмотрщиков — SumatraPDF: тоже быстрый, многоформатный (из того, чем пользуюсь я умеет DjVu, ePub, FB2) и свободный (у кого-то из вышеперечисленных Foxit или STDU лицензия раньше позволяла бесплатно только для личного использования).
Много вы видели бухгалтеров или секретарш, которые бы пользовались бы Foxit Reader'ом?
Я своим просто поставил фоксит, без пояснений и вопросов. Пользуются.
У меня довольно таки слабый ноутбук. Отказался и от Adobe Readera и от Foxit Readera. Пользуюсь STDUViewer именно по причине его скорости. Читает большинство форматов, не лезет самостоятельно в инет за обновлениями.
Не считаю себя суперпродвинутым гиком. Обычный пользователь.
Не считаю себя суперпродвинутым гиком. Обычный пользователь.
Поставил нашей секретарше Foxit Reader. Теперь, как меня увидит, спасибо за него говорит. Нарадоваться не может. Она банально про него ничего не знала. Потом все бухгалтера меня попросили его установить.
Как раз Foxit Reader — не показатель, его очень даже часто ставят.
А вот действительно пример раздутого ПО, которое продолжают использовать — это MSOffice.
А вот действительно пример раздутого ПО, которое продолжают использовать — это MSOffice.
есть альтернатива офису?
я больше года был «против пиратства» и привыкал к опенофису (для простых задач у него не так много недостатков), но после того, как он второй раз убил кириллицу во всех последних файлах (об этом узнаёшь только после открытия этих файлов, потому могут оказаться битыми даже ручные бэкапы), перестал играть в робин гуда и пошёл на рутрэкер за православным МСофисом.
я больше года был «против пиратства» и привыкал к опенофису (для простых задач у него не так много недостатков), но после того, как он второй раз убил кириллицу во всех последних файлах (об этом узнаёшь только после открытия этих файлов, потому могут оказаться битыми даже ручные бэкапы), перестал играть в робин гуда и пошёл на рутрэкер за православным МСофисом.
Вы сохраняли в docx? У меня часто при сохранении в docx сбивалось форматирование, а иногда даже при попытке получившийся файл открыть МСофисом последний просто начинал падать или неадекватно себя вести. Поэтому то, что собираюсь редактировать я всегда сохраняю в odt, а для отправки кому-нибудь — в pdf.
Никогда не видел таких ужасов. Но и сохранять в чём-то, кроме ODT/ODS/etc я, разумеется, не пробовал. Это уже не игра в «робин гуда», а игра «в русскую рулетку».
есть альтернатива офису?Мне знакомец, имеющий дело с текстами чуть более, чем всегда (редактор научного журнала) всячески нахваливал SoftMaker freeoffice. Говорит, перешел полностью, и с проблемами не встречался, притом что присылают статьи, естественно, в известном формате.
Кстати, на Foxit он же переходить не стал, ибо помянутый Foxit как-то не так работает с комментариями.
TeX. Настолько мощная штука, что текстовые WYSIWYG-процессоры после него кажутся убожеством для домохозяек. В M$ Office, впрочем, подобная мощь тоже достигается макросами на VBA, но ради безопасности их часто отключают. Превосходно заменяет Word, PowerPoint и Publisher. Минусы — лэгаси зашкаливает; высокой порог вхождения, который должны преодолеть все редактирующие документ; об экспорте в .doc/.docx не стоит и мечтать, если вёрстка сложнее уровня WordPad; просмотр изменений требует компиляции; сложная отладка, сообщения об ошибках малоинформативны, особенно при использовании готовых пакетов.
В MSOffice легаси не меньше, обратите внимание как знатоки оффиса рассказывают, что многие простые вещи оказывается сделать возможно, просто нужно проделать некоторое количество сложных и неочевидных манипуляций.
А TEX когда нужно написать заявление на отпуск — жесточайший оверкилл. Ворд — тоже, хоть и в меньшей степени, но у него хотя бы низкий порог вхождения, хотя когда нужно набрать что-то посложнее того же заявления, приходится изрядно попотеть.
А TEX когда нужно написать заявление на отпуск — жесточайший оверкилл. Ворд — тоже, хоть и в меньшей степени, но у него хотя бы низкий порог вхождения, хотя когда нужно набрать что-то посложнее того же заявления, приходится изрядно попотеть.
LibreOffice имхо получше будет OpenOffice, перешел на него пока проблем не было.
Сравнивать LibreOffice с OpenOffice — это как сравнивать MS Office 2010 и MS Office 2003.
Это один и тот же продукт, просто Oracle «встал в позу» в какой-то момент и новая версия стала называться LibreOffice.
Это один и тот же продукт, просто Oracle «встал в позу» в какой-то момент и новая версия стала называться LibreOffice.
Мне про либру такие страшилки рассказывали:
модули проверки орфографии и пунктуации в Либре оставляют желать лучшего. [...]
большая часть расширений Оупена работает только в нём, а в Либре аналогов или нет, или они довольно куцые и пропускают больше чем аналоги в Оупене. Часто сохранённые в Либре файлы вели себя некорректно в Оупене и наоборот — в частности текстовые и таблицы. Причина не понятна, или какой-то баг контента или реально рандомная несовместимость пакетов. Либре обновляясь ловила непредсказуемые глюки. И пусть их правили следующим патчем, сохранить документ который потом не откроется — не очень приятно. Чтобы не ломать себе голову — использую Оупен только в связке с 2003 вордом. С Либрой больше возиться не захотелось.
Опенофис медленный как незнамо что, запускается на четырехядерном планшетнике с с гигом оперативки и Win8.1 несколько минут, адски виснет, но да, места мало занимает. Майкросовтовский офис работал вообще без проблем, но бесплатный год кончился…
А вот действительно пример раздутого ПО, которое продолжают использовать — это MSOffice.
Я бы понял это замечание году этак в 1997-м, когда мы бы обсуждали прожорливость нового Office 97 на машинах с 8 метрами памяти. Но сейчас про MS Office язык не поворачивается сказать ни одного плохого слова в плане его «раздутости». Вот я сейчас смотрю на приложения в Диспетчере задач. Опера с вот этой самой страницей — 300 мегабайт памяти. Скайп — 105 мегабайт, упомянутый мною тут ниже плагин CallNote — 140 мегабайт. Вайбер 96 мегабайт. Сам диспетчер задач — 17 мегабайт. И MS Word с открытым шестистраничным документом, приложение, которое по функционалу превышает все вышеупомянутые вместе взятые, съел аж 40 мегабайт.
Проблема не в прожорливости, а в неудобности: из за непомерного числа фич им с каждым годом всё сложнее становится пользоваться, а баги, типа неудаляемых переводов строк, или пробелов, при удалении которых сбивается форматирование, или невозможности вставить рисунок в нужное место, исправлять никто не собирается.
Не знаю, как по мне, там особо придираться не к чему. Интерфейс менялся всего один раз, и то, десять лет назад, все элементы управления находятся там, где привык их искать. Новых фич наоборот, в интерфейсе особо и не появляется. По крайней мере, мешающих использовать старые фичи.
Что касается багов, самый мой крупный документ в Word'e — это моя диссертация. Не бог весть какой хитровымудренный по вёрстке документ, но две сотни страниц с иллюстрациями, таблицами, содержанием, ссылками, стилями. Сейчас в основном поскромнее — документация, спецификации. Страниц до 70 доходит. Поэтому я хоть и не гоняю Word в хвост и в гриву, но работаю с ним, пожалуй, активнее среднестатистического пользователя. И вот ни одного бага мне не попадалось уже много лет. Наверняка они есть, но мне кажется, встречаются лишь в каких-то очень уж специфических случаях, потом и не отловлены.
Что касается багов, самый мой крупный документ в Word'e — это моя диссертация. Не бог весть какой хитровымудренный по вёрстке документ, но две сотни страниц с иллюстрациями, таблицами, содержанием, ссылками, стилями. Сейчас в основном поскромнее — документация, спецификации. Страниц до 70 доходит. Поэтому я хоть и не гоняю Word в хвост и в гриву, но работаю с ним, пожалуй, активнее среднестатистического пользователя. И вот ни одного бага мне не попадалось уже много лет. Наверняка они есть, но мне кажется, встречаются лишь в каких-то очень уж специфических случаях, потом и не отловлены.
Странно, как вспомню как я будучи студентом пытался с вордом работать, и как на прошлой работе, до сих пор предплечье болит. Может быть и можно привыкнуть к тому, что при удалении символа может сбиться форматирование последующих символов, но я предпочитаю считать багом, а не фичей ситуацию, когда я не могу сделать в один приём банальную вещь, которая у других работает как надо.
> когда я не могу
_Вы_ не можете. Потому что не умеете. Кто-то другой — умеет и может. Вот если сделать что-то невозможно (или просто объективно сложно/неудобно) — другой разговор.
_Вы_ не можете. Потому что не умеете. Кто-то другой — умеет и может. Вот если сделать что-то невозможно (или просто объективно сложно/неудобно) — другой разговор.
То есть вы считаете, что когда банальная операция удаления символа влечёт за собой неожиданные и как правило не нужные эффекты — это не «объективно сложно/неудобно»?
> То есть вы считаете, что когда банальная операция удаления символа влечёт за собой неожиданные и как правило не нужные эффекты
Очевидно, что у человека, умеющего работать в ворде, удаление символа неожиданных последствий за собой не влечет.
Очевидно, что у человека, умеющего работать в ворде, удаление символа неожиданных последствий за собой не влечет.
Это называется доводом истинного шотландца: даже если при наборе нескольких безобидных на вид символов ворд внезапно начнёт форматировать диск C, всё равно это — не баг, потому что для «человека, умеющего работать в ворде» это, очевидно, не является «неожиданными последствиями».
> всё равно это — не баг
Баг, это когда что-то работает не так, как должно по спецификации. Ворд работал в вашем случае не так? Вы опишите конкретно что сделали, и что произошло.
Баг, это когда что-то работает не так, как должно по спецификации. Ворд работал в вашем случае не так? Вы опишите конкретно что сделали, и что произошло.
А где я могу увидеть эти спецификации?
В руководстве пользователя, например? Там не описано, как ведут себя стили? И вы опишите уже конкретно, что вы сделали, и что именно произошло.
Вы можете дать ссылку где описано именно это поведение?
Конечно, нет, ведь я не знаю, о каком поведении речь. Уже несколько раз спрашивал, а вы все никак не отвечаете.
при удалении символа может сбиться форматирование последующих символов
Это ничего не говорит. Какое форматирование, как сбилось? Что сделали, как удаляли?
В том-то и дело, что по-разному бывает. Например, я ставлю курсор в конец страницы и нажимаю «del», предполагая, что должен удалиться разрыв страницы — вместо этого удаляется форматирование заголовка в начале следующей страницы. Или разрыв удаляется, но вместе с форматированием последующего текста. Иногда — наоборот форматирование последующего текста применяется к предшествующему тексту. Каким-то образом отличать на глаз, в каком случае как поведёт себя удаление символа я не могу.
В данном случае поведение очень даже детерменировано.
Если разрыв страницы вставлен «самостоятельно», он удалится. Если разрыв страницы там присутствует как атрибут заголовка, то он не удалится, зато удалится разрыв между абзацами, заголовок пришпилится к предыдущему абзацу и примет его стиль. Чтобы понимать, что именно произойдет (если это так важно для вас), в ворде есть кнопка для отображения спецсимволов.
Если разрыв страницы вставлен «самостоятельно», он удалится. Если разрыв страницы там присутствует как атрибут заголовка, то он не удалится, зато удалится разрыв между абзацами, заголовок пришпилится к предыдущему абзацу и примет его стиль. Чтобы понимать, что именно произойдет (если это так важно для вас), в ворде есть кнопка для отображения спецсимволов.
Именно из-за этого лоеры очень долго не пользовали Word, а пользовали WordPerfect, где есть режим «reveal codes».
Тем не менее тот факт, что в Word форматирование «прилеплено» к символам — это особенность дизайна. Она описана в документации (по крайней мере в книгах про Word об этом писали лет 10 назад, когда я про это читал) и багом, eds, не является.
Тем не менее тот факт, что в Word форматирование «прилеплено» к символам — это особенность дизайна. Она описана в документации (по крайней мере в книгах про Word об этом писали лет 10 назад, когда я про это читал) и багом, eds, не является.
Ну значит не баг, а багофича. Особенность неудачной архитектуры.
Это другая история. Но, увы. WordPerfect несовместим со «стандартом» (а с ним никто, на самом деле, не может быть совместим, дажа сам Microsoft на Mac'е использует ту же самую виндовую библиотеку, что и на Windows ибо иначе все багофичи не воспроизвести), а стало быть реальной альтернативой не является… если вы не лоер в Штатах, конечно.
За много лет нашел только один, не единично встречающийся, баг (?): если открыть в 2007 офисе документ, созданный в 2010, из него иногда исчезают пробелы.
Много лет использовал MS Office (на уровне не только набора документов, но и макросов, VBA, БД). Последний раз серьёзно использовал в 2013 году. По крайней мере, на то время альтернатив не было. Различные вариации «офисов» под Linux, Windows годны были для базового набора документов и таблиц. Плохая совместимость с «оригиналом», неудачный интерфейс и минимум функций как-то не позволили сказать, что ими следует пользоваться. Ну да, бесплатно дома пописать, сохранить в odt, ну и всё.
Ну про тот же Open/LibreOffice не сказал бы, что функций мало, если без VBA и некоторых особых фич, именно в нём многое делать многократно удобнее, чем в том же MSOffice. Хотя бы потому, что он ориентируется на создание структуры документа, поверх которой накладывается оформление. После того, как несколько раз перелопатишь документ чтобы исправить отступы, начинаешь ценить такой подход.
После того, как несколько раз перелопатишь документ чтобы исправить отступы, начинаешь ценить такой подход
Как вы думаете, зачем в Word уже примерно четверть века существует панель «Стили»?
Сравните с реализацией той же функции в OpenOffice. Да, нет модных кнопочек и предпросмотра при наведении курсора, зато через панель стилей настраивается всё. Ну и до кучи, при удалении символов стиль к новому фрагменту текста применяется предсказуемо.
Ну так и в Ворде через панель стилей также настраивается всё. Если у вас есть такое желание.
Другое дело, что Ворд предоставляет вам альтернативу — вы можете сесть и пользоваться им практически сразу, не изучая никакие дополнительные сущности и методики.
Другое дело, что Ворд предоставляет вам альтернативу — вы можете сесть и пользоваться им практически сразу, не изучая никакие дополнительные сущности и методики.
Отступы от краёв тоже через стили можно настроить? Формат страницы? Порядок печати колонтитулов? Маркеры списка? Абзацные отступы? Отступы в ячейках таблицы? Если оно через отступы настраивается, я пока не нашёл, где.
Формат страницы и порядок печати колонтитулов нельзя (и как по мне, и не должно было бы, т.к. это метаданные документа, а не текста), всё остальное через стили настраивается, и весьма странно, что вы этого не нашли, т.к. атрибуты стилей собраны рядом в одном меню, и вы его либо видели, либо не видели.
Почему же именно документа? Весьма часто бывает необходимо в документ с книжной ориентацией добавить несколько страниц в альбомной, либо с другими полями, а иногда и вовсе на бумаге другого формата. В ворде это — нетривиальная задача. А если нужно и чтобы были листы разного формата, и чтобы на первой странице не отображался колонтитул — такого ворд не предусматривает вообще.
Что касается остального — прямо сейчас у меня доступа к Word-у нет, но когда я писал предыдущий комент, передо мной был 2010-й ворд, и в настройках стилей я нашёл только шрифты, цвета и межстрочный интервал. Может быть я не там искал?
Что касается остального — прямо сейчас у меня доступа к Word-у нет, но когда я писал предыдущий комент, передо мной был 2010-й ворд, и в настройках стилей я нашёл только шрифты, цвета и межстрочный интервал. Может быть я не там искал?
Весьма часто бывает необходимо в документ с книжной ориентацией добавить несколько страниц в альбомной, либо с другими полями, а иногда и вовсе на бумаге другого формата. В ворде это — нетривиальная задача.
В MSWord 2007 это делается через меню: Разметка страницы — Разрывы — Разрывы разделов: Следующая страница.
После таких манипуляций на странице после разрыва раздела можно менять и поля, и размер листа, и ориентацию.
А если нужно и чтобы были листы разного формата, и чтобы на первой странице не отображался колонтитул — такого ворд не предусматривает вообще.
В MSWord 2007 нужно открыть меню с колонтитулами и там будут флажок "Особый колонтитул для первой страницы". Отмечаете его и просто не делаете колонтитул для первой страницы.
в настройках стилей я нашёл только шрифты, цвета и межстрочный интервал.
Доступ к настройкам стилей немного неочевидный. В MSWord2007 меню "Главная", блок "Стили". Нужно нажать на маленькую неподписанную кнопочку в правом-нижнем углу блока. Ну или "Alt+Ctrl+Shift+S".
В MSWord 2007 это делается через меню:
Я знаю, как это делается, но при работе с этим постоянно возникает куча мелочей, например, если нужно изменить формат только для нескольких страниц внутри документа, прежде чем добьёшься нужного результата приходится изрядно помучиться.
Отмечаете его и просто не делаете колонтитул для первой страницы.
И этот же особый колонтитул применяется при каждом изменении формата страницы, а мне нужно только для первой.
Нужно нажать на маленькую неподписанную кнопочку в правом-нижнем углу
Ишь ты, как удобно и интуитивно понятно!
Весьма часто бывает необходимо в документ с книжной ориентацией добавить несколько страниц в альбомной. В ворде это — нетривиальная задача.
А почему нетривиальная? Различная вёрстка (ориентация, размер листа, разбиение на колонки) применяется к различным разделам. Бьёте документ на разделы и форматируете каждый из них как вам удобно. Это просто и логично. Новый раздел вставляется одной кнопкой, форматирование для него делается так же, как и для документа в целом.
А если нужно и чтобы были листы разного формата, и чтобы на первой странице не отображался колонтитул — такого ворд не предусматривает вообще.
Ну как это не предусматривает? Точно так же, для каждого раздела вы можете задать разные форматы листов, и разные колонтитулы.
и в настройках стилей я нашёл только шрифты, цвета и межстрочный интервал
В настройках стилей есть все атрибуты шрифтов, параграфов, таблиц, списков, цветов и т.д… Это появилось этак в шестом ворде или что-то около того. И находится в том же меню уже примерно четверть века. Щелкните на стиле правой кнопкой мышки, нажмите «Изменить», затем «Формат».
На самом деле проблема лишь в том, что вы просто не знаете Word на том уровне, который вам необходим для этих действий. Может быть, потому, что просто его не используете.
Продемонстрируйте, пожалуйста, документ Word, в котором на первой странице отсутствует колонтитул, а на остальных — есть, и при этом имеются листы как с книжной, так и с альбомной. Я с этим мучился очень долго: если есть страницы другой ориентации, на них колонтитул тоже пропадает. Пришлось мне тупо замазывать колонтитул на первой странице квадратиками.
Ну вот: prntscr.com/ioonq0
Делается в несколько щелчков:
«Вставить разрыв раздела»
На втором разделе — «альбомная ориентация»
На колонтитуле второго раздела снять галочку «Копировать предыдущий», после этого на колонтитул второго раздела изменения колонтитула первого раздела не будут никак влиять
Делается в несколько щелчков:
«Вставить разрыв раздела»
На втором разделе — «альбомная ориентация»
На колонтитуле второго раздела снять галочку «Копировать предыдущий», после этого на колонтитул второго раздела изменения колонтитула первого раздела не будут никак влиять
Я так понимаю, что хочется как раз обратного: чтобы колонтитулы были везде одни и те же, во всех разделах, а на первой странице их не было.
Именно так.
Я именно так и сделал. Мне просто показалось очевидным, что вы можете представить себе этот же самый документ, только без набранной надписи «Первый колонтитул». И что если я добавлю ещё сколько угодно разделов, там будет скопирован колонтитул второго раздела, если у них будет стоять галочка «Копировать предыдущий»
Ладно, в следующий раз попробую. Но как же это неудобно: вместо того, чтобы задать стиль листа, думать про «следующий-предыдущий». Привыкнуть можно, но ведь можно проще!
Эх, сразу не зашёл в ветку, а тут столько интересного написали. Согласен с предыдущими авторами, в Word'е можно сделать почти всё. Другие пакеты копируют эти функции с разной долей успешности. Вряд ли есть какие-то задачи, которые есть в других офисных пакетах, но отсутствуют у MS. Да, работа с большими документами трудна и даже опасна (неудачные действия могут привести к невозможности редактирования или даже просмотра документов), но для этого существуют резервные копии. Также документы из сотен страниц достаточно долго загружаются, а редактирование превращается в мучение. Минусы есть, но для работы этот пакет подходит несколько лучше других.
Минусы есть, но для работы этот пакет подходит несколько лучше других.На самом деле нет. Люди, которые переходят с WordPerfect буквально рыдают, когда их отрывают от их любимого Reveal Codes, и утверждают, что многое в Word'е — «делается через одно место» (говоря строго формально в любой программе редактирования, позволяющей ставить отдельные пиксели на лист бумаги можно породить любой документ, так что говорить что что-то там совсем не делается — нельзя), но… стандарт есть стандарт.
Я, честно говоря, вижу только силу привычки. Я не скажу, что в Ворде интерфейс везде логичен, там действительно есть немало легаси (что, может быть, даже и хорошо, учитывая опыт миллионов его пользователей и тысячи учебников, которые не теряют своей актуальности от версии к версии).
Но в данном конкретном случае для меня, наоборот, подход Ворда кажется более логичным. Сделать настройки колонтитулов по умолчанию одинаковыми для всех разделов с возможностью прервать цепочку на любом стыке разделов — это как раз наиболее частый кейс их использования, разве не так?
Но в данном конкретном случае для меня, наоборот, подход Ворда кажется более логичным. Сделать настройки колонтитулов по умолчанию одинаковыми для всех разделов с возможностью прервать цепочку на любом стыке разделов — это как раз наиболее частый кейс их использования, разве не так?
Вопрос не в стыковке колонтитулов. Вопрос в принципе. В случае с TeX'ом — вы всё видите на экране во время редактирования. Нет никаких невидимых скрытых «ручек». Никаких подвохов. Если два куска текста выглядят идентичнок — то они таки идентичны (да, я знаю про макросы… в большинстве документов не принято макросы посреди документа переопределять). В Word — это не так. Есть некая структура документа, которую увидите невозможно. Есть много «палочек», которыми можно в неё «потыкать» — но нет единого плана. Зато WYSIWYG.
В WordPerfect, как мне говорили, есть оба этих режима: обычно структура документа не видна и вы работаете в режиме WYSIWYG… но если «приспичит» — можно ей проявить и работать с ней напрямую.
В WordPerfect, как мне говорили, есть оба этих режима: обычно структура документа не видна и вы работаете в режиме WYSIWYG… но если «приспичит» — можно ей проявить и работать с ней напрямую.
> Вопрос не в стыковке колонтитулов. Вопрос в принципе. В случае с TeX'ом — вы всё видите на экране во время редактирования.
Вы знаете, с настройкой колонтитулов в ворде справляется прекрасно любая условная тетя Глаша. А вот с оформлением курсовых в техе у нас у некоторых будущих итшников проблемы серьезные были.
> Если два куска текста выглядят идентичнок — то они таки идентичны
Вообще-то, нет. И выше вы именно это (то, что два одинаковых текста в техе срендерить можно как заблагорассудится) вы, вроде, приводили в плюс теха, нет?
Вы знаете, с настройкой колонтитулов в ворде справляется прекрасно любая условная тетя Глаша. А вот с оформлением курсовых в техе у нас у некоторых будущих итшников проблемы серьезные были.
> Если два куска текста выглядят идентичнок — то они таки идентичны
Вообще-то, нет. И выше вы именно это (то, что два одинаковых текста в техе срендерить можно как заблагорассудится) вы, вроде, приводили в плюс теха, нет?
с настройкой колонтитулов в ворде справляется прекрасно любая условная тетя Глаша
Видать я тупее условной тёти Глаши, и весь наш коллектив на прошлой работе, потому что именно с этой настройкой колонтитулов мучились очень долго.
Вообще-то, нет. И выше вы именно это (то, что два одинаковых текста в техе срендерить можно как заблагорассудится) вы, вроде, приводили в плюс теха, нет?Не совсем я, ну да ладно.
Тут рассматриваются два разных случая. Два одинаковых куска текста в разных TeX-документах могут вынлядеть сильно по разному. Так как стили отделены от семантики.
В одном же документе всё будет одинаково. Или даже если по разному — можно будет легко увидеть почему. Нажимать на маленькую неподписанную кнопочку в правом-нижнем углу никогда не требуется.
«Возможность прервать цепочку» — это очень плохо для сложного документа: если нужно изменить такую «прерывающуюся цепочку», нужно пробежаться по всем местам, где она прерывается. Гораздо проще иметь «стиль колонтитула А» и «стиль колонтитула Б» и использовать их в документе где нужно.
Речь идет о типовом кейсе. Если из 1000 документов для одного нужны произвольные колонтитулы на случайных страницах в середине документа, а для 999 нужно их копировать до конца документа, и только вначале он может отличаться, надо делать интерфейс под эти 999 случаев, а не для того одного уникального.
Много вы видели бухгалтеров или секретарш, которые бы пользовались бы Foxit Reader'ом?
Бухгалтеры и секретари пользуются тем, что им установил ИТ отдел. А те выбирают максимально совместимое решение с понятной политикой поддержки (в том числе bug bounty).
Ну или к какому привыкли.
плюсом к этому.
раньше, наряду с флэшем на многих сайтах была приписка, что для открытия ПДФ нужно скачать адоб (акробат) ридер. точно также народ переходит на яндекс браузер, случайно устанавливая его вместе с каким-либо ПО (ГОМплеер, привет!). да и воспоминания с «софтом» от мэйл.ру ещё свежи.
так и создаются «привычки».
раньше, наряду с флэшем на многих сайтах была приписка, что для открытия ПДФ нужно скачать адоб (акробат) ридер. точно также народ переходит на яндекс браузер, случайно устанавливая его вместе с каким-либо ПО (ГОМплеер, привет!). да и воспоминания с «софтом» от мэйл.ру ещё свежи.
так и создаются «привычки».
Я бы поспорил. У меня, например, старенький слабый смартфон. Поэтому у меня стороннее приложение для ВК (Kate Mobile), стороннее приложение для Telegram… И для Twitter бы поставил, если бы оно было в наличии (тем более официальное больше не поддерживает мою версию ОС). И таких людей много. В своё время многие выбирали Оперу вместо IE (когда ещё не было Хрома) по тем же причинам. И по этим же причинам меня раздражает фейсбук — что десктопный сайт, что огромное и безумно тяжёлое приложение под Андроид, жрущее кучу памяти в фоне.
В своё время многие выбирали Оперу вместо IE (когда ещё не было Хрома) по тем же причинам.Много — это сколько? Opera никогда не имела больше 10% рынка.
Восемь лет назад Опера в России имела ~30% gs.statcounter.com/#browser-RU-monthly-201012-201012-bar
могу соврать, но именно в России Опера действительно имела огромный кусок пирога. было даже интересно, почему именно у нас.
Именно так. Россия — вообще странная страна. Дело в том, что в мире все эти Foxit'ы, Opera'ы и прочее непопулярны потому что если у вас, как у меня, на ноуте 32GiB памяти, а на десктопе 64GiB, то вам особо не интересно искать самые-малопотребляющие-программы-в-мире, а если вы себе подобное не можете позволить — то вы, стало быть, о компьютерах мало что знаете о существовании подобных программ просто не в курсе.
В России же как-то так получаются что людей, которые разбираются в компьютерах и не могущих себе, при этом, позволить купить приличное железо — довольно много. Отсюда такой феномен.
В России же как-то так получаются что людей, которые разбираются в компьютерах и не могущих себе, при этом, позволить купить приличное железо — довольно много. Отсюда такой феномен.
В России(и не только) привыкли пользоваться альтернативами. Например торренты, а не официальные сайты.
При этом я не могу это связать с финансовой стороной, у меня на компе i7 и 32 оперативы, а на нетбуке только атом и 2гб, и это предел который позволяет чипсет. Я хотел бы прикупить туда 4 ил 8 гб, но так решили intel, и пришлось поставить FF с плагинами отрезающими всё лишнее, фокситы, либреофисы. С отключением префеч и суперфеч, ссд позволяет.
При этом я не могу это связать с финансовой стороной, у меня на компе i7 и 32 оперативы, а на нетбуке только атом и 2гб, и это предел который позволяет чипсет. Я хотел бы прикупить туда 4 ил 8 гб, но так решили intel, и пришлось поставить FF с плагинами отрезающими всё лишнее, фокситы, либреофисы. С отключением префеч и суперфеч, ссд позволяет.
В России(и не только) привыкли пользоваться альтернативами.Тем не менее на родине, в Норвегии Опера в 2010м занимала 6%, а в России — 30%. В какой ещё стране и когда она занимала больше 10%?
При этом я не могу это связать с финансовой стороной, у меня на компе i7 и 32 оперативы, а на нетбуке только атом и 2гб, и это предел который позволяет чипсет.Чипсет на нетбуке сменить нельзя, но можно вместо нетбука взять нормальный лаптоп… вот что заставляет людей в России мучаться с атомом и 2GB памяти вместо того, чтобы потратить $200-300 и взять, хотя бы с рук, лаптоп с приличным процессором 8GB-16GB памяти? Неужели ваше время так дёшево стоит? Это ведь не только возня по настройке «FF с плагинами отрезающими всё лишнее», но и дополнительное время потом — как ни крути, а скорость работы Атома заметно меньше, чем у Core i5/i7…
размер? ноуты калибра 9-10" — стоят как чугунный мост, либо еще более тормоза чем тот атом.
вот что заставляет людей в России мучаться с атомом и 2GB памяти вместо того, чтобы потратить $200-300 и взять, хотя бы с рук, лаптоп с приличным процессором 8GB-16GB памяти?Как только вы мне покажете модель хоть новый, хоть с рук с «приличным процессором и 16гб памяти», 10-12" и автономностью не менее 8 часов — сразу начну искать где заказать. Потому как ничего, в продаже сейчас нет.
Последние два критерия являются основными необходимыми для удобства ношения и гарантированной работы в течении дня.
Последние два критерия являются основными необходимыми для удобства ношения и гарантированной работы в течении дня.Но при этом только и исключительно в России. Интересно — почему.
Учитывая, что я меня есть опыт работы у нескольких странах ЕС, и там этот же ноут применялся ровно точно так же — г-н khim ищет черную кошку так где её нет.
А если бонусом добавить, что он и был куплен в ЕС, по совету коллег в Германии, и обдумать это, то может прийти просветление и понимание, что есть специальные задачи и специальные инструменты для них.
А если бонусом добавить, что он и был куплен в ЕС, по совету коллег в Германии, и обдумать это, то может прийти просветление и понимание, что есть специальные задачи и специальные инструменты для них.
А если бонусом добавить, что он и был куплен в ЕС, по совету коллег в Германии, и обдумать это, то может прийти просветление и понимание, что есть специальные задачи и специальные инструменты для них.«Специальные задачи» и «специальные инструменты» — пожалуйста, но только в России «специальные инструменты» оказываются массовым явлением. И на них вместо решения «специальных задач» пытаются смотреть видео со совершенно «неспециального» YouTube.
Вот это — уже какой-то достаточно специфичный Российский феномен, похожий на феномен Хромбуков и iPad'ов в США (там они занимают больше половины школьного рынка, притом, что в других странах ничего подобно и близко нету)
феномен Хромбуков и iPad'ов в США (там они занимают больше половины школьного рынка, притом, что в других странах ничего подобно и близко нету)
Это не феномен, а всего лишь результат работы маркетинга этих компаний в США.
А вне США маркетологам кто-то работать мешает?
А вне США маркетологам кто-то работать мешает?Вне США работают другие маркетологи.
В ЕС одни, в Японии другие. Если вы посетите Японию, то удивитесь, тому что там популярно и продается, при этом это мало распространено в других странах.
РФ в этом плане отличается тем, что хватает «моду» то от ЕС, то США, то Японии и Ю.Кореи, и при этом как то переиначивая или смешивая.
Побывав хоть раз заграницей, и проанализировав понимаешь, что там всё другое — перестаешь мерять категориями «лучше-хуже», а всё больше «похоже-непохоже» к привычному.
в России «специальные инструменты» оказываются массовым явлением.Особенности менталитета «любить так королеву». Простой пример, куча народа ставят себе сразу проф.решение — фотошоп. И пофигу, что мало кому реально нужен. Тоже самое в железе, недавно забирая заказ в комп.магазине, видел как младшекласснику у взяли «для уроков» Ryzen 7 1700 с 32Gb. Хорошо хоть не тредрипер.
РФ в этом плане отличается тем, что хватает «моду» то от ЕС, то США, то Японии и Ю.Кореи, и при этом как то переиначивая или смешивая.Но ни в США, ни в Японии, ни в Ес ни в Ю.Корее Опера никогда не занимала более 10% рынка!
Может быть.в России «специальные инструменты» оказываются массовым явлением.Особенности менталитета «любить так королеву».
Побывав хоть раз заграницей, и проанализировав понимаешь, что там всё другое — перестаешь мерять категориями «лучше-хуже», а всё больше «похоже-непохоже» к привычному.Ну если «побывать хоть раз». Я как раз много где бывал (в Ю. Корее не бывал, правда, но в ЕС, США, Японии и даже Австралии приходилось по работе бывать) и нигде не видел даже попыток использования «специальных инструментов для специальных целей» в качестве замены обычному ноуту. То есть да, если вам нужно собирать какую-то статистику целый день «в полях», то у вас может быть нетбук для этого, а то и какая-нибудь Zebra… но её не будут приспосабливать под замену лаптопу! Именно потому что это «специальный инструмент для специальных целей»!
А в России — это нормально.
нигде не видел даже попыток использования «специальных инструментов для специальных целей» в качестве замены обычному ноуту. То есть да, если вам нужно собирать какую-то статистику целый день «в полях», то у вас может быть нетбук для этогоВы реально не понимаете к чему я это описываю?
Хорошо, говорю прямо — после опыта использования 3 ноутбуков, 2 нетбуков и планшета (х86), я определился — нетбук оптимален. Он значительно мощнее и автономнее планшета, с полными возможностями полноценного пк(ноутбука). У теперь меня нет никакого желания таскать с собой, что либо тяжелее чем кило(при том что чуть меньше половины это вес аккумулятора) и размером более 12".
И я понимаю тех кто так решил так же.
Почему так не происходит в других странах?
Допустим, там это не продвигалось и достаточное кол-во людей не смогли не смогли оценить удобство, что б это стало массовым.
Почему Опера?
Первый из массовых браузеров который лет 10 назад сделал, то что очень популярно последние годы. Например: запоминать вкладки, блокировать рекламу, пасс.менеджер, очистку куки(приват.мод нынче зовётся). И то, чего до сих пор не могут современные браузеры, например умная работа с кешем, возможность включать/отключать активный контент(js,gif) в 2-3 клика и многое другое как опции самого браузера с соответсвующей высокой скоростью работы, а не плагинами (которые тоже можно).
И это описание, всего лишь, версии 9.
Всё еще интересно? Стоит глянуть версию 11, которую не пустили в мир.
Foxit Reader у 100% наших сотрудников, где бухгалтеров намного меньше половины.
сайты. я лично всецело поддерживаю автора в контексте сайтов.
когда страничка съедает у тебя ядро целиком на какую-то фоновую активность (нет, не майнинг), или просто заставляет браузер на телефоне падать — это диагноз.
а если такое происходит на сайте компьютерного магазина — то это вообще тушите свет. сдох комп, открываешь с телефона сайт любимого магазина — а телефон от всех украшательств и аякса тупо падает…
когда страничка съедает у тебя ядро целиком на какую-то фоновую активность (нет, не майнинг), или просто заставляет браузер на телефоне падать — это диагноз.
а если такое происходит на сайте компьютерного магазина — то это вообще тушите свет. сдох комп, открываешь с телефона сайт любимого магазина — а телефон от всех украшательств и аякса тупо падает…
а если такое происходит на сайте компьютерного магазина — то это вообще тушите свет. сдох комп, открываешь с телефона сайт любимого магазина — а телефон от всех украшательств и аякса тупо падает…И что вы после этого делаете? Идёте на сайт другого магазина или включаете-таки комп?
В конечном итоге магазину нужны продажи, а не экономия батарейки на вашем телефоне. Если покупателей, которые уйдут из-за того, что телефон «не тянет» будет достатончо много — ну выделят ресурсы, чуток адаптивности убавят, может фоновое видео на телефонах выключат.
Но будет сделано ровно столько, чтобы у большинства посетеителей сайт стал работать, не больше, не меньше.
Никто заморачиваться с поддержкой какого-нибудь KitKat'а не будет. Не окупится.
я ушел на сайт другого магазина. в первую очередь потому что мне надо было купить замену чему-то сдохшему в компе.
да, речь идет про Олди нескольких лет давности — они выкатили омг модный аяксовый сайт, когда нетбуки на атоме были в ходу и в общем-то не сильно и тормозили. и нет, мобильной версии там НЕБЫЛО.
да, речь идет про Олди нескольких лет давности — они выкатили омг модный аяксовый сайт, когда нетбуки на атоме были в ходу и в общем-то не сильно и тормозили. и нет, мобильной версии там НЕБЫЛО.
да, речь идет про Олди нескольких лет давности — они выкатили омг модный аяксовый сайт, когда нетбуки на атоме были в ходу и в общем-то не сильно и тормозили. и нет, мобильной версии там НЕБЫЛО.При этом, насколько я вижу, «модный AJAX» у них остался и они вполне себе продолжают существовать, так что вас таких явно недостаточно много, чтобы вы могли «сделать погоду».
Речь же не о том, кому что нравится, а о том, сколько народу привлечёт «модный AJAX» и сколько народу уйдёт из-за того, что он не работает на их мобильнике.
сейчас у них уже третья версия сайта — которая еще и быстрее той, о которой я говорил.
ну и потом был эпичный факап твиттера, который в одной из итераций отдавал кучу JS и JSON, а все рендерилось на компах пользователей… правда недолго, их разве что с говном не съели за это и пришлось нови модни клеви технологии откатывать обратно до серверного рендеринга.
ну и потом был эпичный факап твиттера, который в одной из итераций отдавал кучу JS и JSON, а все рендерилось на компах пользователей… правда недолго, их разве что с говном не съели за это и пришлось нови модни клеви технологии откатывать обратно до серверного рендеринга.
сейчас у них уже третья версия сайта — которая еще и быстрее той, о которой я говорил.Но произошло ли это потому, что народ стал уходить… или потому что «оно» перестало помещаться в компьютеры их пользователей? Напомню, что в 2016м, наконец-то, они перекочевали из сумок в карманы.
ну и потом был эпичный факап твиттера, который в одной из итераций отдавал кучу JS и JSON, а все рендерилось на компах пользователей… правда недолго, их разве что с говном не съели за это и пришлось нови модни клеви технологии откатывать обратно до серверного рендеринга.Такое тоже бывает. Но зачастую проблема не в потреблении ресурсов, а просто в привычках пользовалей. Пример: Windows 7 => Windows 8 => Windows 10. В этом случае тоже пришлось всё откатывать — но не потому, что нови модни клеви технологии потребляли больше ресурсов. А потому что люди хотели старих, звичних.
да там что угодно вплоть до того, что кто-то из начальства таки зашел туда с телефона...:)
и нет, я говорю именно про пожирание ресурсов, а не смену привычек.
и нет, я говорю именно про пожирание ресурсов, а не смену привычек.
А что именно откатили в Windows 10? Проводник сделали не таким убогим, как в Win7? Так это скорее шаг обратно к XP даже. Меню Пуск немного вернули как было, это да. А остальное всё не вернули. Даже Aero Glass.
KitKat как бы довольно новая ОС. Меня вот плохая поддержка сайтами и приложениями Gingerbread беспокоит, а вы KitKat ругаете… =)
Не знаю, как vorphalack, а я иду на сайт другого магазина.
Особенно удивляет тут Google Hangouts в Google Chrome, в котором анимация говорящего собеседника (двигающийся в такт голосу ореол вокруг аватара) сжирает 100% ЦП. Аудиозвонки жрут больше ресурсов, чем видеозвонки, ололо! Причём в Firefox ЦП жрётся гораздо меньше (в тех редких случаях, когда Hangouts удаётся запустить в Firefox: обычно гугл перекидывает на страницу, на которой объясняет, что ложил большой и толстый на конкуренцию браузеров и пользуйтесь хромом — я тут д'Артаньян монополист)
занимает более-менее все ресурсы
Добро пожаловать в двадцать первый век! У нас тут в 2018 году господствуют многозадачные ОС, у меня прямо сейчас запущен 271 процесс, которые можно условно поделить на примерно 35 задач, например. Лично мне совершенно не хотелось бы, чтобы каждый из них пытался забрать «более-менее все ресурсы». А компьютером, который способен запустить максимум одну задачу, выжирающую «более-менее все ресурсы», пользоваться не очень удобно.
Лично мне совершенно не хотелось бы, чтобы каждый из них пытался забрать «более-менее все ресурсы»И? Что дальше?
А компьютером, который способен запустить максимум одну задачу, выжирающую «более-менее все ресурсы», пользоваться не очень удобно.Согласен. Но как вы решаете эту проблему? Переходите с поделок на Electronе на что-то «быстрое и лёгкое»? Или покупаете ноут с 32GiB памяти вместо обычных для «двадцать первого века» 4GB-8GB?
У нас тут в 2018 году господствуют многозадачные ОС, у меня прямо сейчас запущен 271 процесс, которые можно условно поделить на примерно 35 задач, например.И как много из этих «процессов» были выпущены в 2018м году? Я тут посмотрел — очень много программ, которыми я пользуюсь появились 3, 5, 10, 20 лет назад. Тогда, когда они появились — они занимали компьютер целиком или почти целиком. Но после того, как компьютеры стали поставляться не с 64MiB RAM, а с 64GiB RAM — да, появилась возможность запускать сотни таких.
Но когда выходит что-нибудь принципиально новое — оно, в основном, делается так, чтобы вписаться в имеющееся у пользователя железо. Не больше, но и не особо меньше. На какой-нибудь Slack посмотрите…
Переходите с поделок на Electronе на что-то «быстрое и лёгкое»?
Да. Если полистать мои комментарии на хабре, можно увидеть, что они пропитаны концентрированной ненавистью к Electron'у и вообще вебу в целом)
Тогда, когда они появились — они занимали компьютер целиком или почти целиком.
Ну не знаю, мессенджеры у меня вроде бы никогда не занимали компьютер «целиком». Аудиоплееры тоже. Да и браузеры были гораздо скромнее чем сейчас при схожих возможностях. Разве что игры занимали компьютер «целиком», но они тот редкий случай, когда действительно можно (хотя я всё равно отдаю предпочтение «скромным» играм, обычно вышедшим те самые ~10 лет назад — другие мои 35 задач тоже оперативку хотят всё-таки).
На какой-нибудь Slack посмотрите…
На какой-нибудь Telegram посмотрите ;) Согласно википедии, запущен в один месяц со Slack, а ресурсов жрёт раз в десять меньше.
Ну не знаю, мессенджеры у меня вроде бы никогда не занимали компьютер «целиком».Вы наверное официальным клиентом ICQ не пользовались. Вот он — норовил не то что целиком компьютер занять, а в своп его загнать.
Да и браузеры были гораздо скромнее чем сейчас при схожих возможностях.К сожалению возможности далеко не «схожие». Попробуйте зайти каким-нибудь Netscape 3 или 4 на современные web-сайты и посмотрите — сколько из них вообще чего-либо покажут. То, что интерфейс браузеров мало изменился (три кнопки да окошко Location) не говорит о том, что у «внутри» всё осталось по старому.
Да. Если полистать мои комментарии на хабре, можно увидеть, что они пропитаны концентрированной ненавистью к Electron'у и вообще вебу в целом)Но выливается ли ваще мнение и мнение таких же, как вы в экономическую нецелесообразность использования моструозных поделок типа Electronа? Вот в чём вопрос.
На какой-нибудь Telegram посмотрите ;) Согласно википедии, запущен в один месяц со Slack, а ресурсов жрёт раз в десять меньше.Прекрасный пример!
Slack — Slack стал самым быстрорастущим бизнес-приложением в истории.
Telegram — В феврале 2016, Телеграм рапортовал, что у него — 100 миллионов активных пользователей
Супериллюстрация моего тезиса, не так ли?
Спасибо за актуальный пример. Хотя и сложный для сравнения.
Легко видеть что и когда нужно использовать, если исходить из экономической целесообразности, не так ли? Slack просто «удавил» всех конкурентов. А Telegram… всё ещё отстаёт в десяток раз от них.
P.S. Вообще если вы посмотрите на мои посты, то вы увидите то же самое отвращение к современным фреймворкам. Потребление ресурсов, размеры, и прочее. Ужас-ужас-ужас. Но… это не мешает мне замечать, что если вы хотите делать что-то успешное — то вам придётся их использовать. Если вы что-то делаете «для себя», «для души» — дело другое. Тут я никогда в жизни использовать Electron не стану. Но если это «на заказ»… глупо выбирать что-то, что принесёт тебе, в конечном итоге, меньше денег…
Вы наверное официальным клиентом ICQ не пользовались.
Да, QIP 2005 вёл себя вполне скромно :)
Попробуйте зайти каким-нибудь Netscape 3 или 4 на современные web-сайты и посмотрите — сколько из них вообще чего-либо покажут.
То, что, простите, кровати в борделе подвигали и сломали совместимость, не говорит о том, что что-то принципиально поменялось. Вот что принципиально нового появилось в браузерах за последние лет десять? Аудио, видео, WebGL, WebRTC — ну и всё в принципе. Но это всё используется мало кем, разве что ютуб какой-нибудь или скайп. Тот же Хабрахабр ничего из перечисленного не использует и продолжает работать абсолютно так же, как и работал десять лет назад, ну разве что пару редизайнов пережил. Но если это никто не использует, то куда тогда делись гигабайты памяти? Неужели в реализацию border-radius и rgba? Ладно, я согласен выделить мегабайт 50 на кэширование тайлов, чтоб 60фпс при плавной прокрутке поддерживать и на плавный CSS3 transition, а остальное-то куда делось?
то есть даже одного миллиона ещё нет
Сравнивать число активных и число новых пользователей — как вы до такой глупости вообще додумались? Из новой версии комментария это пропало, но теперь конкретных чисел вообще нет.
А на какой планете QIP 2005 был оффициальным клиентом ICQ, я извиняюсь?Вы наверное официальным клиентом ICQ не пользовались.Да, QIP 2005 вёл себя вполне скромн
Вот что принципиально нового появилось в браузерах за последние лет десять? Аудио, видео, WebGL, WebRTC — ну и всё в принципе.А что — для того, чтобы потребовалось больше ресурсов нужно что-то принципиально новое? Да одних свойств всяких CSS3/CSS4 появились десятки! Всякие единицы измерения типа vw или vmax, :before и :after и прочее, прочее, прочее — всё это требует поддержки.
Тот же Хабрахабр ничего из перечисленного не использует и продолжает работать абсолютно так же, как и работал десять лет назад,Точно-точно? Вы 10 лет назад пробовали «File->Save As» сделать? Оно тогда тоже 5MB занимало? И всякие :before :after активно использовало? MS IE 6 половину CSS, который используется современным Хабром не понимает, знаете ли…
ну разве что пару редизайнов пережилУгу. И в результате этих редизайнов страница стала состоять не из нескольких тысяч обьектов и атрибутов, а из полумиллиона.
Ладно, я согласен выделить мегабайт 50 на кэширование тайлов, чтоб 60фпс при плавной прокрутке поддерживать и на плавный CSS3 transition, а остальное-то куда делось?Посмотрите на DOM-дерево этой стараницы, на котни килобайт CSS (а оно ведь каскадное!) и мегабайты JavaScript'а — и всё увидите.
Сравнивать число активных и число новых пользователей — как вы до такой глупости вообще додумались?Извиняюсь, тут прокол, да. Не туда посмотрел.
Напрямую их сравнивать вообще нельзя, так как это продукты разных классовов. Но можно заметить, что Slack обошёл всех конкуретнов, в том числе вышедших задолго до его появления. А Telegram — всё ещё отстаёт.
А на какой планете QIP 2005 был оффициальным клиентом ICQ, я извиняюсь?
А на какой планете официальным клиентом ICQ хоть кто-нибудь пользовался, я извиняюсь? А на какой планете ICQ со своим тяжёлым клиентом не сдохла в 2010-м, продавшись мэйлрушечке, я извиняюсь? ICQ — как раз очень наглядный пример, что ресурсы надо было экономить и с агрессивной рекламой не играться :)
Да одних свойств всяких CSS3/CSS4 появились десятки!
И что, всем им гигабайты оперативки нужны? Не, не верю.
Точно-точно?
Перечислите хотя бы пять принципиальных отличий старого хабра от нового, влияющих на потребление ресурсов, не считая дизайна? На :before и :after мне как пользователю плевать (сайты и без них успешно делали), а как разработчик я могу обходиться и без них. Они, к слову, были ещё в IE8 в 2009-м (под который я, кстати, успешно верстаю по сей день, просто потому что могу. Ну да, border-radius не работает, ну и что).
Посмотрите на DOM-дерево этой стараницы, на котни килобайт CSS (а оно ведь каскадное!) и мегабайты JavaScript'а — и всё увидите.
Ещё раз: где принципиальные отличия от хабра десятилетней давности? Зачем килобайты JavaScript'а превратились в мегабайты? От каскада, кстати, нынче модно отказываться, БЭМ и всё такое.
А на какой планете официальным клиентом ICQ хоть кто-нибудь пользовался, я извиняюсь
На Земле. Вполне себе используется в качестве корпоративного мессенджера (из 20 контаков, правда, всего 2 официальцых — новых, без рекламы, штуки 3 Миранд и остальное Кип. Клиент значительно легче скайпа и исторически используется, а переходить на новый смысла нет — везде нужен телефон (в аське до сих пор нет, если не менять пароль), выбрать единый новый никак — всякие вайберы, да телеграммы с вотсапами — у каждого свой набор.
Угу. И в результате этих редизайнов страница стала состоять не из нескольких тысяч обьектов и атрибутов, а из полумиллиона.
Эх, печально, если так. Читал как-то одну интересную статью про влияние числа элементов в DOM на производительность. Статья правда старая, 2010-2011 год. Так вот из статьи следовало, что тормоза начнутся уже при 70-80 тысячах, если не ошибаюсь… Я конечно в курсе, что сейчас и железо мощнее, и браузеры другие. Но зачем? Зачем такие монструозные сайты делать, если можно реализовать то же самое, но компактнее и легче.
Вот что принципиально нового появилось в браузерах за последние лет десять
Например, возможность заставить сайт откликаться на изменение размера окна почти без лишних ухищрений, но именно это и ломает совместимость.
Аудио, видео, WebGL, WebRTC — ну и всё в принципе.
Браузер стал мультиплатформерной средой разработки приложений.
Покажите мне еще хоть одну такую же, которая жрет меньше памяти.
Мне, например, удобно когда я могу в gmail назначить митинг, он отобразится в соседней вкладке в календаре, а если нажать на ссылку то откроется hangouts и я увижу всех собеседников по камере (а если станет скучно, можно еще и хабр тут же полистать, или параллельно что-нибудь в консоли AWS настроить и т.п.)
Я не хотел бы устанавливать по 100500 приложений на свой компьютер на каждый чих или мега-монструозные пакеты приложений от гугла и т.п.
Не думаю что мир без современных браузеров был бы гарантировано лучше.
ПС
Помню несколько лет назад все смеялись над текстовыми редакторами на электроне, тем временем VSCode сейчас жрет меньше памяти и работает шустрее чем тот же webstorm
Браузер стал мультиплатформерной средой разработки приложений.
И это отвратительно. О чём я в общем-то уже не раз высказывался на хабре, да и не только я. Можно было поадекватнее платформу придумать.
Покажите мне еще хоть одну такую же, которая жрет меньше памяти.
Android? Там даже запуск приложений без установки вроде где-то завозили.
Мне, например, удобно когда я могу в gmail назначить митинг, он отобразится в соседней вкладке в календаре, а если нажать на ссылку то откроется hangouts и я увижу всех собеседников по камере (а если станет скучно, можно еще и хабр тут же полистать, или параллельно что-нибудь в консоли AWS настроить и т.п.)
Это всё может любая нормальная ОС, будь под неё соответствующие приложения.
Я не хотел бы устанавливать по 100500 приложений на свой компьютер на каждый чих или мега-монструозные пакеты приложений от гугла и т.п.
Тем не менее вы это постоянно делаете в браузере. Чем скачивание кучи мегабайт пожатых джаваскриптов с последующим их кэшированием принципиально отличается от установки? Разве что кнопочку «Установить» кликать не надо — ну так никто не запрещает сделать аналогично где-нибудь на уровне ОС или просто платформе более адекватной чем браузер, только все прицепились к браузерам и никому это не нужно теперь.
Не думаю что мир без современных браузеров был бы гарантировано лучше.
А я думаю. Всё, что сейчас происходит в браузерах, можно было сделать и альтернативными способами без браузеров, причём более адекватными.
несколько лет назад все смеялись над текстовыми редакторами на электроне
Я и сейчас смеюсь, особенно когда выходят новости про мигающий курсор, кушающий 13% процессора)
Не, ну что-то в этом всё же есть: унификация, кроссплатформенность, все дела. Я как раз за те возможности, что дают сейчас онлайн-сервисы, это очень круто. Кстати, такой вариант ещё и безопаснее чем Ваш, с установкой нативных приложений — меньше шансов скачать малварь под видом официального приложения и нечаянно её установить. Браузеры же весьма хорошо изолируют скрипты, доступа к ФС прямого нет, всё относительно (повторяю, относительно) безопасно.
Но вот пресловутый Электрон… Это уже лишнее, я согласен. Если можно сделать что-то нативно на C/C++, это будет не сильно сложнее в разработке, а работать будет быстрее — нужно так и делать.
Но вот пресловутый Электрон… Это уже лишнее, я согласен. Если можно сделать что-то нативно на C/C++, это будет не сильно сложнее в разработке, а работать будет быстрее — нужно так и делать.
> О чём я в общем-то уже не раз высказывался на хабре, да и не только я. Можно было поадекватнее платформу придумать.
Видите ли, браузер именно как мультиплатформенную среду разработки никто не придумывал. Он сам, естественным образом таковой стал. За неимением альтернатив. Никакие другие варианты не дают даже близко подобной доступности и легкости разворачивания у клиента.
> Это всё может любая нормальная ОС, будь под неё соответствующие приложения.
В том и преимущество веба, что вам не надо ставить никаких дополнительных приложений. Вам достаточно одного единственного браузера.
> Тем не менее вы это постоянно делаете в браузере. Чем скачивание кучи мегабайт пожатых джаваскриптов с последующим их кэшированием принципиально отличается от установки?
Тем, что в случае веба вы никак не можете заметить скачивания пожатых джаваскриптов с их кешированием и никаких специальных телодвижений для этого не совершаете.
> Всё, что сейчас происходит в браузерах, можно было сделать и альтернативными способами без браузеров, причём более адекватными.
Так сделайте, кто вам мешает?
Видите ли, браузер именно как мультиплатформенную среду разработки никто не придумывал. Он сам, естественным образом таковой стал. За неимением альтернатив. Никакие другие варианты не дают даже близко подобной доступности и легкости разворачивания у клиента.
> Это всё может любая нормальная ОС, будь под неё соответствующие приложения.
В том и преимущество веба, что вам не надо ставить никаких дополнительных приложений. Вам достаточно одного единственного браузера.
> Тем не менее вы это постоянно делаете в браузере. Чем скачивание кучи мегабайт пожатых джаваскриптов с последующим их кэшированием принципиально отличается от установки?
Тем, что в случае веба вы никак не можете заметить скачивания пожатых джаваскриптов с их кешированием и никаких специальных телодвижений для этого не совершаете.
> Всё, что сейчас происходит в браузерах, можно было сделать и альтернативными способами без браузеров, причём более адекватными.
Так сделайте, кто вам мешает?
Он сам, естественным образом таковой стал.
Поэтому он и получился таким говном. Любому здравомыслящему человеку, понимающему в компах, очевидно, что платформу нужно переделать по-нормальному с нуля. Но об этом см. ниже.
Вам достаточно одного единственного браузера.
А должно быть достаточно одной-единственной ОС. ОС — это и так абстракция от железа, нафига городить абстракцию от абстракции, именуемую браузером?
Тем, что в случае веба вы никак не можете заметить скачивания пожатых джаваскриптов с их кешированием и никаких специальных телодвижений для этого не совершаете.
Ничто не мешает делать это на уровне ОС.
Так сделайте, кто вам мешает?
Мешает легаси. Всё уже повязано на браузерах. Даже если я и сделаю что-нибудь, никто это использовать не станет, потому что всё сделано уже под браузеры. Это постоянно тормозит прогресс: также фигня с архитектурами процессоров, с третьим питоном, с Win32 и так далее.
Поэтому всё, что таким как я остаётся, — ныть в комментах. Чем я и занимаюсь.
> Любому здравомыслящему человеку, понимающему в компах, очевидно, что платформу нужно переделать по-нормальному с нуля.
Конечно. Как будете решать проблему обратной совместимости?
> А должно быть достаточно одной-единственной ОС. ОС — это и так абстракция от железа, нафига городить абстракцию от абстракции, именуемую браузером?
Ну вот так вышло, что имеющиеся в наличии ОС не предоставляют абстракции от железа. В итоге функцию подобных ОС выполняет браузер. Считайте, что браузер — это и есть ОС, запущенная в виртуалке.
> Ничто не мешает делать это на уровне ОС.
Так напишите свою браузеро-ос.
> Мешает легаси. Всё уже повязано на браузерах. Даже если я и сделаю что-нибудь, никто это использовать не станет, потому что всё сделано уже под браузеры.
> Поэтому всё, что таким как я остаётся, — ныть в комментах.
И использовать то, что есть (браузер вместо ОС). Правильно?
Конечно. Как будете решать проблему обратной совместимости?
> А должно быть достаточно одной-единственной ОС. ОС — это и так абстракция от железа, нафига городить абстракцию от абстракции, именуемую браузером?
Ну вот так вышло, что имеющиеся в наличии ОС не предоставляют абстракции от железа. В итоге функцию подобных ОС выполняет браузер. Считайте, что браузер — это и есть ОС, запущенная в виртуалке.
> Ничто не мешает делать это на уровне ОС.
Так напишите свою браузеро-ос.
> Мешает легаси. Всё уже повязано на браузерах. Даже если я и сделаю что-нибудь, никто это использовать не станет, потому что всё сделано уже под браузеры.
> Поэтому всё, что таким как я остаётся, — ныть в комментах.
И использовать то, что есть (браузер вместо ОС). Правильно?
Любому здравомыслящему человеку, понимающему в компах, очевидно, что платформу нужно переделать по-нормальному с нуля.
Любому здравомыслящему разработчику яснее ясного что переписывание проекта такого масштабного с нуля — путь в никуда.
А должно быть достаточно одной-единственной ОС. ОС — это и так абстракция от железа, нафига городить абстракцию от абстракции, именуемую браузером?
Потому-что сейчас не 1988 год и куча всего в индустрии поменялось, появилось больше слоев абстракций.
Даже если я и сделаю что-нибудь, никто это использовать не станет
Нет, тут надо не сделать «что-нибудь», а сделать то же что сейчас делает браузер, только не «тормозит», в этом же ваше основное недовольство заключается?
Любому здравомыслящему разработчику яснее ясного что переписывание проекта такого масштабного с нуля — путь в никуда.
Я об этом и говорил, ага. https://habrahabr.ru/post/350432/#comment_10698798
появилось больше слоев абстракций.
Любому здравомыслящему человеку понятно, что абстракций стало слишком много.
сделать то же что сейчас делает браузер, только не «тормозит», в этом же ваше основное недовольство заключается?
Ага, но любой здравомыслящий человек понимает, что этим не будут пользоваться, потому что без поломки обратной совместимости этого не сделать, а ломать обратную совместимость не получится из-за легаси https://habrahabr.ru/post/350432/#comment_10698798
Так и живём.
Android?
Запустите мне Андроид-приложение на маке, винде и линуксе, так чтобы оно везде одинаково выглядело и все АПИ работали (оповещения и т.д.)
Понимаете почему это не то же самое?
Это всё может любая нормальная ОС, будь под неё соответствующие приложения.
Поправка, это может не ОС — а сами приложения. Только тут опять же проблема установки 100500 разных приложений. А если у меня дома другая операционка? Тогда 201000 разных приложений нужно?
Чем скачивание кучи мегабайт пожатых джаваскриптов с последующим их кэшированием принципиально отличается от установки?
Многим.
Размером — размер меньше чем если бы мне нужно было еще скачивать оболочку, локальные настройки, библиотеки и прочее что может понадобиться программе.
Скоростью загрузки — для веба считается плохим тоном если страница грузится дольше 3х секунд, десктопные приложения таким не очень парятся обычно.
Безопасностью — программа работающая в браузере гораздо безопаснее программы имеющей доступ ко всей системе.
Портативностью — абсолютное большинство современных веб-приложений являются «responsive»
Унифицированностью — в браузере я всегда могу выделить текст, сделать зум, сохранить картинку, нажать CTRL+F и т.д. Это дорогого стоит…
Мультиплатформерностью — мне не надо скачивать отдельную программу для каждого своего девайса и операционки.
Думаю можно ещe придумать, но этого должно быть достаточно.
ну так никто не запрещает сделать аналогично где-нибудь на уровне ОС или просто платформе более адекватной чем браузер
КАКОЙ?? У вас есть ответ?
Всё, что сейчас происходит в браузерах, можно было сделать и альтернативными способами без браузеров, причём более адекватными
Какой это способ? Делать отдельное приложение под каждую операционку? Для кого это решениe «более адекватное»?
Я и сейчас смеюсь, особенно когда выходят новости про мигающий курсор, кушающий 13% процессора
Согласен, это довольно смешно, но зацикливаться на этом я бы не стал…
для веба считается плохим тоном если страница грузится дольше 3х секунд,
Хабрахабр, к стати, не укладывается в это время — хром показывает чуть больше 3000 мс (при том, что считать начинает от первого ответа, а до того момента сайт еще полсекунды думает).
По сабжу — все почему-то забывают что браузерное приложение (внезапно!) требует интернет для работы. Зачастую даже для тех функций, которые не требуют какой-то реальной работы с сервером. А интернет до сих пор даже в развитых странах не везде хороший (мобильный или публичные вайфаи)
Понимаете почему это не то же самое?
Нет, не понимаю. Андроид нынче ставится почти на любую железку. Для ПК есть Android-x86. То, что под андроид нет всяких фотошопов — уже не проблемы ОС.
Вообще, я предлагаю андроид не как готовое решение, а как примерную реализацию того, как это могло бы выглядеть в идеале. Понято, что конкретно текущий андроид делается для мобильников и полноценные фотошопы на нём вряд ли появятся в ближайшее время и на андроиде даже обычная мышка работает криво, но теоретически допилить ничего не мешает-то.
Если вы захотите мне возразить, что ОС бывают разные и идея единой ОС не прокатит — я вам напоминаю, что в вебе всё абсолютно то же самое! Браузеры бывает разные, Chrome впереди планеты всей, Firefox в догоняющих, Edge выпендривается, а Safari просто слоупочит. Ничем не лучше разных ОС. Ну или разве что тем, что есть единые стандарты HTML/CSS/JS — ну так никто не мешает повторить это на уровне ОС, тем более POSIX уже был.
Размером
Если вы заглянете в любой репозиторий любого линукс-дистрибутива, то увидите, что средний размер программы — даже с гуем — в пределах нескольких мегабайт, а иногда что-нибудь дельное бывает запихнуто и в десятки килобайт. У андроида вроде как вообще запрет на программы более 100 мегабайт ЕМНИП. Ну а для реально больших программ (фотошопы, игры) ничто не мешает скачивать только нужные в данный момент части — как это и происходит в вебе сейчас.
Скоростью загрузки… десктопные приложения таким не очень парятся обычно.
Но запариться ничего не мешает. Кроме лени.
Безопасностью
Я нигде не предлагал открывать приложениям доступ ко всей системе. Опять же глядим на андроид: приложения весьма неплохо разделены даже без контейнеров, а если подключить контейнеры, то безопасность вообще впереди планеты всей (вот бы уязвимостей ещё не было...)
Портативностью — абсолютное большинство современных веб-приложений являются «responsive»
Опять же, ничто не мешает повторить для десктопа.
Унифицированностью
А вот тут да. Но на всякий случай напомню, что если всё отрисовывается в канвасе, то облом :)
Мультиплатформерностью
Снова смотрим на андроид.
Думаю можно ещe придумать, но этого должно быть достаточно.
Убедительно выглядит только унифицированность, так что недостаточно)
КАКОЙ?? У вас есть ответ?
Сделать новую платформу, очевидно. Но делать это бессмысленно, потому что легаси — см. https://habrahabr.ru/post/350432/#comment_10698798
Андроид нынче ставится почти на любую железку.
Согласен, но это не то же самое что «могу меньше чем за минуту открыть любое приложение на любой ОС»
Если вы заглянете в любой репозиторий любого линукс-дистрибутива, то увидите, что средний размер программы — даже с гуем — в пределах нескольких мегабайт
В вебе то же самое — весь основной «вес» уже заложен в платформе.
Я нигде не предлагал открывать приложениям доступ ко всей системе. Опять же глядим на андроид
Ну, честно говоря, на Андроиде отключение permision'ов нe очень очевидно (по крайней мере до последних версий)
Так то я с вами согласен, имеем то что имеем и могло бы быть лучше. Но мнe кажется, в целом все не так уж плохо как вы описываете.
Java SE спешит на помощь! :)
Пишем приложение на Java, получаем JAR файл, запускаем на любой ОС. Имеем логику и GUI. Если очень надо — можно сверху надстройки небольшие сделать для разных ОС, типа инсталляторов с возможностью создания ярлыков и добавления в каталог установленных программ. Всё)
Не, если у нас что-то сложное, где нужно на низком уровне работать с железом — тогда мимо. Но в остальных-то случаях (те же мессенджеры, аудиоплееры, визуальные редакторы) — чем не вариант?
Пишем приложение на Java, получаем JAR файл, запускаем на любой ОС. Имеем логику и GUI. Если очень надо — можно сверху надстройки небольшие сделать для разных ОС, типа инсталляторов с возможностью создания ярлыков и добавления в каталог установленных программ. Всё)
Не, если у нас что-то сложное, где нужно на низком уровне работать с железом — тогда мимо. Но в остальных-то случаях (те же мессенджеры, аудиоплееры, визуальные редакторы) — чем не вариант?
Какой-то портал статистики (https://www.statista.com/statistics/652779/worldwide-slack-users-total-vs-paid/), первый в выдаче гугла, говорит что у слака 6 миллионов пользователей в сентябре 2017 года. Возможно, они и самый быстро-растущий проект, но до телеграма ещё ой как далеко.
Слак не корректно сравнивать с телеграмом. Слак для работы — а не с друзьями просто так трепаться (и не бесплатный к тому же).
Что у них на главной написано: slack.com
Что у них на главной написано: slack.com
То-то я смотрю Skype долю свою теряет уже который год кряду. Мобильная версия всегда была ужасно тормозной. Десктопная версия была ещё терпимой, но тут они выкатывают свеженькую 8.x, которая — такой же тормозящий монстр, как и мобильная версия. Я то надеялся, что они пилят новую версию — это оптимизируют, хотят сделать быстрой и удобной. Но нет, похоже что руководство Microsoft думает, что люди бегут со Skype не из-за тормозов и багов, а из-за недостаточно яркой раскраски сообщений.
Slack не использовал никогда. Судя по Google Trends, Telegram в 2 раза популярнее Slack. В моём окружении популярностью пользуются Viber (среди мам, пап и других родственников) и Telegram (среди более продвинутой аудитории). Некоторые контакты в Skype уже всегда неактивны. Чем-то напоминает ICQ, откуда когда-то люди активно мигрировали в Skype. Многие используют Skype только потому что он используется на работе, поэтому достучаться до человека через Skype можно только в рабочее время.
Вы упомянули Netscape. Это тоже хороший пример. Он проиграл войну браузеров не потому что IE был встроен в систему (как много людей использует встроенный IE/Edge сейчас?), а потому что Netscape был тормозящим и глючащим монстром, а IE версий 5 и 6 был прорывным (сильно опережающим время, соответственно и станадрты) и быстрым браузером для своего времени, у которого просто не было адекватных конкурентов.
Slack не использовал никогда. Судя по Google Trends, Telegram в 2 раза популярнее Slack. В моём окружении популярностью пользуются Viber (среди мам, пап и других родственников) и Telegram (среди более продвинутой аудитории). Некоторые контакты в Skype уже всегда неактивны. Чем-то напоминает ICQ, откуда когда-то люди активно мигрировали в Skype. Многие используют Skype только потому что он используется на работе, поэтому достучаться до человека через Skype можно только в рабочее время.
Вы упомянули Netscape. Это тоже хороший пример. Он проиграл войну браузеров не потому что IE был встроен в систему (как много людей использует встроенный IE/Edge сейчас?), а потому что Netscape был тормозящим и глючащим монстром, а IE версий 5 и 6 был прорывным (сильно опережающим время, соответственно и станадрты) и быстрым браузером для своего времени, у которого просто не было адекватных конкурентов.
Вы упомянули Netscape. Это тоже хороший пример. Он проиграл войну браузеров не потому что IE был встроен в систему (как много людей использует встроенный IE/Edge сейчас?), а потому что Netscape был тормозящим и глючащим монстром, а IE версий 5 и 6 был прорывным (сильно опережающим время, соответственно и станадрты) и быстрым браузером для своего времени, у которого просто не было адекватных конкурентов.
Не надо только передергивать. Netscape, в отличии от современных браузеров, был платный. И его убило именно то, что IE(кстати далеко не 5 или 6 версия, а более ранняя) стала встроенным браузером по умолчанию в винде.
И его убило именно то, что IE(кстати далеко не 5 или 6 версия, а более ранняя) стала встроенным браузером по умолчанию в винде.
Ну, не совсем так. Нетскейп имел крайне лояльную аудиторию, и в разгар браузерной войны уже был бесплатный. Его убило то, что называется «бестолковая разработка». Они сначала пилили два года четвертую версию, потом увязли в ней, потом отказались от выпуска пятой, т.к. не смогли поддерживать существующий код, и начали писать шестую с нуля.
С таким подходом они сами себе не оставили ни единого шанса на конкуренцию.
Вы упомянули Netscape. Это тоже хороший пример. Он проиграл войну браузеров не потому что IE был встроен в систему (как много людей использует встроенный IE/Edge сейчас?), а потому что Netscape был тормозящим и глючащим монстром, а IE версий 5 и 6 был прорывным (сильно опережающим время, соответственно и станадрты) и быстрым браузером для своего времени, у которого просто не было адекватных конкурентов.Красивая теория, но… не срастается. То есть если бы вы продвигали свою теорию году так в 2001м — мне и ответить было бы нечего. Но после 2001го последовал 2002й, 2003й и так далее… и MS IE 6 начал терять рынок — его начали теснить ещё более монструозные Netscape 7-9, а дальше — чуть менее монструозный Firefox (он легче, чем Netscape 7, но по сравнению с MS IE 6 всё равно — монстр).
Так что нет — MS IE выиграл не потому, что он был легче, а потому что он был «фичастее». То, что он при этом оказался ещё и легче — это другая история: там экономикой и не пахло, там ставилась задача «убить Netscape, во сколько бы это ни обошлось» (это потом суды подтвердили).
Slack не использовал никогда. Судя по Google Trends, Telegram в 2 раза популярнее Slack.Slack и Telegram — они немножко о разном. Slack — это корпоративный мессенджер, не публичный. И он — самый популярный в своей категории с большим отрывом.
Сам ненавидел Electron, пока не попробовал Visual Studio Code. Скажем: VS Code c плагинами работает быстрее, запускается быстрее, и памяти жрёт меньше, чем менее функциональная IDE на Java (я не говорю об Eclipse). На удивление шустро работает, я бы сказал. Так что всё познаётся в сравнении.
Sublime Text 3 работает ещё быстрее, запускается ещё быстрее, памяти жрёт ещё меньше, функциональность при этом вроде как схожая при наличии соответствующих плагинов. VS Code — прожорливая тормознутость, всё познаётся в сравнении :)
При наличии плагинов, которых для Sublime Text под мои задачи нет, потому что это редактор, а не IDE. Всё-таки сравнивать надо яблоки с яблоками.
Я не люблю тормозные фреймворки, но я понимаю желание людей писать с использованием тех технологий, которыми они хорошо владеют (в данном случае — js, CSS), а также желание брать готовые отлаженные компоненты вместо написания велосипедов. Когда у них получается хороший продукт, могу только поприветствовать.
Я не люблю тормозные фреймворки, но я понимаю желание людей писать с использованием тех технологий, которыми они хорошо владеют (в данном случае — js, CSS), а также желание брать готовые отлаженные компоненты вместо написания велосипедов. Когда у них получается хороший продукт, могу только поприветствовать.
Я вот люблю писать велосипеды в целом, это интересно и расширяет навыки. Но в целом соглашусь, хорошо иметь IDE, к которой сам можешь написать плагин, потому что сама IDE на JS работает.
Кхм…
Так Visual Studio Code тоже редактор как и Sublime.
Так Visual Studio Code тоже редактор как и Sublime.
Таки Visual Studio Code — это тоже просто редактор кода. Сравнивать яблоки разных сортов вполне реально.
Сейчас погуглил — для него тоже есть плагины для тех целей, для которых мне понравилась Code, но степень их развитости отличается на два порядка. Это никоим образом не значит, что Sublime Text хуже как приложение, но говорит о степени развития экосистемы.
А ещё Sublime весь такой из себя нативный, что аж на Python написан. Не вижу принципиальной разницы.
А ещё Sublime весь такой из себя нативный, что аж на Python написан. Не вижу принципиальной разницы.
А ещё Sublime весь такой из себя нативный, что аж на Python написан
С чего это он на Python написан? Из-за того, что у него Python'овское API?
Сейчас погуглил — для него тоже есть плагины для тех целей, для которых мне понравилась Code, но степень их развитости отличается на два порядка.Оценивать степень развитости экосистемы по портированным плагинам — это так себе методика.
А ещё Sublime весь такой из себя нативный, что аж на Python написан.Нужно еще погуглить.
Оценивать степень развитости экосистемы по портированным плагинам — это так себе методика.
А по чём же ещё? Приложение А позволяет мне делать крутые вещи, а приложение Б — нет. При этом, я даже готов признать, что по некоторым объективным признакам приложение Б лучше. Но оно для меня бесполезно.
А по каким показателям вы предлагаете оценивать развитость экосистемы, как не по количеству плагинов под разные задачи, и качеству этих плагинов?
Приложение А позволяет мне делать крутые вещи, а приложение Б — нет.Может вы просто не нашли подходящий плагин? Это ведь не приложение делает, а именно сторонняя свистелка.
А по каким показателям вы предлагаете оценивать развитость экосистемы, как не по количеству плагинов под разные задачи, и качеству этих плагинов?Я говорил лишь о том, что неправильно ограничиваться поиском портированных плагинов.
На какой-нибудь Telegram посмотрите ;) Согласно википедии, запущен в один месяц со Slack, а ресурсов жрёт раз в десять меньше.
Просто используйте веб приложение для слака — оно от десктопного мало чем отличается.
Даже компьютер с 16мегабайтами уже можно было использовать с многозадачностью.
Главное дискетку не форматировать
Windows NT 4 сносно жила на 16 МБ, при этом:
— не тормозила на работе с дисководом ;)
— не вешалась от cli + jmp $ (cli + hlt)
— не тормозила на работе с дисководом ;)
— не вешалась от cli + jmp $ (cli + hlt)
95 + 16 Mb — нормально
98 + 16 Mb — медленно
NT4 + 48 Mb — нормально
То, с чем сталкивался лично
98 + 16 Mb — медленно
NT4 + 48 Mb — нормально
То, с чем сталкивался лично
NT4 на 16 Мб работала довольно бодро. Это её «родной» объем памяти. Система-то вышла, минуточку, в 1996-м году. Тогда 16 метров — это был объем памяти топового железа. Но сервиспаки для неё выходили вплоть до 1999-го года, и с ними и аппетиты системы росли. NT4 + SP6 уже для нормальной работы хотела хотя бы 32 метра.
И да, там можно было форматировать дискетку и одновременно слушать mp3.
И да, там можно было форматировать дискетку и одновременно слушать mp3.
Если речь не идёт об игре (которой я как пользователь могу отдать полностью весь ресурс своего железа) — я бы не хотел, чтобы какой-нибудь софт нагружал мой процессор на 20-30 процентов в фоне, когда я ничего не делаю. Или занимал просто так гигабайт RAM, просто потому, что хочет.
Браузеры сейчас примерно столько памяти и занимают, и даже больше. Но даже в этом случае я терпеть не могу сайты, который постоянно грузят процессор на 10-15 процентов или больше, будучи даже открытыми в фоновой вкладке. Потому что как минимум это лишнее электричество, за которое я плачу. А если комп старый — то ещё и дикие тормоза всего браузера.
Браузеры сейчас примерно столько памяти и занимают, и даже больше. Но даже в этом случае я терпеть не могу сайты, который постоянно грузят процессор на 10-15 процентов или больше, будучи даже открытыми в фоновой вкладке. Потому что как минимум это лишнее электричество, за которое я плачу. А если комп старый — то ещё и дикие тормоза всего браузера.
> У нас тут в 2018 году господствуют многозадачные ОС, у меня прямо сейчас запущен 271 процесс, которые можно условно поделить на примерно 35 задач, например.
Менеджить ресурсы между процессами — задач ОС, а не процессов. И мне вот не хотелось бы терять функционал приложений из-за того, что кто-то запускает его одновременно с 50 другими.
Менеджить ресурсы между процессами — задач ОС, а не процессов. И мне вот не хотелось бы терять функционал приложений из-за того, что кто-то запускает его одновременно с 50 другими.
Зачем терять-то? Нужно использовать ресурсы настолько по минимуму, насколько это возможно без ущерба для решаемой задачи. А ещё лучше, чтобы это было настраиваемым: тот же mysql может вполне скромно вести себя на дешёвом VDS с 512МБ оперативки или отжирать всё на мощной махине с 128ГБ оперативки. Ему можно: чем больше оперативки ему выделить, тем быстрее он будет выполнять запросы. А вот в то, что простенькому мессенджеру, передающему обыкновенный текст и отрисовывающему с десяток мелких аватарок, зачем-то нужно ресурсов больше, чем мускулю на дешёвом VDS, который там вполне неплохо работает, я абсолютно не верю.
> Зачем терять-то?
Ну а какие еще вы знаете способы освобождения ресурсов?
> А вот в то, что простенькому мессенджеру, передающему обыкновенный текст и отрисовывающему с десяток мелких аватарок, зачем-то нужно ресурсов больше, чем мускулю на дешёвом VDS, который там вполне неплохо работает, я абсолютно не верю.
Так у вас обратная какая-то логика. Мускулю как раз ресурсов и не надо, все, что он делает — это парсинг/компиляцию запроса ну и побегать по файлам/памяти собрать ответ. В 2018 даже у самого распоследнего месседжера, учитывая зависимости, функционал строго больше. Да что уж там — мессенджер легко может какую-нибудь БД в качестве зависимости просто строго содержать. И по-этому, конечно, ресурсов меньше жрать по определению не может.
Ну а какие еще вы знаете способы освобождения ресурсов?
> А вот в то, что простенькому мессенджеру, передающему обыкновенный текст и отрисовывающему с десяток мелких аватарок, зачем-то нужно ресурсов больше, чем мускулю на дешёвом VDS, который там вполне неплохо работает, я абсолютно не верю.
Так у вас обратная какая-то логика. Мускулю как раз ресурсов и не надо, все, что он делает — это парсинг/компиляцию запроса ну и побегать по файлам/памяти собрать ответ. В 2018 даже у самого распоследнего месседжера, учитывая зависимости, функционал строго больше. Да что уж там — мессенджер легко может какую-нибудь БД в качестве зависимости просто строго содержать. И по-этому, конечно, ресурсов меньше жрать по определению не может.
Ну а какие еще вы знаете способы освобождения ресурсов?
Не говнокодить. Ваш Капитан Очевидность.
Мускулю как раз ресурсов и не надо, все, что он делает — это парсинг/компиляцию запроса ну и побегать по файлам/памяти собрать ответ.
И это происходит в десятки раз быстрее, если содержимое файлов находится в памяти, поэтому ресурсы мускулю в десятки раз нужнее, чем мессенджеру. Мессенджер же по файлам/памяти не бегает.
В 2018 даже у самого распоследнего месседжера, учитывая зависимости, функционал строго больше.
Например? Вот лично меня функционал Telegram, например, вполне устраивает, но при этом он вписывается в сотню-другую мегабайт оперативки (это мне тоже кажется многовато, но всё же ни в какое сравнение со Slack) и абсолютно не кушает проц. Какая такая киллер-фича начнёт гигабайты жрать?
мессенджер легко может какую-нибудь БД в качестве зависимости просто строго содержать.
Какой-нибудь легковесный sqlite3, который ресурсы тоже не кушает, ага)
И по-этому, конечно, ресурсов меньше жрать по определению не может.
А Telegram при этом почему-то жрёт меньше. Ваш коммент противоречит реальности.
> Не говнокодить. Ваш Капитан Очевидность.
Ну а при чем тут говнокод? Тормоза-то не из-за говнокода (в 99% процентов случаев).
> И это происходит в десятки раз быстрее, если содержимое файлов находится в памяти, поэтому ресурсы мускулю в десятки раз нужнее, чем мессенджеру
А мессенджеру надо рисовать свистоперделки. И если задержку в ответе мускула на даже на 1 секунду никто не заметит, то лишняя задержка в 1/30 секунды при отрисовке свистоперделки будет заметна любому и доставит конечному пользователю гораздо больше неудовольствия. По-этому берем ресурсы у мускуля и отдаем на отрисовку свистоперделок. Приоритет, понимаете?
> Например?
Да хотя бы графическая подсистема.
> Вот лично меня функционал Telegram, например, вполне устраивает, но при этом он вписывается в сотню-другую мегабайт оперативки (это мне тоже кажется многовато, но всё же ни в какое сравнение со Slack) и абсолютно не кушает проц.
Ну у меня слак занимает те же 200мб и 0% загрузки процессора. Что вы с ним делаете, что там гигабайты?
Ну а при чем тут говнокод? Тормоза-то не из-за говнокода (в 99% процентов случаев).
> И это происходит в десятки раз быстрее, если содержимое файлов находится в памяти, поэтому ресурсы мускулю в десятки раз нужнее, чем мессенджеру
А мессенджеру надо рисовать свистоперделки. И если задержку в ответе мускула на даже на 1 секунду никто не заметит, то лишняя задержка в 1/30 секунды при отрисовке свистоперделки будет заметна любому и доставит конечному пользователю гораздо больше неудовольствия. По-этому берем ресурсы у мускуля и отдаем на отрисовку свистоперделок. Приоритет, понимаете?
> Например?
Да хотя бы графическая подсистема.
> Вот лично меня функционал Telegram, например, вполне устраивает, но при этом он вписывается в сотню-другую мегабайт оперативки (это мне тоже кажется многовато, но всё же ни в какое сравнение со Slack) и абсолютно не кушает проц.
Ну у меня слак занимает те же 200мб и 0% загрузки процессора. Что вы с ним делаете, что там гигабайты?
Тормоза-то не из-за говнокода (в 99% процентов случаев).
В том-то и проблема, что из-за говнокода — см. Slack и Skype. Именно из-за говнокода я и ною тут в комментах. Если бы ресурсы действительно потреблялись на что-то дельное, я бы помалкивал.
А мессенджеру надо рисовать свистоперделки.
UT99 даже в программной отрисовке выдаёт не меньше 120 кадров в секунду. Даже под вайном в линуксе. Думаю, не надо пояснять, что по меркам 2018 года он ресурсов не кушает вообще? Почему вдруг примитивный мессенджер должен тормозить и жрать ресурсы сильнее весьма сложных компьютерных игр? Графика в UT99 по современным меркам не очень, но всё же технически она сложнее чем в любом мессенджере.
Да, над UT99 работала куча талантливых разработчиков, сделавших прекраснейший программный рендеринг, но блин, неужели современные разработчики настолько деградировали, что даже три с половиной несчастных свистоперделки в мессенджере подлатать не в состоянии? Это при том, что, в отличие от времён создания UT99, им доступен OpenGL [ES], прекрасно работающий на любой кофеварке. Илон, забери меня на Марс, я не хочу жить на одной планете с такими людьми.
Да хотя бы графическая подсистема.
Пример с UT99 выше.
Ну у меня слак занимает те же 200мб и 0% загрузки процессора. Что вы с ним делаете, что там гигабайты?
Даладна, неужели с помента последнего его использования мной его подлатали? Он у меня жрал полгига сразу же после запуска.
Telegram, к слову, прямо сейчас у меня кушает всего 100 мегабайт оперативки и 0% процессора, хотя я его активно пользую. (Были слухи о 50 мегабайтах на винде, но лично не проверял.)
> В том-то и проблема, что из-за говнокода — см. Slack и Skype.
А с чего вы взяли что тормоза в slack и skype из-за говнокода?
> Почему вдруг примитивный мессенджер должен тормозить и жрать ресурсы сильнее весьма сложных компьютерных игр?
Потому что мессенджер рисует сильно не так, как UT99. Неужели надо упоминать такие очевидности?
> Это при том, что, в отличие от времён создания UT99, им доступен OpenGL [ES], прекрасно работающий на любой кофеварке.
Даже если бы вы были из тех талантливых разработчиков UT99, то не смогли бы сделать свою свистоперделку за полчаса. Ну или она бы тормозила.
А с чего вы взяли что тормоза в slack и skype из-за говнокода?
> Почему вдруг примитивный мессенджер должен тормозить и жрать ресурсы сильнее весьма сложных компьютерных игр?
Потому что мессенджер рисует сильно не так, как UT99. Неужели надо упоминать такие очевидности?
> Это при том, что, в отличие от времён создания UT99, им доступен OpenGL [ES], прекрасно работающий на любой кофеварке.
Даже если бы вы были из тех талантливых разработчиков UT99, то не смогли бы сделать свою свистоперделку за полчаса. Ну или она бы тормозила.
А с чего вы взяли что тормоза в slack и skype из-за говнокода?
С того, что Electron. Потому что нужно брать нормальный Qt5, слава телеграму.
Потому что мессенджер рисует сильно не так, как UT99. Неужели надо упоминать такие очевидности?
Да, надо. Что именно там не так? 24-битные RGB-пиксели вроде бы одинаковые и там, и тут. OpenGL вроде бы одинаковый и там, и тут — при этом UT99 на OpenGL у меня выдаёт все 300 кадров в секунду и оперативки опять же не кушает (если перерисовывать кадр реже чем 300 раз в секунду, то и процессор не будет кушать). Такими темпами создание мессенджера на игровом движке окажется хорошей идеей :\
> С того, что Electron.
Какая связь между electron и говнокодом?
> Потому что нужно брать нормальный Qt5
Чем он лучше electron? Чем он нормальный, а electron — «не нормальный»?
> 24-битные RGB-пиксели вроде бы одинаковые и там, и тут.
Очевидно, никакие мессенджеры пикселями не рисуют. Если вы будете рисовать свистоперделки в мессенджере пикселями, то ваш мессенджер выйдет примерно никогда.
Какая связь между electron и говнокодом?
> Потому что нужно брать нормальный Qt5
Чем он лучше electron? Чем он нормальный, а electron — «не нормальный»?
> 24-битные RGB-пиксели вроде бы одинаковые и там, и тут.
Очевидно, никакие мессенджеры пикселями не рисуют. Если вы будете рисовать свистоперделки в мессенджере пикселями, то ваш мессенджер выйдет примерно никогда.
Какая связь между electron и говнокодом?
Electron сам по себе говнокод, js сам по себе неоптимизированное говно с динамической типизацией. А современная мода на функциональное программирование всё усугубляет, потому что на интерпретируемых ЯП работает очень плохо. Неужели надо упоминать такие очевидности?)))
Чем он нормальный
Да хотя бы тем, что на C++, который компилируется в машинный код и в сравнении с тем же js кушает минимум ресурсов. Но нет же, C++ для современных веб-макак слишком сложный, сидят говнокодят на электронном js, и в результате мы получаем какой-нибудь Slack.
Очевидно, никакие мессенджеры пикселями не рисуют.
Эм, они в принципе не могут рисовать не пикселями, у меня все имеющиеся мониторы вполне себе пиксельные вообще-то. Векторные мониторы ещё в прошлом веке вымерли. Кроме того, я не знаю никакой современной видеоподсистемы, конечным результатом работы которой были бы не пиксели.
> Electron сам по себе говнокод
Это вы с чего взяли?
> js сам по себе неоптимизированное говно с динамической типизацией.
Каким образом факт динамической типизации сам по себе делает код — говнокодом?
Ну и плюсы, если уж на то пошло — слаботипизированный язык. Я понимаю, если бы вы назвали тот же хаскель. Но между плюсами и js разница в типах около нуля, и там и там — полное говно.
> Да хотя бы тем, что на C++, который компилируется в машинный код и в сравнении с тем же js кушает минимум ресурсов.
А цель — съест поменьше ресурсов? Я думал, что цель — разработать приложение, в соответствии с требованиями. Разве нет?
> Но нет же, C++ для современных веб-макак слишком сложный
Да ладно, с++ семантически проще, чем js.
> Эм, они в принципе не могут рисовать не пикселями, у меня все имеющиеся мониторы вполне себе пиксельные вообще-то
99% графических приложений даже не в курсе, что они вообще будут рисоваться на мониторе. Какие пиксели-то? Никто такого низкоуровневого апи не использует.
Это вы с чего взяли?
> js сам по себе неоптимизированное говно с динамической типизацией.
Каким образом факт динамической типизации сам по себе делает код — говнокодом?
Ну и плюсы, если уж на то пошло — слаботипизированный язык. Я понимаю, если бы вы назвали тот же хаскель. Но между плюсами и js разница в типах около нуля, и там и там — полное говно.
> Да хотя бы тем, что на C++, который компилируется в машинный код и в сравнении с тем же js кушает минимум ресурсов.
А цель — съест поменьше ресурсов? Я думал, что цель — разработать приложение, в соответствии с требованиями. Разве нет?
> Но нет же, C++ для современных веб-макак слишком сложный
Да ладно, с++ семантически проще, чем js.
> Эм, они в принципе не могут рисовать не пикселями, у меня все имеющиеся мониторы вполне себе пиксельные вообще-то
99% графических приложений даже не в курсе, что они вообще будут рисоваться на мониторе. Какие пиксели-то? Никто такого низкоуровневого апи не использует.
Это вы с чего взяли?
А вы можете рассказать, куда он, как и хром, девает полгига оперативки сразу же после запуска? Как это объясняется, кроме как говнокодом? Только повторно гнать пургу про свистоперделки не надо, пожалуйста, я не поведусь.
Каким образом факт динамической типизации сам по себе делает код — говнокодом?
Ладно, это моё субъективное мнение. Я ненавижу динамически типизированные и интерпретируемые ЯП. Потому что можно и нужно делать статически типизированные и компилируемые хотя бы в байткод (хорошо что хоть WebAssembly появился). Это опять же даст плюс к производительности.
Ну и плюсы, если уж на то пошло — слаботипизированный язык.
Но при этом статически типизированный. Это огромный плюс к производительности.
Я думал, что цель — разработать приложение, в соответствии с требованиями. Разве нет?
Вы на протяжении всей этой ветки так и не рассказали, почему «требованиям» нужно так много ресурсов. Не увиливайте от вопроса. При этом, когда я говорю про говнокод, вы почему-то с этим не соглашаетесь. Если не из-за говнокода — так почему же?
Да ладно, с++ семантически проще, чем js.
Ну вот и прекрасно! Давайте писать всё хотя бы на C++? Нахрена существует js?
Какие пиксели-то?
RGB, по 8 бит на канал. Откройте свой Slack, нажмите PrintScreen, вставьте картинку из буфера обмена в какой-нибудь графический редактор и поиграйтесь с масштабом и пипеткой — вы увидите, что Slack отрисован очень даже пикселями.
Никто такого низкоуровневого апи не использует.
А при чём тут низкоуровневые апи? UT99 тоже манипулирует вполне себе полигонами и текстурами, а не пикселями, но при этом не тормозит. И текста там тоже хватает. Мессенджеру тоже ничего не мешает рисовать так же, только не 300 кадров в секунду, а пореже. Каковы же принципиальные отличия UT99 от мессенджера, которые вынужнают последнего кушать кучу ресурсов, вы так и не рассказали. (Спойлер: это отличие — говнокод и лень разработчиков. Какого-то другого правдоподобного варианта я от вас так и не услышал.)
Slack еще и ужасно работает в 2G. Telegram — прекрасно работает. Из чего можно сделать вывод, что разработчики Slack не только интерфейсы разрабатывают плохо, но и сетевую часть.
Ничего я не путаю.
Всего полминуты после запуска — и 1281 грёбаный мегабайт!!! Куда блэт???
(фаерфокса это тоже касается, но он хотя бы больше суток с кучей вкладок висит открытый)
Не в защиту хрома, но сумировать RES некорректно, поскольку часть его может (и будет) "shared". Реальное же подтребление высчитать довольно трудно.
Хм, я всегда думал, что они раздельны. Но ладно, даже если так, общее потребление памяти в компе при запуске пустого хрома у меня подскакивает с 5.20 гб до 5.45 гб — мне всё ещё непонятно, почему бы пустому браузеру не вписываться в сотню мегабайт.
Насколько я понимаю это перпендикулярные понятия. Шареная память может быть как virt (например неиспользуемая библиотека), так и res (используемая в данный момент библиотека, ну или реальная разделяемая память (как в БД)).
Например для баз данных метод подсчета сумированием RES не дает ничего, поскольку цифры получаются в разы больше чем физическая память.
> почему бы пустому браузеру не вписываться в сотню мегабайт.
Потому что никому не надо оптимизировать потребление _пустого браузера_. Никто не запускает браузер за тем, чтобы смотреть на стартовую страницу (ну, кроме тех, кто кидает скриншоты с потреблением памяти).
Потому что никому не надо оптимизировать потребление _пустого браузера_. Никто не запускает браузер за тем, чтобы смотреть на стартовую страницу (ну, кроме тех, кто кидает скриншоты с потреблением памяти).
Открыл хабр в чистом хроме — тот отожрал ещё две сотни мегабайт. Куда? Зачем? Почему? Что такого на главной хабра занимает две сотни мегабайт?
Кстати, Mozilla в презентации нового Firefox утверждали, что он потребляет на 20-25 процентов меньше паямти, чем Хром. Открыл одну и ту же страницу Хабра в Хроме 49 и последнем Firefox (расширений ни там, ни там не установлено).
Однако, картина с точностью до наоборот. Firefox быстрее последних Хромов (но по ощущениям такой же, как Хромы более старых версий, в районе 45-49), но памяти жрёт минимум на 200 процентов больше даже при одной открытой вкладке. Более того, при закрытии вкладок память, отведённая под них, явно не чистится (видимо, чтобы потом быстрее можно было открыть по Shift+Ctrl+T).
Я правда когда в Хроме поскроллил страницу вниз, потребление памяти одним из процессов стало расти, и дошло примерно до 145-148 мегабайт в каком-то месте. Может, выросло бы и ещё больше, прокрути я дальше. Но всё-таки.
Однако, картина с точностью до наоборот. Firefox быстрее последних Хромов (но по ощущениям такой же, как Хромы более старых версий, в районе 45-49), но памяти жрёт минимум на 200 процентов больше даже при одной открытой вкладке. Более того, при закрытии вкладок память, отведённая под них, явно не чистится (видимо, чтобы потом быстрее можно было открыть по Shift+Ctrl+T).
Я правда когда в Хроме поскроллил страницу вниз, потребление памяти одним из процессов стало расти, и дошло примерно до 145-148 мегабайт в каком-то месте. Может, выросло бы и ещё больше, прокрути я дальше. Но всё-таки.
Использую PaleMoon, клон файрфокса, раньше он глючил после 1900 с чем-то вкладок (начинали пропадать элементы меню и т.п.), сейчас на 2300 полёт нормальный. Всё это на машине с 4 гигами. По факту он всегда отжирает 1.5гига не зависимо от вкладок, а при активном использовании с открытыми 2300 доходит до 2.5гиг. Хром умирает на 30 вкладках полностью.
> Куда? Зачем? Почему? Что такого на главной хабра занимает две сотни мегабайт?
жс и дом, что тут неочевидного?
жс и дом, что тут неочевидного?
Насколько я знаю, хром очень много памяти «берет про запас» чтобы все подряд кешировать и т.п. Попробуйте начать забивать оперативку чем-нибудь. ЕМНИП, хром за этим следит и начинает освобождать не используемые запасы.
> А вы можете рассказать, куда он, как и хром, девает полгига оперативки сразу же после запуска?
Почему полгига? У меня vsc занимает в памяти 300мб. И, я уверен, будет еще меньше, если поотключать всякие плагины. Так на основании чего вы решили, что это говнокод? Просто дешевый треп?
> Но при этом статически типизированный. Это огромный плюс к производительности.
Современные джиты вполне успешно оптимизируют мономорфный динамический код до практически неотличимого от статического. Проблема тормозов в жс не в том, что там динамика, а в том, что сама система типов слаба — фактически все, что не число, то объект (если вы в плюсах так же систему типов ограничите, получите те же тормоза, хоть и в статике). С соответствующими накладными расходами на объем и боксинг/анбоксинг. Кроме того, как язык js семантически значительно более сложный, его просто труднее эффективно компилировать.
Ну и сборщик не самый оптимальный (хоть и оптимальнее ручного управления, но тормознее дефолтных ручных аллокаторов ничего еще не придумали, так что тут заслуга невелика).
> Если не из-за говнокода — так почему же?
Потому что задачи объективно требуют этих ресурсов. Если вы собираетесь доказывать, что какая-то из задач решена объективно неэффективно при прочих равных, то представьте эту задачу, неэффективное решение и аргументы в пользу его неэффективности (прямые, конечно, а не косвенные). Бремя доказательства существования лежит на том, кто утверждает существование. Я, очевидно, не могу доказать, что таких задач/решений нет (это недоказуемо в принципе).
> Ну вот и прекрасно! Давайте писать всё хотя бы на C++? Нахрена существует js?
С++ не работает в браузерах.
> RGB, по 8 бит на канал. Откройте свой Slack, нажмите PrintScreen
Поверьте, в исходниках slack нету ничего про пиксели, rgb и 8бит на канал.
> А при чём тут низкоуровневые апи? UT99 тоже манипулирует вполне себе полигонами и текстурами, а не пикселями
Что значит «тоже»? slack не манипулирует полигонами и текстурками, по-этому «тоже» неуместно. Если бы UT99 манипулировал тем же, чем slack (dom), то он и тормозил бы соответствующим образом.
> Спойлер: это отличие — говнокод и лень разработчиков
Программы стараются разрабатывать быстрее не потому, что разрабатывать долго — лень. А потому, что в 99% случаев иметь приложение, которое работает с удовлетворительной производительностью сегодня, лучше, чем то, которое работает ну пипец как быстро, но завтра. Потому что в первом случае вы сегодня имеете приложение, которое решает ваши задачи, а во втором — не имеете.
Почему полгига? У меня vsc занимает в памяти 300мб. И, я уверен, будет еще меньше, если поотключать всякие плагины. Так на основании чего вы решили, что это говнокод? Просто дешевый треп?
> Но при этом статически типизированный. Это огромный плюс к производительности.
Современные джиты вполне успешно оптимизируют мономорфный динамический код до практически неотличимого от статического. Проблема тормозов в жс не в том, что там динамика, а в том, что сама система типов слаба — фактически все, что не число, то объект (если вы в плюсах так же систему типов ограничите, получите те же тормоза, хоть и в статике). С соответствующими накладными расходами на объем и боксинг/анбоксинг. Кроме того, как язык js семантически значительно более сложный, его просто труднее эффективно компилировать.
Ну и сборщик не самый оптимальный (хоть и оптимальнее ручного управления, но тормознее дефолтных ручных аллокаторов ничего еще не придумали, так что тут заслуга невелика).
> Если не из-за говнокода — так почему же?
Потому что задачи объективно требуют этих ресурсов. Если вы собираетесь доказывать, что какая-то из задач решена объективно неэффективно при прочих равных, то представьте эту задачу, неэффективное решение и аргументы в пользу его неэффективности (прямые, конечно, а не косвенные). Бремя доказательства существования лежит на том, кто утверждает существование. Я, очевидно, не могу доказать, что таких задач/решений нет (это недоказуемо в принципе).
> Ну вот и прекрасно! Давайте писать всё хотя бы на C++? Нахрена существует js?
С++ не работает в браузерах.
> RGB, по 8 бит на канал. Откройте свой Slack, нажмите PrintScreen
Поверьте, в исходниках slack нету ничего про пиксели, rgb и 8бит на канал.
> А при чём тут низкоуровневые апи? UT99 тоже манипулирует вполне себе полигонами и текстурами, а не пикселями
Что значит «тоже»? slack не манипулирует полигонами и текстурками, по-этому «тоже» неуместно. Если бы UT99 манипулировал тем же, чем slack (dom), то он и тормозил бы соответствующим образом.
> Спойлер: это отличие — говнокод и лень разработчиков
Программы стараются разрабатывать быстрее не потому, что разрабатывать долго — лень. А потому, что в 99% случаев иметь приложение, которое работает с удовлетворительной производительностью сегодня, лучше, чем то, которое работает ну пипец как быстро, но завтра. Потому что в первом случае вы сегодня имеете приложение, которое решает ваши задачи, а во втором — не имеете.
У меня vsc занимает в памяти 300мб.
У меня чистый vsc жрал полгига сразу после первого запуска без каких-либо сторонних плагинов. Мы в разных вселенных живём что ли?
Современные джиты вполне успешно оптимизируют мономорфный динамический код до практически неотличимого от статического.
Вы запутались. Джиты не нужно было бы изобретать, если бы изначально было нормальный язык, компилирующийся во что-нибудь нормальное. А теперь эти сами джиты, наверно, и отъедают те самые полгига памяти — они проделывают очень много работы ради оптимизаций, которые можно было бы не проделывать с изначально нормальным языком. А теперь куча человекочасов угроблено в попытках добиться того, чтобы говноязык не так сильно тормозил. К счастью, в последнее время народ одумался и запилил WebAssembly — я очень надеюсь, что с ним веб станет лучше и скромнее по ресурсам. Хотя и он тоже не без недостатков.
С++ не работает в браузерах.
Мы подходим к самому главному: пришло время избавиться от браузеров! Ещё немного, и получится Telegram!))
Поверьте, в исходниках slack нету ничего про пиксели, rgb и 8бит на канал.
Уверен, хотя бы несколько PNG-картинок найдутся. Да и в CSS что-нибудь подобное обязательно упоминается. Но всё равно это не причина тормозить и жрать память.
Если бы UT99 манипулировал тем же, чем slack (dom), то он и тормозил бы соответствующим образом.
Отсюда напрашивается вывод: dom нахрен не нужен! Slack написан на технологиях, идеально подходящих для того, чтобы тормозить без уважительных причин. Напоминаю ещё раз про С++ и Qt5 :)
в 99% случаев иметь приложение, которое работает с удовлетворительной производительностью сегодня, лучше, чем то, которое работает ну пипец как быстро, но завтра
Slack появился почти пять лет назад. Ладно, пусть прототип был фигак-фигак и в продакшен, но за пять лет-то самое быстрорастущее бизнес-приложение в истории (где-то выше в комментах такое утверждали) мог бы переписаться на что-нибудь более приличное и стать ещё более быстрорастущим, уделав любые телеграмы.
а во втором — не имеете.
Ну, телеграм, который на C++ и Qt5, у меня есть и вполне меня устраивает) Других пользователей и самих разработчиков, думаю, тоже. (Паранойя вроде закрытого сервера или обязательности мобильника это отдельная история, ресурсов не касающаяся.)
Slack появился почти пять лет назад. Ладно, пусть прототип был фигак-фигак и в продакшен, но за пять лет-то самое быстрорастущее бизнес-приложение в истории (где-то выше в комментах такое утверждали) мог бы переписаться на что-нибудь более приличное и стать ещё более быстрорастущим, уделав любые телеграмы.Это с чего вы так решили? Те пользователи, которые уже и так им пользуются — были бы счастливы, но они же уже пользователи! А новых проще привлечь новыми фичами, чем большей скоростью работы.
Skype начал терять популярность не тогда, когда он стал монструозен, а когда из него «выпилили» самую главную фишку — умение выйти в интеренет через
После чего он превратился из уникальной вещи, обеспечивающей беспрецедентное качество аудио и видеозвоноков очередным 100500м мессенджером, завязанным на центральные сервера…
> У меня чистый vsc жрал полгига сразу после первого запуска без каких-либо сторонних плагинов.
Ну откуда я знаю что вы там с ним делаете?
> Джиты не нужно было бы изобретать, если бы изначально было нормальный язык, компилирующийся во что-нибудь нормальное.
Джит и компилирует язык во «что-нибудь нормальное». И, нет, джит нужно было бы изобретать — потому нельзя скомпилировать машкод заранее под платформу, которая в это «заранее» неизвестно. Такие случаи бывают. Веб — один из них. Если без джита — то будет интерпретатор вообще.
> А теперь эти сами джиты, наверно, и отъедают те самые полгига памяти — они проделывают очень много работы ради оптимизаций
Нет, не отъедают. И джиты работают _очень_ быстро. Фактически, заметить работу джита невооруженным взглядом невозможно (если только не использовать специально сконструированный для этого кейс).
> Мы подходим к самому главному: пришло время избавиться от браузеров!
Ну идите к разработчикам http и рассказывайте _им_ о том, что они все идиоты и говнокодеры. Остальные то тут при чем?
> Но всё равно это не причина тормозить и жрать память.
Почему же не причина? Причина и есть. И ваш UT99 так бы тормозил и жрал память при подобной модели.
> Напоминаю ещё раз про С++ и Qt5 :)
А c++ и qt5 позволяет разрабатывать приложения и фичи так же быстро?
> но за пять лет-то самое быстрорастущее бизнес-приложение в истории (где-то выше в комментах такое утверждали) мог бы переписаться
А зачем? Не лучше ли доставить пользователю какую-то _полезную_ ему фичу, чем заниматься тратой бюджета на глобальное переписывание, которого он даже не заметит в подавляющем большинстве случаев?
> Ну, телеграм, который на C++ и Qt5, у меня есть и вполне меня устраивает)
Ну а кого-то другого вполне устраивает slack.
Ну откуда я знаю что вы там с ним делаете?
> Джиты не нужно было бы изобретать, если бы изначально было нормальный язык, компилирующийся во что-нибудь нормальное.
Джит и компилирует язык во «что-нибудь нормальное». И, нет, джит нужно было бы изобретать — потому нельзя скомпилировать машкод заранее под платформу, которая в это «заранее» неизвестно. Такие случаи бывают. Веб — один из них. Если без джита — то будет интерпретатор вообще.
> А теперь эти сами джиты, наверно, и отъедают те самые полгига памяти — они проделывают очень много работы ради оптимизаций
Нет, не отъедают. И джиты работают _очень_ быстро. Фактически, заметить работу джита невооруженным взглядом невозможно (если только не использовать специально сконструированный для этого кейс).
> Мы подходим к самому главному: пришло время избавиться от браузеров!
Ну идите к разработчикам http и рассказывайте _им_ о том, что они все идиоты и говнокодеры. Остальные то тут при чем?
> Но всё равно это не причина тормозить и жрать память.
Почему же не причина? Причина и есть. И ваш UT99 так бы тормозил и жрал память при подобной модели.
> Напоминаю ещё раз про С++ и Qt5 :)
А c++ и qt5 позволяет разрабатывать приложения и фичи так же быстро?
> но за пять лет-то самое быстрорастущее бизнес-приложение в истории (где-то выше в комментах такое утверждали) мог бы переписаться
А зачем? Не лучше ли доставить пользователю какую-то _полезную_ ему фичу, чем заниматься тратой бюджета на глобальное переписывание, которого он даже не заметит в подавляющем большинстве случаев?
> Ну, телеграм, который на C++ и Qt5, у меня есть и вполне меня устраивает)
Ну а кого-то другого вполне устраивает slack.
Если без джита — то будет интерпретатор вообще.
Вы видимо не понимаете, что такое джит. Если без джита — то будет какой-нибудь транслятор, который странслирует условный WebAssembly-байткод в машинный код и закэширует. И так как все оптимизации проведены ещё на уровне байткода, то такой транслятор в теории был бы чудовищно прост и почти не требовал бы ресурсов, в отличие от монстра V8 с его джитом, пытающимся оптимизировать говнокод на говноязыке хоть как-нибудь. И вообще вспомните Android: там тоже от джита отказались (теперь ahead-of-time компиляция при установке приложения), а кроссплатформенность как-то никуда не делась.
Ну идите к разработчикам http и рассказывайте им о том, что они все идиоты и говнокодеры.
Так они и без меня в курсе.
И ваш UT99 так бы тормозил и жрал память при подобной модели.
Ещё раз: значит такая модель не нужна.
А c++ и qt5 позволяет разрабатывать приложения и фичи так же быстро?
Ну у телеграма с этим проблем нет почему-то. Значит, видимо, позволяет. И за пять лет нормальный клиент Slack вполне можно было сделать.
А зачем?
Чтобы завести пользователю полезную ему фичу — экономию ресурсов — и не вынуждать тратить деньги на апгрейд компа, если перед запуском слака приходится выключать все виртуалки и наоборот.
> Если без джита — то будет какой-нибудь транслятор, который странслирует условный WebAssembly-байткод в машинный код и закэширует.
Что за херню вы несете? «Транслятор, который странслирует вебассембли-байткод в машинный код и закеширует» — это _и есть джит_! По определению.
> И так как все оптимизации проведены ещё на уровне байткода
И опять полная чушь. Байткод не позволяет делать практически никаких низкоуровневых оптимизаций, а именно эти оптимизации и требуют наибольших ресурсов.
> такой транслятор в теории был бы чудовищно прост и почти не требовал бы ресурсов
Работа джита в v8 — это максимум единицы процентов. производительности. Даже если ваш джит веб-ассембли будет работать мгновенно (а он не будет), то больше этих процентов вы выиграть на самом процессе компиляции не сможете даже в теории.
> там тоже от джита отказались (теперь ahead-of-time компиляция при установке приложения)
АОТ для жс по понятным причинам невозможен (то есть в теории возможен, но практически бесполезен).
> Ещё раз: значит такая модель не нужна.
Но она есть. И альтернатив ей — нет.
> Чтобы завести пользователю полезную ему фичу — экономию ресурсов
В чем польза для пользователя, если он даже не заметит разницы? С другой стороны — те же усилия можно потратить на реализацию каких-то дополнительных фич, что пользователь заметит.
> перед запуском слака приходится выключать все виртуалки и наоборот
Ну так обратитесь к разработчикам ваших виртуалок. Пусть не говнокодят, а пишут нормальные виртуалки.
Что за херню вы несете? «Транслятор, который странслирует вебассембли-байткод в машинный код и закеширует» — это _и есть джит_! По определению.
> И так как все оптимизации проведены ещё на уровне байткода
И опять полная чушь. Байткод не позволяет делать практически никаких низкоуровневых оптимизаций, а именно эти оптимизации и требуют наибольших ресурсов.
> такой транслятор в теории был бы чудовищно прост и почти не требовал бы ресурсов
Работа джита в v8 — это максимум единицы процентов. производительности. Даже если ваш джит веб-ассембли будет работать мгновенно (а он не будет), то больше этих процентов вы выиграть на самом процессе компиляции не сможете даже в теории.
> там тоже от джита отказались (теперь ahead-of-time компиляция при установке приложения)
АОТ для жс по понятным причинам невозможен (то есть в теории возможен, но практически бесполезен).
> Ещё раз: значит такая модель не нужна.
Но она есть. И альтернатив ей — нет.
> Чтобы завести пользователю полезную ему фичу — экономию ресурсов
В чем польза для пользователя, если он даже не заметит разницы? С другой стороны — те же усилия можно потратить на реализацию каких-то дополнительных фич, что пользователь заметит.
> перед запуском слака приходится выключать все виртуалки и наоборот
Ну так обратитесь к разработчикам ваших виртуалок. Пусть не говнокодят, а пишут нормальные виртуалки.
Что за херню вы несете? «Транслятор, который странслирует вебассембли-байткод в машинный код и закеширует» — это и есть джит! По определению.
Джит по определению транслирует в машинный код во время его работы. AOT транслирует в машинный код перед его работой. Джит делает это каждый раз при запуске программы, AOT делает это единственный раз. Так работает Android. И это хорошо и правильно. Ваш джит не нужен.
Байткод не позволяет делать практически никаких низкоуровневых оптимизаций
За низкоуровневые, специфичные для текущего процессора, будет отвечать AOT. А вот высокоуровневые прекрасно делаются на уровне байткода. В то время как вашему джиту, компилирующему js, приходится делать и то и другое. Нахрена, когда это можно сделать один раз на компьютере разработчика?
АОТ для жс по понятным причинам невозможен (то есть в теории возможен, но практически бесполезен).
Почему же это? Скрипты на сайтах обновляются далеко не каждую минуту, скачать его и положить машинный код в кэш — проблем в этом я не вижу. Как минимум пару недель точно послужит, пока сайт не обновят.
Но она есть. И альтернатив ей — нет.
Но ведь же в UT99 модель какая-то другая и она не тормозит? Давайте использовать модель из UT99! Что мешает? Лень разработчиков?
В чем польза для пользователя, если он даже не заметит разницы?
Я пользователь и я замечу. Тем более Slack позиционируется для всяких рабочих команд, а эти самые рабочие команды очень любят экономить ресурсы. Это телеграму как раз можно в принципе не экономить, но он почему-то как раз экономит.
Ну так обратитесь к разработчикам ваших виртуалок. Пусть не говнокодят, а пишут нормальные виртуалки.
А они-то тут при чём, если вин10, жрущую память и проц, наговнокодили в майкрософте? Ну а майкрософту и без меня пишут все кому не лень.
> AOT транслирует в машинный код перед его работой.
То есть, вы предлагаете полностью с оптимизациями регулярно компилировать ВСЕ мегабайты кода (даже те, что компилировать нахрен и не надо, особенно с оптимизациями), вместо того, чтобы эффективно джитить только hot patches? Вы представьте себе, что каждая страница содержит полновесную копию кути, которая будет каждый раз компилироваться. Вам не плохо еще от собственных идей?
> За низкоуровневые, специфичные для текущего процессора, будет отвечать AOT.
Именно низкоуровневые оптимизации и требуют наибольших усилий от компилятора. Так что вы тут не выигрываете много.
> Почему же это? Скрипты на сайтах обновляются далеко не каждую минуту, скачать его и положить машинный код в кэш — проблем в этом я не вижу.
Ну так скомпилированный код и так в v8 кешируется. Просто код не компилируется с оптимизациями весь целиком при октрытии сайта. Только важные куски.
> Давайте использовать модель из UT99! Что мешает?
Невозможность доставлять функционал в приемлемые сроки.
> Это телеграму как раз можно в принципе не экономить
Это телеграм как раз запускается на мобильных устройствах, по-этому ему надо экономить. А слак крутится на рабочих пека, для которых обычно требуется выполнять задачи значительно более серьезные, чем слак покрутить.
> А они-то тут при чём, если вин10, жрущую память и проц, наговнокодили в майкрософте?
Вы так говорите, как будто есть другие ОС, которые предоставляют тот же набор ф-й и при этом жрут память и проц видимо меньше.
То есть, вы предлагаете полностью с оптимизациями регулярно компилировать ВСЕ мегабайты кода (даже те, что компилировать нахрен и не надо, особенно с оптимизациями), вместо того, чтобы эффективно джитить только hot patches? Вы представьте себе, что каждая страница содержит полновесную копию кути, которая будет каждый раз компилироваться. Вам не плохо еще от собственных идей?
> За низкоуровневые, специфичные для текущего процессора, будет отвечать AOT.
Именно низкоуровневые оптимизации и требуют наибольших усилий от компилятора. Так что вы тут не выигрываете много.
> Почему же это? Скрипты на сайтах обновляются далеко не каждую минуту, скачать его и положить машинный код в кэш — проблем в этом я не вижу.
Ну так скомпилированный код и так в v8 кешируется. Просто код не компилируется с оптимизациями весь целиком при октрытии сайта. Только важные куски.
> Давайте использовать модель из UT99! Что мешает?
Невозможность доставлять функционал в приемлемые сроки.
> Это телеграму как раз можно в принципе не экономить
Это телеграм как раз запускается на мобильных устройствах, по-этому ему надо экономить. А слак крутится на рабочих пека, для которых обычно требуется выполнять задачи значительно более серьезные, чем слак покрутить.
> А они-то тут при чём, если вин10, жрущую память и проц, наговнокодили в майкрософте?
Вы так говорите, как будто есть другие ОС, которые предоставляют тот же набор ф-й и при этом жрут память и проц видимо меньше.
Вот и подошли к ещё одной проблеме веба: ад зависимостей. Кутя по возможности должна быть одна на все сайты.
Именно низкоуровневые оптимизации и требуют наибольших усилий от компилятора. Так что вы тут не выигрываете много.
Окей, тут мне возразить нечего. Но это не отменяет того, что в v8 много костылей именно под js: замена его на байткод сделает всё проще и адекватнее.
А слак крутится на рабочих пека,
Странно, все виденные мной рабочие компы были дохлее моего домашнего посредственного ноута. И если домашний ноут ещё можно просто взять и обновить, то обновление рабочего компа надо ещё как-то обосновывать. Потому что чатик тормозит? Ха-ха, лол.
Вы так говорите, как будто есть другие ОС, которые предоставляют тот же набор ф-й и при этом жрут память и проц видимо меньше.
Таких дистрибутивов линукса навалом. Но, к сожалению, тестить сайты нужно и в Microsoft Edge тоже. И Adobe Illustrator в вайне не работает (он весьма экономно юзает память, кстати)
А чем не вариант виртуалку на линукс установить, и тестить Edge в ней?)
Так я именно этим и занимаюсь) Только вот вин10 в виртуалке кушает много памяти, и условный Slack запустить уже невозможно. И наоборот: если я запущу условный Slack, то не смогу запустить виртуалку.
> Только вот вин10 в виртуалке кушает много памяти
Очевидно, потому, что ОС оптимизирована не для работы в виртуалке, и не против съесть _всю_ возможную память (на кеши). С точки зрения ОС, вообще, если память свободна, то эффективнее ее чем-то занять, чем держать свободной. Андроид вон вообще не выгружает приложения из памяти, пока память не закончится. Зато уже открытое ранее приложение открывается практически мгновенно.
Очевидно, потому, что ОС оптимизирована не для работы в виртуалке, и не против съесть _всю_ возможную память (на кеши). С точки зрения ОС, вообще, если память свободна, то эффективнее ее чем-то занять, чем держать свободной. Андроид вон вообще не выгружает приложения из памяти, пока память не закончится. Зато уже открытое ранее приложение открывается практически мгновенно.
> Вот и подошли к ещё одной проблеме веба: ад зависимостей. Кутя по возможности должна быть одна на все сайты.
В вебе как раз проблемы ада зависимостей нет, а вот в десктопных приложениях — вполне есть. И если вы предлагаете сделать веб «как десктоп» — вы на эту проблему сходу и натыкаетесь.
> Но это не отменяет того, что в v8 много костылей именно под js: замена его на байткод сделает всё проще и адекватнее.
Да это снизит, конечно, издержки на парсинг и разбор js. Но прям каких-то драматичных результатов не даст — вот о чем речь.
> Странно, все виденные мной рабочие компы были дохлее моего домашнего посредственного ноута.
И какие задачи на них решались?
> Таких дистрибутивов линукса навалом.
Пока что нету ни одного дистрибутива линукс, в котором можно просто нормально поставить дрова на видео/звуковую карту, не имея значительного риска уткнуться в какую-нибудь проблему. Конечно, за последние годы в этом плане развитие идет, но в плане just works бубунтам до винды еще лет 10-20 развиваться.
В вебе как раз проблемы ада зависимостей нет, а вот в десктопных приложениях — вполне есть. И если вы предлагаете сделать веб «как десктоп» — вы на эту проблему сходу и натыкаетесь.
> Но это не отменяет того, что в v8 много костылей именно под js: замена его на байткод сделает всё проще и адекватнее.
Да это снизит, конечно, издержки на парсинг и разбор js. Но прям каких-то драматичных результатов не даст — вот о чем речь.
> Странно, все виденные мной рабочие компы были дохлее моего домашнего посредственного ноута.
И какие задачи на них решались?
> Таких дистрибутивов линукса навалом.
Пока что нету ни одного дистрибутива линукс, в котором можно просто нормально поставить дрова на видео/звуковую карту, не имея значительного риска уткнуться в какую-нибудь проблему. Конечно, за последние годы в этом плане развитие идет, но в плане just works бубунтам до винды еще лет 10-20 развиваться.
каждая страница содержит полновесную копию кути
В вебе как раз проблемы ада зависимостей нет
Ну лол же.
Но прям каких-то драматичных результатов не даст
Я столько всяких разных ужасов начитался про джаваскриптовый arguments (и не только), что совсем не уверен в верности данного утверждения.
И какие задачи на них решались?
Самые разные, с браузерами и виртуалками в том числе.
Пока что нету ни одного дистрибутива линукс, в котором можно просто нормально поставить дрова на видео/звуковую карту, не имея значительного риска уткнуться в какую-нибудь проблему.
За десять лет пользования линуксом у меня ни разу не было проблем с этим. Впрочем, нытьё других линуксоидов намекает, что я просто везучий.
Ну и да, дрова обычно не имеют отношения к прикладному ПО. Какой-нибудь дум-2016 может выжимать всё из железа и натыкаться на баги в реализации дров, но вот условному Slack вполне будет достаточно, чтобы был хоть какой-то OpenGL, возможно даже программный. А без свистоперделок и OpenGL будет в принципе не нужен (хотя в последнее время пошла мода на его использование во всяких гуёвых тулкитах).
> Ну лол же.
Что лол?
> Я столько всяких разных ужасов начитался про джаваскриптовый arguments (и не только), что совсем не уверен в верности данного утверждения.
И что там с ужасами об arguments?
> Самые разные, с браузерами и виртуалками в том числе.
Ну значит и слак там не тормозит.
> За десять лет пользования линуксом у меня ни разу не было проблем с этим.
Вам очень повезло.
> Ну и да, дрова обычно не имеют отношения к прикладному ПО.
Слушайте, пользователю совершенно неважно что к чему имеет отношение. Либо он получает стабильно работающий функцинал Х, либо не получает.
> Какой-нибудь дум-2016 может выжимать всё из железа и натыкаться на баги в реализации дров
Да куда там дум лол. Просто стандартная проблема — рандомно слетающее разрешение. Ну и иксы, которое имеют свойство регулярно падать при открытии случайной папки, менюшки, нажатии на кнопку…
Это понятно, почему линуксоиды не любят гуи. У них ведь никогда и не было работающего гуи. Я б тоже не любил гуи, если бы любое действие влекло за собой вполне ощутимый риск ПРОВАЛА.
Что лол?
> Я столько всяких разных ужасов начитался про джаваскриптовый arguments (и не только), что совсем не уверен в верности данного утверждения.
И что там с ужасами об arguments?
> Самые разные, с браузерами и виртуалками в том числе.
Ну значит и слак там не тормозит.
> За десять лет пользования линуксом у меня ни разу не было проблем с этим.
Вам очень повезло.
> Ну и да, дрова обычно не имеют отношения к прикладному ПО.
Слушайте, пользователю совершенно неважно что к чему имеет отношение. Либо он получает стабильно работающий функцинал Х, либо не получает.
> Какой-нибудь дум-2016 может выжимать всё из железа и натыкаться на баги в реализации дров
Да куда там дум лол. Просто стандартная проблема — рандомно слетающее разрешение. Ну и иксы, которое имеют свойство регулярно падать при открытии случайной папки, менюшки, нажатии на кнопку…
Это понятно, почему линуксоиды не любят гуи. У них ведь никогда и не было работающего гуи. Я б тоже не любил гуи, если бы любое действие влекло за собой вполне ощутимый риск ПРОВАЛА.
Разродилъ меня споръ вашъ неблагодатный на пасту сію
— Братишка! Братишка!
— Ну что там опять, ты мне дашь бизнес-план дочитать или нет?!
— Как там рекламная кампания, всё готово, братишка?
— Фу! Сгинь, пропади, пёс смердящий!
— Что такое, братишка? Я тебе продукт принёс!
— Ты что наделал, гад! Уноси его нахрен отсюда!
— В чём дело, братишка? Я продукт в срок принёс, все дедлайны соблюдены, фичи реализованы, баги пойманы!
— Какой продукт? Какой это нахрен продукт?! Ты в диспетчер задач смотрел, скотина?
— Зачем диспетчер задач, братишка? Диспетчера в ТЗ не было!
— Ну и мудак, оно же 4 гигабайта на старте только жрёт. Как клиенты это запускать будут, у них же засвопится всё нахрен!
— Ну как, как. Вот смотри, заходишь в меню «Пуск»…
— Какое меню, нахрен, ты понимаешь, что ты говнокод принёс? Дуй переписывать! Чтоб через пять минут больше полгигабайта не ело!
— Братишка, но у меня же всё работает, смотри, открываешь программу, создаёшь новую запись, всё работает! У меня вся команда, все тестировщики пользовались! Это продукт, это готовый продукт!
— Какие тестировщики, ты понимаешь, что у клиентов память не резиновая?! Ты в компьютерном магазине когда последний раз был? Какие там характеристики? Какие характеристики, скотина? Сколько гигабайт оперативки обычно?! Сколько гигабайт, сволочь ты эдакая?
— Ну 3, 4… Так продукт и потребляет же 4, братишка!
— Ой дурак, ой дурак… Как они работать-то с твоим продуктом будут? Другие программы запускать как?
— Ну закроют, запустят продукт…
— Рот себе закрой, придурок! Ты в каком веке живёшь, продукт под DOS, что ли, или под Palm OS? Знаешь, что такое многозадачность, свинья тупорылая?!!!
— Братишка, ну сроки же, пора продукт выпускать, а то испортится!
— Иди переписывай! Иди весь этот говнокод лично переписывай!
— Братишка, ну давай мы клиентам памяти докупим?
— Что докупим, кому докупим, куда докупим, твою мать! Ты совсем башней поехал!
— Это продукт, это готовый продукт! Всё в сроки, всё по ТЗ!
— Иди бюджетный ноутбук покупай, скотина! С двумя гигабайтами оперативки и жёстким диском! При мне тестить будешь!
— Братишка, ну клиенты новые купят, хорошие!
— Ох я тебя щяс самого куплю! Ох я тебя куплю, будешь у меня пожизненно код вылизывать, скотина! Какие фичи, какой продукт, ты понимаешь, что тут говнокод на говнокоде? Как мы клиентам в глаза смотреть будем?
— Братишка, ну вон же Slack сколько ест, посмотри.
— Какой Slack, скотина, в нём только программисты сидят! Ты что, ещё и вебни сюда напихал? Мы вам, скотинам, мощные ПК для работы, чтобы код быстро компилировался, а вы вместо этого скриптоты насовали и на свободных ресурсах Slack запускаете?! Ану марш на C++ переписывать, скотина! Родина дала ему Qt — используй, используй Qt, не, не хочу, хочу вебню жрать! И это программисты? Это программисты?!!! Ану марш с глаз моих, дерьма кусок, чтобы я больше твоих поделий не видел!
— Ну что там опять, ты мне дашь бизнес-план дочитать или нет?!
— Как там рекламная кампания, всё готово, братишка?
— Фу! Сгинь, пропади, пёс смердящий!
— Что такое, братишка? Я тебе продукт принёс!
— Ты что наделал, гад! Уноси его нахрен отсюда!
— В чём дело, братишка? Я продукт в срок принёс, все дедлайны соблюдены, фичи реализованы, баги пойманы!
— Какой продукт? Какой это нахрен продукт?! Ты в диспетчер задач смотрел, скотина?
— Зачем диспетчер задач, братишка? Диспетчера в ТЗ не было!
— Ну и мудак, оно же 4 гигабайта на старте только жрёт. Как клиенты это запускать будут, у них же засвопится всё нахрен!
— Ну как, как. Вот смотри, заходишь в меню «Пуск»…
— Какое меню, нахрен, ты понимаешь, что ты говнокод принёс? Дуй переписывать! Чтоб через пять минут больше полгигабайта не ело!
— Братишка, но у меня же всё работает, смотри, открываешь программу, создаёшь новую запись, всё работает! У меня вся команда, все тестировщики пользовались! Это продукт, это готовый продукт!
— Какие тестировщики, ты понимаешь, что у клиентов память не резиновая?! Ты в компьютерном магазине когда последний раз был? Какие там характеристики? Какие характеристики, скотина? Сколько гигабайт оперативки обычно?! Сколько гигабайт, сволочь ты эдакая?
— Ну 3, 4… Так продукт и потребляет же 4, братишка!
— Ой дурак, ой дурак… Как они работать-то с твоим продуктом будут? Другие программы запускать как?
— Ну закроют, запустят продукт…
— Рот себе закрой, придурок! Ты в каком веке живёшь, продукт под DOS, что ли, или под Palm OS? Знаешь, что такое многозадачность, свинья тупорылая?!!!
— Братишка, ну сроки же, пора продукт выпускать, а то испортится!
— Иди переписывай! Иди весь этот говнокод лично переписывай!
— Братишка, ну давай мы клиентам памяти докупим?
— Что докупим, кому докупим, куда докупим, твою мать! Ты совсем башней поехал!
— Это продукт, это готовый продукт! Всё в сроки, всё по ТЗ!
— Иди бюджетный ноутбук покупай, скотина! С двумя гигабайтами оперативки и жёстким диском! При мне тестить будешь!
— Братишка, ну клиенты новые купят, хорошие!
— Ох я тебя щяс самого куплю! Ох я тебя куплю, будешь у меня пожизненно код вылизывать, скотина! Какие фичи, какой продукт, ты понимаешь, что тут говнокод на говнокоде? Как мы клиентам в глаза смотреть будем?
— Братишка, ну вон же Slack сколько ест, посмотри.
— Какой Slack, скотина, в нём только программисты сидят! Ты что, ещё и вебни сюда напихал? Мы вам, скотинам, мощные ПК для работы, чтобы код быстро компилировался, а вы вместо этого скриптоты насовали и на свободных ресурсах Slack запускаете?! Ану марш на C++ переписывать, скотина! Родина дала ему Qt — используй, используй Qt, не, не хочу, хочу вебню жрать! И это программисты? Это программисты?!!! Ану марш с глаз моих, дерьма кусок, чтобы я больше твоих поделий не видел!
В вебе как раз проблемы ада зависимостей нет, а вот в десктопных приложениях — вполне есть.
Это раньше так было. Сейчас времена меняются. Десктопные платформы научились хранить разделяемые библиотеки в разных версиях, а в веб наоборот, пришли сложные многоуровневые зависимости, которых там раньше не было.
> пришли сложные многоуровневые зависимости, которых там раньше не было
В вебе нет зависимостей (каждое приложение содержит все, что требуется, а не тянет хз откуда), потому и проблем с ними быть не может.
В вебе нет зависимостей (каждое приложение содержит все, что требуется, а не тянет хз откуда), потому и проблем с ними быть не может.
«каждое приложение содержит все, что требуется, а не тянет хз откуда» — ага, а сайты тянущие внешние скрипты с 20 цднок одновременно тогда что?
Статически слинкованные зависимости (т. е. зашитые в бандл) — тоже зависимости. И если отдельно подключённые библиотеки хоть сколь-нибудь кэшировались, то с бандлами это не работает. Налицо чисто виндузяцкий подход: пока не обновят бандл — библиотеки будут старых версий, с известными багами и уязвимостями. И копия библиотеки в каждом бандле своя, что не лучшим образом сказывается на его размере — равно как и для виндовых сборок программ нормально весить десятки мегабайт, тогда как пакеты тех же программ для GNU/Linux-дистрибутивов весят пару мегабайт, а библиотеки ставятся отдельными пакетами, общими на все программы, совместимые с теми же версиями библиотек.
Справедливости ради, у ES6-совместимых библиотек работает поистине инновационное и, вроде, неслыханное доселе решение — три-шейкинг. Из библиотеки включаются только нужные в конкретном web-приложении компоненты, вплоть до отдельных методов, остальные в бандл не попадают. Помню, как я, озабоченный производительностью и легковесностью, в 2012-м году долго и кропотливо выковыривал из Java-библиотеки лишние методы, чтобы мидлет много не весил. А для JS это уже автоматика делает.
Да и без бандлов ситуация не особо лучше, если на сайты прикручена определённая версия библиотеки, а не последняя стабильная, например, или последняя в пределах мажорной версии. С одной стороны, это даёт повышенную стабильность, но с другой — вышеупомянутые проблемы. Я лично сталкивался на одном сайте с проблемой — после обновления движка на транскодерах Opera Mini там поломалась валидация форм, и вместе с этим — создание постов. Оказалось, что в соответствующем jQuery-плагине проблему оперативно починили, но на сайте до моего расследования продолжала использоваться конкретная захардкоженная старая версия.
Справедливости ради, у ES6-совместимых библиотек работает поистине инновационное и, вроде, неслыханное доселе решение — три-шейкинг. Из библиотеки включаются только нужные в конкретном web-приложении компоненты, вплоть до отдельных методов, остальные в бандл не попадают. Помню, как я, озабоченный производительностью и легковесностью, в 2012-м году долго и кропотливо выковыривал из Java-библиотеки лишние методы, чтобы мидлет много не весил. А для JS это уже автоматика делает.
Да и без бандлов ситуация не особо лучше, если на сайты прикручена определённая версия библиотеки, а не последняя стабильная, например, или последняя в пределах мажорной версии. С одной стороны, это даёт повышенную стабильность, но с другой — вышеупомянутые проблемы. Я лично сталкивался на одном сайте с проблемой — после обновления движка на транскодерах Opera Mini там поломалась валидация форм, и вместе с этим — создание постов. Оказалось, что в соответствующем jQuery-плагине проблему оперативно починили, но на сайте до моего расследования продолжала использоваться конкретная захардкоженная старая версия.
Справедливости ради, у ES6-совместимых библиотек работает поистине инновационное и, вроде, неслыханное доселе решение — три-шейкинг. Из библиотеки включаются только нужные в конкретном web-приложении компоненты, вплоть до отдельных методов, остальные в бандл не попадают. Помню, как я, озабоченный производительностью и легковесностью, в 2012-м году долго и кропотливо выковыривал из Java-библиотеки лишние методы, чтобы мидлет много не весил. А для JS это уже автоматика делает.Прям как в Turbo Pascal 1.0, выпущенном 35 лет назад? И почти как в OS/360, выпущенной полвека назад?
Иногда, глядя на «новомодные» технологии хочется плакать. Потому что как «серебрянная пуля» представляются вещи, которые, в общем-то известны десятилетиями. Хорошие вещи, правильные… вот только не «серебрянная пуля» они ни разу.
Единственный действенный способ борьбы с безграничным потребление ресурсов — голова. Позволяющая выбирать решения, не требующие гигабайтов и сотен процессорных ядер. Всё остальное — вторично.
> Единственный действенный способ борьбы с безграничным потребление ресурсов — голова.
Пока пользователю безграничное потребление ресурсов не мешает — никто экономить не будет. Голова тут не при чем.
Пока пользователю безграничное потребление ресурсов не мешает — никто экономить не будет. Голова тут не при чем.
Пока пользователю безграничное потребление ресурсов не мешает — никто экономить не будет. Голова тут не при чем
А, вы этого не замечаете, да? Вы не видели, как возмущаются ваши знакомые, что их смартфон через пару лет обновлений начинает почему-то еле ворочаться, хотя новых функций у него не прибавилось? Или браузер нынче не жрёт 100% ресурсов обычного офисного компа, и пользователи не возмущаются?
Нынешняя ситуация уже начинает раздражать практически всех, кроме разве что небольшой группки владельцев убер-девайсов, которые проблему заметят чуть позже.
> А, вы этого не замечаете, да? Вы не видели, как возмущаются ваши знакомые, что их смартфон через пару лет обновлений начинает почему-то еле ворочаться, хотя новых функций у него не прибавилось?
Нет, не видел. Смотрите, если бы пользователю была нужна производительность — это было бы конкурентным преимуществом. Тогда люди писали бы производительные приложения и отжимали рынок у непроизводительных. Но этого не происходит.
Штука ведь в том, что по факту со временем пользователь видит только ускорение работы. windows 10 на среднем компьютере 2014 года работает шустрее, чем windows xp на среднем компьютере 2001. Аналогично с сервисами и приложениями. Да, условное приложение из нулевых конечно сегодня работает шустрее. Но тогда, в нулевых, на конфе нулевых, оно работало медленнее, чем нынешний аналог на современной конфе. Так что пользователь по факту наблюдает лишь рост производительности, а вайнят только ITшники, потому что их бомбит.
Нет, не видел. Смотрите, если бы пользователю была нужна производительность — это было бы конкурентным преимуществом. Тогда люди писали бы производительные приложения и отжимали рынок у непроизводительных. Но этого не происходит.
Штука ведь в том, что по факту со временем пользователь видит только ускорение работы. windows 10 на среднем компьютере 2014 года работает шустрее, чем windows xp на среднем компьютере 2001. Аналогично с сервисами и приложениями. Да, условное приложение из нулевых конечно сегодня работает шустрее. Но тогда, в нулевых, на конфе нулевых, оно работало медленнее, чем нынешний аналог на современной конфе. Так что пользователь по факту наблюдает лишь рост производительности, а вайнят только ITшники, потому что их бомбит.
Нет, не видел.
Я это не сочинил. Это действительно так, и работа устройств через какое-то время перестаёт устраивать практически всех пользователей.
Смотрите, если бы пользователю была нужна производительность — это было бы конкурентным преимуществом. Тогда люди писали бы производительные приложения и отжимали рынок у непроизводительных. Но этого не происходит.
Это и есть конкурентное преимущество. Но для него нужны квалифицированные разработчики. А их в отрасли на общем фоне не так уж и много. Среднестатистический пользователь же сам не в состоянии выбрать среди двух десятков приложений то, которое лучшее, чтобы «проголосовать кошельком» или хотя бы лайками/звездочками. Он выберет то, которое сеошники засунули в топ. Т.е. что будут покупать/устанавливать, сейчас определяют не столько пользователи и разработчики, сколько маркетинг. Элементарные законы свободного рынка сейчас не работают.
windows 10 на среднем компьютере 2014 года работает шустрее, чем windows xp на среднем компьютере 2001.
Вы одновременно и правы, и нет :)
Если брать средний компьютер среди всех используемых, то да, Windows 10 работает шустрее. Если брать средний компьютер среди новых продаваемых, то средняя машина конца 2001 года примерно соответствовала рекомендуемым требованиям для Windows XP, и там ничего не «тормозило», равно как и средняя машина конца 2014 года соответствовала рекомендуемым требованиям Windows 10.
Но сейчас Windows 10 действительно работает шустро на большем количестве компьютеров. Почему? Потому что их производительность практически перестала расти, и новый компьютер 2014 года не слишком отличался от нового компьютера, например, 2012 года.
Смотрите на 2001-й год — пользователям доступны гигагерцовые процессоры, в то время как пару лет назад до этого топовым был P3-450.
Теперь смотрите на 2018-й год. Мейнстрим у нас Kaby Lake, свежее прошлогоднее семейство. Насколько оно быстрее, например, процессоров семейства Sandy Bridge? О, на целых 20%. Вроде бы прогресс, да? Но минуточку, сандики выпущены в 2011 году! Т.е. производительность процессоров выросла на 20% за семь лет. Возьмите 2001-й год и отмотайте семь лет назад. Да вы в эпоху палеолита провалитесь, когда в топе прайсов ещё 486 DX100 встречались.
Поэтому розовые очки пора снимать, производительность компьютеров расти практически перестала много лет назад. А разработка софта как жила по заветам 1990-х годов, так и живёт. Причем судя по
Так что пользователь по факту наблюдает лишь рост производительности
… даже не утруждает себя общением с пользователями.
> Это и есть конкурентное преимущество. Но для него нужны квалифицированные разработчики.
Квалифицированных разработчиков вполне достаточно, вы же не хотите сказать, что их вообще нет? Надо просто им поставить соовтетствующую задачу. Но никто не ставит.
> Потому что их производительность практически перестала расти, и новый компьютер 2014 года не слишком отличался от нового компьютера, например, 2012 года.
Если производительность перестала расти — то это аргумент как раз за мою точку зрения.
> Но минуточку, сандики выпущены в 2011 году! Т.е. производительность процессоров выросла на 20% за семь лет.
Производительность процессора очень мало влияет на воспринимаемую скорость пользователем. Типичные задачи (если не считать игор) не способны даже на четверть процессор загрузить, он простаивает и ждет память после кешмисса. Так что вопрос в памяти, ее количестве и скорости, в ссдшниках. Вот это и дает буст, а не процессор. Просто замена хдд на ссд ускоряет работу системы _в разы_.
Квалифицированных разработчиков вполне достаточно, вы же не хотите сказать, что их вообще нет? Надо просто им поставить соовтетствующую задачу. Но никто не ставит.
> Потому что их производительность практически перестала расти, и новый компьютер 2014 года не слишком отличался от нового компьютера, например, 2012 года.
Если производительность перестала расти — то это аргумент как раз за мою точку зрения.
> Но минуточку, сандики выпущены в 2011 году! Т.е. производительность процессоров выросла на 20% за семь лет.
Производительность процессора очень мало влияет на воспринимаемую скорость пользователем. Типичные задачи (если не считать игор) не способны даже на четверть процессор загрузить, он простаивает и ждет память после кешмисса. Так что вопрос в памяти, ее количестве и скорости, в ссдшниках. Вот это и дает буст, а не процессор. Просто замена хдд на ссд ускоряет работу системы _в разы_.
Квалифицированных разработчиков вполне достаточно, вы же не хотите сказать, что их вообще нет?
Я хочу сказать, что во многих командах их действительно нет. Или есть, но не того профиля, который требуется для создания качественного приложения под целевую платформу. Например, есть JS-разработчик, которого посадили писать под десктоп.
Если производительность перестала расти — то это аргумент как раз за мою точку зрения.
В смысле? Что надо писать больше плохого и неповоротливого софта?
Производительность процессора очень мало влияет на воспринимаемую скорость пользователем.
Я процессор привёл как пример. Замените слово «процессор» на «компьютер». Никаких радикальных улучшений ни в быстродействии ОЗУ, ни в его емкости не происходит. Был один качественный скачок по накопителям при появлении SSD, но других даже в отдаленной перспективе не предвидится. Так что забывайте про мантру «выпустить сейчас как получится, все равно через полгода быстродействие компьютеров дорастёт». Не дорастёт. Есть ещё какой-то запас по росту у смартфонов, но и это временно.
> Я хочу сказать, что во многих командах их действительно нет. Или есть, но не того профиля, который требуется для создания качественного приложения под целевую платформу.
Если квалифицированных разработчиков не существует, то может это потому, что вы так само понятие квалифицированного разработчика определили, что они просто и существовать не могут в нашей вселенной?
> В смысле?
В том смысле, что падение производительности идет не так быстро.
Смотрите, еще раз — речь о том, что _с точки зрения пользователя_ программы стали работать _быстрее_ (!). И это факт. И только специалисты понимают, что программы стали работать быстрее, например, в полтора раза, а железо стало быстрее в десять. И их бомбит. Но пользователь то этого не понимает. Он наблюдает строго позитивную картину.
>. Так что забывайте про мантру «выпустить сейчас как получится, все равно через полгода быстродействие компьютеров дорастёт». Не дорастёт.
Так на «дорост» никто ничего не выпускает (разве что если речь об играх-долгостроях), расчет идет всегда на имеющиеся устройства. Сперва растут выч. мощности, а потом уже «замедляются» (так назовем) приложения. Не наоборот.
Если квалифицированных разработчиков не существует, то может это потому, что вы так само понятие квалифицированного разработчика определили, что они просто и существовать не могут в нашей вселенной?
> В смысле?
В том смысле, что падение производительности идет не так быстро.
Смотрите, еще раз — речь о том, что _с точки зрения пользователя_ программы стали работать _быстрее_ (!). И это факт. И только специалисты понимают, что программы стали работать быстрее, например, в полтора раза, а железо стало быстрее в десять. И их бомбит. Но пользователь то этого не понимает. Он наблюдает строго позитивную картину.
>. Так что забывайте про мантру «выпустить сейчас как получится, все равно через полгода быстродействие компьютеров дорастёт». Не дорастёт.
Так на «дорост» никто ничего не выпускает (разве что если речь об играх-долгостроях), расчет идет всегда на имеющиеся устройства. Сперва растут выч. мощности, а потом уже «замедляются» (так назовем) приложения. Не наоборот.
Если квалифицированных разработчиков не существует
Я не догадываюсь, какими логическими преобразованиями вы получили этот вывод из фразы:
во многих командах их действительно нет. Или есть, но не того профиля
Подскажете?
Смотрите, еще раз — речь о том, что _с точки зрения пользователя_ программы стали работать _быстрее_
И это я не понимаю, откуда вы могли взять. Вот смотрите, QIP работал мгновенно практически на любой конфигурации в своё время. Сейчас у меня на компьютере с 16Гб памяти и топовым NVMe SSD Samsung 950Pro десктопный вайбер иногда подлагивает.
Кстати, о вайбере. Он регулярно обновляется, правда, без каких-либо видимых изменений. Последнее заметное было декабре прошлого года. Добавилась функция «Ответить на сообщение». Спасибо, милые разработчики, аплодирую стоя. Напомню, мы говорим о немаленькой профессиональной команде с многолетним опытом и неслабым бюджетом. Гора рожает мышь, и это в ИТ творится повсеместно.
Он наблюдает строго позитивную картину.
см.
… даже не утруждает себя общением с пользователями.
Пользователей всё чаще наши поделки огорчают и раздражают, а иногда их откровенно тошнит. У них просто альтернатив пока нет. Пока.
> Я не догадываюсь, какими логическими преобразованиями вы получили этот вывод из фразы:
Если они существуют — где же те классные производительные приложения, захватывающие рынок?
> И это я не понимаю, откуда вы могли взять.
Ну это объективный факт. Сейчас вы плачетесь что вам 20 вкладок мало, а в 2000 компьютер 10 не выдерживал. qip мог открываться полминуты, винда — грузиться 5 минут, а не 15 секунд, как сегодня.
Условно говоря, в тогдашние 512мб оперативки влезало 20 приложений по 25мб. В нынешние 16гб влезает 80 приложений по 200мб. Вчетверо больше, чем было раньше.
> Пользователей всё чаще наши поделки огорчают и раздражают, а иногда их откровенно тошнит.
Да пользователя всегда тошнит, когда что-то меняется. Это естественная реакция.
Если они существуют — где же те классные производительные приложения, захватывающие рынок?
> И это я не понимаю, откуда вы могли взять.
Ну это объективный факт. Сейчас вы плачетесь что вам 20 вкладок мало, а в 2000 компьютер 10 не выдерживал. qip мог открываться полминуты, винда — грузиться 5 минут, а не 15 секунд, как сегодня.
Условно говоря, в тогдашние 512мб оперативки влезало 20 приложений по 25мб. В нынешние 16гб влезает 80 приложений по 200мб. Вчетверо больше, чем было раньше.
> Пользователей всё чаще наши поделки огорчают и раздражают, а иногда их откровенно тошнит.
Да пользователя всегда тошнит, когда что-то меняется. Это естественная реакция.
Если они существуют — где же те классные производительные приложения, захватывающие рынок?
Дык есть же они. Среди мессенджеров, например, Телеграм — он качественный, ест умеренно, работает быстро. А насчет «захвата рынка», я уже писал, его захватывают не качеством, а рекламой.
в 2000 компьютер 10 не выдерживал. qip мог открываться полминуты, винда — грузиться 5 минут, а не 15 секунд
На компьютере 2000-го года в 2000-м году? Вы серьезно? Ну не надо так. На чём-то раза в четыре более слабом, возможно. Если вы возьмёте новый комп 2000 года, это будет что-то вроде Пентиум-3/Атлон 450-600, 64-128Мб ОЗУ, и винт гиг на 10-20. Тогдашняя популярная ОС Windows 98 на нём летала со всем софтом. Или, к примеру, популярные средства разработки, будь-то Delphi или Visual Studio 6, запускались мгновенно, билдили проекты в разы быстрее, чем сейчас на «16 гб».
Да пользователя всегда тошнит, когда что-то меняется. Это естественная реакция.
Именно эта реакция и отличает хорошие, удачные продукты от плохих.
del
> равно как и для виндовых сборок программ нормально весить десятки мегабайт
Экономить аж десятки мегабайт в 2018 — очень актуально.
Экономить аж десятки мегабайт в 2018 — очень актуально.
Экономить аж десятки мегабайт в 2018 — очень актуально.
Экономить десятки мегабайт актуально даже для меня с топ десктоп процом и 32гб оперативы.
Потому как я это брал для своих целей, и я хочу, что б там шустро работали 2 виртуали, и среда разработки, а не какой-нить скайп и браузер, который почти не изменили функционал, но стали занимать в 10 раз больше.
PS:
Иначе бы я взял предложенный менеджером пентиум или i3 с 4гб оперативы, обычным хдд и получил очень заметные тормоза скайпа или вайбера. Которые регулярно вижу у секретаря. Никак не понимаю, когда кто-то доказывает, что надо брать топконфиг для чатиков.
> Потому как я это брал для своих целей, и я хочу, что б там шустро работали 2 виртуали
Если у вас на 32гб тормозят виртуалки, то от экономии 50мб скайпом они тормозить не перестанут. Обращайтесь к разработчиком виртуалок, пусть оптимизируют потребление памяти у них.
Если у вас на 32гб тормозят виртуалки, то от экономии 50мб скайпом они тормозить не перестанут. Обращайтесь к разработчиком виртуалок, пусть оптимизируют потребление памяти у них.
> Если у вас на 32гб тормозят виртуалки, то от экономии 50мб скайпом они тормозить не перестанут.
Хватит оправдывать чей-то быдлокодинг. Вам самими не понятно, что виртуалки это не самоценный софт, а в них внутри что-то ещё запущено? Там скайп сожрал на 50мб больше (на самом деле больше 50), там ещё один «шедевр» с аналогичной логикой сожрал +гбайт, и когда у вас вся машина забита такими вот поделиями, вы тратите в разы больше ресурсов чем надо.
Хватит оправдывать чей-то быдлокодинг. Вам самими не понятно, что виртуалки это не самоценный софт, а в них внутри что-то ещё запущено? Там скайп сожрал на 50мб больше (на самом деле больше 50), там ещё один «шедевр» с аналогичной логикой сожрал +гбайт, и когда у вас вся машина забита такими вот поделиями, вы тратите в разы больше ресурсов чем надо.
то от экономии 50мб скайпом они тормозить не перестанут.если б за 10 лет увеличилось на 50 — нет, не было бы проблем.
А вот когда 50 каждый год, это уже серьёзная проблема.
На самом деле не 50мб, а (как пытались тут всех убедить) все доступные ресурсы. Каждый софт, при 2х виртуалках это получается 400% производительности сожраны, даже на каждой запущено по одному приложению (виртуалки — сами приложения и должны быть хорошими).
> Каждый софт, при 2х виртуалках это получается 400% производительности сожраны
Еще раз — это конкретная проблема виртуалок. ОС не в состоянии менеджить ресурсы виртуалок. Не в скайпе проблема. В виртуалках.
Еще раз — это конкретная проблема виртуалок. ОС не в состоянии менеджить ресурсы виртуалок. Не в скайпе проблема. В виртуалках.
Это конкретная проблема некачественного софта, и только его.
Не соглашусь. Вам выше товарищи пишут, что поскольку Скайп хочет много памяти, в настройках виртуалки тоже приходится доступный ресурс по оперативной памяти поднимать, чтобы там внутри всё не тормозило, и сама виртуальная машина тут ни при чём совершенно.
И если задержку в ответе мускула на даже на 1 секунду никто не заметит
Дайте угадаю — коммерческим программированием не занимались. 1 секунду не заметят в сложном запросе, который выполняется от минуты, а если он на каждый чих (запросов в секунду могут укладываться десятки) будет добавлять секунду, то его выкинут.
И тормоза в большинстве случаев от говнокода — если вы на каждый чих распределяете память (не понимая когда это происходит), копируете кучу данных, лишний раз лазаете по сложной иерархии, то это и порождает тормоза.
> Дайте угадаю — коммерческим программированием не занимались. 1 секунду не заметят в сложном запросе, который выполняется от минуты, а если он на каждый чих (запросов в секунду могут укладываться десятки) будет добавлять секунду, то его выкинут.
Так речь о запросе в минуту максимум.
> И тормоза в большинстве случаев от говнокода — если вы на каждый чих распределяете память (не понимая когда это происходит), копируете кучу данных, лишний раз лазаете по сложной иерархии, то это и порождает тормоза.
А чтобы этого всего не делать — надо заранее распределить память, скопировать данные, закешировать лазание по иерархии. То есть — отожрать тот самый гиг оперативной памяти :)
Так речь о запросе в минуту максимум.
> И тормоза в большинстве случаев от говнокода — если вы на каждый чих распределяете память (не понимая когда это происходит), копируете кучу данных, лишний раз лазаете по сложной иерархии, то это и порождает тормоза.
А чтобы этого всего не делать — надо заранее распределить память, скопировать данные, закешировать лазание по иерархии. То есть — отожрать тот самый гиг оперативной памяти :)
Не увидел где было про «запрос в минуту», это какой-то крайне непопулярный сайт (там и запрос в неделю может быть), но при нормальных нагрузках такие задержики недопустимы и проектируются СУБД явно не в расчёте на «запрос в минуту».
> надо заранее распределить память, скопировать данные, закешировать лазание по иерархии
Только вот сколько под это съедать памяти и ресурсов. Когда данные исчисляются парой мегабайт, а съедаются под них сотни — вот это уже не очень выглядит.
> надо заранее распределить память, скопировать данные, закешировать лазание по иерархии
Только вот сколько под это съедать памяти и ресурсов. Когда данные исчисляются парой мегабайт, а съедаются под них сотни — вот это уже не очень выглядит.
> Не увидел где было про «запрос в минуту», это какой-то крайне непопулярный сайт
А при чем тут сайт?
У нас просто мускуль на домашнем пека. Мы ведь с мессенджером сравниваем?
> Только вот сколько под это съедать памяти и ресурсов. Когда данные исчисляются парой мегабайт, а съедаются под них сотни — вот это уже не очень выглядит.
Так нужны не просто данные, а данные в определенном представлении (удобном потом для конкретных кейсов конкретного приложения). Это предполагает и накладные расходы на хранение и многократное дублирование.
А при чем тут сайт?
У нас просто мускуль на домашнем пека. Мы ведь с мессенджером сравниваем?
> Только вот сколько под это съедать памяти и ресурсов. Когда данные исчисляются парой мегабайт, а съедаются под них сотни — вот это уже не очень выглядит.
Так нужны не просто данные, а данные в определенном представлении (удобном потом для конкретных кейсов конкретного приложения). Это предполагает и накладные расходы на хранение и многократное дублирование.
У нас просто мускуль на домашнем пека. Мы ведь с мессенджером сравниваем?
Мы сравниваем MySQL в его родной среде (под нагрузкой) и мессенджер у пользователя (без особой нагрузки) и удивляемся что мессенджер сливает. Его, наверное, эффективные программисты писали, while(true) malloc(1);
многократное дублирование.
Десяти-стократное? Это и есть говнокод.
Мессенджер же по файлам/памяти не бегает.
Скажите это разработчикам Скайпа, которые умудрились сделать синхронизацию чатов из тысяч мелких файлов, так что на HDD приходилось удалять профиль чтобы просто запустить клиент.
В мессенджере база с одним подключением, локальная, небольшой модуль отрисовки и небольшой сетевой модуль. У SQL-сервера задачи всё-таки побольше — тт и целостность данных, и множественные параллельные запросы и те же ХП&Co, если мессенджер использует такую СУБД как зависимость, то стоит выкинуть такой мессенджер. У него, наверное, отрисовка через UnrealEngine идёт.
Просто потому, что если это будет не так, то другой разработчик, такой же технически грамотный, но лучше понимающий как работает рынок — выпустит продукт раньше и захватит рынок.
Понимаете, нет никакой причины делать ресурсоемкий и неэффективно использующий ресурсы софт. Ни технической, ни экономической. Вы можете брать для своего проекта хорошие решения и хорошие библиотеки, а можете брать первое, что попадётся под руку. Первое не требует сколько-нибудь значимых затрат по времени, чтобы ваши конкуренты вас опередили. Это всего лишь безразличие многих разработчиков к качеству их продукции.
просто обязан выпускать вещь, которая занимает более-менее все ресурсы у типичного пользователя
Это сарказм? Я разработчик блокнота, сосед разработчик калькулятора, пользователь запускает оба наших продукта для посчитать и записать результат, система загружена на 200%. Мы превосходные разработчики! Если брать прикладное ПО, которое обеспечивает какой-то АРМ, то даже там надо запускать всякие офисы для отчётов и деятельность разная — одно дело вбивать какой-то документ, а другой — построение тяжёлого отчёта, в какой момент требуется загружать на 100%? Если не всё время (99% времени заносятся данные), то программист плох, т.к. не выполнил свои обязанности по 100% загрузке.
Это сарказм?Это больше похоже на реальность.
У нас тут (в нашей реальности в прошлом году) 13% CPU тратилось на мигание курсора.
> Это сарказм?
Ну вообще-то все верно. Купил я, например, 16гб оперативной памяти, а общее потребление, допустим, 10гб. Конечно же, логичнее потратить оставшиеся 6гб на всякого рода кеширование.
Я платил деньги не за то, чтобы эти гигабайты просто _были_, а за то, чтобы они использовались. Аналогично, вобщем-то, с процессором, на кой хрен мне гигагерцы, если они не используются? Добавьте какой-нибудь функционал (который будет хотя бы условно полезным), который их нагрузит, я как пользователь только выигрываю.
Ну вообще-то все верно. Купил я, например, 16гб оперативной памяти, а общее потребление, допустим, 10гб. Конечно же, логичнее потратить оставшиеся 6гб на всякого рода кеширование.
Я платил деньги не за то, чтобы эти гигабайты просто _были_, а за то, чтобы они использовались. Аналогично, вобщем-то, с процессором, на кой хрен мне гигагерцы, если они не используются? Добавьте какой-нибудь функционал (который будет хотя бы условно полезным), который их нагрузит, я как пользователь только выигрываю.
логичнее потратить оставшиеся 6гб на всякого рода кеширование.
Логичнее, поэтому любая современная ОС этим занимается автоматически, со стороны разработчиков приложений никаких дополнительных действий обычно не требуется :) (Исключения вроде mysql это исключения.)
Конечно же, логичнее потратить оставшиеся 6гб на всякого рода кеширование.
Да, только когда у вас появится софт, которому действительно для производительности нужно всякого рода кеширование, ваши гигабайты и гигагерцы будут поделены и сожраны мелкими утилитами. Надо вам такое использование вычислительных ресурсов?
Вот я смотрю, например, сейчас у меня плагин для Skype Callnote жрет целиком одно ядро процессора и 140 мегабайт памяти. Это плагин для записи звонков. Спасибо ему за утилизацию моих гигагерцев, но он сейчас не делает ничего. Просто висит в памяти и ждет, когда кто-то позвонит. И при этом употребляет целое ядро. Нифига не чувствую себя в выигрыше, если честно.
> Да, только когда у вас появится софт, которому действительно для производительности нужно всякого рода кеширование, ваши гигабайты и гигагерцы будут поделены и сожраны мелкими утилитами. Надо вам такое использование вычислительных ресурсов?
Конечно же, надо! Оптимизация должна производиться в приоритете на наиболее типичные кейсы. Отсутствие подобного кеширования приводет к тому, что компьютер будет _иногда_ работать быстро (когда вы включили то самое приложение) и тормозить во всех остальных случаях.
> Это плагин для записи звонков. Спасибо ему за утилизацию моих гигагерцев, но он сейчас не делает ничего. Просто висит в памяти и ждет, когда кто-то позвонит.
Это уже проблема ОС, а не плагина. У плагина нет никакого способа эффективно определить будущую загрузку системы и освободить память/подгрузиться, когда требуется.
Конечно же, надо! Оптимизация должна производиться в приоритете на наиболее типичные кейсы. Отсутствие подобного кеширования приводет к тому, что компьютер будет _иногда_ работать быстро (когда вы включили то самое приложение) и тормозить во всех остальных случаях.
> Это плагин для записи звонков. Спасибо ему за утилизацию моих гигагерцев, но он сейчас не делает ничего. Просто висит в памяти и ждет, когда кто-то позвонит.
Это уже проблема ОС, а не плагина. У плагина нет никакого способа эффективно определить будущую загрузку системы и освободить память/подгрузиться, когда требуется.
Конечно же, надо! Оптимизация должна производиться в приоритете на наиболее типичные кейсы
Что такое «наиболее типичный кейс»? Я не ошибусь, если скажу, например, что все ваши данные в вашем любимом мессенджере (контакты, профили, база текстовых сообщений и всё остальное, кроме скачанных файлов, которые он и так не кеширует) за несколько лет истории влезут в пару мегабайт вместе со служебными структурами и индексами/хешами для быстрого поиска. Вот наиболее типичный кейс — когда он запрашивает под свои структуры столько, сколько ему может понадобиться хотя бы в пределах сотни лет вашей работы с ним. Если он запрашивает памяти для хранения истории лет на пятьсот вперёд, то это не оптимизация, а её полное отсутствие.
Это уже проблема ОС, а не плагина. У плагина нет никакого способа эффективно определить будущую загрузку системы
Да вы шо? ОС должна за ваши приложения решать, давать им процессорное время и память, или не давать? О_о Дескать, дружище, извини, но у тебя там запущен ролик с ютуба, поэтому я заберу ресурсы у записывалки звонков, ничего, что записать не сможет — надо было самому думать, когда ролик запускал.
Боюсь, вам такая ОС не понравится. Всегда и везде ОС выделяет ресурсы приложениям в том объеме, который они запрашивают, а не по своему усмотрению. И если одно приложение, которое не делает ничего, жрет четверть ресурсов компьютера, это признак его плохого качества, а не каких-либо других причин.
Подозреваю, что оный плагин в ожидании тупо крутит бесконечный цикл, и это таки проблема плагина, точнее — с его авторами. Вообще, полная утилизация проца или одного ядра (для многоядерных) чаще всего означает, что прога зациклилась.
на кой хрен мне гигагерцы, если они не используются
"Труба у унитаза такая не для постоянного использования, а для пиковых нагрузок"(Ц)
Мегагерцы нужны в моменты пика, если постоянно майнить на 100% загрузки, то процессор быстро откинет коньки, они делаются с расчётом на длительную эксплуатацию при далёкой от 100% загрузке. Тем более при полной загрузке начнётся троттлинг и тормоза.
огичнее потратить оставшиеся 6гб на всякого рода кеширование
ОС с этим неплохо справляется.
> ОС с этим неплохо справляется.
Да нет, как раз плохо. Для нормального кеширования надо знать как работает приложение, какие данные в каком случае и в каком виде ему понадобятся. И ОС этой информацией не обладает. У ОС есть, фактически, только страничный кеш, который в большинстве случаев тут никак не помогает.
Да нет, как раз плохо. Для нормального кеширования надо знать как работает приложение, какие данные в каком случае и в каком виде ему понадобятся. И ОС этой информацией не обладает. У ОС есть, фактически, только страничный кеш, который в большинстве случаев тут никак не помогает.
Те приложения, которым это надо — реализуют свои кеши, но это обычно не скайп, который сожрал дофига памяти, а как раз СУБД (потому она и сложнее) и тот же торрент-клиент, где много случайного чтения. Базы тех же мессенджеров или файлы офисных пакетов компактнее, не нуждаются в частом случайном чтении и вполне обходятся кшеме ОС (если написаны нормально).
Так все вообще-то наоборот полностью. Как раз бд (и тем более торренты, в случае которых ручной кеш не то что обычно бесполезен, а зачастую и вреден) вполне могут эффективно использовать дефолтные системы кеширования ОС. А вот в мессенджере их использовать никак не выйдет — и профиль использования не тот и характер данных не позволяет.
В мессенджере и требования к производительности, имхо, куда ниже, чем в том же торренте (и тем более в серьёзной СУБД).
А вот в мессенджере их использовать никак не выйдет
Вы не поверите (с)
Если вы заглянете в папку с данными вашего мессенджера, будь-то скайп, вайбер, телеграм и другие, вы обнаружите, что он данные как раз хранит в базе данных, все они используют СУБД SQLite для хранения и профилей, и сообщений.
Которая кстати совсем не требует много ресурсов. Так куда уходит вся память, Зин?))
Не знаю. Но вайбер в декабре 2017-го года меня порадовал новой фичей — у него появилась функция «ответить на сообщение». Очевидно, несколько лет разработки этой выдающейся и без сомнения бросающей вызов всем конкурентам функции должны быть вознаграждены как минимум парой десятков мегабайт памяти.
А если без сарказма, то для меня действительно большая загадка, чем все эти парни занимаются, и что они такого добавляют в свой софт, что он растёт в размере и ресурсоемкости, время от времени приобретая крохотные фичи, код которых раньше умещался в килобайты.
А если без сарказма, то для меня действительно большая загадка, чем все эти парни занимаются, и что они такого добавляют в свой софт, что он растёт в размере и ресурсоемкости, время от времени приобретая крохотные фичи, код которых раньше умещался в килобайты.
Мессенджер имеет очень ограниченный объём данных, считывает настройки и список контактов на старте (ОС вполне нормально справляется с кешированием, особенно для одного файла), у СУБД выборка может быть достаточно хаотичной и объём не влезает в память многократно (зачастую даже индексы не влезают) и потому требуется управление, разная политика вытеснения кеша для данных, индексов, метаданных, объектов кода. ОС с этим справится не так хорошо, потому и говорил о слабом представлении о разработке — всё с точностью до наоборот.
Многие стали юзать SQLite — база, но с ограниченным набором типов объектов и малого объёма (должна быть по крайней мере) — потому кешируется при обращении и дальше чтение оттуда дешёвое, даже если на каждый чих.
> Мессенджер имеет очень ограниченный объём данных, считывает настройки и список контактов на старте
Вы говорите про файловый кеш, а я говорю про кеш данных. В случае мессенджера 99% данных вообще ни в каких файлах не хранится, по-этому ОС их закешировать в принципе не в состоянии. С другой стороны, БД работает как раз с данными из файлов (большей частью) — и они прекрасно кешируются системой. Конечно, БД делает еще много чего (по-этому ручной кеш даст значительный выигрыш), но суть в том, что кеш ОС для БД работает на порядок эффективнее, чем для мессенджера.
Вы говорите про файловый кеш, а я говорю про кеш данных. В случае мессенджера 99% данных вообще ни в каких файлах не хранится, по-этому ОС их закешировать в принципе не в состоянии. С другой стороны, БД работает как раз с данными из файлов (большей частью) — и они прекрасно кешируются системой. Конечно, БД делает еще много чего (по-этому ручной кеш даст значительный выигрыш), но суть в том, что кеш ОС для БД работает на порядок эффективнее, чем для мессенджера.
В случае мессенджера 99% данных вообще ни в каких файлах не хранится
Я вам там чуть выше написал — все современные мессенджеры все свои данные хранят в базе данных. В файле, представьте себе. Который, представьте себе, сидит в дисковом кеше ОС точно так же, как любой другой аналогичный.
Вообще, вы чёрта с два найдете у себя на компьютере сейчас хоть одну программулину, которая своё текущее состояние не сбрасывает регулярно в какой-то файл, журнал или базу данных.
> Я вам там чуть выше написал — все современные мессенджеры все свои данные хранят в базе данных.
Мы говорим о тех данных, которые вообще нигде не хранятся и существуют только во время работы приложения.
> Вообще, вы чёрта с два найдете у себя на компьютере сейчас хоть одну программулину, которая своё текущее состояние не сбрасывает регулярно в какой-то файл, журнал или базу данных.
Сбрасывать состояние в файл с надеждой, что ОС нормально это все закеширует — так себе методика.
Мы говорим о тех данных, которые вообще нигде не хранятся и существуют только во время работы приложения.
> Вообще, вы чёрта с два найдете у себя на компьютере сейчас хоть одну программулину, которая своё текущее состояние не сбрасывает регулярно в какой-то файл, журнал или базу данных.
Сбрасывать состояние в файл с надеждой, что ОС нормально это все закеширует — так себе методика.
Но сбрасывать всё равно нужно, если эти данные понадобятся при следующем запуске. Ваш КО
Мы говорим о тех данных, которые вообще нигде не хранятся и существуют только во время работы приложения.
Не «мы», а «вы». Ну и много ли там таких данных? Сто байт служебных переменных? Двести байт?
Мессенджер даже состояние текущих вкладок сохраняет в ваш профиль, не говоря уже о сообщениях. Т.е. как раз наоборот, 99% данных у него хранится в базе данных, и какие-то крохи действительно существуют только в памяти в пределах одного сеанса работы.
Сбрасывать состояние в файл с надеждой, что ОС нормально это все закеширует — так себе методика.
Другой эффективной пока не придумали. Десктопные ОС, как ни странно, лет этак 30 назад научились нормально кешировать всё, что им дают для записи в файлы, а разработчики прикладного софта научились этому доверять. Вы вот сколько десятилетий назад изучали файловый ввод/вывод?
>Не «мы», а «вы». Ну и много ли там таких данных?
Ну в оснвном с ними приложение и работает. Можно для упрощения считать, что других данных там и нет.
> Другой эффективной пока не придумали.
Ну как не придумали? Придумали — кешировать руками. И кешируют руками не только там, где надо (в мессенджерах), но и там где не сильно надо (бд), и там, где не надо вообще (в торрентах). Так что на практике у нас с доверием системному кешу как-то похуже обстоят дела, чем вы пытаетесь показать.
Ну в оснвном с ними приложение и работает. Можно для упрощения считать, что других данных там и нет.
> Другой эффективной пока не придумали.
Ну как не придумали? Придумали — кешировать руками. И кешируют руками не только там, где надо (в мессенджерах), но и там где не сильно надо (бд), и там, где не надо вообще (в торрентах). Так что на практике у нас с доверием системному кешу как-то похуже обстоят дела, чем вы пытаетесь показать.
Ну в оснвном с ними приложение и работает. Можно для упрощения считать, что других данных там и нет.
Как-то не вижу логики в ваших рассуждениях. Абсолютно все данные в абсолютно всех программах так или иначе попадают в ОЗУ перед использованием. И отличия как раз в том, что некоторые данные существуют только в ОЗУ, а некоторые попадают туда с диска, и на диск потом сохраняются. Данные мессенджеров — как раз второй случай.
но и там где не сильно надо (бд),
Разработчики БД смотрят на вас с изумлением.
> Данные мессенджеров — как раз второй случай.
Нет, данные мессенджера — как раз первый случай. Посмотрите, сколько данных мессенджер хранит на диске, и сколько он занимает в ОЗУ.
> Разработчики БД смотрят на вас с изумлением.
Мы же говорим о сравнительных показателях. Естественно, в бд это нужно, но просто меньше чем в мессенджерах (потому что кеш ОС под данные и задачи бд ложится хорошо, а под данные и задачи мессенджеров — совсем нет).
Нет, данные мессенджера — как раз первый случай. Посмотрите, сколько данных мессенджер хранит на диске, и сколько он занимает в ОЗУ.
> Разработчики БД смотрят на вас с изумлением.
Мы же говорим о сравнительных показателях. Естественно, в бд это нужно, но просто меньше чем в мессенджерах (потому что кеш ОС под данные и задачи бд ложится хорошо, а под данные и задачи мессенджеров — совсем нет).
Так что же там за данные у мессенджера, которые нельзя сбросить на диск? Я вот тоже вас не совсем понимаю.
Ваша же цитата. И что же там тогда такое хранится в памяти? История сообщений за последние пару часов (которой нет на диске, но есть на сервере и в RAM)? Окей, но не сотню метров же она весит. Тем более, видел я, сколько сообщений доступны для мгновенного прочтения без подзагрузки, например, в том же скайпе. Не так уж много…
Не говоря уже о том, что это «немного», всё же, берётся с диска при запуске, имхо (то есть основная часть сообщений на сервере, а самое недавнее — на диске, и в память попадает только при загрузке, причём и весит копейки).
Посмотрите, сколько данных мессенджер хранит на диске, и сколько он занимает в ОЗУ.
Ваша же цитата. И что же там тогда такое хранится в памяти? История сообщений за последние пару часов (которой нет на диске, но есть на сервере и в RAM)? Окей, но не сотню метров же она весит. Тем более, видел я, сколько сообщений доступны для мгновенного прочтения без подзагрузки, например, в том же скайпе. Не так уж много…
Не говоря уже о том, что это «немного», всё же, берётся с диска при запуске, имхо (то есть основная часть сообщений на сервере, а самое недавнее — на диске, и в память попадает только при загрузке, причём и весит копейки).
Посмотрите, сколько данных мессенджер хранит на диске, и сколько он занимает в ОЗУ.
А какое отношение потребляемый мессенджером объем ОЗУ имеет к данным? Современные приложения большей частью состоят из «мусорного» кода, который тянут за собой библиотеки и компоненты, и который никак не используется при работе приложения, но при этом инициализируется и потребляет память. Мессенджеры тут не исключение.
> А какое отношение потребляемый мессенджером объем ОЗУ имеет к данным?
В смысле, какое? Совершенно прямое. В ОЗУ лежат необходимые для работы мессенджера данные. Если эти данные оттуда убрать, то мессенджер работать перестанет.
> Современные приложения большей частью состоят из «мусорного» кода
Это, конечно, не так.
В смысле, какое? Совершенно прямое. В ОЗУ лежат необходимые для работы мессенджера данные. Если эти данные оттуда убрать, то мессенджер работать перестанет.
> Современные приложения большей частью состоят из «мусорного» кода
Это, конечно, не так.
Совершенно прямое. В ОЗУ лежат необходимые для работы мессенджера данные.
Необходимые для работы мессенджера данные — это несколько мегабайт сообщений, данные профиля, ключи шифрования, состояние его UI. Всё остальное либо избыточное, либо вообще мусор. Например, как вы выше говорили, DOM. Для функционирования мессенджера DOM не нужен. Это совершенно побочный костыль, который появился потому, что какая-то команда разработчиков решила сэкономить на разработке UI за счет его качества и слепила его на электроне или ещё каком-то JS-движке.
Это, конечно, не так.
Это именно так. Сделайте приложение с одинаковым функционалом в Visual Studio начала 2000-х, и современной. Или откройте один и тот же сайт в Хроме десятилетней давности и современном. И сравните потребление памяти. Будет отличаться в разы, при одинаковом функционале.
При этом, ясен пень, современный Хром будет поддерживать гриды, флексбоксы и тому подобное, и пусть у вас на сайте их и не будет, но память всё это сожрет. И это именно мусорный код для вашего приложения.
Вы вообще в состоянии оценить абсурдность проблемы — сделать мессенджер на веб-движке, который для отображения списка сообщений будет загружать ядро браузера со всеми наворотами, в него тянуть HTML-формы, стили и код на JS, который там будет вам реализовывать непосредственно функционал мессенджера? А потом решать вопросы кеширования и оптимизации всего этого, чтобы оно быстрее работало. И утилизировало ресурсы компьютера. Если вам это не кажется абсурдным, возьмите сумку, положите в неё десять кирпичей, и когда вам нужно будет сделать себе кофе, берите её в руки, и сначала делайте с ней три круга трусцой вокруг квартала. Если отбросить пользу для мышц, то это будет примерно то, чем занимается ваш компьютер.
> Например, как вы выше говорили, DOM. Для функционирования мессенджера DOM не нужен.
Ну как же не нужен? В электроне нужен.
> Это именно так.
Нет, не так
> Если вам это не кажется абсурдным
Если это решение оптимальнее других — нет, не кажется.
Ну как же не нужен? В электроне нужен.
> Это именно так.
Нет, не так
> Если вам это не кажется абсурдным
Если это решение оптимальнее других — нет, не кажется.
Если это решение оптимальнее других — нет, не кажется.
Оно финансово оптимальнее для авторов сего непотребства, и на этом его оптимальность заканчивается.
Ну как же не нужен? В электроне нужен.
DOM вам в мессенджере на вашем компьютере не нужен вместе со всем электроном.
Если это решение оптимальнее других — нет, не кажется.
Это решение в принципе не может быть оптимальнее других, оно находится где-то вблизи самого дна по качеству и оптимальности.
Прошу прощения, а какая оптимальность еще требуется авторам проекта?
А причем тут «авторы проекта»? Мы говорим про мессенджер у вас на компьютере, у меня на компьютере, про то, как он использует ресурсы наших компьютеров. Я не пишу и не продаю мессенджеры. Возможно, вы пишете и продаете? Это хоть как-то объясняет вашу позицию.
«Оптимальный для автора проекта» — это когда они вообще ничего не делают, а им приносят деньги. Например, самый оптимальный мессенджер для авторов проекта — это когда кто-то проводит ICO и обещает выпустить мессенджер, а потом исчезает. Но вы же не захотите такой, верно? Поэтому некоторые из разработчиков пытаются сделать мессенджер таким, чтобы пользователи им ещё и пользовались.
А пользователи вправе требовать от разработчиков ещё и поддержания качества их продуктов. Например, не писать десктопные приложения на JS-фреймворках.
> Это решение в принципе не может быть оптимальнее других, оно находится где-то вблизи самого дна по качеству и оптимальности.
Вы можете предложить другое?
> А причем тут «авторы проекта»?
При том, что они — авторы проекта. Очевидно, что каков будет проект — решают те, кто занимается его разработкой, разве нет?
> А пользователи вправе требовать от разработчиков ещё и поддержания качества их продуктов.
Ну так требуйте, кто вам мешает?
Вы можете предложить другое?
> А причем тут «авторы проекта»?
При том, что они — авторы проекта. Очевидно, что каков будет проект — решают те, кто занимается его разработкой, разве нет?
> А пользователи вправе требовать от разработчиков ещё и поддержания качества их продуктов.
Ну так требуйте, кто вам мешает?
Вы можете предложить другое?
Легко. .NET, QT, нативные средства разработки под каждую платформу — любое решение будет лучше, чем JS-фреймворк.
Очевидно, что каков будет проект — решают те, кто занимается его разработкой, разве нет
Естественно, они это сами решают. И если они хотят вместо качественной программы выпустить говно, никто не вправе им это запретить. Но вы теперь ещё раз сами себя перечитайте сначала ветки: вас не только не возмущает то, что некоторые разработчики вам предлагают говно, но вы ещё и утверждаете, что это говно должно максимально употреблять ваш компьютер.
Чем питаться и чем кормить вашу технику — это тоже ваше личное право, конечно. Но считать вышеупомянутое нормой, знаете, это чересчур.
Но считать вышеупомянутое нормой, знаете, это чересчур.Почему? Это, на самом деле, логичное развитие подохода чем хуже, тем лучше.
Для того, чтобы продукт был успешным (а, как вы видим, это единственное, что волнует Druu) у него должно быть два свойства:
1. Он должен быть (то есть написать его следует как можно быстрее)
2. Он должен работать на существующей технике (а посколько сегодня техника мощная, то можно легко пожертвовать 99.9% эффективности).
Да, GEOS умещает в 64K и 1MHz те, вещи, для которых Macу требовался процессор на 8MHz и 512KB ROM'а (Windows тогда требовала сравнимых ресурсов), то есть он в 8 раз эффективнее — но какая, нафиг, разница, если через 4-5 лет после его появления Mac/Windows компьютеры получат ещё примерно в 10 более мощный процессор и мегабайты оперативной памяти, а GEOS так и останется в C64/C128?
Пока действует закон Мура в том или ином виде тратить время на написание эффективного кода — непозволительная роскошь вне очень узкой прослойки «системного» кода, который будет использоваться всегда и везде.
Да, лет через 20-30, когда закон Мура исчерпает себя (а мы уже переходим к финальной стадии «марлезонского балета», когда уплотнение достигается не столько за счёт уменьшения длины и ширины транзисторов, сколько за счёт увеличения числа своёв в «тортике»), тогда — да. Но не сегодня и не завтра ещё…
> Легко. .NET, QT, нативные средства разработки под каждую платформу — любое решение будет лучше
Вы гарантируете, что эти решения позволят доставлять функционал с теми же затратами и в тот же срок, что электрон?
> И если они хотят вместо качественной программы выпустить говно,
Качественная программа — это та, которой люди будут хотеть пользоваться. Авторы, конечно, всегда хотят выпустить качественную программу, а не говно.
> вас не только не возмущает то, что некоторые разработчики вам предлагают говно
Но мне не предлагают говно.
> но вы ещё и утверждаете, что это говно должно максимально употреблять ваш компьютер
Безусловно. Именно за тем я и покупал гигабайты и гигагерцами, чтобы приложения потом ими пользовались, а не тормозили (зато памяти занимали мало).
Вы гарантируете, что эти решения позволят доставлять функционал с теми же затратами и в тот же срок, что электрон?
> И если они хотят вместо качественной программы выпустить говно,
Качественная программа — это та, которой люди будут хотеть пользоваться. Авторы, конечно, всегда хотят выпустить качественную программу, а не говно.
> вас не только не возмущает то, что некоторые разработчики вам предлагают говно
Но мне не предлагают говно.
> но вы ещё и утверждаете, что это говно должно максимально употреблять ваш компьютер
Безусловно. Именно за тем я и покупал гигабайты и гигагерцами, чтобы приложения потом ими пользовались, а не тормозили (зато памяти занимали мало).
Именно за тем я и покупал гигабайты и гигагерцами, чтобы приложения потом ими пользовались, а не тормозили (зато памяти занимали мало).Тут какая-то подмена понятий произошла. Приложения, разработанные в стиле 80х-90х не тормозят абсолютно. Всё эти гигабайтные кеши позволяют лишь добиться того, чтобы современные монстры тормозили не так отчаянно, не более того.
Не копировать и не обрабатывать гигабайт… ммм… добра заведомо быстрее, чем обработать его любым способом.
А вот тут, собственно, собака и порылась. Не будет «в тот же срок». Будет дольше. Раз в 5 дольше.> Легко. .NET, QT, нативные средства разработки под каждую платформу — любое решение будет лучше
Вы гарантируете, что эти решения позволят доставлять функционал с теми же затратами и в тот же срок, что электрон?
Собственно тут собака и порылась. Все современные технологии нацелены на ускорение разработки. При этом ускорее времени разработки процентов на 30-50 покупается трёх-четырёхкратным увеличением требований к «железу». После так примерно пяти-шести итераций имеем сегодняшнюю ситуацию, когда временит на разработку требуется в 3-5 раз меньше, а ресурсов полученное приложение потом потребляет в 1000 раз больше.
Что, собственно, DrPass и называет «говном». Я не могу сказать, что это «говно», но, в то же время, ситуация в целом — явно нездоровая.
Когда только примерно 0.1-1% ресурсов моего компьютера используются по делу, а вокруг бегают стада «зелёных»… становится смешно.
А вот тут, собственно, собака и порылась. Не будет «в тот же срок». Будет дольше. Раз в 5 дольше.
Ну я же тоже не динозавров перечислил :) Это живые современные и эффективные платформы. Просто Электрон плох во всех отношениях, кроме одного — на нём может писать веб-разработчик.
Что, собственно, DrPass и называет «говном». Я не могу сказать, что это «говно», но, в то же время, ситуация в целом — явно нездоровая.
Да, я несколько резковато высказался. И самое неприятное, что закон Мура уже иссяк, компьютеры-то от поколения к поколению ускоряются не в два раза за полтора года, как раньше, а процентов на пять. А разработка ПО ещё к новым реалиям не привыкла.
Просто кое-какие эффективные менеджеры (из того же Skype) решили, что им нужно на одну кодовую базу меньше (или на две, не знаю, на каких ещё платформах кроме Win электрон работает). А веб-версия у них уже 2-3 года как существует и вполне себе хорошо работает. И что они делают? Правильно, внедряют код веб-версии в десктопную…
Вы гарантируете, что эти решения позволят доставлять функционал с теми же затратами и в тот же срок, что электрон?
Кроме нативных средств разработки, которые предполагают разные кодовые базы для каждой платформы — да, при наличии профильных специалистов в команде.
Авторы, конечно, всегда хотят выпустить качественную программу, а не говно.
Люди пользуются тем, что есть, а не тем, чем хотят. Насколько бы не был глючным клиент Skype под Андроид, им все равно будут пользоваться, потому что нет другого способа пообщаться с другим абонентом Skype с андроидофона.
Но мне не предлагают говно.
Вы просто принюхались
Именно за тем я и покупал гигабайты и гигагерцами, чтобы приложения потом ими пользовались, а не тормозили
Приложение, которому не нужны гигабайты и гигагерцы для того, чтобы отправлять и принимать сообщения, не нуждается и в их кэшировании. И этот способ ускорения работы компьютера (и вашей работы) на порядок эффективнее.
Люди пользуются тем, что есть, а не тем, чем хотят. Насколько бы не был глючным клиент Skype под Андроид, им все равно будут пользоваться, потому что нет другого способа пообщаться с другим абонентом Skype с андроидофона.
По поводу skype кстати очень наглядный пример. Чтобы данный софт был относительно приличным, достаточно было просто ничего не трогать с где-то 2014 года. Или хотя бы не ставить палки в колёса работающим старым версиям. Но имеет место намеренная трата ресурсов на ухудшение потребительских качеств программы в течение нескольких лет. По глупости ли или по злому умыслу — не знаю.
Качественная программа — это та, которой люди будут хотеть пользоваться
В условиях голода люди готовы есть мусор, но это не значит что мусор — это хорошо. Потому говнософт в условиях отстутсвия альтернативы (или незнания людей о ней) вполне существует.
Но мне не предлагают говно.
Бывает отсутствие обоняние и вкуса, но это не значит что остальные не видят.
Вы гарантируете, что эти решения позволят доставлять функционал с теми же затратами и в тот же срок, что электрон?
А вы таки считаете, что добавление за полгода такой мега-грандиозной фичи, как «ответить на сообщение» в Вайбере (пишу безотносительно к подходу с электроном, а просто в целом) — это достойный результат? Я бы понял, если бы использование вашего подхода позволяло пилить фичи в 2-4 раза быстрее (или пилить более крутые фичи). Но где они?
Я бы понял, если бы использование вашего подхода позволяло пилить фичи в 2-4 раза быстрее (или пилить более крутые фичи). Но где они?В каждом новом релизе, однако.
Вы просто не понимаете, что, после того, как базовый функционал отлажен и работает, привлекает внимание потребителей и потому становится важным для производителей. Думаете скорость и потребление памяти? Ага. Щаз. Важны градиенты и цветовые переходы, красивые кнопочки и «потрясающие» менюшки. И если бы это был сарказм — я был бы счастлив.
Так я же не против красивых кнопочек и градиентов. Но штука в том, что и они не особо изменяются или добавляются от релиза к релизу (если не брать мажорные версии, ну или хотя бы вторую цифру после мажорной). Всё остальное время чем там разрабы заняты, если им даже не до оптимизации? :)
Но штука в том, что и они не особо изменяются или добавляются от релиза к релизу (если не брать мажорные версии, ну или хотя бы вторую цифру после мажорной).А этого мало??? Посмотрите на «старые добрые времена». Turbo Pascal. Почти такой же популярный продукт в те времена, как сегодня Skype. Массивных редизайнов — три за двенадцать лет существования продукта (1981й — первый мультиплатформенный релиз, 1987й — Turbo Pascal 4.0, где сделали существенно переработанный UI, но отказались от кросс-платформы, да Turbo Pascal 6.0 — в 1990м). А сегодня редизайны выпускаются раз в год (а могли бы и чаще, но тут уже маркетологи решают).
Ну, как по мне, иногда хочется чего-то новенького в оформлении. Я не против. Например, до версии 8 меня дизайн скайпа только радовал (хотя после 5-ки к 6-ки пришлось какое-то время привыкать, но в итоге привык и полюбил).
А вы глубже посмотрите. Turbo Pascal в 1987 году получил новый интерфейс, модульность и кучу клёвых фишек. В 1988-м получил отладчик, обновлённую оболочку, контекстную справку. В 1989-м году — поддержку ООП. В 1990-м году получил опять новую IDE, поддержку Windows, библиотеку Turbo Vision. В 1992-м году вообще вышел монстр Borland Pascal 7.0, а ещё через два года — Delphi.
Вайбер за год прирос функциями «Ответить на сообщение», «Закрепить беседу вверху списка» и парой паков новых смайликов.
А теперь давайте прикинем сложность разработки Turbo Pascal, и того же Вайбера. Вы же не будете спорить, что первый на порядок более сложное приложение, даже несмотря на то, что разработчики второго решают ряд уникальных задач?
И при этом, минуточку, годовой чистый доход от вайбера с поправкой на инфляцию примерно как раз равен годовому чистому доходу Борланда в конце 1980-х. При этом те ухитрялись целый спектр приложений развивать — компиляторы и IDE C++/Pascal/Prolog, математический пакет Eureka, СУБД Paradox.
Чувствуете подвох? Мы тут выработали кучу приёмов, которые якобы усовершенствуют нашу работу, обеспечивают более высокое качество кода, гибкость к изменениям, непрерывную доставку и прочие няшки. Но каким-то образом получается, что продуктивность разработчиков четвертьвековой давности, у которых ничего этого не было, как-то оказывается значительно выше, нежели сейчас. И даже качество софта было как минимум не хуже, чем сейчас, со всем современным автоматизированным тестированием.
Вайбер за год прирос функциями «Ответить на сообщение», «Закрепить беседу вверху списка» и парой паков новых смайликов.
А теперь давайте прикинем сложность разработки Turbo Pascal, и того же Вайбера. Вы же не будете спорить, что первый на порядок более сложное приложение, даже несмотря на то, что разработчики второго решают ряд уникальных задач?
И при этом, минуточку, годовой чистый доход от вайбера с поправкой на инфляцию примерно как раз равен годовому чистому доходу Борланда в конце 1980-х. При этом те ухитрялись целый спектр приложений развивать — компиляторы и IDE C++/Pascal/Prolog, математический пакет Eureka, СУБД Paradox.
Чувствуете подвох? Мы тут выработали кучу приёмов, которые якобы усовершенствуют нашу работу, обеспечивают более высокое качество кода, гибкость к изменениям, непрерывную доставку и прочие няшки. Но каким-то образом получается, что продуктивность разработчиков четвертьвековой давности, у которых ничего этого не было, как-то оказывается значительно выше, нежели сейчас. И даже качество софта было как минимум не хуже, чем сейчас, со всем современным автоматизированным тестированием.
А теперь давайте прикинем сложность разработки Turbo Pascal, и того же Вайбера. Вы же не будете спорить, что первый на порядок более сложное приложение, даже несмотря на то, что разработчики второго решают ряд уникальных задач?Буду спорить. Я в какой-то библиотеке видел уникальный журнальчик: какие-то маньяки депаскализировали в конце 90х IDE Turbo Pascal 7.0 и опубликовали в пять, кажется, номерах журнала. По размеру — исходники были не больше, чем какой-нибудь компонент, который в Вайбере строчку на экран выводит.
Тут та же самая история что и с автомобилями. Кресло в современной модели может содержать больше деталей и быть сложнее по конструкции, чем какой-нибудь Ford T целиком. А все изменения между моделями соседних лет сводятся к каким-то малосущественным изменениям формы разных мелочей.
При этом те ухитрялись целый спектр приложений развивать — компиляторы и IDE C++/Pascal/Prolog, математический пакет Eureka, СУБД Paradox.Заметьте, что все продукты из этого списка — не были разработками фирмы Borland. Их купили (C, Basic, Prolog, Eureka, Paradox, dBase — это всё купленные продукты, причём Basic и Prolog и сейчас ещё разрабатываются их оригинальными авторами.
Но это так — к слову.
Но каким-то образом получается, что продуктивность разработчиков четвертьвековой давности, у которых ничего этого не было, как-то оказывается значительно выше, нежели сейчас.Нет, конечно! Ну чесслово, сравните Turbo Pascal 4.0 и Turbo Pascal 5.5 — что поменялось, кроме палитры?
Секрет айсберга, наконец-то, перестал быть секретом. Потому сейчас все усилия уходят на то, что видно. А всякая функциональность, которую ещё искать нужно… ну нафиг она нужна?
Кстати вы зря думаете, что софтописатели тут исключение. Вовсе нет. Как в «обзоре» таймера от Gefu: Придя домой и вскрыв коробку с таймером, я понял, за что были отданы деньги. Дизайнеры явно не зря получали свои евро — коробка выглядело дорого, а само устройство, которое вы можете наблюдать на картинке к посту, ещё дороже… Достав из ящика сисадминскую крестовую отвёртку, я хладнокровно разобрал устройство. Как я и предполагал, внутри оказался примитивный механизм из дешёвого, одноразового пластика, причём столь грязного и исцарапанного вида, что сразу становилось ясно, какие рабочие и в каком цеху его собирали. Все деньги у Gefu, видимо, ушли на стильный ретродизайн — на часовщиках было принято решение сэкономить.
Так и с софтом: важны пупочки, «переливы», трансформации, градиенты и прочий вау-фактор, который заставит вас это поделие купить/установить/запустить.
Как это реально будет использоваться — дело 10е, потому что вещь, которая не «супер-вау» не будет установлена, а, стало быть, не будет и использоваться.
Надо, впрочем, признать, что самое-самое ядро сейчас делается прилично: про то, что Windows 95 не может прожить больше 49.7 дней узнали только через несколько лет, так как она гарантированно висла раньше, а ядро Android'а и iOS'а всё-таки держится дольше… но это просто потому что в обоих случаях всё держится на энтузиастах, а кнопочек у ядра просто нет в приниципе… Всё же, что выше… свистелки-перделки решают, а все тесты и прочее — призваны добиться, чтобы когда их в 100500й раз переделывают поделие потом хоть как-то хоть куда-то запускалось. Чтобы оно работало устойчиво и пользоваться им было удобно — уже никто и не думает…
По размеру — исходники были не больше, чем какой-нибудь компонент, который в Вайбере строчку на экран выводит.
IDE — это всего лишь многооконный текстовый редактор. Там ещё и компилятор, и отладчик, и профайлер был, а главное — библиотеки. Но даже не в этом суть. Суть в том, что как вы привели сравнение с абстрактным компонентом из вайбера, современный софт overengineered (я не знаю, какой аналог подобрать в русском языке. Ну т.е. если вам нужно было вывести данные на форму, программист 90-х брал данные и выводил их содержимое в поля.
Программист 2010-х, вооружившись теорией про SOLID, сопровождаемость и т.д. сделает модель данных, модель представления, контроллер, пропитает это DI и приправит юнит-тестами, и потратив в несколько раз больше времени получит тот же результат. И при этом он будет свято верить, что с ростом проекта эти его затраты как-то окупятся.
А знаете, в чём подвох? Подвох в том, что они на самом деле нихрена не окупаются. Вернее, окупаются только в каких-то частных случаях. Потому что в подавляющем большинстве проектов на всём их сроке жизни все равно проще вывести напрямую данные на форму/представление, и там же налепить обработчиков, чем упаковывать каждую форму в какой-то там паттерн MVC/MVP/MVVM
А знаете, в чём подвох? Подвох в том, что они на самом деле нихрена не окупаются. Вернее, окупаются только в каких-то частных случаях.Они окупаются. Только не там и не так, как вам кажется. Возьмите тот же Borland. Всем прекрасно известно, что Turbo Pascal был написан Андерсом Хейлсбергом и компилятор Turbo C — тоже был работой каких-то вполне конкретных разработчиков.
Вот только когда Microsoft переманил этих людей (во главе с Bradом)… оказалось, что заменить их — не так-то просто. Boralnd C++ 4.0 был катастрофой.
И вот чтобы подобное предотвратить — и были придуманы все эти SOLID'ы, DI и «поклонение юнит-тестам» (я ничего не имею против юнит-тестов как таковых, но когда мне предлагают изуродовать структуру программы, чтобы было её удобнее тестировать — я прихожу в бешенство… а «новое поколение» считает, что только так и надо).
Borland погубило не отсутствие технического лидера или качественных программистов, а отсутствие толкового менеджмента, которые не понимали, куда и как развивать продукты.
В целом вы правы, в какой-то мере это вынужденные каноны, соблюдение которых позволяет писать более-менее пригодные продукты силами программистов невысокой квалификации. Но проблема-то остаётся — в результате мы как раз и получаем вместо двух-трёх замечательных продуктов широкий выбор из нескольких десятков более-менее пригодных.
И вот чтобы подобное предотвратить — и были придуманы все эти SOLID'ы, DI и «поклонение юнит-тестам»
В целом вы правы, в какой-то мере это вынужденные каноны, соблюдение которых позволяет писать более-менее пригодные продукты силами программистов невысокой квалификации. Но проблема-то остаётся — в результате мы как раз и получаем вместо двух-трёх замечательных продуктов широкий выбор из нескольких десятков более-менее пригодных.
> Вы же не будете спорить, что первый на порядок более сложное приложение
ТБ — обычное клиентское приложение. Конечно же, оно на порядок проще. 90% работы разработчиков вайбера просто не видно.
ТБ — обычное клиентское приложение. Конечно же, оно на порядок проще. 90% работы разработчиков вайбера просто не видно.
90% работы разработчиков вайбера просто не видно
90% работы разработчиков вайбера — это как раз клиентские приложения. Я не ошибусь, если скажу, что серверная часть там никаких особых изменений за последние несколько лет не получила. Да, это суровый highload плюс масштабируемость, но там ничего, требующего регулярных изменений, нет — клиентская база и менеджмент подключений.
> 90% работы разработчиков вайбера — это как раз клиентские приложения.
Конечно, нет.
> Я не ошибусь, если скажу, что серверная часть там никаких особых изменений за последние несколько лет не получила.
С чего вы взяли?
Конечно, нет.
> Я не ошибусь, если скажу, что серверная часть там никаких особых изменений за последние несколько лет не получила.
С чего вы взяли?
С чего вы взяли?
Потому что это очевидно. Последний раз функционал вайбера, который требовал каких-то доработок в серверной части, появился почти год назад, это переадресация голосовых вызовов.
Или вы думаете, они там бедненькие, сидят и непрерывно архитектуру совершенствуют? Типа «Ой, нагрузка в этом году вырастет на 10%, наш балансировщик поддерживает только 1024 ноды, давате его полностью переработаем, чтобы поддерживал 1536 нод, а потом если что через два года снова полностью переработаем»?
Посмотрите, сколько данных мессенджер хранит на диске, и сколько он занимает в ОЗУ.
Так об этом все и говорят — они явно не очень разумно этим распоряжаются, отсюда и проблемы с производительностью.
кеш ОС под данные и задачи бд ложится хорошо
С рандомным чтением, на порядки превышающим размер кеша, в отличии от мессенджера, где размер файла на порядки меньше объёма кеша? противоречие вижу я. Противоречие реальности.
> Так об этом все и говорят — они явно не очень разумно этим распоряжаются, отсюда и проблемы с производительностью.
Так давайте не хранить дом в памяти, а 60 раз в секунду перестраивать ^_^
И жс-код компилировать/кешировать не будем — будем исполнять влоб, даже без построения АСТ. И гц на размер оттьюним. Зато занимать будет приложение 20мб в ОЗУ!
> где размер файла
При чем тут файлы? Еще раз, 90% данных мессенджера ни в каких файлах не хранится. Именно по-этому (потому что данные в файлах не хранятся и храниться, в сущности, не могут), кеш системы и не поможет.
Так давайте не хранить дом в памяти, а 60 раз в секунду перестраивать ^_^
И жс-код компилировать/кешировать не будем — будем исполнять влоб, даже без построения АСТ. И гц на размер оттьюним. Зато занимать будет приложение 20мб в ОЗУ!
> где размер файла
При чем тут файлы? Еще раз, 90% данных мессенджера ни в каких файлах не хранится. Именно по-этому (потому что данные в файлах не хранятся и храниться, в сущности, не могут), кеш системы и не поможет.
Так давайте не хранить дом в памяти
Давайте, я согласен. Выкинуть дом, браузер, жабаскрипт и всё связанное и будет занимать 20 мегабайт (или меньше) нативно. Зачем в мессенджере всё это?
90% данных мессенджера ни в каких файлах не хранится.
Ещё раз — 90% этих не хранящихся данных лишние, скажу более — 90% данных мессенджера из файлов не нужны в ОЗУ. Зачем мне там история 5летней давности, если я даже ищё по ней раз в год (или никогда), она загружается каждый раз. Каждый. Или нет (тогда ваши 90% превращаются в мои 90%, которых в памяти нет).
А dom, который не хранится в файлах, как раз не нужен — он источник тормозов и непомерного жора. Вот и ответ, не надо говнокодить — и всё будет получаться быстрее и ресурсоэкономнее. Но да, не получится писать это хипстерам-юзателям-фреймворков, как нынче модно.
Раньше за такое статья была — «вредительство». Шутка, но горькая шутка.
Если бы клиент того же телеграма у меня как у юзера занимал бы все ресурсы, не знаю как бы вы, а лично был бы недоволен от слова «совсем». Т.е. — удалил бы нафиг. Если это способ захвата рынка, то — флаг в руки.
Если бы клиент того же телеграма у меня как у юзера занимал бы все ресурсы, не знаю как бы вы, а лично был бы недоволен от слова «совсем». Т.е. — удалил бы нафиг. Если это способ захвата рынка, то — флаг в руки.
В точку!
Я работаю за ноутбуком, ресурсы которого вообще никак нельзя сопоставить с ресурсами сервера, на котором будет крутиться приложение, которое я разрабатываю. Если мой ноутбук будет медленнее — я буду разрабатывать медленнее (потому что MSVS жрет больше ресурсов, чем разрабатываемое приложение), но к пользователю все равно не приближусь, потому что он находится в принципиально других условиях.
(мой домашний компьютер, что характерно, мощнее этого ноутбука)
А еще "быстрое ПО" — не обязательно "хорошее ПО".
А еще «быстрое ПО» — не обязательно «хорошее ПО».
А медленное ПО (по мнению большинства пользователей) практически всегда- плохое ПО.
Речь явно о приложениях а не серверном ПО.
Ой ли?
Легко понять почему так, ведь на работе это рабочий инструмент, нельзя терять время в ожидании компиляции, загрузки веб-страницы или другой ресурсозатратной операции. [...] «Вот тут страница грузится теперь в 2 раза быстрее, а вот этот модуль работает вполне себе» — ответят многие. [...] Что если бы каждый раз они запускали свое приложение, открывали свою страницу им бы приходилось ждать так же как и пользователю, а то и больше?
В Хроме есть режим замедления CPU и режим эмуляции плохой сети, так что можно разрабатывать в хорошей IDE, но при этом тестировать на «слабом» железе, и всё это на одном компьютере. Но мотивации намного больше, когда нет возможности это отключить, да :).
Лет пятнадцать назад я бы хотел заставить русских разработчиков (The Bat, Qip etc.) пользоваться китайской виндой с тамильской или арабской локалью, чтобы прониклись, что чувствуют их пользователи с нерусской виндой.
нельзя терять время в ожидании компиляции, загрузки веб-страницы или другой ресурсозатратной операции.Ok — нельзя терять время! Но ИМХО правильная мысль, что не все потребители могут поспевать за прогрессом. Компании, у которых возраст больше пары лет, периодически обновляют оборудование. Не надо выбрасывать старое или продавать за бесценок. Оставьте старый системный блок на рабочем месте — не так много места он занимает, а переключатель клавы-мыши-монитора и доп. кабели стоят копейки. Время от времени можно будет контролировать совместимость с устаревшим железом и софтом — во многих случаях это даст доп. прибыль и снизит число жалоб.
Тогда, выходит, разрабатывая софт на свежем железе — мы стимулируем технический прогресс и мировую экономику? 8)
А также создание большого количества электронных отходов.
Идея выглядит привлекательно, но доведена до абсурда.
Не проще ли для цели статьи использовать вторую машину или процесс тестирования со специализированными ролями тестировщиков, если софт промышленно пишется?
Это несложно и более оптимально, если есть желание. А если его нет, любая идея обречена.
Не проще ли для цели статьи использовать вторую машину или процесс тестирования со специализированными ролями тестировщиков, если софт промышленно пишется?
Это несложно и более оптимально, если есть желание. А если его нет, любая идея обречена.
довольно не слабое железо, заметно отличающееся от обычного домашнего компьютера обычного человека
Сейчас выше среднего (но ниже своего домашнего, а тем более домашнего компа игромана, даже без учёта видео, которое в проце), но обычно достаточно слабое (в нескольких местах, в которых работал). Главное — не компьютер разработчика. а понимание железа клиентов. Сейчас есть парк тестовых машин и тестовых виртуалок с близкими конфигурациями — это позволяет представлять скорость работы и узкие места, а сборка по полчаса ничего не решает.
А если у вас в ЦА будут гомосексуалисты, то вам тоже нужно будет обязательно всё на себе прочувствовать?
Если у вас гомосексуальное программное обеспечение (например, мобильный гейдар) — то да.
(Вот такой дефейс сайта MediaWiki я ухитрился заскриншотить)
А если фотографическое — нужно быть рядом с фотографами. А если аналитика продаж — то рядом с продажниками.
(Вот такой дефейс сайта MediaWiki я ухитрился заскриншотить)
А если фотографическое — нужно быть рядом с фотографами. А если аналитика продаж — то рядом с продажниками.
А в виртуальной машине с лимитами установленными кто мешает тестировать?
Да это дело хорошее. Рабочий компук вполне так мощный, а рядом стоит макбук к2дуо последний из пластиковых. Действительно иногда тестирование на старом выявляет очень интересные места в коде :)
А что делать, если у меня ноутбук с i7 и 16 гб?
согласен с автором на 100%. есть у меня на компе WinAmp 2.82. Он играет музыку, он в памяти занимает меньше 3 МБ!!! он запускается и начинает играть быстрее чем я моргаю! он справится с больше чем 95% музыки.
ну и есть современные плееры… которые даже на Core i5 свежем умудряются тормозить. Как жаль, что хороших программ становится меньше((
ну и есть современные плееры… которые даже на Core i5 свежем умудряются тормозить. Как жаль, что хороших программ становится меньше((
Мне кажется большинством не уловлен основной посыл статьи. Никто не отрицает, что тестирование должно захватывать и медленные машины. Но основная мысль — поставить разработчика в такие условия, чтобы ему от выбранных неоптимальных решений стало дискомфортно. Медленная компиляция есть следствие также и неоптимального кода, неверно выбранного набора библиотек. Долгая и тяжелая отладка порождается плохой архитектурой, когда код запутан, дублируется, плохо разделен. Плохая архитектура провоцирует к написанию неоптимального кода (просто не видно способов оптимизации).
Эх, вот эмбеддерам повезёт — компилить на 16-битных процах с 640к оперативки :)
Мне есть что сказать на это. В моей практике был опыт написания кода для уникальной железки, для которой даже эмулятор приходилось писать собственноручно. Но всех прелестей функционала эмулятор конечно же не раскрывал, поэтому запуски и отладки проходили не только в нем, но и на рабочей железке обложенной отладочными выводами. Так вот пока я варился в эмуляторе меня не сильно напрягал неудобный код, эмулятор прыгал по нему и позволял неплохо отсматривать контекст, перестартовывать разные случаи, ну и прочие вольности и свободы. Как только я уходил в работу реального железа, я перед написанием каждой строчки кода задумывался, как я ее буду отлаживать.
Аналогия из параллельной реальности. Я учился фотографировать на пленочную камеру проявляя и печатая фотографии самостоятельно. Снимая очередную пленку я думал над каждым кадром, как я его буду печатать и что цена 36 бракованных кадров — это полдня в ванной без какого-то результата.
Опять же я не утверждаю, что быстрая машина разработки и цифровая фотокамера — это зло. Но когда ты только жмешь на кнопку (хе, аналогия сразу на два случая), а о результате тебе как нибудь при случае «напоет Рабинович», качество страдает. Личный опыт. Возможно я что-то делаю не так.
Аналогия из параллельной реальности. Я учился фотографировать на пленочную камеру проявляя и печатая фотографии самостоятельно. Снимая очередную пленку я думал над каждым кадром, как я его буду печатать и что цена 36 бракованных кадров — это полдня в ванной без какого-то результата.
Опять же я не утверждаю, что быстрая машина разработки и цифровая фотокамера — это зло. Но когда ты только жмешь на кнопку (хе, аналогия сразу на два случая), а о результате тебе как нибудь при случае «напоет Рабинович», качество страдает. Личный опыт. Возможно я что-то делаю не так.
Я, кстати, это тоже проходил, и прекрасно Вас понимаю. Особенно интересна работа без эмулятора и отладчика вообще, когда отладчик в виде uart'а железки был счастьем, а в худшем случае таковым являлся какой-нибудь светодиод.
Да, код был красивый и быстрый, а главное — сильно дисциплинировал на будущее. Но скорость разработки была ужасна. Так что ответ на вопрос, какой путь развития лучше — экстенсивный или интенсивный — я не знаю.
Да, код был красивый и быстрый, а главное — сильно дисциплинировал на будущее. Но скорость разработки была ужасна. Так что ответ на вопрос, какой путь развития лучше — экстенсивный или интенсивный — я не знаю.
Уже несколько лет существует статистика.
store.steampowered.com/hwsurvey?l=russian
store.steampowered.com/hwsurvey?l=russian
Google в своё время использовала Nexus 4 с 512 Мб RAM (софтово разработчикам урезали), чтобы по максимуму оптимизировать Android 4.4. На выходе получилась реально крутая система.
А сейчас пришлось телефон с 2Gb ram менять на новый, потому что в машине работала либо музыка, либо навигация (google music и google maps), тупо не хватало оперативки!
А сейчас пришлось телефон с 2Gb ram менять на новый, потому что в машине работала либо музыка, либо навигация (google music и google maps), тупо не хватало оперативки!
У меня ASUS X55Sv, причём две штуки! прекрасная машинка и даёт фору самым последним ноутам. И естественно установлена W7
гм… Однажды я запустил свой крохотный WinAPI-проект на древнем-древнем нетбуке с WinXP… И только благодаря его тормознутости и малости ОЗУ обнаружил баг, который на других машинах либо вообще не воспроизводился, либо требовал 30+ часов непрерывного тестирования UI.
А разработчики IDE тестируют свои поделия на слабом железе? По сути все тот же тестовый редактор с автодополнением, как и 10 лет назад, а тормозов все больше и больше.
Ежедневно пользуюсь ноутбуком с Celeron M 933, на нём и тестирую свои веб поделки (жирные датагриды, деревья). В общем то хорошая практика, держать себя в тонусе, находить правильные решения для оптимизации
Прогерский софт прожорлив, и главный расщедрился на «простенький» i7 предыдущего поколения и 16 гигабайт памяти. Однажды это сыграло злую шутку: я не нашёл неоптимальность в программе.
Согласен с автором, несколько лет назад продал на детали MacBook Pro который достал своими поломками и перегревами и купил за те же 10К HP Chromebook 11 с ARM процессором, доволен до сих пор. Да бывают тормоза, но в основном связанные с беспечностью разработчиков веб-приложений. Но в основном все хорошо, кроме веба, музыку и видео(даже MKV) проигрывает. Даже p2p можно качать через JSTorrent.
Давно из-за слабого железа парюсь за оптимизации в своём софте. Вошло в привычку, на работе тоже стараюсь писать оптимально, так как это уже стиль кодирования…
У меня ноут на Pentium 2117U с 8 ГБ памяти как основная рабочая машина (не хайлоад веб, бэкэнд)
Android Studio не позволяет работать на слабом железе. Я пробовал.
Для TensorFlow нужны неслабые дискретные видеокарты. Интегрированные не подходят.
Так что слабенькая теория
Для TensorFlow нужны неслабые дискретные видеокарты. Интегрированные не подходят.
Так что слабенькая теория
По схожей концепции для теста андроид приложения на работе использую древний Huawei на 4.4 — если на нём приложение работает без тормозов, то с высокой вероятностью и у других оно будет работать хорошо. Бывали реальные случаи, когда мощные устройства «съедали» баги связанные с производительностью
Вы под 2.3 и 4.0 вообще не тестите, я так понимаю?)
минималка 4.4, так что необходимости нет)
Я как бы понимаю, что на дворе 2018-ый, но как обладатель клавиатурника на 2.3 (на котором последняя оф. прошивка на 4.0, и та жутко тормозит при скролле постоянно) очень огорчён, что разработчики совсем перестали релизить приложения под старые версии, хех.
Ну тут вопрос отдельного приложения, мы проанализировали пользователей, ниже 4.4 не было — мы подняли версию (приложение нишевое, так что «знаем каждого пользователя в лицо»). А вообще тема холиварная, я бы с удовольствием поддерживал все версии (или скорее предпочел чтобы все были на последних 2х), но эт довольно «дорого», так что приходится идти на компромиссы(
Ice Cream Sandwitch (хотя на самом деле, конечно, Honeycomb — но кто ж его видел?) кардинально изменил архитектуру (очень многое завязано в системе на 3D-ускоритель теперь), так что, с одной стороны, приложения под 2.x и 4.x+ нужно писать сильно по-разному, а во-вторых — требуется аппаратная поддержка, с которой, по всей видимости, у вашего клавиатурника плохо.
Как-то делал крупный 3Д проект на ноутбуке, научился оптимизировать сцену, создавать «деревья» из прилинкованных сцен и очень доволен таким экспириенсом. Выяснилось, что вполне себе можно делать сложное на простой скромной машине.
Так можно и до создания демок дойти www.theproduct.de
На слабой машине имеет смысл тестировать. Потому что иногда требования разработки могут отличаться от требований работы готового приложения. Например регулярная переупаковка графики и звуков для финального проекта на слабой машине станут пустой тратой рабочего времени.
Конечно этот аргумент поможет задуматься о том, чтобы сделать меньше графики и звуков, но это зависит от проекта, а не от хотелок программиста.
По мере роста проекта наступит момент, когда преимущества быстрого тестирования на слабом железе, помогающего постоянно отслеживать быстродействие и сразу задумываться о производительности будут перекрыты медленными операциями — переключениями между ветками, долгой сборкой и прочими техническими операциями, такими как упаковка ресурсов, к примеру.
Конечно этот аргумент поможет задуматься о том, чтобы сделать меньше графики и звуков, но это зависит от проекта, а не от хотелок программиста.
По мере роста проекта наступит момент, когда преимущества быстрого тестирования на слабом железе, помогающего постоянно отслеживать быстродействие и сразу задумываться о производительности будут перекрыты медленными операциями — переключениями между ветками, долгой сборкой и прочими техническими операциями, такими как упаковка ресурсов, к примеру.
Конечно этот аргумент поможет задуматься о том, чтобы сделать меньше графики и звуков, но это зависит от проекта, а не от хотелок программиста.
Зато вполне от программиста зависит сделать отладочный режим, который всё это берёт в неупакованном виде. А упаковывать 1 раз перед релизом.
перекрыты медленными операциями — переключениями между ветками, долгой сборкой и прочими техническими операциями, такими как упаковка ресурсов, к примеру.
Это туда же.
Разрабатываю софт уже 3-4 года исключительно на Toshiba AC100. Все заказчики в шоке от скорости работы программ и их коробочной кроссплатформенности для использования в тех же ARM (нет C++14 на старой убунте..). Я в восторге от этой машинки и не променяю ее ни на какой-то девайс с i3-i7.
Как хочется проапгрейдить рабочий комп до уровня домашнего… Ну, хотя бы без учета видухи…
Рабочий лаптоп Core i7, 16Gb оперативы. Софт для Cypress FX3, 300кБ на код и ~200кБ на DMA буфера и RAM, процессор ARM на 200 MHz. Другой проект, на Intel Atom E3900 (ex Apollo Lake) 1.6GHz, оперативы, правда целых 8Gb.
Нюанс в том, что на рабочем компе работает не только целевой софт, но куча средств для разработки, как минимум компилятор (мои языки C и C++) и ждать за чашкой чая конца сборки тоже неприятно. Просто должны быть сформулированы требования к софту и нужно проверять и тестировать работу в целевом окружении, а не упрощать и делать более слабым комп разработчика, уменьшая скорость CPU, объём RAM и жёсткого диска.
а у меня стоит Core i5 с 8GB… Но Win10 Pro
— Сколько занимает места Windows?
— Сколько находит, столько и занимает. (с)
В этом плане теория не нова. Но хочется добавить, что теория имеет смысл в более широкой трактовке — ограничения ресурсов при решении задачи. Если у вас ресурсы ограничены (бюджет, люди, время, ..), то вам приходится быть более изобретательным и это даёт соответствующую мотивацию. Т.е. подобный подход можно использовать не только в программировании.
— Сколько находит, столько и занимает. (с)
В этом плане теория не нова. Но хочется добавить, что теория имеет смысл в более широкой трактовке — ограничения ресурсов при решении задачи. Если у вас ресурсы ограничены (бюджет, люди, время, ..), то вам приходится быть более изобретательным и это даёт соответствующую мотивацию. Т.е. подобный подход можно использовать не только в программировании.
Теория дряхлого ноутбука