Comments 123
Дежавю:
habrahabr.ru/post/337010
habrahabr.ru/post/337010
UFO just landed and posted this here
Первую половину текста автор плачется что системы стали слишком сложные и многослойные, вторую — призывает добавить еще слоев и сложности…
А мне кажется он предлагает не наращивать слои, а интегрировать функционал в нижние слои.
Даже лучше. Он сначала плачется что они были слишком сложными, а теперь стали менее сложными (пример про несуществующий в природе X Windows это наглядно показывает). Затем они стали проще, и теперь их снова пора усложнить. ;-)
Ну, как вариант.
Ну, как вариант.
всесистемная шина сообщений в реальном времени
D-Bus. Ну да, не совсем всесистемная, но тем не менее, если разработчик озаботился о его поддержки в своём приложении, им можно будет управлять.
Если разделить стандартный почтовый клиент на GUI и сетевые модули, которые общаются исключительно через сообщения по шине, то разработка программы станет намного проще.
В юниксах давно практикуется с разной степенью успеха
всесистемная версионированная база данных в реальном времени
В macos файлы вполне нормально индексируются, можно искать по всей системе по содержимому. Старые версии файлов можно откопать в TimeMachine
Сервисы доступны во всей системе. Это означает, что мы можем запустить единый сервис, где пользователь может назначать сочетания клавиш (keybindings). Это также означает, что у сочетаний клавиш появится более глубокий смысл.
И снова macos. С помощью автоматора и редактора скриптов можно создать сервис, можно управлять любым GUI-шным приложением, и всё это можно привязать к любому сочетанию клавиш. Более того, в любой программе любую команду из его меню можно привязать к хоткею (если даже в самой программе такого биндинга не предусмотрено)
Ещё там можно, например, замутить свою голосовую команду и др
Проблема самого автоматора — он сложный для изучения. И Applescript очень непривычный и странный (хотя можно и на js писать)
Почему я не могу подать голосом команды компьютеру
Привет, сири.
И у нас до сих пор этого нет? Почему так?
Но почти всё из перечисленного есть. Что-то исчезло из обихода как раз потому, что на деле что-то не такое уж и оно вышло удобным и надёжным. Многое из перечисленного довольно специфичное и простому пользователю не нужно.
Хочу подчеркнуть, что абсолютно ничего из того, о чём я рассказывал, не является новым.
Статья о том, что всё это уже есть, но по отдельности. Автор призывает переписать всё с нуля, правильно скомпоновав уже реализованные идеи.
Гораздо удобнее расширять существующую систему, чем создать нечто новое; но расширение также означает, что вы ограничены выбором, сделанным в прошлом.
В этом и тезис статьи.
Автору (не переводчику) — не нравится — не ешь. Возьми да напиши свою с нуля с картами и поэтессами. Только, боюсь, один он все равно не напишет, а даже если с командой, то к моменту когда у него по экрану начнет мышка бегать, придется весь код выбросить в дев нулл, потому что «обрастет костылями и слоями за давностью» и начать заного.
Значит здесь тоже есть некий недостаток — избыточный порог сложности при написании ОС. Может быть и имеет смысл начать с его устранения. Продумать и создать новый язык программирования вместо Си, максимально поддерживающий модульную композицию и изоляцию; далее написать аспектно-ориентированные модули, образующие ядро ОС, драйверы периферийных устройств — таким образом, чтобы эти модули были предельно простыми и не связанными друг с другом, а умный компилятор интегрировал бы их в единое быстрое ядро.
Аналогично — с пользовательским слоем ОС. Там тоже нужна фундаментальная декомпозиция сущностей, формирование предельно простых абстракций и их аспектное связывание на уровне компиляции, а не путем порождения новых и новых рантайм-слоев.
Это все большая работа. И для этого действительно нужны новые идеи и новые инструменты.
Аналогично — с пользовательским слоем ОС. Там тоже нужна фундаментальная декомпозиция сущностей, формирование предельно простых абстракций и их аспектное связывание на уровне компиляции, а не путем порождения новых и новых рантайм-слоев.
Это все большая работа. И для этого действительно нужны новые идеи и новые инструменты.
Вроде как в Plan-9 и Inferno это и сделали. Не знаю, как там с производительностью, однако структурно оно выглядит достаточно интересно. Правда на данный момент они существуют только в виде надстроек над обычной ОС.
драйверы периферийных устройств — таким образом, чтобы эти модули были предельно простыми и не связанными друг с другом, а умный компилятор интегрировал бы их в единое быстрое ядро.
Ведь именно на таких идеях базировались, емнип, GNU и Minix. Только оказалось, что отладить независимые модули сложнее.
Нативные приложения слишком тяжеловесны, их долго разрабатывать и они живут в бункерахЭто проблема разработчиков, а не системы. Хрень можно писать на чём угодно и в каком угодно окружении. Как и нормальный софт. При чём тут ОС?
Не только «файлы» существуют более чем в одном месте и становятся легко доступны для поиска, но гарантированное наличие высокопроизводительной БД намного облегчает создание приложений.Есть плюсы, есть минусы. Пихать в базу файлы по несколько терабайт — бессмысленный перебор. И мир не ограничивается кучкой легко теггируемых файлов. По большей части это тысячи разных заточенных под конкретные задачи файлов. Вопрос производительности бд так-же не столь прост. Сколько ресурсов системы мы готовы отдать на работу этой бд?
Шина сообщений станет единым способом межпроцессных взаимодействий. Мы избавляемся от сокетов, файлов, каналов, ioctrl, общей памяти, семафоров и всего остальногоБред. «Всё остальное» появилось не на пустом месте и избавление от него только добавит геморроя разработчикам. Ах да, мы же выкинули нативные программы и перешли на скриптовые обёртки…
Ниже показана схема Wayland — компоновщика, который когда-нибудь станет работать по умолчанию в LinuxИ если я правильно понял — игровые движки и всё, требовательное к графике в него не входит.
Завершив вывод графики и при необходимости обновления они просто отправляют сообщения: пожалуйста, перерисуй меня.Эмм… А сейчас не так? И что делать системе, если это ей понадобилось, чтобы приложение себя перерисовало? Или храним в текстурах все окна пока приложение работает (ну да, сейчас вроде так и делают на самом деле. Но как быть если нам нужна вся видеопамять под более насущные задачи?)
Разделение почтового клиента на компоненты значительно облегчает замену отдельных его частей.Упомянутые в прошлой статье OLE, COM и прочие — не? К сожалению сейчас как раз всё скатывается к сваливанию в одно приложение всего-всего.
В нашей новой ОС любое окно стыкуется как вкладка к другому окну. Или к боковой панели. Или к чем-нибудь ещё. Независимо от приложения.В вынде это можно легко сделать и так (правда второе приложение может немного упасть при закрытии родительского окна). Однако в чём смысл? Некоторые программы наоборот, ушли в сторону «один документ — одно окно». А к панелям и чему-нибудь ещё в современных ос они и так умеют цепляться вроде как.
На скриншоте внизу пользователь приподымает границу окна, чтобы посмотреть, что там внизу. Это очень круто!Это при желании реализуется вообще элементарно. Была для вынды прога, которая по сочетанию клавиш сворачивала/разворачивала окно в заголовок. Функция на поиграться.
У приложения неизвестного происхождения — чёрная рамка, или оно вообще не выводится на экран.Т.е. юзер даже не узнает, что у него работает какая-то подозрительная программа? Логично, зачем его пугать лишний раз.
Но зачем ограничивать себя этим. Сделаем буфер обмена, который вмещает больше одного элемента. У нас гигабайты памяти.Вот с фразы «у нас гигабайты памяти» обычно начинается быстрое её исчезновение. А буфер с кучей кусков делали программно много раз. Вот честно, часто ли оно требуется? Ставил себе такую прогу ради интереса. Как поставил, так и забыл. Максимум эта полка превратится в табы браузера, когда вместо сохранения инфы по делу мы используем корзину для хранения временных (год-другой) документов.
Обычно я разделяю личные и рабочие файлы. Это отдельные папки, аккаунты, иногда разные компьютеры. В Идеальной ОС мои файлы могут разделяться средствами самой ОС. У меня может быть один экран с домашней почтой, а другой экран — с рабочей. Это одно и то же приложение, просто инициализированное с разными настройками запросов.Многие программы (браузеры, почты..) позволяют указывать профиль, с которым работаешь, и в котором все настройки. Можно создать несколько юзеров (В ллинухе) и запускать программы от них. Соответственно по умолчанию они имеют окружение конкретного пользователя и имеют индивидуальные ограничения и права на уровне системы.
Почему у нас этого нет?Потому, что это не нужно? ХромОС (и где она сейчас?) которая основана на андроиде. В котором как раз всё это и стараются реализовать. Вот только не все хотят превращать компьютер в телефон.
Маниловщина.
В комментариях большую часть описали: «всё очень сложно… а я тут вот так придумал (ещё сложнее).
Отдельное и универсальное решение точно есть, но зачем это стандартным средством в OS?
В чём вообще проблема и причём тут OS?
Таких приложений — десятки, зачем это в OS?
Опять же — тут всё в руках, причём тут всё всего несколько строчек.
В комментариях большую часть описали: «всё очень сложно… а я тут вот так придумал (ещё сложнее).
Рассмотрим следующие задачи:
Я хочу использовать ноутбук как усиленный микрофон. Я говорю в него, а голос звучит из колонок Bluetooth в другом конце комнаты.
Отдельное и универсальное решение точно есть, но зачем это стандартным средством в OS?
Как только я публикую твит с хештегом #mom, его копия должна отправляться по электронной почте моей маме.
В чём вообще проблема и причём тут OS?
Я хочу использовать iPhone в качестве микроскопа, закреплённого на стойке из конструктора «Лего». Он транслирует картинку на ноутбук, где у меня управление — кнопки для записи, паузы, приближения и ретрансляции прямого эфира на YouTube.
Таких приложений — десятки, зачем это в OS?
Я хочу сделать простой байесовский фильтр, который реагирует на почтовые сообщения от «Энергосбыта», добавляет тег «коммунальные услуги», делает запись на веб-сайте, извлекает из письма сумму и дату платежа и добавляет запись в мой календарь.
Опять же — тут всё в руках, причём тут всё всего несколько строчек.
Я был бы рад поучаствовать в этом, но сначала хочу выразить свою позицию по этому поводу…
Во-первых, с чего начались почти все(может вообще все) современные ОС? Правильным ответом на это будет Unix(или я не прав?). С чего начинался Unix? С языка программирования C. То есть все современное ПО держится сейчас по сути на одном языке(даже Python в него транслируется). Но этот язык был написан 40 с лишком лет назад, и, следовательно, безбожно устарел под требования современных задач(ведь сейчас 3 идиом, включая кроссплатформенность уже не хватает; им параллелизм подавай)… Поэтому, по-моему сугубо личному мнению, прежде чем писать ОС нужно написать компилятор языка программирования, который будет лучше С под современные задачи, при этом полностью транслирующийся в код ассемблера, и еще поддерживающий ассемблерные вставки(вспомните молодость и TurboC30, хотя я и не застал те времена, но предпочту работу с ним, чем с современной IDE по типу codeblocks)
Во-вторых, написание OC требует времени и денег, если ты, конечно, не работаешь на энтузиазме. Но уже довольно давно появился механизм «Pay what you want», который, возможно, сделает, в теории, твой энтузиазм поощряемым и будет стимулировать тебя на написание хорошего кода.(Но как известно это не очень распространенный метод, да и современный мир погряз в получении «выгоды», поэтому время и затраты на написание продукта стараются по максимуму сократить, что приводит к некачественному(небыстрому) коду)
В-третьих, насколько я понял эмпирическим путем, твоя ОС сможет «просуществовать» до новой ветки устаревающих технологий не более 20 лет, при умном проектрировании, поэтому ее разработка должна быть достаточно быстрой, что повлечет работу в огромной команде людей, что вновь приводит нас к предыдущим пунктам, но также создаст кучу ошибок совмещения, что, в свою очередь, будет влиять на доверие пользователей к ОС из-за проблем безопасности...(может этот пункт и не возникнет, если остановиться на системе уровня MS-Dos c небольшими дополнениями)
В-общем(еще я мог что-нибудь забыть, но это уже потом), я готов помочь, но мне важно выполнение первого пункта(над которым я работаю, но пока не хватает знаний в реализации компиляторов и потребностей современного рынка).
Во-первых, с чего начались почти все(может вообще все) современные ОС? Правильным ответом на это будет Unix(или я не прав?). С чего начинался Unix? С языка программирования C. То есть все современное ПО держится сейчас по сути на одном языке(даже Python в него транслируется). Но этот язык был написан 40 с лишком лет назад, и, следовательно, безбожно устарел под требования современных задач(ведь сейчас 3 идиом, включая кроссплатформенность уже не хватает; им параллелизм подавай)… Поэтому, по-моему сугубо личному мнению, прежде чем писать ОС нужно написать компилятор языка программирования, который будет лучше С под современные задачи, при этом полностью транслирующийся в код ассемблера, и еще поддерживающий ассемблерные вставки(вспомните молодость и TurboC30, хотя я и не застал те времена, но предпочту работу с ним, чем с современной IDE по типу codeblocks)
Во-вторых, написание OC требует времени и денег, если ты, конечно, не работаешь на энтузиазме. Но уже довольно давно появился механизм «Pay what you want», который, возможно, сделает, в теории, твой энтузиазм поощряемым и будет стимулировать тебя на написание хорошего кода.(Но как известно это не очень распространенный метод, да и современный мир погряз в получении «выгоды», поэтому время и затраты на написание продукта стараются по максимуму сократить, что приводит к некачественному(небыстрому) коду)
В-третьих, насколько я понял эмпирическим путем, твоя ОС сможет «просуществовать» до новой ветки устаревающих технологий не более 20 лет, при умном проектрировании, поэтому ее разработка должна быть достаточно быстрой, что повлечет работу в огромной команде людей, что вновь приводит нас к предыдущим пунктам, но также создаст кучу ошибок совмещения, что, в свою очередь, будет влиять на доверие пользователей к ОС из-за проблем безопасности...(может этот пункт и не возникнет, если остановиться на системе уровня MS-Dos c небольшими дополнениями)
В-общем(еще я мог что-нибудь забыть, но это уже потом), я готов помочь, но мне важно выполнение первого пункта(над которым я работаю, но пока не хватает знаний в реализации компиляторов и потребностей современного рынка).
Ах да, совсем забыл. Еще было бы полезно сделать общую систему и для ПК, и для смартфонов.
Уже было и есть. Называется линукс.
На смартфонах это представлено вариантами Maemo, Meego, Mer, Sailfish. Особенно Maemo была хороша.
Если же речь об идентичном интерфейсе, то в морг. Работа на экранах разных размеров с разными устройствами ввода порождает очень разные требования к интерфейсу…
Мелкомягкие уже попытались продвинуть идею унифицированного рабочего пространства на основе общего интерфейса для всех устройств. Получилось ожидаемо убого.
Я готов поверить, что линукс 90-х был «той самой» системой, но сейчас я больше даже поверю винде… Половина пакетов написана на python, потребление памяти выше, никаких пояснений.
Разве можно назвать сейчас этого бесповоротного монстра хорошей системой?
Разве можно назвать сейчас этого бесповоротного монстра хорошей системой?
Линукс просто достиг некоторого баланса между обратной совместимостью и наличием более-менее эффективных современных инструментов. Отсюда и монстрообразность и неповоротливость.
При этом линукс сохранил возможность выбирать альтернативы.
Например, монстрообразный DE вроде гнома или KDE легко заменяется на что-то более легкое вроде LXDE.
Насчет питона не совсем соглашусь. Питоньи программы в репозитариях широко представлены, это да. Но я не припомню, чтобы для чего-то с высокими требованиями к поизводительности не имелось не скриптового варианта.
А аппарат на Maemo5 (легендарный Nokia N900) при весьма ограниченном железе шустрил лучше аппаратов на других ОС с более серьезным железом.
Причем там крутился полноценный линукс с иксами и всем остальным. И это были уже давно не 90-е.
С виндой же все обстоит намного хуже.
Монстрообразность такая же, как у линукса по тем же причинам (достигнутый баланс между обратной совместимостью и новшествами). Но все это осложнено полным отсутствием легковесных альтернатив (в системе, естественно, не на уровне пользовательских приложений). А пользовательские приложения все чаще писаны на .NET, что во многих случаях никак не способствует повышенной производительности.
Пока что актуальный линукс способен эффективно работать на существенно более слабых машинах, чем актуальная винда. Во многом, кстати, благодаря наличию легковесных альтернативных версий реализации графического интерфейса.
Язык программирования не определяет в ОС на самом деле почти ничего. Он может в лучшем случае облегчить разработку и сделать работу ОС эффективнее (за счет более эффективной компиляции в команды процессора). Архитектура ОС же будет определяться исключительно логикой написанной программы. Если мы опишем хоть на C, хоть на неведомом языке архитектуру существующей ОС, то она вне зависимости от выбранного языка останется архитектурой существующей ОС.
Да ладно язык программирования C. Буквы!!! Исходные коды OC написаны с помощью букв, а их придумали ещё чёрт знает когда, они давно устарели. Поэтому прежде чем писать новый язык программирования нужно придумать новые буквы.
Во-первых, с чего начались почти все(может вообще все) современные ОС? Правильным ответом на это будет Unix(или я не прав?). С чего начинался Unix? С языка программирования C
Windows семейства NT скорее базируется на идеях VMS и других DECовских, вроде RSX.
Если абстрагироваться от вопросов безопасности, то все написанное в статье не особо то и приносит ценности.
Касательно единой БД, никто не мешает поставлять с приложением свою базку данных (тот же SQLite), оптимизированную именно под задачи приложения. Где-то нужна документарная, где-то SQL, а всем хорошо (да еще и на десятилетия вперед) не сделаешь. Да, лишние мегабайты, но
Касательно единой шины, сейчас не особо то и надо межпроцессное взаимодействие. Для редких задач есть куча средств и так. В основном запросы к серверу надо (либо сокет), вот и все.
Вспоминаю, как дважды в жизни работал с smtp программно (раз на C#, раз на питоне), за 5 минут на стековерфлоу находилась ссылка на бесплатные опенсорс либы, и писалось приложение в 10 строк кода. В чем проблема? Лишние библиотеки на n килобайт?
Касательно единой БД, никто не мешает поставлять с приложением свою базку данных (тот же SQLite), оптимизированную именно под задачи приложения. Где-то нужна документарная, где-то SQL, а всем хорошо (да еще и на десятилетия вперед) не сделаешь. Да, лишние мегабайты, но
у нас ведь гигабайты памяти
Касательно единой шины, сейчас не особо то и надо межпроцессное взаимодействие. Для редких задач есть куча средств и так. В основном запросы к серверу надо (либо сокет), вот и все.
Он просто ищет в БД документы с указанным типом «email». Когда GUI хочет отправить сообщение, то назначает ему свойство outgoing=true. Простой модуль составит список всех исходящих почтовых сообщений и отправит их по STMP.
Вспоминаю, как дважды в жизни работал с smtp программно (раз на C#, раз на питоне), за 5 минут на стековерфлоу находилась ссылка на бесплатные опенсорс либы, и писалось приложение в 10 строк кода. В чем проблема? Лишние библиотеки на n килобайт?
Я согласен почти полностью с автором, но есть слишком весомые «против», чтобы реально сесть и начать писать:
1. Legacy. Тяжёлое, тухлое, ненавистное, но оно везде — я про венду и всё, что с ней связано, от курсов для яслей до сложных программных комплексов. Есть десятки уже написанных ОС с интересными концепциями — почему они не победили? Legacy. Самый яйцеголовый гений бессилен перед секретаршей, у которой «икспишечка» и «флэшечка» — твои «файлы в базе» ничего не стóят, если их нельзя записать на флешку в формате ворда-95 (уверен, до сих пор есть такие юзеры). Поэтому как бы ты ни рвался в своём идеальном мире воплотить лучшие идеи человечества, все они махом разбиваются о тысячи хомячковых систем и привычек.
2. ОС — это хоть и адская затея в плане затрат, но всё же преодолимая. Что делать с драйверами? Что ты скажешь тому же HP — «смотрите, мы сваяли лучшую ОСь на свете»? Они и линукс-то поддерживают через пень-колоду, зачем миру коммерции тратить усилия на ОСь, которая не занимает даже тысячной доли процента? Хуже того — мрази из того же MS могут спокойно подкупить (как они это всегда и делали) производителей на «windows only» драйвера и тогда ты вообще не увидишь кода! И это наша проблема, не их.
3. Патенты. Из России с её «мы им покажем кузькину мать!» всё выглядит легко как у подростка, читающего «кунфу». Но попробуй напиши хоть что-то, напоминающее окна/двери/скруглённые углы, тут же получишь уведомление из самой крутой адвокатской конторы. Это нам смешно видеть «патенты на ковыряние в носу» — там это тупой, но действенный метод держать монополию. Или плати. Причём непонятно кому и непонятно за что.
4. Форматы файлов придуманы не от глупости великой, а наживы ради. Поэтому-то и смешит этот автор-идеалист, который тут вышел весь в белом и предлагает компаниям «давайте житьдружно честно!» — кому это надо? Мелкософт потому и монополист, что годами сидел на своих закрытых форматах! Открытый формат — убийца посредственностей, они просто не выживут. Поэтому никто не будет использовать «единые файлы с тегами» — вот что надо рассматривать, прежде чем публиковать мечтания.
5. Я бы не торопился с идеями «файлы как база» (ввиду бессмысленности) и единой шины. Шину можно склепать за неделю, как ею пользоваться?? Ну послал ты в шину «save» — и чо? :) «Всем сохраниться»? Вот-вот, тут же вылезает проблема адресации, переполнения самой шины, то, сё… непродуманная идея мечтателя. Надо ещё очень много продумать, прежде чем бросаться в бой — концепции закладываются в фундамент, а после первого этажа фундамент не меняют, извини.
В целом, с автором согласен — мир ИТ, несмотря на суету, изрядно протух и некому (и нечем) пнуть всяких микрософтов и гуглов, чтобы шевелили булками. И конкурирующую ОСь тоже неплохо бы создать. Но её перспективы… они не просто туманны — они уже обросли венками. Самому жалко, но это мёртвый проект. Подобные вещи должна двигать средняя компания с хорошим запасом финансов, которая хотя бы выкатит юзабельное ядро и драйвера, а уж программы потихоньку допишутся. И конечно, никакого тухлого POSIX.
1. Legacy. Тяжёлое, тухлое, ненавистное, но оно везде — я про венду и всё, что с ней связано, от курсов для яслей до сложных программных комплексов. Есть десятки уже написанных ОС с интересными концепциями — почему они не победили? Legacy. Самый яйцеголовый гений бессилен перед секретаршей, у которой «икспишечка» и «флэшечка» — твои «файлы в базе» ничего не стóят, если их нельзя записать на флешку в формате ворда-95 (уверен, до сих пор есть такие юзеры). Поэтому как бы ты ни рвался в своём идеальном мире воплотить лучшие идеи человечества, все они махом разбиваются о тысячи хомячковых систем и привычек.
Отступление: давно облизываюсь на QNX. Прекрасная система, микроядро,
сеть, GUI… но опаршивились ребята за своей жадностью — вместо «своё и качественно»,
купились на FOSS — «дёшево и сердито», причём больше сердито, чем дёшево. Вместо нормальной IDE (которая у них была!) — безобразный Эклипс. Вместо того, чтобы взять какой-нибудь D (как прикладной язык) — похабная «сишечка» от gcc. Писать на «этом», с позволения сказать, «инструменте» нет ни малейшего желания. Вот так эти клоуны и сидят как слива в своём embedded рынке последние 20 лет. А бизнес, который не развивается — мёртвый бизнес. Ждём, когда им прилетит граблями «банкрот» и они наконец очухаются.
2. ОС — это хоть и адская затея в плане затрат, но всё же преодолимая. Что делать с драйверами? Что ты скажешь тому же HP — «смотрите, мы сваяли лучшую ОСь на свете»? Они и линукс-то поддерживают через пень-колоду, зачем миру коммерции тратить усилия на ОСь, которая не занимает даже тысячной доли процента? Хуже того — мрази из того же MS могут спокойно подкупить (как они это всегда и делали) производителей на «windows only» драйвера и тогда ты вообще не увидишь кода! И это наша проблема, не их.
3. Патенты. Из России с её «мы им покажем кузькину мать!» всё выглядит легко как у подростка, читающего «кунфу». Но попробуй напиши хоть что-то, напоминающее окна/двери/скруглённые углы, тут же получишь уведомление из самой крутой адвокатской конторы. Это нам смешно видеть «патенты на ковыряние в носу» — там это тупой, но действенный метод держать монополию. Или плати. Причём непонятно кому и непонятно за что.
4. Форматы файлов придуманы не от глупости великой, а наживы ради. Поэтому-то и смешит этот автор-идеалист, который тут вышел весь в белом и предлагает компаниям «давайте жить
5. Я бы не торопился с идеями «файлы как база» (ввиду бессмысленности) и единой шины. Шину можно склепать за неделю, как ею пользоваться?? Ну послал ты в шину «save» — и чо? :) «Всем сохраниться»? Вот-вот, тут же вылезает проблема адресации, переполнения самой шины, то, сё… непродуманная идея мечтателя. Надо ещё очень много продумать, прежде чем бросаться в бой — концепции закладываются в фундамент, а после первого этажа фундамент не меняют, извини.
В целом, с автором согласен — мир ИТ, несмотря на суету, изрядно протух и некому (и нечем) пнуть всяких микрософтов и гуглов, чтобы шевелили булками. И конкурирующую ОСь тоже неплохо бы создать. Но её перспективы… они не просто туманны — они уже обросли венками. Самому жалко, но это мёртвый проект. Подобные вещи должна двигать средняя компания с хорошим запасом финансов, которая хотя бы выкатит юзабельное ядро и драйвера, а уж программы потихоньку допишутся. И конечно, никакого тухлого POSIX.
Почему я не могу иметь файл в двух местах одновременно в своей файловой системе?
Почему не можете?
Это придумали в UNIX очень давно. И до сих пор оно так. И даже в винде оно вроде сделано (естественно не в FAT).
И механизм называется "ссылки".
Есть символические, в которых просто написано, где реально расположен файл в иерархии подкаталогов.
А есть "жесткие", которые реально размещают один и тот же файл в нескольких подкаталогах.
Замедление выпуска новых осей как раз следствие того что спрос удовлетворен уже. Меня всё устраивало еще в хрюше, я переходил на 7 и 10, просто чтоб не отставать, и игры начали уже некоторые не запускаться на XP.
Я так понимаю, автор видит идеальность в максимальном упрощении протоколов взаимодействия приложений между собой и с ОС, а так же в реализации в рамках ОС большого количества универсальных модулей, предназначенных для решения стандартных задач пользователя. И третья идея в том, чтобы приложения тоже были более модульными и более зависимыми от ОС. В принципе, в этом есть рациональное зерно.
И мне, кстати, кажется, что база данных, встроенная прямо в ОС — это очень крутая тема.
Я даже больше скажу: у меня есть предположение, что хранение данных в виде файлов, возможно, — не лучшая парадигма. И хранение данных в виде нереляционной БД было бы куда как интереснее и удобнее.
Ведь что такое обычный файл? Это имя-размер-несколько простых атрибутов и всё. Чтобы корректно прочитать данные из файла, вам надо сначала разобраться (или знать заранее), а что, собсно, за данные в нём находятся, потом, зная его структуру, распарсить, выделить необходимые данные и т.д.
А теперь представьте, что файл хранится сразу как объект в NoSQL-базе. Т.е. вы можете иметь доступ к его структуре средствами ОС безо всякой дополнительной работы. А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой, что позволило бы хранить повторяющийся в разных объектах-файлах кусок данных в одном месте вместо дублирования. Опять же на уровне самой БД можно было бы сделать, чтобы она сама следила, чтобы дублирующие файлы удалялись, оставаясь физически в одном экземпляре.
Допустим, есть у меня сайт с большим количеством статических html-страниц, у которых у всех одинаковые шапки и подвалы. В обычном режиме я просто буду хранить в каждом файле свои копии шапок и подвалов, но имея под рукой вышеописанную систему, я мог бы выделить их в два отдельных файла и подключить к другим файлам через ссылки. А затем я мог бы и эти html-страницы отдавать не собранными, а прямо в виде подграфа объектов, выдранного из БД, и браузер бы уже сам собирал эти страницы.
Конечно, здесь у нас вылазят сразу все проблемы, связанные с синхронностью, дэдлоками и общим усложнением системы хранения, но это же решаемые вещи — все базы данных так или иначе их решают.
И мне, кстати, кажется, что база данных, встроенная прямо в ОС — это очень крутая тема.
Я даже больше скажу: у меня есть предположение, что хранение данных в виде файлов, возможно, — не лучшая парадигма. И хранение данных в виде нереляционной БД было бы куда как интереснее и удобнее.
Ведь что такое обычный файл? Это имя-размер-несколько простых атрибутов и всё. Чтобы корректно прочитать данные из файла, вам надо сначала разобраться (или знать заранее), а что, собсно, за данные в нём находятся, потом, зная его структуру, распарсить, выделить необходимые данные и т.д.
А теперь представьте, что файл хранится сразу как объект в NoSQL-базе. Т.е. вы можете иметь доступ к его структуре средствами ОС безо всякой дополнительной работы. А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой, что позволило бы хранить повторяющийся в разных объектах-файлах кусок данных в одном месте вместо дублирования. Опять же на уровне самой БД можно было бы сделать, чтобы она сама следила, чтобы дублирующие файлы удалялись, оставаясь физически в одном экземпляре.
Допустим, есть у меня сайт с большим количеством статических html-страниц, у которых у всех одинаковые шапки и подвалы. В обычном режиме я просто буду хранить в каждом файле свои копии шапок и подвалов, но имея под рукой вышеописанную систему, я мог бы выделить их в два отдельных файла и подключить к другим файлам через ссылки. А затем я мог бы и эти html-страницы отдавать не собранными, а прямо в виде подграфа объектов, выдранного из БД, и браузер бы уже сам собирал эти страницы.
Конечно, здесь у нас вылазят сразу все проблемы, связанные с синхронностью, дэдлоками и общим усложнением системы хранения, но это же решаемые вещи — все базы данных так или иначе их решают.
>А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой, что позволило бы хранить повторяющийся в разных объектах-файлах кусок данных в одном месте вместо дублирования.
Еще один новый способ послать клиенту вместо файла ярлык на него? О да, его так не хватало!
Еще один новый способ послать клиенту вместо файла ярлык на него? О да, его так не хватало!
Не понял, при чем тут «ярлык» вообще. Высылаться должны данные, а ссылки живут только в рамках передаваемого или хранимого блока. Т.е. просто необходимо подобные связные файлы передавать единым блоком данных, а не разрозненными частями. Т.е. такие ссылки имеют смысл только в рамках БД или пересылаемого дампа.
> Т.е. вы можете иметь доступ к его структуре средствами ОС безо всякой дополнительной работы. А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой
Если «мы можем иметь доступ» — то такая нетривиальная вещь обязательно приведет к ситуациям когда пользователи будут передавать не то что надо.
А если всё это работает под капотом и нам наружу не показывается — это уже есть, зовется дедупликацией, предъявляет требования к оборудованию и производительности, и рядовому пользователю десктопной системы в общем не сдалось.
И вот так везде в этих хотелках.
Если «мы можем иметь доступ» — то такая нетривиальная вещь обязательно приведет к ситуациям когда пользователи будут передавать не то что надо.
А если всё это работает под капотом и нам наружу не показывается — это уже есть, зовется дедупликацией, предъявляет требования к оборудованию и производительности, и рядовому пользователю десктопной системы в общем не сдалось.
И вот так везде в этих хотелках.
А теперь представьте, что файл хранится сразу как объект в NoSQL-базе. Т.е. вы можете иметь доступ к его структуре средствами ОС безо всякой дополнительной работы
Один формат сериализации to rule them all? Спасибо, нет.
А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой, что позволило бы хранить повторяющийся в разных объектах-файлах кусок данных в одном месте вместо дублирования.
Циклические ссылки в масштабе все системы?
Опять же на уровне самой БД можно было бы сделать, чтобы она сама следила, чтобы дублирующие файлы удалялись, оставаясь физически в одном экземпляре.
Встроенная дедупликация уже давно есть в ряде файловых систем. Как обычно, ценой производительности.
Один формат сериализации to rule them all? Спасибо, нет.
Во-первых. У вас один формат хранения информации о файле в файловой системе.
Во-вторых, с точки зрения приложения взаимодействие с файлом не требует его «сериализации» и «десериализации» — это всё будет делать ОС, а вам надо только запросить/сохранить нужные данные в объекте. Как именно будут сериализованны эти данные и как они будут храниться в БД — это отдельный вообще вопрос.
В-третьих, хранить предлагается стандартную информацию + ту, которую захочет программист. Скажем, письмо можно хранить сразу в виде полей «тип файла», «кому», «от кого», «тема», ", «текст» (и т.д.), а сериализацию-десериализацию при его пересылке оставить на ответственность ОС. Опять же никто не мешает сделать свой сериализатор для произвольного объекта.
Циклические ссылки в масштабе все системы?
В базах данных эти вещи решаются. А в сборщиках мусора вообще в реальном времени решаются. И живут как-то)
Встроенная дедупликация уже давно есть в ряде файловых систем. Как обычно, ценой производительности.
Ясное дело, что усложнение систем обычно приводит к уменьшению производительности, но во-первых, мы же говорим о десктопе, который как правило имеет периодический график использования «то пусто, то густо». Операционные системы и так многие вещи стараются делать, когда система не нагружена — таким же образом можно производить и дедупликацию, поскольку это вообще говоря такая вещь, которая на целостность системы вообще не должна влиять. Т.е. система в фоне ищет дубликаты, лишние — удаляет. Если какие-то дубликаты сохранились, то ничего страшного — пусть подождут своей очереди. Хотя… я понял, на производительность это может повлиять, когда нам надо изменить данные в файле, на который уже есть несколько ссылок. Тогда с него надо сначала сделать копию, и её уже править… Теоретически такую проблему можно решить разбиением файла на небольшие чанки (по размеру кластера, например) и копировать только кластер, например… В общем, да, это вопрос для обдумывания. :)
Во-первых. У вас один формат хранения информации о файле в файловой системе.
И что? Это не моя прикладная информация.
Во-вторых, с точки зрения приложения взаимодействие с файлом не требует его «сериализации» и «десериализации» — это всё будет делать ОС, а вам надо только запросить/сохранить нужные данные в объекте. Как именно будут сериализованны эти данные и как они будут храниться в БД — это отдельный вообще вопрос.
Ну так это и плохо: я как программист теряю контроль за тем, что меня волнует (а меня волнует эффективность хранения "объектов" — это если у меня вообще объекты).
В-третьих, хранить предлагается стандартную информацию + ту, которую захочет программист.
Вот на месте "ту, которую захочет программист" и проблема.
Опять же никто не мешает сделать свой сериализатор для произвольного объекта.
… системный?
В базах данных эти вещи решаются.
В реляционных не решаются. В объектных и графовых — возможно, но сколько это стоит?
А в сборщиках мусора вообще в реальном времени решаются.
В сборщиках мусора немного другие задачи решаются.
Ясное дело, что усложнение систем обычно приводит к уменьшению производительности, но во-первых, мы же говорим о десктопе, который как правило имеет периодический график использования «то пусто, то густо».
"То густо, то выключено", вы хотели сказать?
Хотя… я понял, на производительность это может повлиять, когда нам надо изменить данные в файле, на который уже есть несколько ссылок. Тогда с него надо сначала сделать копию, и её уже править… Теоретически такую проблему можно решить разбиением файла на небольшие чанки (по размеру кластера, например) и копировать только кластер, например… В общем, да, это вопрос для обдумывания.
Это типичный copy-on-write, давно реализованный. Просто дорого.
И что? Это не моя прикладная информация.
Вы это информацией пользуетесь, значит это и ваша информация тоже.
Опять же, никто не мешает вам точно так же работать со своими форматами, а в системной базе хранить только базовые атрибуты. Т.е. никто ж не мешает хранить произвольные данные в блоке данных. У вас просто появляется возможность хранить части файла сразу в виде разных полей объекта базы данных, а не хотите — можете всё единым бинарным блоком засунуть в единственное кастомное поле, и тогда это будет практически ничем не отличаться от обычного файла.
Ну так это и плохо: я как программист теряю контроль за тем, что меня волнует (а меня волнует эффективность хранения «объектов» — это если у меня вообще объекты).
См. предыдущий пункт. Программист волен выбрать, что ему важнее. Эффективность сжатия данных? Храни блобы. Удобство доступа? Храни объекты. В чем проблема-то? Мы не теряем то, что имели, а только добавляем новые возможности.
Вот на месте «ту, которую захочет программист» и проблема.
Не понимаю, где проблема. Программист в любом случае хранит в файле ту информацию, которую считает нужным, а проблема обмена такими файлами решается (по жизни) стандартизацией и спецификацией формата.
В реляционных не решаются. В объектных и графовых — возможно, но сколько это стоит?
Я, вроде, изначально говорил о нереляционных. Насчёт «сколько стоит» — не знаю, надо смотреть уже в алгоритмы. В некоторых случаях нереляционные БД эффективнее реляционных. Я не углублялся в рассчёты — мне показалась интересной сама идея :)
В сборщиках мусора немного другие задачи решаются.
В сборщиках мусора в том числе решаются проблемы циклических ссылок.
«То густо, то выключено», вы хотели сказать?
Не знаю, как у вас, но лично у меня компьютер выключается максимум раз в два-три месяца, когда я больше, чем на день, куда-то уезжаю :)
Это типичный copy-on-write, давно реализованный. Просто дорого.
Ну, да, мы тут всё время говорим о том, что всё это уже где-то реализовано, но не собрано в одну кучу. И, собсно, с чего вообще начался разговор — с того, что современные ОС слишком неэффективны и неудобны, т.е. если бы мы смогли при сохранении той же эффективности на несколько порядков увеличить удобство, то потомки нам только спасибо сказали бы :) Опять же, мы ведем речь конкретно о десктопах, а не о высоконагруженных серверах, а на десктопах вполне, я считаю, допустимо пожертвовать частью производительности в пользу удобства.
Вы это информацией пользуетесь, значит это и ваша информация тоже.
Нет — я не несу за нее ответственности. Это очень важное разделение.
Опять же, никто не мешает вам точно так же работать со своими форматами, а в системной базе хранить только базовые атрибуты.
Это ничем не будет отличаться от того, что есть сейчас — и, как следствие, не будет униформности.
В чем проблема-то?
В отсутствии униформности. Без униформности вся эта идея с "БД вместо ФС" не имеет смысла.
Программист в любом случае хранит в файле ту информацию, которую считает нужным, а проблема обмена такими файлами решается (по жизни) стандартизацией и спецификацией формата.
Правильнее было бы сказать "не решается".
Насчёт «сколько стоит» — не знаю, надо смотреть уже в алгоритмы.
Так может надо сначала посмотреть, чтобы понять, осмысленно ли это предлагать?
В сборщиках мусора в том числе решаются проблемы циклических ссылок.
Между "у нас между объектами циклическая ссылка, их можно удалить" и "у нас между объектами циклическая ссылка, их надо вернуть… гм, как?" есть фундаментальная разница.
Не знаю, как у вас, но лично у меня компьютер выключается максимум раз в два-три месяца, когда я больше, чем на день, куда-то уезжаю
А у меня все десктопы (рабочие станции, ноутбук) включаются только тогда, когда мне от них что-то надо — например, поработать. Для постоянной работы есть сервер.
Опять же, мы ведем речь конкретно о десктопах, а не о высоконагруженных серверах, а на десктопах вполне, я считаю, допустимо пожертвовать частью производительности в пользу удобства.
Вот только не "удобства", а "экономии места". И диски сейчас дешевле, чем мое время, поэтому спасибо, нет.
Это ничем не будет отличаться от того, что есть сейчас — и, как следствие, не будет униформности.
Униформность — это вопрос стандартов/спецификаций. Так же, как есть спецификация структуры jpg или png, и вообще любого файла, с которым вы работаете, кроме, может быть, чистых текстовых файлов. Ну, или я не понимаю, что Вы пытаетесь сказать.
Так может надо сначала посмотреть, чтобы понять, осмысленно ли это предлагать?
Ну, это Вы, батенька, совсем расшалились. Во-первых, я сюда, в комменты к довольно абстрактной статье на Хабре, не устраиваться к вам на работу пришел, и я никому не обязан «показывать результат» и что-то там просчитывать. Я зашёл, увидел зацепившую меня идею и немного высказался по этому поводу. Во-вторых, может надо сначала посмотреть, чтобы понять, осмысленно ли это отвергать? Как-то Вы уж больно агрессивно ведёте себя, вам не кажется?
Между «у нас между объектами циклическая ссылка, их можно удалить» и «у нас между объектами циклическая ссылка, их надо вернуть… гм, как?» есть фундаментальная разница.
И в чем же эта фундаментальность, простите?
А у меня все десктопы (рабочие станции, ноутбук) включаются только тогда, когда мне от них что-то надо — например, поработать. Для постоянной работы есть сервер.
Ну, видите, у всех по-разному. А Вы, когда работаете, прям нагружаете свой компьютер по полной, гоняете все время бэнчмарки, игры и майните биткоин? Или, скажем, есть время, когда Вы просто сидите стрОчите комментарии в Хабр, а компьютер в это время по большей части отдыхает? ;)
Вот только не «удобства», а «экономии места». И диски сейчас дешевле, чем мое время, поэтому спасибо, нет.
Да нет же, дедупликация — это только как потенциальная возможность, в целом-то речь идёт не о дедупликации, а об устройстве ФС в виде БД. Ну, и, кроме того, дедупликация — это не только экономия места, но так же и экономия ресурса (количества чтений) диска (один раз объект закэшировали — сто раз отдаём), и экономия сетевого трафика (отдаём повторяющийся кусок один раз, а не десять). Так что, тут главный вопрос в сценарии использования. Например, при большом количестве записи по отношению к количеству чтений, пожалуй, дедупликация вредна, но если у тебя 99% данных (как у меня на десктопе, например), никогда не меняется, то это вполне может оказаться выигрышной стратегией.
поэтому спасибо, нет.
Да никто ж Вас не заставляет)) Как говорится, голосуйте ногами. Не нравится идея и не хочется с ней разбираться — проходите мимо — пусть разбираются те, кому хочется. У нас тут простой «кухонный» разговор на уровне идей, а Вы каких-то цифр уже требуете и доказательств. Не бывает доказательств без эксперимента или по крайней мере строгой математической модели, о чем тут вообще пререкаться?
У вас просто появляется возможность хранить части файла сразу в виде разных полей объекта базы данных,
Шо, опять привет из VMS?
Ох жива идея-то, со внешней структуризацией файлов-то…
Или это уже речь о кошерном формате копибуков, который натягивает структуру на поток битов? Типа кто хочет тот работает структурировано через копибуковую трансляцию, а кто не хочет так тому битики, хмм…
Ох щи… а сейчас-то кто мешает? Я вот пользуюсь там где надо.
Или тут ключ к пониманию — «нереляционная БД»? Так запихать «метаданные» в одну известную не-ACID БД на букву «Монга» я могу и сейчас. И даже бывают случаи, когда там реально «все» хранится, включая двоичные артефакты в виде к примеру PDF (не, я с ума не сошел, просто вот такой вот способ забивания гвоздей микроскопом).
Так где вы говорите, будет added value от того что «НеРСУБД» будет в kernel space?
А то нам инженерам идеи очень нравятся, просто хотелось бы понимания — какую задачу решают.
Так же, как есть спецификация структуры jpg или png, и вообще любого файла, с которым вы работаете
Угу, расскажите мне об этом. Почему-то до сих пор нет унифицированного стандарта на файл на выходе с цифровой камеры, и бедные производители софта, начиная от Adobe и заканчивая dcraw, вынуждены постоянно добавлять поддержку новых камер.
И в чем же эта фундаментальность, простите?
В том, что GC достаточно увидеть цикл, определить, что внешних ссылок в него нет, и выкинуть все объекты (я упрощаю, конечно). А маркирующие GC и вовсе трактуют циклы как "а, мы сюда уже приходили, дальше не надо". А вот когда мы используем ссылки для "а давайте включим один файл в другой", то что делать веб-серверу из примера где-то тут в комментариях, когда тот рисует страницу (ок), в нее включен заголовок (ок, его отрисовали тоже), в заголовок включено меню (ок, его отрисовали тоже), в него включен заголовок (ой, что?).
Или, скажем, есть время, когда Вы просто сидите стрОчите комментарии в Хабр, а компьютер в это время по большей части отдыхает? ;)
Обычно я строчу комментарии на хабр, когда компьютер чем-то занят полезным, типа сборки билда или тестов. А еще планшеты есть, с них тоже ничего так писать на хабр.
Ну, и, кроме того, дедупликация — это не только экономия места, но так же и экономия ресурса (количества чтений) диска (один раз объект закэшировали — сто раз отдаём), и экономия сетевого трафика (отдаём повторяющийся кусок один раз, а не десять).
Чтобы было выгодно кэшировать объект, нужно чтобы он запрашивался много раз (а чтобы включилась дедупликация — чтобы запрашивались разные объекты, которые дедуплицировались в один).
А чтобы экономился сетевой трафик, нужно, чтобы сетевой протокол поддерживал дедупликацию и ссылки, и устройство ФС тут мало поможет.
UFO just landed and posted this here
Солидарен со многими вещами, но не со всеми.
Десктопные ОС и правда замерли в середине 90-х.
Нововведения хороши, но они должны делать работу прозрачнее, интуитивнее. А не увеличивать количество абстракций.
Я уже пару лет периодически задумываюсь над заменой Active Directory(как правило после глубокого копания). Такая архаичная и неудобная система, но каких-либо вменяемых аналогов нет, и MS ничего менять не собирается.
Десктопные ОС и правда замерли в середине 90-х.
Нововведения хороши, но они должны делать работу прозрачнее, интуитивнее. А не увеличивать количество абстракций.
Я уже пару лет периодически задумываюсь над заменой Active Directory(как правило после глубокого копания). Такая архаичная и неудобная система, но каких-либо вменяемых аналогов нет, и MS ничего менять не собирается.
По поводу ФС как БД с тегами и прочей метаинформацией всецело поддерживаю. Это реально нужная вещь.
Конечно в основе должна быть иерархическая модель — так удобно и привычно, зачем ломать то что хорошо себя зарекомендовало. В распространенных ФС под все основные ОС есть хардлинки и симлинки, а также области для метаатрибутов; но работа с ними очень плохо интегрирована с GUI. В линуксе симлинки и хардлинки еще более-менее используются, а в винде — почти никак. В тот же Total Commander никак не хотят добавить кнопки «создать симлинк» и «создать хардлинк» — причем люди просят, но у авторов есть официальная позиция, и знаете какая? «Большинство не осилит». И вот по таким причинам «большинство» вообще не знает о том, что файл может физически находиться в нескольких местах ФС одновременно. Да и зачем это большинству, если оно тупо хранит свои файлы на «рабочем столе»?
Но для хардлинков нужно как минимум максимально удобное отображение счетчика ссылок на файл — чтобы при удалении было понятно, удаляем ли мы его вообще или просто удаляем одну из ссылок. Симлинки же в NTFS вообще странно сделаны, в двух вариантах.
Я уж не говорю о том, что крайне необходимо иметь продуманную и интегрированную в ФС систему пользовательских атрибутов/тегов. Поиск, сортировку по ним, конвертацию одних тегов в другие и т.д. Мне вот приходится исхитряться и придумывать собственную условную нотацию для именования файлов и папок, добавлять в начало имен всякие "_", "-", "@", "!" и прочие чтобы хоть как-то внести дополнительную информацию.
Конечно в основе должна быть иерархическая модель — так удобно и привычно, зачем ломать то что хорошо себя зарекомендовало. В распространенных ФС под все основные ОС есть хардлинки и симлинки, а также области для метаатрибутов; но работа с ними очень плохо интегрирована с GUI. В линуксе симлинки и хардлинки еще более-менее используются, а в винде — почти никак. В тот же Total Commander никак не хотят добавить кнопки «создать симлинк» и «создать хардлинк» — причем люди просят, но у авторов есть официальная позиция, и знаете какая? «Большинство не осилит». И вот по таким причинам «большинство» вообще не знает о том, что файл может физически находиться в нескольких местах ФС одновременно. Да и зачем это большинству, если оно тупо хранит свои файлы на «рабочем столе»?
Но для хардлинков нужно как минимум максимально удобное отображение счетчика ссылок на файл — чтобы при удалении было понятно, удаляем ли мы его вообще или просто удаляем одну из ссылок. Симлинки же в NTFS вообще странно сделаны, в двух вариантах.
Я уж не говорю о том, что крайне необходимо иметь продуманную и интегрированную в ФС систему пользовательских атрибутов/тегов. Поиск, сортировку по ним, конвертацию одних тегов в другие и т.д. Мне вот приходится исхитряться и придумывать собственную условную нотацию для именования файлов и папок, добавлять в начало имен всякие "_", "-", "@", "!" и прочие чтобы хоть как-то внести дополнительную информацию.
Эмм, разве обычный ярлык не является симлинком? Хардлинки в системе тоже широко используются, взять хотя бы ту же горячо любимую папку WinSxS.
Другое дело, что пользователи часто не знают об этом функционале и его реализация не заложена в GUI Windows. Вообще Майкрософт любят делать никому не нужные ограничения. Например в Проводнике длина пути ограничена 255 символами, когда NTFS поддерживает 32767. Исправили сию «фичу, а не багу» только в Windows 10, и то поддержку длинных имен надо ручками включать.
Другое дело, что пользователи часто не знают об этом функционале и его реализация не заложена в GUI Windows. Вообще Майкрософт любят делать никому не нужные ограничения. Например в Проводнике длина пути ограничена 255 символами, когда NTFS поддерживает 32767. Исправили сию «фичу, а не багу» только в Windows 10, и то поддержку длинных имен надо ручками включать.
UFO just landed and posted this here
Я с удовольствием прочел статью, отдельно улыбнулся над футуристической картинкой, где проектор создает рабочие экраны для удобно лежащего человека. Вспомнил Тони Старка с его Джарвисом — кто бы ни хотел себе настолько умную систему(не ИИ), которую можно обучать своим привычкам, и она будет запоминать, в каком порядке вы просматриваете сайты, проснувшись или придя с работы, например, какие сообщения из мессенджеров более важные и их следует показывать поверх всего вашего «рабочего пространства». Если уж исходить из идеи проектора, который через камеру и другие датчики определяет куда вы тыкаете, то эти же устройства могут использоваться для оценивания состояния самого пользователя, степени его усталости, например. Сама концепция идеальной ОС, представленная в этой статье, уже сама по себе настолько футуристично выглядит, что несмотря на то, что «здесь нет ничего нового», на проверку окажется, что для работы подобной системы придется придумывать, именно придумывать, новое железо, и если не начинку, то хотя бы все HID-устройства, поскольку мышкоклавой будет банально неудобно пользоваться.
И, собственно, почему всего этого еще нет? Да потому, что автор (я лишь предполагаю) еще не полностью утратил потенциал воображения, а вот все те, кто придумывает новшества в таких больших компаниях-производителях ОСей, своей фантазии уже давно лишились, и могут улучшить (или нет) лишь то, что уже есть и работает. И не потому, что начинать с нуля опасно по многим причинам, в т.ч. и по расходам — а потому, что пойди найди штат программистов, которые захотят и будут во время разработки думать именно так, как тот самый будущий пользователь идеальной ОСи. Потому что узкая специализация и, как следствие, полное остутствие возможности вообразить и претворить фантазии в реальность, в наши дни — норма для общества. Конечно, это лишь мое мнение, и исключения из правил есть всегда. И проще сказать что таки да — никому эта идеальная ОСь не нужна из пользователей, а что уж говорить про разработчиков.
И, собственно, почему всего этого еще нет? Да потому, что автор (я лишь предполагаю) еще не полностью утратил потенциал воображения, а вот все те, кто придумывает новшества в таких больших компаниях-производителях ОСей, своей фантазии уже давно лишились, и могут улучшить (или нет) лишь то, что уже есть и работает. И не потому, что начинать с нуля опасно по многим причинам, в т.ч. и по расходам — а потому, что пойди найди штат программистов, которые захотят и будут во время разработки думать именно так, как тот самый будущий пользователь идеальной ОСи. Потому что узкая специализация и, как следствие, полное остутствие возможности вообразить и претворить фантазии в реальность, в наши дни — норма для общества. Конечно, это лишь мое мнение, и исключения из правил есть всегда. И проще сказать что таки да — никому эта идеальная ОСь не нужна из пользователей, а что уж говорить про разработчиков.
>Я с удовольствием прочел статью, отдельно улыбнулся над футуристической картинкой, где проектор создает рабочие экраны для удобно лежащего человека.
Картинка хорошо иллюстрирует статью, да.
«Давайте сделаем чего-то эдакое чтобы ново, круто, футуристично и чтобы УХ!» — а при попытке реализовать на практике или хотя бы нарисовать как они это видят получается та еще лютая хрень. Как вот с этим креслом. Без нормального подголовника под затылок в таком положении экранов голова через пару часов отвалится, как и руки, которыми предлагают тыкать в экранчики на уровне выше головы, при этом не имея подлокотников. Про то что икры будут затекать без опоры под пятки дизайнер тоже забыл потому что не рисовать не мешки ворочать, зато экранчики на основании прилепить — это святое, это необходимо. Ну и полупрозрачные экраны, конечно, это же так удобно и полезно для глаз — видеть комнату сквозь текст…
Картинка хорошо иллюстрирует статью, да.
«Давайте сделаем чего-то эдакое чтобы ново, круто, футуристично и чтобы УХ!» — а при попытке реализовать на практике или хотя бы нарисовать как они это видят получается та еще лютая хрень. Как вот с этим креслом. Без нормального подголовника под затылок в таком положении экранов голова через пару часов отвалится, как и руки, которыми предлагают тыкать в экранчики на уровне выше головы, при этом не имея подлокотников. Про то что икры будут затекать без опоры под пятки дизайнер тоже забыл потому что не рисовать не мешки ворочать, зато экранчики на основании прилепить — это святое, это необходимо. Ну и полупрозрачные экраны, конечно, это же так удобно и полезно для глаз — видеть комнату сквозь текст…
Потому что узкая специализация и, как следствие, полное остутствие возможности вообразить и претворить фантазии в реальность, в наши дни — норма для общества. Конечно, это лишь мое мнение, и исключения из правил есть всегда. И проще сказать что таки да — никому эта идеальная ОСь не нужна из пользователей, а что уж говорить про разработчиков.
Тогда эту ОС нужно создавать энтузиастам в Майнкрафт — и сообщество там большое — в том числе и "образцовых" пользователей, которые считают что компьютер — это его дисплей и с фантазией всё в порядке и игру можно использовать как среду для тестирования в условиях, близких к реальным.
Как только появится массовый двусторонний нейроинтерфейс — можно будет говорить о «перенаправить видео из скайпика куда то там» и всякое такое. Сейчас же — это все не нужно, неудобно и вредно.
Статья из разряда
В 1995 году Doom не использовал 3Д ускорителей поскольку их просто не было у большинства. И под Windows в 1995 году он не работал (не под 95, не под 3.11 и не под NT) а только под DOS.
Раньше трава была зеленееа по фактам
Требовались огромные усилия, чтобы запустить Doom с 3D-ускорением в X Windows в середине 2000-х, тривиальная задача для середины 1990-х в Microsoft Windows.
В 1995 году Doom не использовал 3Д ускорителей поскольку их просто не было у большинства. И под Windows в 1995 году он не работал (не под 95, не под 3.11 и не под NT) а только под DOS.
По поводу быстрого поиска файлов по названию, может кто-то не видел:
Everything
Не совсем то, что хочется автору (поиск по мета-тэгам), но по названию ищет очень быстро на больших списках. Индексирование работает на уровне NTFS.
Everything
Не совсем то, что хочется автору (поиск по мета-тэгам), но по названию ищет очень быстро на больших списках. Индексирование работает на уровне NTFS.
Многое из того, что хочет автор (таскание вкладок между разными приложениями, ноутбук как усилитель голоса и т.д.), нужно только автору небольшому количеству пользователей. Обычно учитывается интересы большого числа пользователей и то не всегда. И если есть какая-то острая потребность, то она будет удовлетворена. Как пример, можно вспомнить браузер IE и потребность в нормальном браузере.
Не совсем с вами согласен. Конкретно, применимо ко мне, с перетаскиваниями страниц из браузера в браузер я бы сильно подружился. Объясню почему: всеми любимый Хром жрёт память как хомяк. А мне часто нужно что-то открыть быстро (не в силу того, что таймер бомбы тикает, а просто потому, что открыто и так слишком много вкладок, и общая работы системы замедляется. А я человек спокойный, но только до определённого момента). К тому же использую разные браузеры для разных целей, в силу того, что в каждом много вкладок (опять же память кушает), а открытие разных экземпляров одного браузера, как вы понимаете, ни к чему хорошему не приводит, опять же, в силу потребления памяти. И частенько нужно посмотреть что-то не по теме открытого браузера (это мое ОКР или СНС, не знаю) :). Простым перетаскиванием я бы решил много проблем…
Сейчас поэкспериментировал с ff и ie
Ссылки и закладки перетаскиваются в обе стороны, но есть неудобство — открывается в текущей вкладке.
Содержимое строки адреса только из ff в ie. Обратно никак.
Вкладки не перетаскиваются совсем. Задумался о плагинах для ff: реализующем перетаскивание вкладок как ссылок и обеспечивающем открытие новой вкладки при заносе ссылки извне.
Насколько я понял из статьи, автор хочет чтоб вкладки браузера можно было перетаскивать не только в другой браузер, а куда угодно. К сожалению, как именно должны реагировать другие приложения, он не описал, там же «растровые прямоугольники из битов», так что все очевидно. А я бы хотел посмотреть на то, что должен делать, например, блокнот, если в него перетащить окно с фильмом и т.д.
Здесь то на уровне фантазии пока, иначе бы это было бизнес-планом :) Я тоже могу много чего придумать без конкретной реализации. Касательно того, что будет делать блокнот, если в окно перетащить окно с фильмом, можно сделать так, что блокнот распишет все диалоги по именам, со ссылками на музыку по времени :) Как вы сами понимаете, пока это недостижимо.
Насколько я понимаю, у автора статьи речь о перетаскивании вкладки не в смысле интеграции содержимого в другое приложение, а в смысле тупой состыковки окон.
Примерно как в каком-нибудь IDE (том же Delphi). Там часто можно пристыковывать друг к другу окна с разным содержимым (например, редактор кода к свойствам объекта), что никак не влияет на взаимозависимость и функциональность окон.
Как по мне, было бы удобно. Пристыковал к тому же IDE вкладку браузера. Она висит себе, функционируя все еще в браузере и будучи никак не связано функционально с IDE, но при этом находясь связанным с окном IDE,
Когда слышу это, сразу вспоминается презентация OLE, DDE. И аналогичных механизмов в OS/2.
Точно такие же футуристические заявления, примеры с прикреплением видео или таблиц в текстовый документ и тому подобное.
Это. Уже. Было.
Точно такие же футуристические заявления, примеры с прикреплением видео или таблиц в текстовый документ и тому подобное.
Это. Уже. Было.
Вот одна из старых презентаций OS/2:
youtu.be/-DAojx2Hgec?t=1h21m36s
youtu.be/-DAojx2Hgec?t=1h21m36s
«Общая шина» это вообще мем
Простите, кто не готов? Wayland? Готовее готовых. У меня на столе лежит Dell XPS13, на нём прекрасно работает Wayland в составе свежей бубунты (17.10). Единственное, что меня останавливает — это отсутствие primary buffer, но и его фиксят.
Я не специалист, но всё написанное, конкретно для меня, очень интересно. И да, я бы поучаствовал в разработке, если бы было больше знаний.
P.S. Всегда хотел буфер обмена хотя бы с 3-мя ячейками (запас). Значительно удобней копировать имя пользователя и пароль из хранителя паролей было бы :)
P.S. Всегда хотел буфер обмена хотя бы с 3-мя ячейками (запас). Значительно удобней копировать имя пользователя и пароль из хранителя паролей было бы :)
Для буфера из 5 ячеек есть AutoIt. Для копирования логин\пароля есть куча менеджеров даже с автовходом на страницу и заполнением, типа 1password и др.
Безопасность, к самой системе, как-то больше доверия.
Не, ну так то да, если половина прог будет изначально в системе будет круто…
… особенно будет круто, если они будут безальтернативными. Правда же?
Без жесткой стандартизации сам смысл такой ОС пропадает (: 99% народа использует стандартый проводник, или стадартный кнтлС+кнтрлв и не знает про другие буферы обмена, будут использовать новый встроенный в новую ОС. Другой вопрос что нужно собрать очень много народу чтобы в целом все обсудить и сразу добавить все нужные фишки, а не так, чтобы все еще на вин10 никак не могут допилить прогресс бар для перекидывания файлов по фтп (он как бы есть, но без скорости и оставшегося времени). Тут надо очень комплексно сначала думать обо всех аспектах сразу, при том, в совокупности.
Всё равно, главное, лишь бы были удобны настолько, чтобы альтернативы не хотелось.
То, что у разных людей разные критерии удобства, вас не смущает?
Если так подходить к вопросу, то каждому человеку следует написать свою собственную ОС, сообразно своему понятию удобства пользования :)
Следует дать возможность выбора. Я бы предпочел, если у меня есть требования к менеджерам паролей, выбирать менеджер паролей, а не ОС.
В этом-то удобство пользования и заключается (как понял смысл данной статьи). Чтобы ОС была одна(едина, или как еще это описать?..), но предоставляла настолько гибкий функционал, что ограничения казались бы невозможными.
Максимально гибкий функционал предоставляет язык программирования.
Это уже не про ОС. Язык реализации неважен. Функционал самих приложений. Для использования конечным потребителем.
Я и говорю: максимально гибкий функционал приложений предоставляется языком программирования. Запрограммируй себе что хочешь.
Я, честно говоря, сомневаюсь, что мы друг друга до конца поняли. Что делать в том случае, если человек не программист? Исключая очевидные ответы, пожалуйста :)
А если человек не программист, он не получит "настолько гибкого функционала". И ему как раз проще выбирать между несколькими программами, нежели "настраивать" одну.
Эти разные программы тоже надо будет настраивать, но без единого интерфейса настройки, что, как вы понимаете, менее удобно :)
А вот не факт. Идеальная (для пользователя) программа — это та, которую настраивать не надо вовсе. Ну и да, что такое "единый интерфейс настройки" я тоже не понимаю.
Идеальная программа, это утопия. А «единый интерфейс настройки» вполне реальная вещь. Примитивный пример: расставить «галки» сообразно своим нуждам в одном меню, которое позволит выбрать именно те функции, которые вам нужны (или будут нужны). Как показывает практика, в разных приложениях это реализовано по-разному(где-то Preferences в главном меню, где-то придётся покопаться). Но главное, опять же функционал самой программы, который позволит это делать (пример: калькулятор в винде — кому-то просто умножить 2 числа, кому-то постоянно инженерный нужен).
Идеальная программа, это утопия
Как и "гибкий функционал".
Как показывает практика, в разных приложениях это реализовано по-разному(где-то Preferences в главном меню, где-то придётся покопаться).
Вы не задумывались, почему?
Так как мы теоритизируем(по крайней мере, я, точно), гибкий функционал более достижим, нежели идеальная программа.
Задумывался. И вариант «защиты от дурака» мне не кажется всеобъясняющим. Скорее всего не прав в этом вопросе. Если не жалко времени, просветите меня. Повторюсь, если вы не читали мой 1-й комментарий: я простой пользователь(потому и теоритизирую :) ), к разработке ПО не имею никакого отношения. Просто выражаю свою точку зрения, исходя из опыта пользования различными программами и ОС.
Вы не задумывались, почему?
Задумывался. И вариант «защиты от дурака» мне не кажется всеобъясняющим. Скорее всего не прав в этом вопросе. Если не жалко времени, просветите меня. Повторюсь, если вы не читали мой 1-й комментарий: я простой пользователь(потому и теоритизирую :) ), к разработке ПО не имею никакого отношения. Просто выражаю свою точку зрения, исходя из опыта пользования различными программами и ОС.
Так как мы теоритизируем(по крайней мере, я, точно), гибкий функционал более достижим
Ну да, достижим. В виде языка программирования. Все остальное недостаточно гибко (да и это — недостаточно гибко).
И вариант «защиты от дурака» мне не кажется всеобъясняющим.
И правильно. Правильный ответ — потому что разным людям так удобнее.
А если предположить, что ОС и язык программирования будут предоставлять такие возможности, что только совсем гуманитарий не сможет написать нужную ему программу с его функционалом...(В качестве совсем утрированного примера можно взять MS-Dos и Python.)
Всегда хотел буфер обмена хотя бы с 3-мя ячейками (запас). Значительно удобней копировать имя пользователя и пароль из хранителя паролей было бы :)
Не скажу за маки, но под линукс и винду менеджеров буфера обмена разной, степени навороченности как у собаки блох.
вот, честно говоря, по причине молодости уже и не вспомню, но мне казалось был буфер на несколько ячеек в 98 винде/ворде того времени
Начал писать подробный ответ, но при чтении про фантазии автора как устроен внутри email-клиент (Кстати, про какой именно клиент речь, он почему-то скромно умолчал), про единую базу документов и единую межпроцессную шину меня разобрал смех и я забил.
Автор банально некомпетентен и скорее всего по жизни занимается высокоуровневой разработкой (пишет glue code), проецируя свой опыт на работу ОС в целом. Кроме того, он путает функцинальность ОС с функциональностью прикладных приложений.
Автор банально некомпетентен и скорее всего по жизни занимается высокоуровневой разработкой (пишет glue code), проецируя свой опыт на работу ОС в целом. Кроме того, он путает функцинальность ОС с функциональностью прикладных приложений.
По-моему автор перечисляет то, о чем в свое время рассказывал Раскин, или пытались сделать в нашей отечественной ОС Фантом ru.wikipedia.org/wiki/Фантом_(операционная_система)
А ведь совершенная ОС нужна. Но её сможет с разумные сроки сделать только… ИИ.
Как странно это бы не звучало. И ещё не известно что легче написать ОС игр ИИ.
По крайней мере в ИИ вбухивают $$. И сделают ИИ от и ОС напишет. По типу джарсиса с элементами ИИ
Как странно это бы не звучало. И ещё не известно что легче написать ОС игр ИИ.
По крайней мере в ИИ вбухивают $$. И сделают ИИ от и ОС напишет. По типу джарсиса с элементами ИИ
UFO just landed and posted this here
Интересно было бы отправить перевод этой линии комментариев автору статьи. Кто-нибудь возьмется перевести их? Дайте ссылку на файл, а я от своего имени любезно поделюсь вашим мнением.
Все таки это не мечты, а натуральная идея — создать Новую Операционную Систему.
В будущем мне представляется, что ОС будет наподобие робота. Робота-добровольца. Робота-раба. Робота-служанки. Друга, товрища, брата, сестры и так далее. Будет зависеть уже от выдумки программиста.
Дальше. Изначально было сказано, на мой взгляд, верное сопостовление — Язык — Операционная Система. Что вы хотите от Си? Максимум Линукс. Ну если бы вся промышленность по производству чипов была на него заточена со своими драйверами и архитетурой вычислительных блоков, то тогда вы бы получили все равно Совершенный Идеальный Линукс и не более того.
Итак — Новый Язык — Новая ОС. Что мы имеем. Язык разрабатывается под определенные задачи. ОС — это не самоцель, а инструмент владения и управления.
Нужно что-то такое подо что ставить цель и под нее задачи. А дальше будут варианты достижения.
То что проблема новой ОС зреет это понятно. То что общество к ней еще не готово, тоже ясно. Поэтому говорить здесь можно только оторвавшись от сегодняшних насущных проблем, помечтав.
Самое выгодное положение для человека — лежа. Под это кто-нибудь делал интерфейс?
В ванне-бассейне теплой воды лежать-плавать — состояние наподобие невесомости. Это идеальная платформа, фон на котором можно делать игровые приложение или как они там будут потом называться. Датчики давления и другие приспособления будут связывать с Реальностью. Тогда будет только одна реальность — как сейчас говорят — дополненная. Тогда она будет называться иначе, наверняка.
«Самое гибкое приложение — это когда ты его сам программируешь» — это из этой линнии комментариев. — Да? Но тогда язык должен быть таким, чтоб любая домохозяйка могла на нем программировать. Это положение входит в систему — ОС — язык.
Программистов единицы. Это глубоко специфическая специальность. Вы, как иностранцы — говорите на своем языке с машиной — программисты. И не требуйте от нас повторения прохождения вашего пути. У нас своя дорога. Так вот — все сводится к тому, что скоро программировать, или как это будет называться потом, сможет каждый. То есть — выше языков высокого уровня. Появятся Житейские языки программирования — это еще более обособленные инструменты от «железа». И на основе их то и можно будет попробовать, что-то строить. Типа, какую-нибудь ОС или приложения.
Автор делает замечание производителям — почему столь сложные системы, как слежение за движением глаз вы делаете на относительно слабых мобильных приборах и не развиваете их сколько-либо приемлемо на мощных и сверхмощных настольных системах и рабочих станциях. Кроме слежения за яблоком глаз есть масса других систем и приспособлений, которые пригодились бы многим. Они же думают только о деньгах, о прибыли, в первую очередь. Это уже всем понятно.
Теперь о Билле Гейтце. Этот парень бизнесмен капиталлистического общества. Что вы от него хотите? Кстати, его миллиардики с него уже сдернули. Это так называемые быстрые деньги.
А теперь главное.
Никто не будет и не сможет у нас финансировать разработку Новой ОС. Только Государство. Только ему сегодня под силу эта задача. В Китае примерно так и поступили — для внутреннего рынка выпустили свои системники и запустили на них Линукс. Ума не хватает свою ОС создать.
А Русские это смогут. Но какой урон потерпит, не просто Майкрософт, а весь англо-саксонский капиталистический мир! Поэтому никто это не позволит. Особенно на фоне нашей, откровенно, слабой страны с ее дурным правительством.
Так что отсутствие Новой ОС — это вопрос философский. Вопрос идеологии и монополии. То есть власти и денег. И отдавать приоритет кому бы то ни было им опасно.
Но США не вечно. Земной шар круглый. Земной мир замкнутый. И придет такое время, когда это будет норма — разработка операционной системы! А не как сейчас, когда монополия давит все в ещё зачатке. И когда есть целые отделы слежки и, как это у них называется — собственной безопасности — не пущать, авторское право, лицензия и информационная, патентная война.
А ещё есть стереотипы, инерционность сознания, привычки, — мы с вами, которые так или иначе задерживаем приход нового! И ему этому Новому надо прилагать неимоверные усилия, чтоб прорваться в наш мир.
Все таки это не мечты, а натуральная идея — создать Новую Операционную Систему.
В будущем мне представляется, что ОС будет наподобие робота. Робота-добровольца. Робота-раба. Робота-служанки. Друга, товрища, брата, сестры и так далее. Будет зависеть уже от выдумки программиста.
Дальше. Изначально было сказано, на мой взгляд, верное сопостовление — Язык — Операционная Система. Что вы хотите от Си? Максимум Линукс. Ну если бы вся промышленность по производству чипов была на него заточена со своими драйверами и архитетурой вычислительных блоков, то тогда вы бы получили все равно Совершенный Идеальный Линукс и не более того.
Итак — Новый Язык — Новая ОС. Что мы имеем. Язык разрабатывается под определенные задачи. ОС — это не самоцель, а инструмент владения и управления.
Нужно что-то такое подо что ставить цель и под нее задачи. А дальше будут варианты достижения.
То что проблема новой ОС зреет это понятно. То что общество к ней еще не готово, тоже ясно. Поэтому говорить здесь можно только оторвавшись от сегодняшних насущных проблем, помечтав.
Самое выгодное положение для человека — лежа. Под это кто-нибудь делал интерфейс?
В ванне-бассейне теплой воды лежать-плавать — состояние наподобие невесомости. Это идеальная платформа, фон на котором можно делать игровые приложение или как они там будут потом называться. Датчики давления и другие приспособления будут связывать с Реальностью. Тогда будет только одна реальность — как сейчас говорят — дополненная. Тогда она будет называться иначе, наверняка.
«Самое гибкое приложение — это когда ты его сам программируешь» — это из этой линнии комментариев. — Да? Но тогда язык должен быть таким, чтоб любая домохозяйка могла на нем программировать. Это положение входит в систему — ОС — язык.
Программистов единицы. Это глубоко специфическая специальность. Вы, как иностранцы — говорите на своем языке с машиной — программисты. И не требуйте от нас повторения прохождения вашего пути. У нас своя дорога. Так вот — все сводится к тому, что скоро программировать, или как это будет называться потом, сможет каждый. То есть — выше языков высокого уровня. Появятся Житейские языки программирования — это еще более обособленные инструменты от «железа». И на основе их то и можно будет попробовать, что-то строить. Типа, какую-нибудь ОС или приложения.
Автор делает замечание производителям — почему столь сложные системы, как слежение за движением глаз вы делаете на относительно слабых мобильных приборах и не развиваете их сколько-либо приемлемо на мощных и сверхмощных настольных системах и рабочих станциях. Кроме слежения за яблоком глаз есть масса других систем и приспособлений, которые пригодились бы многим. Они же думают только о деньгах, о прибыли, в первую очередь. Это уже всем понятно.
Теперь о Билле Гейтце. Этот парень бизнесмен капиталлистического общества. Что вы от него хотите? Кстати, его миллиардики с него уже сдернули. Это так называемые быстрые деньги.
А теперь главное.
Никто не будет и не сможет у нас финансировать разработку Новой ОС. Только Государство. Только ему сегодня под силу эта задача. В Китае примерно так и поступили — для внутреннего рынка выпустили свои системники и запустили на них Линукс. Ума не хватает свою ОС создать.
А Русские это смогут. Но какой урон потерпит, не просто Майкрософт, а весь англо-саксонский капиталистический мир! Поэтому никто это не позволит. Особенно на фоне нашей, откровенно, слабой страны с ее дурным правительством.
Так что отсутствие Новой ОС — это вопрос философский. Вопрос идеологии и монополии. То есть власти и денег. И отдавать приоритет кому бы то ни было им опасно.
Но США не вечно. Земной шар круглый. Земной мир замкнутый. И придет такое время, когда это будет норма — разработка операционной системы! А не как сейчас, когда монополия давит все в ещё зачатке. И когда есть целые отделы слежки и, как это у них называется — собственной безопасности — не пущать, авторское право, лицензия и информационная, патентная война.
А ещё есть стереотипы, инерционность сознания, привычки, — мы с вами, которые так или иначе задерживаем приход нового! И ему этому Новому надо прилагать неимоверные усилия, чтоб прорваться в наш мир.
UFO just landed and posted this here
Самое выгодное положение для человека — лежа.
Разве? Почему?
Всё, описанное автором, давно имеется, но не используется. Почему не используется? Вероятно, потому что мало доступных и понятных примеров использования. Многие слышали, что можно обмениваться данными через пайпы, управлять контролами через сигналы, что в файловой системе есть метаданные. Но как это правильно использовать — знают немногие. А вот описаний и примеров использования громоздких коммерческих решений и их опенсорсных аналогов — очень много.
Мне нравится ход мыслей автора, он хочет легкости и инновационности. Но тяжелое легаси не позволяет это все сделать.
Краеугольная проблема в том, что куча компаний работают с революционным подходом.. Революционный стиль выражается в том, что в погоне за наживой и рынком, коммерческие компании параллельно ведут разработку над одними и теми же проблемами. Каждая решает проблему с нуля «своим» способом, в результате проделывается огромное количество дублированной работы. Многие из крупных компаний хотят чуть ли не захватить весь мир и «посдаить всех на иглу». В погоне за долей рынка, компании стремятся вытеснить друг друга вместо того, чтобы объединиться и скооперироваться для решения одной и той же задачи. Все было бы относительно неплохо, если бы рынок завоевывался ислючительно честными способами, без аггресивного маркетинга, а опыт неудач был бы использован.
Такой подход породил кучу неподдерживаемого и несовместимого легаси, как на уровне ПО, так и на уровне железа.
Как мне кажется, выход заключается в применении консервативного подхода, когда целью становится не получение прибыли, а получение продукта с заранее заданными характеристиками. Не существует 10 систем параллельно, а есть всего лишь какая-то обозримая линейка, заточенная под нужды пользователя. Для мобильной одна ОС, для десктопа другая и т.д. Но при этом все они базируются на каких-то общих компонентах и принципах. Точно так же со всем остальным ключевым или массовым софтом и технологиями. Такой подход выглядит несбыточным, т.к. требует централизованного комитета стандартизации/аттестации, когда рассмотрев 5 образцов выбирает 2 или 3 под нужные задачи. И потом все разработчики работают над 2-3 компонентами вместо 20.
Из недавнего поразил зоопарк пакетов для разработки под nodejs. Открытость и отсуствие централизации порождает неимоверное количество компонентов, каждый из которых дублирует какую-то часть другого. Одни библиотеки для рисования графиков чего стоят. Хотя по факту обошлись бы всего тремя типами, либо симбиозом трех: супер быстрые на canvas(растровые), комбинированные SVG+canvas, красивые и кастомизируемые на SVG, но требующие выч мощносте при обновлении данных.
А в итоге наплодили графических библиотек целую кучу и потом сидишь и тратишь время на то, чтобы понять какая лучше, в итоге КПД получается как у паровоза, либо *як-*як и в прод.
Итог: пока в электронике транзисторы и конденсаторы, то и жить нам с таким легаси, т.к. его очень и очень много. Революционно новое появится, когда массово будут использоваться другие технологии: квантовые компьютеры или био программы
Снился такой сон: я стою в какой-то комнате, передо мной некая субстанция по форме напоминающая кренга (из черепаше нинзя), только меньше (примерно 1,5-2 мужских кулака по объему). На ней ярко выражены сверические области(https://cdn.pixabay.com/photo/2015/08/02/23/26/adrenaline-872346_960_720.png примерно как на картинке, только областей было больше), разных ядовитых цветов: coral, magenta, mauve. Рядом стоит какой-то человек. Я говорю: "«адо тут стол протереть и посуду помыть». Человек беретэту субстанцию кладет в ящик, напоминающий по виду микроволновку (такого бело цвета в которых шаурму у метро греют), гворит: «Сейчас сделаем». И я так понимаю, что этот кренг потом просто переработает остатки пищи с посуды и пыль со стола.
Просыпаюь в легком шоке, от мысли, что я же вообще ничего не знаю про био программирование и такие технологии. Чем зарабатывать на жизнь, если безнадежно отстал? Потом понимаю, что хто сон, но ппц реалистичный.
Краеугольная проблема в том, что куча компаний работают с революционным подходом.. Революционный стиль выражается в том, что в погоне за наживой и рынком, коммерческие компании параллельно ведут разработку над одними и теми же проблемами. Каждая решает проблему с нуля «своим» способом, в результате проделывается огромное количество дублированной работы. Многие из крупных компаний хотят чуть ли не захватить весь мир и «посдаить всех на иглу». В погоне за долей рынка, компании стремятся вытеснить друг друга вместо того, чтобы объединиться и скооперироваться для решения одной и той же задачи. Все было бы относительно неплохо, если бы рынок завоевывался ислючительно честными способами, без аггресивного маркетинга, а опыт неудач был бы использован.
Такой подход породил кучу неподдерживаемого и несовместимого легаси, как на уровне ПО, так и на уровне железа.
Как мне кажется, выход заключается в применении консервативного подхода, когда целью становится не получение прибыли, а получение продукта с заранее заданными характеристиками. Не существует 10 систем параллельно, а есть всего лишь какая-то обозримая линейка, заточенная под нужды пользователя. Для мобильной одна ОС, для десктопа другая и т.д. Но при этом все они базируются на каких-то общих компонентах и принципах. Точно так же со всем остальным ключевым или массовым софтом и технологиями. Такой подход выглядит несбыточным, т.к. требует централизованного комитета стандартизации/аттестации, когда рассмотрев 5 образцов выбирает 2 или 3 под нужные задачи. И потом все разработчики работают над 2-3 компонентами вместо 20.
Из недавнего поразил зоопарк пакетов для разработки под nodejs. Открытость и отсуствие централизации порождает неимоверное количество компонентов, каждый из которых дублирует какую-то часть другого. Одни библиотеки для рисования графиков чего стоят. Хотя по факту обошлись бы всего тремя типами, либо симбиозом трех: супер быстрые на canvas(растровые), комбинированные SVG+canvas, красивые и кастомизируемые на SVG, но требующие выч мощносте при обновлении данных.
А в итоге наплодили графических библиотек целую кучу и потом сидишь и тратишь время на то, чтобы понять какая лучше, в итоге КПД получается как у паровоза, либо *як-*як и в прод.
Итог: пока в электронике транзисторы и конденсаторы, то и жить нам с таким легаси, т.к. его очень и очень много. Революционно новое появится, когда массово будут использоваться другие технологии: квантовые компьютеры или био программы
Снился такой сон: я стою в какой-то комнате, передо мной некая субстанция по форме напоминающая кренга (из черепаше нинзя), только меньше (примерно 1,5-2 мужских кулака по объему). На ней ярко выражены сверические области(https://cdn.pixabay.com/photo/2015/08/02/23/26/adrenaline-872346_960_720.png примерно как на картинке, только областей было больше), разных ядовитых цветов: coral, magenta, mauve. Рядом стоит какой-то человек. Я говорю: "«адо тут стол протереть и посуду помыть». Человек беретэту субстанцию кладет в ящик, напоминающий по виду микроволновку (такого бело цвета в которых шаурму у метро греют), гворит: «Сейчас сделаем». И я так понимаю, что этот кренг потом просто переработает остатки пищи с посуды и пыль со стола.
Просыпаюь в легком шоке, от мысли, что я же вообще ничего не знаю про био программирование и такие технологии. Чем зарабатывать на жизнь, если безнадежно отстал? Потом понимаю, что хто сон, но ппц реалистичный.
А вот что получится если не будут гнаться за прибылью:
то есть — всё то же самое, только еще хуже и ужаснее.
Из недавнего поразил зоопарк пакетов для разработки под nodejs. Открытость и отсуствие централизации порождает неимоверное количество компонентов, каждый из которых дублирует какую-то часть другого.
то есть — всё то же самое, только еще хуже и ужаснее.
Это потому что организации нет или ее недостаточно. Линус переписал линукс, организовал комьюнити и живет. Перед тем как будут вложены чьи-то труды они проходят оценку.
А у капиталистов цель одна — получить прибыль, чем больше продашь, тем больше прибыль, а чтобы продать товар должен быть красивым/нужным. О внутренней структуре и стратегическом планировании никто не думает.
Комерсам хорошо делать простую работу.
А у капиталистов цель одна — получить прибыль, чем больше продашь, тем больше прибыль, а чтобы продать товар должен быть красивым/нужным. О внутренней структуре и стратегическом планировании никто не думает.
Комерсам хорошо делать простую работу.
Комерсы весьма успешно запускают спутники. Так что про простую работу мимо.
Комерсам хорошо делать простую работу.
Про трансатлантический телеграфный кабель никогда не слышали?
Тогда еще не было такого аггресивного маркетинга. В каждой выборке есть исключения из основой массы например www.youtube.com/watch?v=0il1-dWX1vU
Но япония это отдельный мир и совершенно другой менталитет.
Простая работа, та которая не требует 10ков лет исследования и расходования денег. Такое под силу только государству с уровнем планирования лет на 20 вперед.
Но япония это отдельный мир и совершенно другой менталитет.
Простая работа, та которая не требует 10ков лет исследования и расходования денег. Такое под силу только государству с уровнем планирования лет на 20 вперед.
(а) в чем вы меряете агрессивность маркетинга, и на основании чего вы утверждаете, что "тогда" она была ниже, чем "сейчас"?
(б) почему вы считаете, что "агрессивность маркетинга" как-то связана со способностью частных компаний делать "сложную работу"?
(ц) у вас очень свое понимание "простой работы".
(д) почему вы считаете, что десятки лет исследования и расходования денег государству под силу, и сколько вы знаете государств с опытом успешного планирования на 20 лет вперед?
Разнообразие — это хорошо. Нужно только иметь достаточное представление о возможностях, достоинствах и недостатках.
Это решается при помощи независимых измерений (тестов), обзоров и отзывов.
Это решается при помощи независимых измерений (тестов), обзоров и отзывов.
Зачем к Raspberry Pi вообще привязались? Это одноплатник, который «универсальный и маленький», но никто не обещал, что он станет отличным десктопом, или еще чем-то. Конечно, перепад цены между ним и макбуком в несколько десятков раз, но ругать его за неработу игр — как жаловаться, что домашний пылесос на стройке сосет не сосет. Увы и ах, у каждой вещи есть границы применимости.
А BeOS, которую несколько раз в упоминает автор, отличная система, кроме одного «но» — непонятно, как использовать ее инновации. Даже в посте есть её скриншоты, но нет описания или иллюстрации, как же идея «ФС как БД» реально работает. Лучше бы просто дали ссылку на Everything, это более действенная иллюстрация того же самого подхода.
И, наконец, давайте скажем дружно: куда идет та же Apple (по сути, загоняя юзеров как под гребенку, в состояние, когда каждый имеет iPhone + iPad + MacBook Pro + оплачиваемый iCloud) нам понятно, но мы сами должны сказать, куда мы хотим идти! Не хочется иметь все более привязываемую к облакам и мобильным девайсам ОСь — поставь прошлую или позапрошлую макось, и живи! Не нравятся GUI ОСи — слезь с макоси/винды, или повесь повех своей ОС какой-нибудь дисплей-менеджер, и живи.
Но чтобы критиковать, придумай понятный людям слой метафор. Иерархическую ФС держат десятилетиями не потому, что она лучшая, а потому, что и ПО, и люди привыкли к её метафорам. Как перевести всех на БД — мне лично не очень понятно, если говорить о том, чтобы новая метафора стала более простой в понимании, чем старые.
А BeOS, которую несколько раз в упоминает автор, отличная система, кроме одного «но» — непонятно, как использовать ее инновации. Даже в посте есть её скриншоты, но нет описания или иллюстрации, как же идея «ФС как БД» реально работает. Лучше бы просто дали ссылку на Everything, это более действенная иллюстрация того же самого подхода.
И, наконец, давайте скажем дружно: куда идет та же Apple (по сути, загоняя юзеров как под гребенку, в состояние, когда каждый имеет iPhone + iPad + MacBook Pro + оплачиваемый iCloud) нам понятно, но мы сами должны сказать, куда мы хотим идти! Не хочется иметь все более привязываемую к облакам и мобильным девайсам ОСь — поставь прошлую или позапрошлую макось, и живи! Не нравятся GUI ОСи — слезь с макоси/винды, или повесь повех своей ОС какой-нибудь дисплей-менеджер, и живи.
Но чтобы критиковать, придумай понятный людям слой метафор. Иерархическую ФС держат десятилетиями не потому, что она лучшая, а потому, что и ПО, и люди привыкли к её метафорам. Как перевести всех на БД — мне лично не очень понятно, если говорить о том, чтобы новая метафора стала более простой в понимании, чем старые.
управление приложениями
Automator на macOS и (как бы не раньше) — MS! с Visual Basic и OLE Automation (получилось правда не очень — в приложения нужную поддержку надо приделывать и не всегда она есть).
Там кстати была (и есть) и возможность в один документ вставлять другой (совсем другого приложения) или ссылку на него (а при клике — к интерфейсу текущего приложения — добавлялся интерфейс нового — оно и сейчас работает… частично, и при этом появляются статьи вроде habr.com/company/dsec/blog/423933 про дыры). Как обычно у MS было сделано… не до конца.
команда «play» в сервис проигрывания mp3? да? А что если я хочу flac? А если я хочу SuperPuperAudioFormat? Либо хочу слушать музыку из Apple(Яндекс/Google/etc) Music в оффлайне (iTunes так умеет но музыка будет разумеется с DRM и что — «сервис проигрывания» должен знать все DRM? Или должна быть возможность делать плагины к нему).
Нормальный относительно поиск — есть в macOS и давно. И им даже пользоваться можно. В том числе — для форматов которые изначально не поддерживаются (берем и пишем плагин к Spotlight, ну или ищем готовый).
Версионирование — Time Machine же а если мало ее интерфейса, со времен Mac OS X Lion — на уровне системных API есть поддержка Versions (прямо в приложении будет меню выбора прошлых версий, интегрируется с Time Machine). Для Windows — вкладка File History в Win10 у файлов в профиле (настраиваемо)(вот только сколько людей про нее знают?) www.pcworld.com/article/2974385/windows/how-to-use-windows-10s-file-history-backup-feature.html.
Ну и опять же — всякие Dropbox'ы/Synology Drive'ы — поддерживают историю предыдущих версий файла, с интеграций в GUI Finder/Explorer и еще и с синхронизацией между компьютерами(уж как могут).
Несколько имен одному файлу? А разве hardlink'и не всеми современными ОС поддерживаются? (между дисками да — symlink'и/junctions). Правда вот нормальный пользовательский интерфейс для этой функции мне не встречался.
Automator на macOS и (как бы не раньше) — MS! с Visual Basic и OLE Automation (получилось правда не очень — в приложения нужную поддержку надо приделывать и не всегда она есть).
Там кстати была (и есть) и возможность в один документ вставлять другой (совсем другого приложения) или ссылку на него (а при клике — к интерфейсу текущего приложения — добавлялся интерфейс нового — оно и сейчас работает… частично, и при этом появляются статьи вроде habr.com/company/dsec/blog/423933 про дыры). Как обычно у MS было сделано… не до конца.
команда «play» в сервис проигрывания mp3? да? А что если я хочу flac? А если я хочу SuperPuperAudioFormat? Либо хочу слушать музыку из Apple(Яндекс/Google/etc) Music в оффлайне (iTunes так умеет но музыка будет разумеется с DRM и что — «сервис проигрывания» должен знать все DRM? Или должна быть возможность делать плагины к нему).
Нормальный относительно поиск — есть в macOS и давно. И им даже пользоваться можно. В том числе — для форматов которые изначально не поддерживаются (берем и пишем плагин к Spotlight, ну или ищем готовый).
Версионирование — Time Machine же а если мало ее интерфейса, со времен Mac OS X Lion — на уровне системных API есть поддержка Versions (прямо в приложении будет меню выбора прошлых версий, интегрируется с Time Machine). Для Windows — вкладка File History в Win10 у файлов в профиле (настраиваемо)(вот только сколько людей про нее знают?) www.pcworld.com/article/2974385/windows/how-to-use-windows-10s-file-history-backup-feature.html.
Ну и опять же — всякие Dropbox'ы/Synology Drive'ы — поддерживают историю предыдущих версий файла, с интеграций в GUI Finder/Explorer и еще и с синхронизацией между компьютерами(уж как могут).
Несколько имен одному файлу? А разве hardlink'и не всеми современными ОС поддерживаются? (между дисками да — symlink'и/junctions). Правда вот нормальный пользовательский интерфейс для этой функции мне не встречался.
Sign up to leave a comment.
Идеальная ОС: переосмысление операционных систем для десктопа