А как же маниакальная страсть к именованию неймспейсов, так что необходимо объявлять класс в самом первом хеловорлде? «Сначала запомните этот бойлерплейт, про классы узнаете как-нибудь потом» − это просто краеугольный камень в обучении Java как первому ЯП. Мне кажется, трудно придумать что-то более мозголомное.
А как насчёт отсутствия беззнаковых целых? Знаковый byte разве мозг не ломает?
Если ваш ЯП имеет гибкие, расширяемые, легко сериализуемые структуры данных, то вы просто пользуетесь ими. Но если система типов вашего ЯП такова, что проще описать структуру данных на чём угодно другом, то a cat is fine too почему бы и не на XML?
Ну, значит, надо что-то где-то допилить, чтоб пользователи предпочитали всё что нужно бесплатно установить сами вместо того, чтобы платить условному Амазону. Раз платят, значит пока установка чего-то, что Амазон уже установил, вызывает боль.
Да почему обязательно боль? Я сейчас бегло глянул на цены EC2 и Amazon ElasticSearch on-demand: получается, что готовый эластик стоит юзеру дешевле, чем если его ставить самостоятельно. Это нечестная игра, демпинг. Elastic Inc ничего не может этому противопоставить в техническом смысле.
исходники от первоначального продукта доступны, значит должно быть не сложнее, а проще поддержать «инновации» в API.
Вопрос опять же не в том, что проще, а зачем вообще. Зачем разработчику популярного продукта, наверняка имеющему планы по его развитию, отвлекать ресурсы от этих планов и тратить их на копирование фич своего же закрытого клона?
Если речь про сферический ES в вакууме, то он и устанавливается одной командой, наверное. ;)
На самом деле юзабилити продукта как таковое тут не при чём. У условного Amazon как у облачного провайдера есть очевидное преимущество перед условным Elastic или условным Canonical: он имеет возможность устанавливать что угодно на сдаваемый им в аренду компьютер, а Elastic или Canonical вынуждены полагаться на арендатора. Я думаю, это преимущество вполне может считаться неконкурентным.
Ах он злой, можно подумать что майкрософт делится кодом с разработчиками вайна.
Это не очень подходящая аналогия: wine не является первой реализацией win32, и MS не основывал Windows на общественно доступном коде (по крайней мере, целиком).
Возможно, помогла бы, но вот MongoDB говорит, что может и не помочь. Или у условного Elastic есть другие причины сохранять пермиссивную лицензию. Я думаю, что это уже вопрос второстепенный. Пусть лучше будет пермиссивная и коммерческая лицензии, чем закрытый код.
Цель — запретить крупным ИТ-компаниям коммерциализировать их программное обеспечение в том или ином виде.
Ну, это же, мягко говоря, неправда.
Смотрите, есть условный Elastic, развивающий открытый продукт, а есть условный Amazon, который проворачивает с продуктом Elastic − ES − следующую нехитрую схему:
Запускает ES в виде готового сервиса,
Получает большую долю пользователей ES, которым лень в apt-get install,
Вносит в API своего ES такие изменения, которые делают сервис несовместимым с оригинальным, открытым ES,
Сообщество забивает на открытый ES, Elastic закрывается,
Amazon выкручивает монетизацию своего ES на 11.
То есть условный Elastic в данном случае не «запрещает монетизировать», а старается элементарно выжить и защитить сообщество.
Я так понимаю, что новое поколение спутников, старлинки и ван-вебы, будут работать как свичи/роутеры, в отличие от стариков, которые были глупыми хабами. Поэтому ловиться не будет.
Я имел в виду, что wine эмулирует (точнее, транслирует) системные вызовы win32 на линуксе, и при этом поддерживается в актуальном состоянии, приносит практическую пользу и не является «мертворожденной затеей». Если так, то почему эмуляция вызовов линукса в виндовс (WSL 1) должна быть «мертворожденной затеей»?
Я не могу понять, что нового даёт WSL 2 в плане интеграции с Linux, чего в Windows не было ещё 10 лет назад? Как я понимаю, основа технологического стека − это
Hyper-V, паравиртуализацию линукса туда завезли ещё в 2008 году емнип,
Протокол 9P, который тоже был с нами уже очень давно, в куче конкретных реализаций под пермиссивными лицензиями, поэтому использовался, например, в VirtualBox, libvirt, QEMU на Windows.
Понятно, что паравиртуализация − это медленно и затратно по сравнению с нативным выполнением; сетевая ФС тоже имеет кучу недостатков, начиная от производительности и кончая необходимостью для доступа к файлам держать клиента запущенным.
И первая реализация WSL вроде как должна была победить эти недостатки за счёт нативной подсистемы исполнения Linux-бинарников, как это сделано в Wine. Но MS выбросил WSL 1 после года разработки (и весьма неплохих результатов, если сравнивать с развитием того же Wine) и сделал откат к технологиям, по сути уже существовавшим как commodity.
::А как же маниакальная страсть к именованию неймспейсов, так что необходимо объявлять класс в самом первом хеловорлде? «Сначала запомните этот бойлерплейт, про классы узнаете как-нибудь потом» − это просто краеугольный камень в обучении Java как первому ЯП. Мне кажется, трудно придумать что-то более мозголомное.
А как насчёт отсутствия беззнаковых целых? Знаковый
byteразве мозг не ломает?a cat is fine tooпочему бы и не на XML?Да почему обязательно боль? Я сейчас бегло глянул на цены EC2 и Amazon ElasticSearch on-demand: получается, что готовый эластик стоит юзеру дешевле, чем если его ставить самостоятельно. Это нечестная игра, демпинг. Elastic Inc ничего не может этому противопоставить в техническом смысле.
Вопрос опять же не в том, что проще, а зачем вообще. Зачем разработчику популярного продукта, наверняка имеющему планы по его развитию, отвлекать ресурсы от этих планов и тратить их на копирование фич своего же закрытого клона?
Если речь про сферический ES в вакууме, то он и устанавливается одной командой, наверное. ;)
На самом деле юзабилити продукта как таковое тут не при чём. У условного Amazon как у облачного провайдера есть очевидное преимущество перед условным Elastic или условным Canonical: он имеет возможность устанавливать что угодно на сдаваемый им в аренду компьютер, а Elastic или Canonical вынуждены полагаться на арендатора. Я думаю, это преимущество вполне может считаться неконкурентным.
Это не очень подходящая аналогия: wine не является первой реализацией win32, и MS не основывал Windows на общественно доступном коде (по крайней мере, целиком).
Чтобы три разных профессиональных продукта устанавливались и настраивались одной командой? Серьёзно?
Прежде всего то, что условный Amazon не делится своим кодом с сообществом, в отличие от условного Elastic.
Ну, это же, мягко говоря, неправда.
Смотрите, есть условный Elastic, развивающий открытый продукт, а есть условный Amazon, который проворачивает с продуктом Elastic − ES − следующую нехитрую схему:
То есть условный Elastic в данном случае не «запрещает монетизировать», а старается элементарно выжить и защитить сообщество.
Понятно, что паравиртуализация − это медленно и затратно по сравнению с нативным выполнением; сетевая ФС тоже имеет кучу недостатков, начиная от производительности и кончая необходимостью для доступа к файлам держать клиента запущенным.
И первая реализация WSL вроде как должна была победить эти недостатки за счёт нативной подсистемы исполнения Linux-бинарников, как это сделано в Wine. Но MS выбросил WSL 1 после года разработки (и весьма неплохих результатов, если сравнивать с развитием того же Wine) и сделал откат к технологиям, по сути уже существовавшим как commodity.
Так за что именно хвалят сейчас MS?
А то у меня прямо сходу глаза на лоб полезли: что может быть такого сложного в установке рельс?! А оно вот как, оказывается.
Ну, и вы как-то неожиданно перешли от Ruby к JavaScript, а потом опять к Ruby. Это несколько сбивает с толку.