Я вообще непонимаю, почему пользователи не замечают еще проблему во всем, что основано на Chromium. Если у кого мощный компьютер, безусловно можно игнорировать большое потребление ресурсов, но как можно игнорировать эти уродливые размытые и бледные шрифты (по крайней мере на Windows)? При чем, чтобы сделать их не бледными, достаточно просто при сборке Skia (библиотека рендеринга, используемая Chromium) указать другую константу гамма-коррекции.
В совсем критической ситуации помочь не получится, это понятно. Я же говорил о «менее» критических случаях. Скажем в связи с каким-нибудь проишествием вдруг потребуется доставить что-то с Земли (продовольствие, вода, лекраства) или вдруг какому-то человеку требуется медицинская помощь, которую можно оказать только на Земле. Это можно как-то организовать в сжатые сроки, в случае с Луной. Если же мы говорим о Марсе, продолжительное время полета играет ключевую роль.
Довольно очевидно, что сначала следует обосноваться на Луне, отработать технику, наработать опыт. Расстояние и гравитация не такие большие, в случае чего есть возможность вернуть человека на Землю. А ломиться сразу на Марс просто глупо. Поэтому слушая фантазии о полете на Марс последние годы, я постоянно недоумевал, неужели говорящие об этом люди (которые гораздо умнее меня) этого не понимают?
Очень сильно раздражает, когда докладчики ставят «неправильные» ударения в заимствованных словах. Дело усугубляется тем, что на таком языке, как правило, разговаривают разработчики внутри своих компаний. Я специально взял слово «неправильные» в кавычки, потому что сложно однозначно сказать, какое ударение правильное.
Парочка примеров, которые мне всегда режут ухо:
кеши́
(множественная форма слова кеш, считаю праильным «ке́ши»),
в гите́
(гит в предложном падеже, считаю правильным «в ги́те»).
Интересно, а не будут ли мешать падающие спутники самолетам? Допустим до земли они не долетят, сгорят в атмосфере. А как сильно они «сгорят» на высоте 10 км?
Сам часто думаю о подобном инструменте. Я бы еще добавил возможность поиска по всем файлам, с предпросмотром и навигацией по результатам поиска (аналог Find in path в IDE от JetBrains или FileLocator Pro).
А как нужно их хранить и где по вашему? В чём же заключается «костыль» и кто мешает хранить простой ключ сессии, как в общем-то многие и делают?
Я бы хранил все данные на сервере и отдавал клиенту только его ID или ID сессии. Костыль заключается в том, что сначала был разработан stateless HTTP, а уже потом появилась необходимость различать сессии/клиентов, в результате чего появились cookies. Конечно, если рассматривать stateless как преимущество, то это уже не костыль. Лично я не вижу особой необходимости в stateless протоколе, но готов поверить вам, т.к. в данном вопросе не имею достаточно опыта.
Наверное такие решения должны прорабатываться, обсуждаться и приниматься с особой осторожностью, чтобы не сломать то, что работает годами, не сделать хуже.
Да, именно взвешенное решение, выработанное в ходе обсуждений я и имею в виду.
Установка соединения (SYN->ACK->ACK) с передачей cookies для каждого запроса дает лишнюю нагрузку на сервер и на канал. Для одного клиента она не существенна, но когда клиентов тысячи, она внезапно начинает играть свою роль. А если мы вспомним, что внутри у нас plain text, то становится еще грустнее.
Смешались в кучу кони, люди, мухи, котлеты… Каждый второй сайт уведомляет об использовании cookies согласно новому закону евросоюза.
Безусловно. Только сами cookies появилсь, чтобы сервер мог хоть как-то хранить на клиенской машине информацию и различать сессии между собой. Исторически, это был именно костыль.
HTTP — это stateless протокол
Мое исходное сообщение было не про «улучшение» HTTP или HTML, а о полном переосмыслении всего веба. В текущем состоянии эти технологии обладают большой гибкостью, но нещадно жрут ресурсы.
Возьмем к примеру QML. По сути QML реализует связку HTML+CSS+JavaScript (безусловно после определенной доработки), но при этом быстрее и выглядит на всех устройствах одинаково. Не требуется для каждой страницы подтягивать портянки bootsrap/jquery/etc (я понимаю, что браузеры кешируют данные, это всего лишь пример).
Более того, работа с cookies и сессиями, как и вся остальная семантика HTTP — совершенно одинаковая, что в HTTP/1.1, что в HTTP/2 и SPDY.
Доработки и улучшения — это хорошо. Но я говорю о «попробовать спроектировать с нуля исходя из текущего опыта». Я понимаю, что это не быстрый процесс и его внедрение может занять многие годы. Но иногда требуется отбросить обратную совместимость и дать дорогу чему-то принципиально новому.
Я не говорил, что SPDY или HTTP/2 не имеют проблем. Однако, одно соединение на один запрос довольно избыточно. В чем, по вашему, правильность данного метода? Даже для реализации «сессии» пришлось придумывать костыли. Теперь каждый второй сайт уведомляет о том, что он использует cookie и просит понять и простить. А все из-за того, что «это правильно, так и должно быть».
Они просто улучшают текущие технологии, не меняя основную идею. HTTP до сих пор использует отдельное TCP соединение для каждого нового запроса (я в курсе о гугловском SPDY), а информация передается в текстовом виде. Это конечно человекочитаемо и удобно, не спорю, но на практике все сводится к избыточному потреблению электроэнергии, ресурсов компьютера и пропускной способности канала.
Вот непонимаю, почему крупные заинтересованные компании (Google, Microsoft, Apple, Amazon, и т.п.) не соберутся и не переизобретут велосипед создадут замену для технологий, применяемых сейчас в вебе. HTTP, HTML, CSS имеют столько исторически сложившихся недоразумений, что проще сделать что-то новое, с учетом современных реалий. Тот же Google может запросто добавить поддержку новой технологии в свой браузер. А по прошествии периода адаптации, объявить старый стек технологий небезопасным/устаревшим, как они уже делали с Flash, HTTP.
Глядишь, и не нужно будет трать столько усилий на написание и поддержку браузерного движка.
А есть возможность задать альтернативный домен для синтеза речи (например translate.google.as)? Мне нужен американский акцент, а гугл отдает его только на .as .cn и может быть некоторых других.
Пользуюсь связкой Mahou + QTranslate. А ваша программа устанавливает глобальный хук клавиатуры во все процессы для переключения раскладок? Просто большинство переключалок раскладки (кроме разве что, Mahou), работают далеко не во всех программах.
Лично мне всегда хватает встроенной памяти, но я знаю много людей, которым нужна карта памяти и две симки одновременно. Поэтому я и считаю, что это могло бы быть в некоторой степени преимуществом данного аппарата. А так — обычный смартфон, которых уже наверно тысячи.
По размерам это типичный представитель 5,5 дюймовых смартфонов, которым во многих ситуациях удобно пользоваться одной рукой — кроме разве что активного серфинга в сети и работы с приложениями.
А что ещё можно делать одной рукой со смартфоном, кроме работы с приложениями? Прикладывать к уху? Кстати руки тоже у всех разные, мне и на 5.15" аппарате не очень комфортно набирать текст одной рукой.
Справа клавиша питания и комбинированный лоток под SIM-карты формата nano и карточку памяти microSDXC.
А казалось бы, всего-то надо было сделать возможность использовать две симки и карту памяти одновременно и для многих людей это стало бы весомым преимуществом.
Парочка примеров, которые мне всегда режут ухо:
(множественная форма слова кеш, считаю праильным «ке́ши»), (гит в предложном падеже, считаю правильным «в ги́те»).
Да, именно взвешенное решение, выработанное в ходе обсуждений я и имею в виду.
Конкретно QML был всего-лишь примером.
Безусловно. Только сами cookies появилсь, чтобы сервер мог хоть как-то хранить на клиенской машине информацию и различать сессии между собой. Исторически, это был именно костыль.
Мое исходное сообщение было не про «улучшение» HTTP или HTML, а о полном переосмыслении всего веба. В текущем состоянии эти технологии обладают большой гибкостью, но нещадно жрут ресурсы.
Возьмем к примеру QML. По сути QML реализует связку HTML+CSS+JavaScript (безусловно после определенной доработки), но при этом быстрее и выглядит на всех устройствах одинаково. Не требуется для каждой страницы подтягивать портянки bootsrap/jquery/etc (я понимаю, что браузеры кешируют данные, это всего лишь пример).
Доработки и улучшения — это хорошо. Но я говорю о «попробовать спроектировать с нуля исходя из текущего опыта». Я понимаю, что это не быстрый процесс и его внедрение может занять многие годы. Но иногда требуется отбросить обратную совместимость и дать дорогу чему-то принципиально новому.
переизобретут велосипедсоздадут замену для технологий, применяемых сейчас в вебе. HTTP, HTML, CSS имеют столько исторически сложившихся недоразумений, что проще сделать что-то новое, с учетом современных реалий. Тот же Google может запросто добавить поддержку новой технологии в свой браузер. А по прошествии периода адаптации, объявить старый стек технологий небезопасным/устаревшим, как они уже делали с Flash, HTTP.Глядишь, и не нужно будет трать столько усилий на написание и поддержку браузерного движка.
А казалось бы, всего-то надо было сделать возможность использовать две симки и карту памяти одновременно и для многих людей это стало бы весомым преимуществом.