Абсолютно точно. На постоянной основе — вообще никак.
Прочтите уже ТК, статья 101, к слову.
Положения, в основном, следующие:
1. Должность должна быть в перечне должностей с ненормированным рабочим днем («Перечень должностей работников с ненормированным рабочим днем устанавливается коллективным договором, соглашениями или локальным нормативным актом, принимаемым с учетом мнения представительного органа работников.») Короче, «запросто так» работнику ненормированный день не установишь. Как минимум, твоя должность должна быть указана в коллективном договоре как должность с ненормированным рабочим днем. Как вариант, еще и в твоем персональном трудовом договоре.
2. Сам факт ненормированного рабочего для позволяет в случае «производственной необходимости» (которую еще нужно, например, обосновать) условно «увеличить продолжительность рабочего дня», но не позволяет увеличить продолжительность рабочей недели. Т.е. рабочие часы должны компенсироваться а) дополнительным отпуском; б) отгулами; в) оплатой по тарифу сверхурочных часов, если отпуск/отгул «ну никак не получается».
И даже если работник с ненормированным рабочим днем ни разу не привлекался к лишней работе, ему один хрен положен дополнительный отпуск (не менее 3 календарных дней).
3. Статья 101 «особо подчеркивает» эпизодический характер привлечения работника к работе по «ненормированным» обязанностям. Короче, раз в неделю на «задержаться на часик после работы» — это уже «регулярное злоупотребление», за такое вполне «ата-та» бывает.
Так что моя формулировка абсолютно точна, с оговоркой «для стандартной 40-часовой 5на8 трудовой недели». Есть еще 42-часовые «в среднем» день-ночь-48 и т.д., но это уже «особый случай», там реально иначе никак.
Вы как-то странно трактуете Трудовой Кодекс…
Ваш личный рабочий график и условия труда регулируются Трудовым Договором — это такая штука, письменное соглашение между работодателем и работником. Трудовой Кодекс в данном контексте — набор относительно разумных ограничений, которым этот самый Трудовой Договор не должен противоречить.
Вот эти «8-часовой рабочий день» в ТК означает, что работодатель не имеет права заставить своего сотрудника на постоянной основе работать более 8 часов в день. Нижней планки Трудовой Кодекс не устанавливает.
Поэтому, если вы хотите работать по 6 часов в день, вам достаточно прийти к своему работодателю и сообщить ему: «Я тут у тебя по 8 часов в день торчу, а реально работаю только 6. Давай как-то в соответствие приведем!» Если вы действительно ценный сотрудник, работодатель, естественно, пойдет вам навстречу, и пересмотрит лично ваш Трудовой Договор, и все будет хорошо, все будут довольны, и Трудовой Кодекс здесь совершенно не при чем.
А вот эти «добились 8-часового рабочего дня, следующий рубеж — 6 часов» ведут ровно в классический анекдот на тему «доколе еще эта хрень со средой продолжаться будет».
>> Может быть и 14 конкурирующих стандартов по XKCD, но доли рынка у них разные.
Собственно, с такой подачей это именно просто 15-й стандарт. Непонятно, что его от остальных отличает… Их и «открытых» уже вагон и маленькая тележка.
Просто в статье вы пишете, что «xmpp пробовал, не получилось. Может быть, у нас получится...» А на выходе получается, что даже и не пытаетесь. У xmpp, хотя бы, транспорты были…
Разработчики фреймворков знают о «протечках» в браузерах. И тоже патчат.
Я, собственно, товарищу mayorovp просто говорю, что «абстракция течёт». Причем проблема ее, в первую очередь, растет из того, что сама она построена поверх другой не самой удачной абстракции. Ну и до кучи, я говорю, что на определенном этапе (например, на этапе перехода от гипертекста к интерфейсам) стоило/стоит подумать о том, что иерархию абстракций, возможно, можно сделать лучше, переработать, причем начиная с уровня «пониже». Вероятно, это могло бы пойти всем на пользу.
Не?
А закусился я на «нормальная абстракция», «мне норм», «ты просто не понимаешь, абстракция норм». Зря, наверное.
Во-первых, абстракция — это не про удобство отладки или парсинга, а про проектирование программы./blockquote>
Точно, и изоляция — это не про сокрытие данных от «вероятного противника», а про сокрытие деталей реализации нижележащего слоя абстракции.
Да, абстракции, обычно, образовывают «слои», т.е. есть «нижний» слой, и «верхний», как правило, над ним, не сбоку. А изоляция — это инструмент, и метрика, если хотите, абстракции. Если сквозь «верхний» слой видно, что лежит «внизу», абстракция «течет», если сверху самого низа не видно — абстракция хорошая.
Ваши примеры того как у вас не получается достать из разметки то, что реально показывается пользователю («B»), как раз и демонстрируют отсутствие протечек в абстракции: процесс отображения надежно заабстрагирован и не виден снаружи.
Ага, со стороны оно выглядит, как модель-представление. На поверку — модель-модель. Скопировать кусок данных — одно из самых хреновых решений. Вопрос представления, как правило, сильно проще вопроса двусторонней синхронизации…
В общем, один вопрос:
Есть DOM, есть Shadow DOM, две абстракции. Какой из этих слоев сверху?
вы зачем-то полезли смотреть HTML-разметку страницы.
На самом деле, мотивация может быть разная, от «посмотреть, что там на самом деле получается» и «разобраться, почему мне макет рас****ло на 4 экрана», до «распарсить новостные статьи с N сайтов и отобразить в красивом единообразном аггрегаторе». Меня вот удивляет то, что вы не видите причин полезть смотреть разметку страницы.
Поведение корректной программы — нет, зависеть не может.
теперь он показывает «B» независимо от своего содержимого.
Т.е. вместо того, чтобы абстрагироваться от реализации, мы абстрагировались от содержимого, и у нас все «Ок»?
не вижу зачем тут нужно обязательно знать детали реализации.
Ну т.е. я захожу на страницу, вижу надпись «Василий». Смотрю в html страницы, вижу там «Павел». Еще раз смотрю на саму страницу… И действительно, зачем мне детали?
Не вижу никакого противоречия.
Давайте попробуем увидеть.
У нас есть семантическая верстка (классика html + css, контент отдельно, представление отдельно, и все это поверх общего дерева объектов). На этом уровне абстракции мы не можем инкапсулировать в одном объекте и данные, и их представление.
Появляется надобность инкапсуляции данных+представления на уровне отдельного объекта. И мы пилим сущность сбоку, которая фактически тупо перекрывает селекторы первой на процессе рендеринга.
На выходе мы имеем два интерфейса работы с семантикой документа и его отображением, при этом теряем возможность «в лоб» отследить связность данные-представление, т.к. у нас появился перекрывающий слой (заметьте, не абстрагирующий, а перекрывающий). При этом на уровне ShadowDOM один хрен сохраняется наследование стилей из первой иерархии. Т.е. «классический» DOM косвенно влияет на представление ShadowDOM, а shadow частично перекрывает селекторы классического.
Осталось понять, нет ли смысла, случаем, проанализировать ситуацию, и отказаться от одной из иерархий, или, например, полностью абстрагировать одну из них другой…
от количества слоев поведение программы не зависит.
Вот это, простите, в идеальном мире происходит. Не в нашем.
Если взглянуть на тот же C++, поведение программы может зависеть не только от количества слоев, но и от вполне себе реальной аппаратной платформы, на которой программа исполняется. Для абстракции от, хотя бы, аппаратной реализации, например, целый LLVM пилят.
трансляция программ — процесс точный
«Точность» трансляции (причем относительная или приемлемая), может быть достигнута только на комбинации определенных языковых подмножеств. Прежде чем так безапелляционно утверждать про «точность», для начала представьте трансляцию по цепочке, допустим, C++ => Java => C. Попробуйте оттранслировать и сравнить набор инструкций на выходе.
И не говорите, что в связке веб-языков эта проблема неактуальна. Иначе для чего, по аналогии с LLVM, нынче WebAssembly пилят?
Нет, подтекающая абстракция — это когда что-то работает не так как утверждалось.
Давайте не будем подменять устоявшуюся терминологию своими субъективными представлениями.
«leaky abstraction» — термин, популяризованный Джоелом Спольски. Традиционно переводится как «протекающая» или «дырявая» абстракция. Вот здесь, например, можно ознакомиться с формулировкой понятия и историей возникновения термина.
Фактически — это абстракция, не абстрагирующая деталей реализации, которые призвана абстрагировать.
А ваше «когда что-то работает не так как утверждалось» — это таки баг, косяк реализации и много еще чего, но точно не она.
Например, сообщение теряется в канале с гарантированной доставкой потому что канала больше нет.
Прямо мимо, этот случай к протекающей абстракции не имеет отношения от слова «никак».
А когда «вам нужно знать, как все это устроено» — это просто любопытство.
Разница в мотивации. Узнать детали реализации, потому что интересно — это любопытство. Узнать детали реализации, потому что без них не работает — дырявая абстракция. «Почувствуйте разницу».
при компиляции С++ в машинный код точно так же пропадают модификаторы доступа
Вы же понимаете, что компиляция С++ в машинный код, который исполняется «как есть» уже на целевой платформе — вещь несколько более предсказуемая, чем «машинный перевод» одного языка в другой, за которым следует трансляция в следующий язык по цепочке. Попробуйте в гуглотранслейте перевести пару предложений с русского на церковнославянский, оттуда на староанглийский, а затем снова на русский, и посмотрите на результат. Я знаю, что набор лексем в языках программирования несколько победнее, да и правила попримитивнее, но ассоциация, в целом, верная.
Допустим, такая вещь, как ShadowDOM. Не, я не отрицаю, штука прикольная и в текущих реалиях нужная. Но реализация…
Для «инкапсуляции представления» мы создаем параллельный DOM. Оно же так работает? Т.е. для того, чтобы оно было как-то «инкапсулировано», мы делаем копию содержимого элемента в стороне и как-то связываем это с происходящим на странице. А дальше мы берем какой-нибудь узел, пишем ему в контент «А», а в shadowDOM — «Б». Вуаля, у нас html-исходник показывает «А», а на странице мы видим «Б». И для того, чтобы понять, почему и что происходит, вам нужно знать, как все это устроено. Мне кажется, абстракция слегка «подтекает».
«Типобезопасность», всяческие TypeScript и т.д. — на выходе транслируются в js, который про всю эту кухню, мягко выражаясь, не в курсе. Т.е. локально на вашей машине с контролируемыми вами же входными данными — все ок, и TS реально полезен. При этом в реальности эта вещь теряет половину своих умелок на этапе трансляции. Мне вот лично не нравится, что часть семантики моего кода где-то по пути к исполнению «выпадает».
Внутри веб-стека достаточно много странностей, это, надеюсь, вы отрицать не будете? Не поймите меня превратно, я не осуждаю людей, которые все это изобрели, они делают реально крутые вещи. Просто местами создается ощущение, что эти самые вещи им приходится лепить из г-на и палок. И многие вещи в вебе, которые мне трудно принять, просто не имеют другого решения в текущих реалиях. А реалии таковы, что на связке из языка-для-разметки-гипертекста + каскадных-таблиц-стилей + не самого удачного скриптового языка усиленно рождается система построения интерфейсов. «Рынок» хочет «уже сейчас», и поэтому вся эта система обрастает все новыми и новыми решениями, причем каждое рождается вне всякой связи с параллельными, а «абстракции текут»…
На выходе мы имеем по 4-10 решений на каждый случай жизни, и при этом каждое «не без недостатка». Может, все же был смысл на определенном этапе, когда веб-интерфейсы стали реально востребованными, попробовать не надстраивать все это над разметкой гипертекста и инструментом для стилизации оного же, а спроектировать язык построения интерфейсов?
Как-то вы фреймворки с языками уравняли с ходу… Angular vs React — сравнение в одной плоскости с Spring vs Play. В первом случае под фреймворком js, во втором — jvm. Только вот на бэке может и не быть этого самого jvm'а, если он не нужен или мешает. А на фронте вы никуда от js не денетесь.
>> На беке же вы прибиты к JSON, HTTP, SQL.
Вы же фронтендер, да? Вы вот реально уверены, что на бэке без SQL никуда? Вы реально считаете, что HTTP — это ограничение именно бэка? Что оно не со стороны фронта ограничение? Вы реально считаете, что форматов обмена, кроме JSON, нету? И вы твердо уверены, что текстовый обмен — это ограничение именно бэка?
>> в конечном итоге, транслируются на выходе ровно в то, что умеет веб-сервер.
Ну, т.е. во что угодно, что в принципе может исполнить компьютер? Вы же понимаете, что тут «умелок» несколько больше?
Мне кажется, как бы ни парадоксально это звучало, преимущество «бэкенд»-технологических стеков именно в их разнообразии. Не подходит Python? Можно Go использовать. Проблемы с PHP? Есть Java.
И вот там, в бекенде, — конкуренция экосистем, каждая из которых рождает какие-то решения, неудачные хоронят, удачные перенимаются. При этом есть такие, которые растут по воле одного «визионера», есть катящиеся по воле сообщества. Но, самое главное — там есть выбор.
На фронте же вы прибиты в html-css-js. Их можно ругать, а можно любить. Но даже самый ярый фанат при наличии сколько-нибудь критического мышления назовет пару-тройку явных неприятных недостатков этих технологий. На бэке, если недостатки для вас критичны, вы просто выбираете другой стек, где недостатки менее критичны. На фронте вам остается только смириться. У вас, фактически, нет другого стека.
Вы можете говорить про angular, react и прочее и прочее, но все они, в конечном итоге, транслируются на выходе ровно в то, что умеет браузер. Они не решают эти проблемы, трансляцией невозможно решить концептуальную проблему того, во что вы транслируете. Получается, что все эти платформы — это «workaround» над проблемой. Способ обойти. При этом — автоматизированный способ обхода… А мы все знаем, что именно такая неявная автоматизация может достаточно больно бить по лбу.
>> В браузерах (IE и Mozilla) только появилась поддержка XmlHttpRequest. В 2004 году запускается Gmail, в 2005 появляется термин AJAX, в 2006 выпускаются первые версии jQuery, YUI и GWT. В 2007 на базе YUI был создан Ext JS. Становится понятно, что веб-платформа обладает довольно мощным потенциалом для реализации сложных интерфейсов.
Вот, ИМХО, где-то на этом месте и произошла небольшая локальная катастрофа. «Становится понятно, что веб-платформа обладает довольно мощным потенциалом для реализации сложных интерфейсов. » При этом сама платформа остается связкой «языка разметки гипертекста», «каскадных таблиц стилей» и прикрученных сильно сбоку скриптов, чтобы все это выглядело как «реализация сложных интерфейсов».
Т.е. интерфейсы стали лепить на том, что предназначено для гипертекста. Смогли? Да. Гениально? Да. Удачно получилось? Спорно.
В проектировании интерфейсов, как ни странно, отлично «заходит» ООП-подход. Вся вот эта «инкапсуляция», «полиморфизмы эти ваши» и т.д. Реально просто хорошо все это ложится «в логику». А в существующей реализации инкапсуляция невозможна, попытки родить абстракции «текут», любая связность — эмуляция, полиморфизм реализуется кодогенерацией…
Мне вот реально кажется, что текущий подход к проектированию веб-интерфейсов, мягко говоря, неидеален. Можно было на отметке «стало понятно» чуть-чуть притормозить, обдумать хорошо и сделать «правильно».
Но, момент упущен…
Универсальность в отсутствии онного. Достаточно только ACL поддерживать, а он есть в любой Linux-kernel based OS, исключая совсем единицы.
Т.е., вкратце, смысл задумки:
Имеем пакет как некую сущность
Этот пакет в чистом виде "как есть" не способен установиться и заработать "из коробке" в подавляющем числе дистрибутивов Linux.
Называем пакет "универсальным".
Что-то никак не пойму, в чем смысл "универсальности"? Для кого этот "пакет"?
В любом случае изоляция не всегда работает и не всегда нужна.
А стабильность API/Runtime в случае ломаной изоляции сохраняется.
Не совсем понимаю, каким образом она сохраняется.
Допустим, в flatpak'е лежит приложуха, которая хочет библиотеку my-awesome-lib2.16.57.so. Точно такая же, как на машине разработчика, сидящего, предположим, на Арче.
В целевой системе, допустим, Ubuntu, лежит my-awesome-lib2.3.12.so.
Предположим, в Fedora — my-awesome-lib2.4.47.so.
В пакетном рантайме — ровно нужная версия.
Вы, вместо пакетного рантайма, подсовываете системный хостовый… И получаете печаль.
То, что отлично работало на машине разработчика, при запуске на Ubuntu отказывается работать вообще, а на Федоре ведет себя странно.
"Кроссплатформенность" покрывается медным тазиком...
Обертка нужна для других функций.
В случае flatpak'а "обертка" и "изоляция", в первую очередь, и делаются для того, чтобы упакованное в него приложение имело ровно те версии библиотек в рантайме, которые ему нужны. Поэтому системный /usr и отрезают, чтобы не возникало путаницы. Случаи, когда приложение, по какой-то причине, хочет именно системный /usr — не для упаковки во flatpak.
И иметь проблемы с тем, что всё ломается раз в полгода. Проходили уже, поддерживать тулинг для этого счастья желания нет никакого.
Ну т.е. целевая платформа таки не все линуксы, а только мейнстрим?
Я не говорю, заметьте, что это в корне неверное решение с вашей, как разработчика, стороны. Оно даже, скорее, правильное. Логичнее сделать нормальный отлаженный рабочий инструмент под ограниченное количество окружений, чем глюкавое поделие "для всех". И поддержка сборок — она тоже вещь "небесплатная", что только оттянет лишние силы.
Но вы настолько настаиваете на безусловной кроссплатформенности своего фреймворка… что я не могу не указать вам на нецелесообразность и нереализуемость декларируемых вами "умелок".
Если забывать про PartialUpgrade, то да будет ломаться.
Вы же понимаете, что претензия не к пакетному менеджеру, а таки к Арчу в целом? Точнее к Rolling-Release модели...
Проходили уже, поддерживать тулинг для этого счастья желания нет никакого.
Достаточно формировать PKGBUILD затем вызвать makepkg и не более.
Дык, формулировка предыдущего ответа, вроде как, достаточно четко дает понять "мы не тратим времени на поддержку маргинальных дистрибутивов". Т.е. никто не будет заморачиваться, будет просто декларировать "универсальный GUI-фреймворк" и "весь Linux" в качестве целевой платформы, отказываясь ограничивать список поддерживаемых линуксов.
Я имел ввиду что ему не нужны Overhead, SELinux и AppArmor.
Собственно, исключить много чего можно. Но тогда о какой универсальности может идти речь?
Забей на меты. Достаточно install и файлов программы.
Какбы от пакета еще, как минимум, стоило бы получать информацию еще о зависимостях, например. Иначе чем лучше configure-make-make install? И даже преимущества над tar -xzvf -C / становятся достаточно спорными...
Debian-like/RHEL-like хочет много X,Y,Z которые не нужны никому другому.
Ну т.е. debian-based и rh-based дистрибутивы (которых, стоит таки признать, подавляющий процент) со своими запросами идут лесом…
Это нормально, если, допустим, на 80% целевых дистрибутивов ваш пакет будут сначала распаковывать, а потом перепаковывать во что-то другое, пригодное для использования в целевом дистрибутиве? Source-tarball для мейнтейнеров мейнстрима будет предпочтительней, т.к. этап "распаковки" и парсинга чужого и, не побоюсь этого слова, чуждого пакета можно будет опустить. Странный подход к универсальности, стоит признать.
Alpine ставится из сорсов через AUR.
Куда, простите, ставится? Вообще ни разу не слышал о каком-либо сродстве Alpine Linux и арчевского AUR...
Нет, он не похож.
Не похожа реализация. Функционал и целеполагание — абсолютно монопенисуальное.
Частично функции распространителя приложений в классическом пакетном менеджере(не DPKG и не RPM, но в libALPM/pacman) все таки имеются. Процедура получения пакета приложения к примеру.
А слой совместимости здесь это лишнее.
Ни dpkg, ни rpm пакетным менеджером не являются. Пакетный менеджер поверх dpkg называется apt, например. И решает он, в первую очередь, НЕ проблему получения пакета или приложения. Вот реально, не для того весь сыр-бор. Эта "проблема" — наименьшая из проблем, стоящих перед пакетным менеджером. Для решения таковой все эти сложности с графами зависимостей и т.д. не нужны — тут и tar + набор sh-скриптов по необходимости справится.
Даже проблема корректного удаления пакета — более сложный процесс, чем процесс получения оного. А первейшая задача пакетного менеджера — руление зависимостями между пакетами.
Понимаете, в чем разница. Основная цель apt'а или yum'а, заради которой они создавались — автоматически разрулить адЪ, содомЪ и гоморру с зависимостями. Остальное — приятный бонус.
Основная цель Flatpak'а — именно доставка приложения. Причем не всякого и не любого, а конкретно заточенного и собранного под соответствующий рантайм. Он абстрагирован от зависимостей, с рулением сущностей на уровне flatpak'а справится третьеклассник. Дерево сущностей примитивное и ацикличное. Не рулит flatpak зависимостями, а просто приносит их вместе с приложениями и складывает в песочницу. Зато гарантия, что не пересекутся — песочницы-то разные.
Повод к жизни сменить все же сложнее.
Вот к этому я не призывал. Я призывал сменить ПОДХОД к жизни, никак не повод. Мотивация к жизни — это несколько более "нижний" уровень самопознания и биологического выживания вида. С этим уже к психологу, наверное… Ну или к философу, на крайний случай.
Чреват чем? Он же как Read-only доступен.
Изоляция несовершенна, "побег из турьмы возможен".
Затевалось все заради стабильного предсказуемого API/рантайма. Прокиньте туда хостовый /usr, и сразу имеем 2 вопроса:
куда делась кроссплатформенность, портируемость?
заради чего вообще городили весь этот городок с flatpak'ом, если изоляцию и стабильность API/рантайма только что выкинули.
Короче, первая претензия к этому подходу в том, что на этом этапе flatpak становится лишней ограничивающей сущностью, не приносящей никакой реальной пользы. Зачем обертка, если рантайм системный?
Прочтите уже ТК, статья 101, к слову.
Положения, в основном, следующие:
1. Должность должна быть в перечне должностей с ненормированным рабочим днем («Перечень должностей работников с ненормированным рабочим днем устанавливается коллективным договором, соглашениями или локальным нормативным актом, принимаемым с учетом мнения представительного органа работников.») Короче, «запросто так» работнику ненормированный день не установишь. Как минимум, твоя должность должна быть указана в коллективном договоре как должность с ненормированным рабочим днем. Как вариант, еще и в твоем персональном трудовом договоре.
2. Сам факт ненормированного рабочего для позволяет в случае «производственной необходимости» (которую еще нужно, например, обосновать) условно «увеличить продолжительность рабочего дня», но не позволяет увеличить продолжительность рабочей недели. Т.е. рабочие часы должны компенсироваться а) дополнительным отпуском; б) отгулами; в) оплатой по тарифу сверхурочных часов, если отпуск/отгул «ну никак не получается».
И даже если работник с ненормированным рабочим днем ни разу не привлекался к лишней работе, ему один хрен положен дополнительный отпуск (не менее 3 календарных дней).
3. Статья 101 «особо подчеркивает» эпизодический характер привлечения работника к работе по «ненормированным» обязанностям. Короче, раз в неделю на «задержаться на часик после работы» — это уже «регулярное злоупотребление», за такое вполне «ата-та» бывает.
Так что моя формулировка абсолютно точна, с оговоркой «для стандартной 40-часовой 5на8 трудовой недели». Есть еще 42-часовые «в среднем» день-ночь-48 и т.д., но это уже «особый случай», там реально иначе никак.
Ваш личный рабочий график и условия труда регулируются Трудовым Договором — это такая штука, письменное соглашение между работодателем и работником. Трудовой Кодекс в данном контексте — набор относительно разумных ограничений, которым этот самый Трудовой Договор не должен противоречить.
Вот эти «8-часовой рабочий день» в ТК означает, что работодатель не имеет права заставить своего сотрудника на постоянной основе работать более 8 часов в день. Нижней планки Трудовой Кодекс не устанавливает.
Поэтому, если вы хотите работать по 6 часов в день, вам достаточно прийти к своему работодателю и сообщить ему: «Я тут у тебя по 8 часов в день торчу, а реально работаю только 6. Давай как-то в соответствие приведем!» Если вы действительно ценный сотрудник, работодатель, естественно, пойдет вам навстречу, и пересмотрит лично ваш Трудовой Договор, и все будет хорошо, все будут довольны, и Трудовой Кодекс здесь совершенно не при чем.
А вот эти «добились 8-часового рабочего дня, следующий рубеж — 6 часов» ведут ровно в классический анекдот на тему «доколе еще эта хрень со средой продолжаться будет».
Собственно, с такой подачей это именно просто 15-й стандарт. Непонятно, что его от остальных отличает… Их и «открытых» уже вагон и маленькая тележка.
Просто в статье вы пишете, что «xmpp пробовал, не получилось. Может быть, у нас получится...» А на выходе получается, что даже и не пытаетесь. У xmpp, хотя бы, транспорты были…
Я, собственно, товарищу mayorovp просто говорю, что «абстракция течёт». Причем проблема ее, в первую очередь, растет из того, что сама она построена поверх другой не самой удачной абстракции. Ну и до кучи, я говорю, что на определенном этапе (например, на этапе перехода от гипертекста к интерфейсам) стоило/стоит подумать о том, что иерархию абстракций, возможно, можно сделать лучше, переработать, причем начиная с уровня «пониже». Вероятно, это могло бы пойти всем на пользу.
Не?
А закусился я на «нормальная абстракция», «мне норм», «ты просто не понимаешь, абстракция норм». Зря, наверное.
Вот тут и разница в разработчиках. Одни чинят и патчат, другие говорят «мне норм».
На самом деле, мотивация может быть разная, от «посмотреть, что там на самом деле получается» и «разобраться, почему мне макет рас****ло на 4 экрана», до «распарсить новостные статьи с N сайтов и отобразить в красивом единообразном аггрегаторе». Меня вот удивляет то, что вы не видите причин полезть смотреть разметку страницы.
Категорично, задорно, по юношески, не верно.
Т.е. вместо того, чтобы абстрагироваться от реализации, мы абстрагировались от содержимого, и у нас все «Ок»?
Ну т.е. я захожу на страницу, вижу надпись «Василий». Смотрю в html страницы, вижу там «Павел». Еще раз смотрю на саму страницу… И действительно, зачем мне детали?
Давайте попробуем увидеть.
У нас есть семантическая верстка (классика html + css, контент отдельно, представление отдельно, и все это поверх общего дерева объектов). На этом уровне абстракции мы не можем инкапсулировать в одном объекте и данные, и их представление.
Появляется надобность инкапсуляции данных+представления на уровне отдельного объекта. И мы пилим сущность сбоку, которая фактически тупо перекрывает селекторы первой на процессе рендеринга.
На выходе мы имеем два интерфейса работы с семантикой документа и его отображением, при этом теряем возможность «в лоб» отследить связность данные-представление, т.к. у нас появился перекрывающий слой (заметьте, не абстрагирующий, а перекрывающий). При этом на уровне ShadowDOM один хрен сохраняется наследование стилей из первой иерархии. Т.е. «классический» DOM косвенно влияет на представление ShadowDOM, а shadow частично перекрывает селекторы классического.
Осталось понять, нет ли смысла, случаем, проанализировать ситуацию, и отказаться от одной из иерархий, или, например, полностью абстрагировать одну из них другой…
Вот это, простите, в идеальном мире происходит. Не в нашем.
Если взглянуть на тот же C++, поведение программы может зависеть не только от количества слоев, но и от вполне себе реальной аппаратной платформы, на которой программа исполняется. Для абстракции от, хотя бы, аппаратной реализации, например, целый LLVM пилят.
«Точность» трансляции (причем относительная или приемлемая), может быть достигнута только на комбинации определенных языковых подмножеств. Прежде чем так безапелляционно утверждать про «точность», для начала представьте трансляцию по цепочке, допустим, C++ => Java => C. Попробуйте оттранслировать и сравнить набор инструкций на выходе.
И не говорите, что в связке веб-языков эта проблема неактуальна. Иначе для чего, по аналогии с LLVM, нынче WebAssembly пилят?
Давайте не будем подменять устоявшуюся терминологию своими субъективными представлениями.
«leaky abstraction» — термин, популяризованный Джоелом Спольски. Традиционно переводится как «протекающая» или «дырявая» абстракция.
Вот здесь, например, можно ознакомиться с формулировкой понятия и историей возникновения термина.
Фактически — это абстракция, не абстрагирующая деталей реализации, которые призвана абстрагировать.
А ваше «когда что-то работает не так как утверждалось» — это таки баг, косяк реализации и много еще чего, но точно не она.
Прямо мимо, этот случай к протекающей абстракции не имеет отношения от слова «никак».
Разница в мотивации. Узнать детали реализации, потому что интересно — это любопытство. Узнать детали реализации, потому что без них не работает — дырявая абстракция. «Почувствуйте разницу».
Вы же понимаете, что компиляция С++ в машинный код, который исполняется «как есть» уже на целевой платформе — вещь несколько более предсказуемая, чем «машинный перевод» одного языка в другой, за которым следует трансляция в следующий язык по цепочке. Попробуйте в гуглотранслейте перевести пару предложений с русского на церковнославянский, оттуда на староанглийский, а затем снова на русский, и посмотрите на результат. Я знаю, что набор лексем в языках программирования несколько победнее, да и правила попримитивнее, но ассоциация, в целом, верная.
Для «инкапсуляции представления» мы создаем параллельный DOM. Оно же так работает? Т.е. для того, чтобы оно было как-то «инкапсулировано», мы делаем копию содержимого элемента в стороне и как-то связываем это с происходящим на странице. А дальше мы берем какой-нибудь узел, пишем ему в контент «А», а в shadowDOM — «Б». Вуаля, у нас html-исходник показывает «А», а на странице мы видим «Б». И для того, чтобы понять, почему и что происходит, вам нужно знать, как все это устроено. Мне кажется, абстракция слегка «подтекает».
«Типобезопасность», всяческие TypeScript и т.д. — на выходе транслируются в js, который про всю эту кухню, мягко выражаясь, не в курсе. Т.е. локально на вашей машине с контролируемыми вами же входными данными — все ок, и TS реально полезен. При этом в реальности эта вещь теряет половину своих умелок на этапе трансляции. Мне вот лично не нравится, что часть семантики моего кода где-то по пути к исполнению «выпадает».
Внутри веб-стека достаточно много странностей, это, надеюсь, вы отрицать не будете? Не поймите меня превратно, я не осуждаю людей, которые все это изобрели, они делают реально крутые вещи. Просто местами создается ощущение, что эти самые вещи им приходится лепить из г-на и палок. И многие вещи в вебе, которые мне трудно принять, просто не имеют другого решения в текущих реалиях. А реалии таковы, что на связке из языка-для-разметки-гипертекста + каскадных-таблиц-стилей + не самого удачного скриптового языка усиленно рождается система построения интерфейсов. «Рынок» хочет «уже сейчас», и поэтому вся эта система обрастает все новыми и новыми решениями, причем каждое рождается вне всякой связи с параллельными, а «абстракции текут»…
На выходе мы имеем по 4-10 решений на каждый случай жизни, и при этом каждое «не без недостатка». Может, все же был смысл на определенном этапе, когда веб-интерфейсы стали реально востребованными, попробовать не надстраивать все это над разметкой гипертекста и инструментом для стилизации оного же, а спроектировать язык построения интерфейсов?
>> На беке же вы прибиты к JSON, HTTP, SQL.
Вы же фронтендер, да? Вы вот реально уверены, что на бэке без SQL никуда? Вы реально считаете, что HTTP — это ограничение именно бэка? Что оно не со стороны фронта ограничение? Вы реально считаете, что форматов обмена, кроме JSON, нету? И вы твердо уверены, что текстовый обмен — это ограничение именно бэка?
>> в конечном итоге, транслируются на выходе ровно в то, что умеет веб-сервер.
Ну, т.е. во что угодно, что в принципе может исполнить компьютер? Вы же понимаете, что тут «умелок» несколько больше?
И вот там, в бекенде, — конкуренция экосистем, каждая из которых рождает какие-то решения, неудачные хоронят, удачные перенимаются. При этом есть такие, которые растут по воле одного «визионера», есть катящиеся по воле сообщества. Но, самое главное — там есть выбор.
На фронте же вы прибиты в html-css-js. Их можно ругать, а можно любить. Но даже самый ярый фанат при наличии сколько-нибудь критического мышления назовет пару-тройку явных неприятных недостатков этих технологий. На бэке, если недостатки для вас критичны, вы просто выбираете другой стек, где недостатки менее критичны. На фронте вам остается только смириться. У вас, фактически, нет другого стека.
Вы можете говорить про angular, react и прочее и прочее, но все они, в конечном итоге, транслируются на выходе ровно в то, что умеет браузер. Они не решают эти проблемы, трансляцией невозможно решить концептуальную проблему того, во что вы транслируете. Получается, что все эти платформы — это «workaround» над проблемой. Способ обойти. При этом — автоматизированный способ обхода… А мы все знаем, что именно такая неявная автоматизация может достаточно больно бить по лбу.
Вот, ИМХО, где-то на этом месте и произошла небольшая локальная катастрофа. «Становится понятно, что веб-платформа обладает довольно мощным потенциалом для реализации сложных интерфейсов. » При этом сама платформа остается связкой «языка разметки гипертекста», «каскадных таблиц стилей» и прикрученных сильно сбоку скриптов, чтобы все это выглядело как «реализация сложных интерфейсов».
Т.е. интерфейсы стали лепить на том, что предназначено для гипертекста. Смогли? Да. Гениально? Да. Удачно получилось? Спорно.
В проектировании интерфейсов, как ни странно, отлично «заходит» ООП-подход. Вся вот эта «инкапсуляция», «полиморфизмы эти ваши» и т.д. Реально просто хорошо все это ложится «в логику». А в существующей реализации инкапсуляция невозможна, попытки родить абстракции «текут», любая связность — эмуляция, полиморфизм реализуется кодогенерацией…
Мне вот реально кажется, что текущий подход к проектированию веб-интерфейсов, мягко говоря, неидеален. Можно было на отметке «стало понятно» чуть-чуть притормозить, обдумать хорошо и сделать «правильно».
Но, момент упущен…
Т.е., вкратце, смысл задумки:
Что-то никак не пойму, в чем смысл "универсальности"? Для кого этот "пакет"?
Не совсем понимаю, каким образом она сохраняется.
Вы, вместо пакетного рантайма, подсовываете системный хостовый… И получаете печаль.
То, что отлично работало на машине разработчика, при запуске на Ubuntu отказывается работать вообще, а на Федоре ведет себя странно.
"Кроссплатформенность" покрывается медным тазиком...
В случае flatpak'а "обертка" и "изоляция", в первую очередь, и делаются для того, чтобы упакованное в него приложение имело ровно те версии библиотек в рантайме, которые ему нужны. Поэтому системный /usr и отрезают, чтобы не возникало путаницы. Случаи, когда приложение, по какой-то причине, хочет именно системный /usr — не для упаковки во flatpak.
Ну т.е. целевая платформа таки не все линуксы, а только мейнстрим?
Я не говорю, заметьте, что это в корне неверное решение с вашей, как разработчика, стороны. Оно даже, скорее, правильное. Логичнее сделать нормальный отлаженный рабочий инструмент под ограниченное количество окружений, чем глюкавое поделие "для всех". И поддержка сборок — она тоже вещь "небесплатная", что только оттянет лишние силы.
Но вы настолько настаиваете на безусловной кроссплатформенности своего фреймворка… что я не могу не указать вам на нецелесообразность и нереализуемость декларируемых вами "умелок".
Вы же понимаете, что претензия не к пакетному менеджеру, а таки к Арчу в целом? Точнее к Rolling-Release модели...
Дык, формулировка предыдущего ответа, вроде как, достаточно четко дает понять "мы не тратим времени на поддержку маргинальных дистрибутивов". Т.е. никто не будет заморачиваться, будет просто декларировать "универсальный GUI-фреймворк" и "весь Linux" в качестве целевой платформы, отказываясь ограничивать список поддерживаемых линуксов.
Собственно, исключить много чего можно. Но тогда о какой универсальности может идти речь?
Какбы от пакета еще, как минимум, стоило бы получать информацию еще о зависимостях, например. Иначе чем лучше configure-make-make install? И даже преимущества над tar -xzvf -C / становятся достаточно спорными...
Ну т.е. debian-based и rh-based дистрибутивы (которых, стоит таки признать, подавляющий процент) со своими запросами идут лесом…
Это нормально, если, допустим, на 80% целевых дистрибутивов ваш пакет будут сначала распаковывать, а потом перепаковывать во что-то другое, пригодное для использования в целевом дистрибутиве? Source-tarball для мейнтейнеров мейнстрима будет предпочтительней, т.к. этап "распаковки" и парсинга чужого и, не побоюсь этого слова, чуждого пакета можно будет опустить. Странный подход к универсальности, стоит признать.
Куда, простите, ставится? Вообще ни разу не слышал о каком-либо сродстве Alpine Linux и арчевского AUR...
Не похожа реализация. Функционал и целеполагание — абсолютно монопенисуальное.
Ни dpkg, ни rpm пакетным менеджером не являются. Пакетный менеджер поверх dpkg называется apt, например. И решает он, в первую очередь, НЕ проблему получения пакета или приложения. Вот реально, не для того весь сыр-бор. Эта "проблема" — наименьшая из проблем, стоящих перед пакетным менеджером. Для решения таковой все эти сложности с графами зависимостей и т.д. не нужны — тут и tar + набор sh-скриптов по необходимости справится.
Даже проблема корректного удаления пакета — более сложный процесс, чем процесс получения оного. А первейшая задача пакетного менеджера — руление зависимостями между пакетами.
Понимаете, в чем разница. Основная цель apt'а или yum'а, заради которой они создавались — автоматически разрулить адЪ, содомЪ и гоморру с зависимостями. Остальное — приятный бонус.
Основная цель Flatpak'а — именно доставка приложения. Причем не всякого и не любого, а конкретно заточенного и собранного под соответствующий рантайм. Он абстрагирован от зависимостей, с рулением сущностей на уровне flatpak'а справится третьеклассник. Дерево сущностей примитивное и ацикличное. Не рулит flatpak зависимостями, а просто приносит их вместе с приложениями и складывает в песочницу. Зато гарантия, что не пересекутся — песочницы-то разные.
Вот к этому я не призывал. Я призывал сменить ПОДХОД к жизни, никак не повод. Мотивация к жизни — это несколько более "нижний" уровень самопознания и биологического выживания вида. С этим уже к психологу, наверное… Ну или к философу, на крайний случай.
Короче, первая претензия к этому подходу в том, что на этом этапе flatpak становится лишней ограничивающей сущностью, не приносящей никакой реальной пользы. Зачем обертка, если рантайм системный?