Комментарии 18
Извините, но причем тут Qt?
От Qt конкретно в моём коде весь GUI. Я изначально планировал рассказать ещё и об этом (тем более, что биндингов к Qt на других языках крайне мало), но понял, что в одну статью никак не влезаю. Собственно, поэтому я в тексте написал, что если кому-то это было бы интересно, то я готов рассказать. Из хабов не стал исключать, потому что иначе шанс пересечения с Qt-аудиторией небольшой.
Понял. А я думал, что в Qt реализовали Melange.
Я просто пройдусь по списку:
Perl — не обновлялся два года
PySide — остановился на Qt4.8
qtruby — не обновлялся два года
KBasic — обновлялся в 2012, платный
Ada2005 — умеет примерно половину библиотек от Qt4.7
Lua — 8 месяцев не обновлялся
QtD — 3 года не обновлялся
и так далее.
Из более-менее живых есть PyQt (самый используемый AFAIK), Qt Jambi (я если честно, думал, что он давно умер, ан нет), Qyoto, может быть ещё пара языков.
Список на сайте выглядит внушительно, но реально, к сожалению, он небольшой. Gtk и тот поддерживает больше языков (причём даже официальных биндингов больше), в силу своего C и GIR. У Qt есть SMOKE, но он что-то не пользуется популярностью.
Perl — не обновлялся два года
PySide — остановился на Qt4.8
qtruby — не обновлялся два года
KBasic — обновлялся в 2012, платный
Ada2005 — умеет примерно половину библиотек от Qt4.7
Lua — 8 месяцев не обновлялся
QtD — 3 года не обновлялся
и так далее.
Из более-менее живых есть PyQt (самый используемый AFAIK), Qt Jambi (я если честно, думал, что он давно умер, ан нет), Qyoto, может быть ещё пара языков.
Список на сайте выглядит внушительно, но реально, к сожалению, он небольшой. Gtk и тот поддерживает больше языков (причём даже официальных биндингов больше), в силу своего C и GIR. У Qt есть SMOKE, но он что-то не пользуется популярностью.
Проекты растут, усложняются. Чтобы бороться со сложностью программы разбивают на независимые части. Сейчас вперед выходят языки не те которые помогают немногословно описывать задачи, а те которые помогают описывать задачи по частям.
ASN.1 вон вообще в 84 году сделали. Другой вопрос, что и protocol buffers и thrift и ASN.1 могут кодировать только сообщения в своём собственном формате. Произвольный формат пакета ты им не закодируешь. А тут просто DSL для написания бинарных кодеков. Сравнивать его с protobuf etc не совсем корректно.
Как раз в ASN.1 формат отделен от схемы данных.
Там есть отдельно Encoding Rules — хоть в битовый поток засунуть, хоть в XML.
Сертификаты X.509 например кодируются в DER.
ru.wikipedia.org/wiki/X.690
Так что ничто не мешает кодировать ASN.1 данные даже в protobuf
Там есть отдельно Encoding Rules — хоть в битовый поток засунуть, хоть в XML.
Сертификаты X.509 например кодируются в DER.
ru.wikipedia.org/wiki/X.690
Так что ничто не мешает кодировать ASN.1 данные даже в protobuf
Мне кажется, что всё-таки корректно. Объясню, почему. Protobuf был введён, как более удобная и экономная замена XML в вопросах кодирования данных с известной структурой, кроме того был платформонезависим, позволяя прозрачно передавать данные от одного языка программирования и ОС — совершенно другому.
В такой постановке вопроса, как мне кажется, не слишком важно, как он там кодирует данные внутри (наверное, кого-то расстраивало, что в protobuf нельзя сформировать UDP-пакет, но вряд ли много кого) и основными отличиями между MPL и Protobuf становятся такие вещи, как расширяемость или опциональные поля в Protobuf и более богатая внутренняя логика в MPL.
ASN.1 и Thrift в этой связи сравнивать с MPL и Protobuf нельзя, потому что ASN.1 — это только описание общей структуры, а Thrift — это уже готовый инструмент для конкретных задач (кроме того, протокол у него внизу может быть разным, мы вполне можем прикрутить Melange как ещё одну реализацию протокола для Thrift).
ASN.1 может стать кодированием с сочетании с BER/DER/XER, но ему как раз по-прежнему не хватает удобства — инструментов, валидаторов, каких бы то ни было плюсов, по сравнению с другими форматами. Фактически, единственное его достоинство — возраст. Он не имеет никаких достоинств по сравнению с другими форматами, и вот так в 2013 году выглядит инструменты для работы с ним. Если бы кто-нибудь когда-нибудь написал для ASN.1/DER что-нибудь, примерно похожее на protobuf и MPL, оно могло бы стать заменой, но я не вижу смысла ввиду отсутствия каких-то плюсов по сравнению с ними.
В такой постановке вопроса, как мне кажется, не слишком важно, как он там кодирует данные внутри (наверное, кого-то расстраивало, что в protobuf нельзя сформировать UDP-пакет, но вряд ли много кого) и основными отличиями между MPL и Protobuf становятся такие вещи, как расширяемость или опциональные поля в Protobuf и более богатая внутренняя логика в MPL.
ASN.1 и Thrift в этой связи сравнивать с MPL и Protobuf нельзя, потому что ASN.1 — это только описание общей структуры, а Thrift — это уже готовый инструмент для конкретных задач (кроме того, протокол у него внизу может быть разным, мы вполне можем прикрутить Melange как ещё одну реализацию протокола для Thrift).
ASN.1 может стать кодированием с сочетании с BER/DER/XER, но ему как раз по-прежнему не хватает удобства — инструментов, валидаторов, каких бы то ни было плюсов, по сравнению с другими форматами. Фактически, единственное его достоинство — возраст. Он не имеет никаких достоинств по сравнению с другими форматами, и вот так в 2013 году выглядит инструменты для работы с ним. Если бы кто-нибудь когда-нибудь написал для ASN.1/DER что-нибудь, примерно похожее на protobuf и MPL, оно могло бы стать заменой, но я не вижу смысла ввиду отсутствия каких-то плюсов по сравнению с ними.
Начнем с того, что ASN.1 стандартизирован. Уже это делает его в определенных ситуациях единственным возможным выбором (а не просто является одним из преимуществ, в противовес вашим мечтам). Во-вторых, ASN.1 является великолепным способом описания интерфейса (именно интерфейса, а не какой-то там «общей структуры»; можно очень хорошо и четко конкретизировать и ограничить возможные значения). В некоторой степени, его сложность и количество возможностей, конечно, плохо повлияли на его распространенность (да просто всем западло кодить Unaligned PER энкодер-декодер для всего этого; а тем более генератор парсеров, как, в общем-то, и подобает нормальному инструменту). Поэтому и появились инструменты, вроде Thrift и ProtoBuffers: бывает, что весь имеющийся арсенал — это дичайший оверкилл. Но в тех областях, где он используется (в первую очередь, конечно, телефония и прочие телекомы, где уровень чуть или сильно ниже перегонки личных сообщений по хттп), он используется и замены ему нет. Собственно, единственный минус ASN.1: это малая распространенность.
Устарел, не устарел, но в Mirage, кадется, вполне себе используется…
Хen умирает (силами Цитрикса). Увы. Проприентарные корни без мощного комьюнити сильно его портят.
Хм, как-то после Xen Dev Summit каждый год у меня такого впечатления не складывается…
Я тоже долгое время так думал. К сожалению, между академической тусовкой и реальной жизнью у зена такие проблемы, на фоне которого игры в паравиртуализацию уже не заметны.
Во-первых цитрикс, который очень очень виндовый и которого вполне устраивает продажа vdi'ев. xen server для них уже давно имиджевый проект, для которого продажа саппорта — лишь галочка при разводе энтерпрайз-клиентов. При формальном опенсорсе xenserver совершенно не libre software, так как весь governance намертво в зубах у цитрикса, а фичи они пилят большей частью под нужды десктопа.
У xenserver'а ужасный код за пределами самого зена. Я несколько раз показывал этот код, покажу ещё раз:
github.com/xapi-project/sm/blob/6e37a85ef88b97c84c6177eccc652e3528bf9b59/tests/faultinjection/util.py
Такой индусный код у них всюду в sm'ах. А block devices — это святая святых виртуализации.
Далее, кто, кроме цитрикса там? Амазон. Много амазон своих наработок отдал? Я на 1000% уверен, что у них там свой тулстек и никому они его не отдадут. SUSE подпиливает, oracle ещё.
После того, как RH махнул рукой на зен, opensource'ной версии (production ready) де-факто не осталось.
Но главное — зен слишком сфокусирован на вопросах микроядра. Ведь (особенно, в свете миража и эквивалента от эрланга) зен просто выступает как микроядро, обеспечивая message passing (events) между доменами (процессами).
Как все микроядерные штуки оно хорошо в теории и отвратительно на практике. Например, xenbus, при кажущейся красоте — омерзительный протокол с кучей рейсов, ведущий к тому, что на хостах с xen'ом до сих пор более одного домена в один момент времени стартовать не может. У цитрикса в коде даже есть отдельный хак с sleep'ом, чтобы домены не смели слишком часто рестартовать.
То, что у зена до сих пор референсным является 2.6.18-xen — ещё тот показатель. pv_ops при формально заявленной поддержке всего и вся — второсортное ядро для зена (кривое управление памятью, плавающие таймеры и т.д.), а это означает, что зен не с линуксом, а сам по себе (что очень согласуется с идеей «микроядро»).
И эта ситуация тянется годами. За это время kvm из поделки для гиков стал очень крутой штукой, основой для RH, самым массовым гипервизором для openstack'а, в то же самое время цитрикс валандается c VDI'ем.
То есть зен стремительно теряет все свои преимущества. kvm уже давно работает со скоростями, сравнимыми с xen'ом (по сетевой и дисковой производительности превосходя оный за счёт отсутствия идиотских лимитов ring buffer'ов), а «родной для линукса» много значит в контексте продакт-деплоя.
Во-первых цитрикс, который очень очень виндовый и которого вполне устраивает продажа vdi'ев. xen server для них уже давно имиджевый проект, для которого продажа саппорта — лишь галочка при разводе энтерпрайз-клиентов. При формальном опенсорсе xenserver совершенно не libre software, так как весь governance намертво в зубах у цитрикса, а фичи они пилят большей частью под нужды десктопа.
У xenserver'а ужасный код за пределами самого зена. Я несколько раз показывал этот код, покажу ещё раз:
github.com/xapi-project/sm/blob/6e37a85ef88b97c84c6177eccc652e3528bf9b59/tests/faultinjection/util.py
cmd = ["ls", path, "-1", "--color=never"]
try:
text = pread2(cmd).split('\n')
Такой индусный код у них всюду в sm'ах. А block devices — это святая святых виртуализации.
Далее, кто, кроме цитрикса там? Амазон. Много амазон своих наработок отдал? Я на 1000% уверен, что у них там свой тулстек и никому они его не отдадут. SUSE подпиливает, oracle ещё.
После того, как RH махнул рукой на зен, opensource'ной версии (production ready) де-факто не осталось.
Но главное — зен слишком сфокусирован на вопросах микроядра. Ведь (особенно, в свете миража и эквивалента от эрланга) зен просто выступает как микроядро, обеспечивая message passing (events) между доменами (процессами).
Как все микроядерные штуки оно хорошо в теории и отвратительно на практике. Например, xenbus, при кажущейся красоте — омерзительный протокол с кучей рейсов, ведущий к тому, что на хостах с xen'ом до сих пор более одного домена в один момент времени стартовать не может. У цитрикса в коде даже есть отдельный хак с sleep'ом, чтобы домены не смели слишком часто рестартовать.
То, что у зена до сих пор референсным является 2.6.18-xen — ещё тот показатель. pv_ops при формально заявленной поддержке всего и вся — второсортное ядро для зена (кривое управление памятью, плавающие таймеры и т.д.), а это означает, что зен не с линуксом, а сам по себе (что очень согласуется с идеей «микроядро»).
И эта ситуация тянется годами. За это время kvm из поделки для гиков стал очень крутой штукой, основой для RH, самым массовым гипервизором для openstack'а, в то же самое время цитрикс валандается c VDI'ем.
То есть зен стремительно теряет все свои преимущества. kvm уже давно работает со скоростями, сравнимыми с xen'ом (по сетевой и дисковой производительности превосходя оный за счёт отсутствия идиотских лимитов ring buffer'ов), а «родной для линукса» много значит в контексте продакт-деплоя.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо. Это очень круто. И своевременно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Melange — DSL для сетевых протоколов