По ссылке интересная статья, но едва ли по ней можно сказать что и сегодня количество удваивается каждые 5 лет. Он берёт количество программистов в 1974, потом сравнивает с 2014, для целей его статьи это нормально. Но предполагать что скорость роста остаётся неизменной и сегодня, только на основании этих данных, было бы неверным. Для того чтобы знать, что происходит сегодня, надо посмотреть статистику последних лет.
Ну и? Кто будет это делать? Кстати почему это «телефоны к ним не относятся»? ICU отсуствует в Android NDK — ровно по причине того, что её размеры слишком велики
…
Для встраиваемых систем уже есть обрезанные версии библиотек на любой вкус. Для телефонов же 20МБ это не проблема, о чём вообще разговор???
Файловой системе — это не нужно: при использовании UTF-8 подход «имя файла — это произвольная последовательность байт, не включающая в себя символов '\0' и '\'» — отлично работает.
При глобальном использовании UTF-8 никакой проблемы и не возникло бы изначально, но (к сожалению) это не так.
Я правильно понял, что прогресса в этой области нет и комитет по стандартизации занимается… гм… другими полезными (на их взгляд) нововведениями?
Сегодня, на секундочку, 2017 год и отсутствие такой, в сущности, базовой функциональности это какой-то позор…
Я не вижу никакой проблемы с увеличением размера библиотеки. Для всяких встраиваемых недокомпьютеров (а телефоны к ним не относятся), как уже указал Antervis, вполне можно сделать либо обрезанную библиотеку, либо отдельный модуль.
Решение этой задачи необходимо, конечно же, не только для графического интерфейса пользователя, но практически везде, где есть обработка текста, файловая система или хотя бы текстовые сообщения об ошибках. Не хочу умалять и необходимость стандартной, продуманной библиотеки графического интерфейса пользователя, но это архисложнейшая задача на многие годы вперёд, которая потребует и вышеуказанное.
Локализация — поддержка перевода текстовых строк на разные языки. То есть то, чем занимается, например, GNU gettext, а также всякие форматы дат и т.п.
Поддержка юникода — классификация символов, поиск/замена, регулярки, конвертация из/в других кодировок. То есть то чем занимается ICU. Но не только — важна поддержка перекодировки для локальных имён файлов/каталогов, например. Или конвертация вывода в std::cout из юникода в локальную кодировку «на лету» и т.п.
На сколько эти все работы завершены и что ещё не сделано?
Именно Scratch2 и не работал в Фаерфоксе под Дебианом как следует. Причём, что самое неприятное — позволял создать программу, запустить её, но не позволял её сохранить — рушился. И только при определённом размере/сложности программы. На маленьких-коротеньких всё работало.
Собственно, нормальная система отношений в социуме, так и должно быть. («Нормальная» — не синоним «хорошая».) И жаловаться тут не на что. Ну а то, что это многим не нравится — и они покидают площадку, так это доминирующему сообществу не кажется страшным. А зря. Но это уже другая история, с софизмами и догмами.
Абсолютно согласен. В результате этих процессов, многие вопросы могут остаться без альтернативного мнения, от чего пострадают все участники дискуссии, увы. Но эти недостатки связаны в первую очередь не с системой рейтингов, а с самим сообществом. Поэтому нечего тут на сайт пенять…
Когда создавали Openttd, они сначала тоже предлагали пользователям скачать оригинальную графику/музыку. А потом, постепенно перерисовали собственнические картинки, сделали свою музыку.
Скрэтч хороший инструмент, но он же на Флэше! У сына в школе преподаватель информатики тоже использует Сктрэтч и дома постоянно проблемы — то он постоянно рушится, то отказывается сохранять проект… Замучились с ним.
А теперь давайте пофантазируем: представим, что какая-то из упомянутых автором технологий, ну например Tcl/Tk, будучи кроссплатформенной и скриптовой, может каким-то образом, аналогично сайту, скачиваться на любое устройство пользователя, хоть Android, хоть десктоп на Windows или Linux, и тут же отображать пользователю GUI. Представили? Ведь это же и будет тот самый убийца Web, так как решает те же задачи!
Так это же и пытались сделать Ява-апплеты и Флэш. Основным недостатком Ява-апплетов, на мой взгляд была излишняя громоздкость (в сравнении с Питоном или Тсл/Тк), основным недостатком Флэш была закрытость. Но в целом они именно это и делали.
Легковесный контейнер, жёстко, на уровне железа изолирующий скачиваемое приложение от клиентской машины и предоставляющий ограниченный, контролируемый системой прав доступа и квот интерфейс к устройствам на клиенте (можно дополнить его встроенным легковесный интерпретатор типа Питона/TclTk) по идее должен бы решить проблему безопасности. Но это будет громоздкая конструкция. Если же такой контейнер соорудить, то почему бы тогда не разрешить запускать в нём бинарные файлы?
Кстати, что-то я не вижу, чтобы всякие игрушки, типа огорода на ок.ру, написанные на Флэш, активно переписывались на HTML5, что ставит под сомнение утверждение о том что HTML5 может его заменить…
В разделе про RSA потерялась формула после «Вычисляется число dd, мультипликативно обратное к числу ee по модулю φ(n)φ(n), то есть число, удовлетворяющее сравнению:»
Настройка клиента openvpn есть в апплете NetworkManager. Настройка же сервера обычно делается на сервере в терминале, и графический интерфейс там обычно не нужен.
Хотя, наверное, в каких-то ситуациях понадобится и такая программа.
После всего этого ваш скрипт можно просто выкинуть, потому что больше он вам не понадобится никогда! Ведь ваши рабочие базы уже находятся в нужном вам состоянии по структуре, а если вы задумаете делать новую базу «с нуля», то тогда вам не надо заставлять базу проходить весь тот путь, который вы прошли, дорабатывая её структуру в процессе разработки.
Начиналось всё хорошо, но в этом абзаце всё пошло прахом… Если моё приложение имеет версию 20, а предыдущие версии моего приложения (от 1 до 20) стоят у тысячи пользователей, то скрипт делающий апгрейд должен уметь проапгрейдить БД каждой из 19 версий до версии 20. Поэтому вышеупомянутый скрипт ну никак нельзя выбрасывать.
На моноблоках и ноутах всё ещё можно получить права суперпользователя и даже поставить альтернативную ОС, даже на многих роутерах. А вот в автомобилях — да, там всё закрыто и чем дальше, тем хуже.
Идея модульного телефона видимо позаимствована из мира персоналок. В своё время IBM PC завоевал мир благодаря модульности. Но это произошло не только благодаря модульности. Операционную систему мог написать каждый, потому что технические спецификации и архитектура были открыты и не требовались магические тайные знания для того чтобы полностью управлять устройством. Сегодня это не так и создать для телефона альтернативную ОС практически невозможно из-за закрытых спецификаций железа. Сегодня даже для получения доступа на уровне суперпользователя приходится извращаться. Это сделано с целью монополизации рынка и недопущения альтернативных ОС на рынок.
Первый же кто выпустит приемлемый по цене и характеристиками телефон с открытыми спецификациями (позволяющий создать установить произвольную ОС так же свободно как и IBM PC) и перевёрнет мир.
Для встраиваемых систем уже есть обрезанные версии библиотек на любой вкус. Для телефонов же 20МБ это не проблема, о чём вообще разговор???
При глобальном использовании UTF-8 никакой проблемы и не возникло бы изначально, но (к сожалению) это не так.
Сегодня, на секундочку, 2017 год и отсутствие такой, в сущности, базовой функциональности это какой-то позор…
Я не вижу никакой проблемы с увеличением размера библиотеки. Для всяких встраиваемых недокомпьютеров (а телефоны к ним не относятся), как уже указал Antervis, вполне можно сделать либо обрезанную библиотеку, либо отдельный модуль.
Решение этой задачи необходимо, конечно же, не только для графического интерфейса пользователя, но практически везде, где есть обработка текста, файловая система или хотя бы текстовые сообщения об ошибках. Не хочу умалять и необходимость стандартной, продуманной библиотеки графического интерфейса пользователя, но это архисложнейшая задача на многие годы вперёд, которая потребует и вышеуказанное.
Поддержка юникода — классификация символов, поиск/замена, регулярки, конвертация из/в других кодировок. То есть то чем занимается ICU. Но не только — важна поддержка перекодировки для локальных имён файлов/каталогов, например. Или конвертация вывода в std::cout из юникода в локальную кодировку «на лету» и т.п.
На сколько эти все работы завершены и что ещё не сделано?
Абсолютно согласен. В результате этих процессов, многие вопросы могут остаться без альтернативного мнения, от чего пострадают все участники дискуссии, увы. Но эти недостатки связаны в первую очередь не с системой рейтингов, а с самим сообществом. Поэтому нечего тут на сайт пенять…
Это не совсем так, ведь есть OpenWRT, а там полноценный ssh
Так это же и пытались сделать Ява-апплеты и Флэш. Основным недостатком Ява-апплетов, на мой взгляд была излишняя громоздкость (в сравнении с Питоном или Тсл/Тк), основным недостатком Флэш была закрытость. Но в целом они именно это и делали.
Легковесный контейнер, жёстко, на уровне железа изолирующий скачиваемое приложение от клиентской машины и предоставляющий ограниченный, контролируемый системой прав доступа и квот интерфейс к устройствам на клиенте (можно дополнить его встроенным легковесный интерпретатор типа Питона/TclTk) по идее должен бы решить проблему безопасности. Но это будет громоздкая конструкция. Если же такой контейнер соорудить, то почему бы тогда не разрешить запускать в нём бинарные файлы?
Кстати, что-то я не вижу, чтобы всякие игрушки, типа огорода на ок.ру, написанные на Флэш, активно переписывались на HTML5, что ставит под сомнение утверждение о том что HTML5 может его заменить…
Хотя, наверное, в каких-то ситуациях понадобится и такая программа.
Начиналось всё хорошо, но в этом абзаце всё пошло прахом… Если моё приложение имеет версию 20, а предыдущие версии моего приложения (от 1 до 20) стоят у тысячи пользователей, то скрипт делающий апгрейд должен уметь проапгрейдить БД каждой из 19 версий до версии 20. Поэтому вышеупомянутый скрипт ну никак нельзя выбрасывать.
Первый же кто выпустит приемлемый по цене и характеристиками телефон с открытыми спецификациями (позволяющий создать установить произвольную ОС так же свободно как и IBM PC) и перевёрнет мир.