Лично мне очень помог интерактивный туториал Rust by Example. Однако, стоит отметить, что этот туториал не для новичков в программировании, а для тех, кто уже хорошо владеет другими языками. Всё-таки, мало языков программирования, с которыми можно ознакомить в рамках одной статьи, вот, например, этот туториал по Rust включает в себя 20 глав. Тем не менее, я думаю, ваша статья тоже будет полезна многим.
Автор, будьте добры впредь писать подобные печаль-статьи куда-нибудь в другое место (я даже гиктаймсу такой статьи не пожелаю, уж не говоря о том, что на хабре вы её за уши притянули в хабы «РАЗРАБОТКА под Android» и «Google App Engine»). У вас ОС запускается на экране, Россия гордо входит в список (да, заслуга самой России, конечно же), Твиттер аккаунт Андроид по вашему мнению ведут разработчики…
Если я правильно понял, то, во-первых, у вас тут вопрос, а не статья, а с вопросами люди ходят в гугл или "тостер", во-вторых, у вас тут не вопрос, а поток сознания, который вообще невозможно разобрать.
Есть ещё новый проект в нише между Parquet и HBase, созданный Cloudera, — Kudu. Он всё ещё Beta, но я собираюсь его попробовать в новом проекте. Есть ли у кого-нибудь быть с ним? Самый привлекательный момент в Kudu проекте для меня — отсутствие JVM, написан Kudu на С++.
Да, я её там в итоге и нашёл, но ожидал всё-таки увидеть при первом использовании названия фреймворка в тексте, так что можете её туда ещё продублировать, лишним не будет, я думаю.
Выглядит круто! Я удивлён, что я вижу это на С++. Автор, на мой взгляд, создал шедевр!
P.S. В тексте поста мне не хватило ссылки на сам Silicon, оставлю её здесь: http://siliconframework.org/
Такой вызов лично для меня выглядит ужасно, тем не менее, спасибо за демонстрацию такой возможности ES6. В своём проекте я бы такой синтаксис не использовал, а взял бы i18next:
Всё-таки мне кажется, что для переводов важен контекст, поэтому переводить нужно всю шаблонизированную строку, а не отдельные её части.
Например: "${name}'s team" ("Vasya Pupkin's team") -> "Команда ${name}" ("Команда Васи Пупкина"), конечно, тут ещё проблема со склонением имён, но даже без проблемы склонения имён, порядок слов изменился.
Кроме того, часто нужен контекст (чтобы "name" в одних случаях переводилось как "имя", а в других — "наименование"), где можно было бы добавить в том числе и внешнюю информацию (пол {М/Ж}, число {единственное/множественное}, и тд и тп).
Выяснили, что регрессия в модуле thermal (rmmod thermal && modprobe thermal приводит к падению частоты). Вроде бы авторы патча уже изучают проблему, так что может быть скоро порешится.
NodeJS не подошло по самому первому требованию автора: "Небольшая, лёгкая утилита". Ну и да, хватит пихать JS куда ему не свойственно быть впихнутым или, иными словами, перестаньте своим молотком забивать шурупы.
Да, IPSec имеет свои плюсы и минусы… А что кричит Nginx? (мне просто для случая если у меня такое начнётся… ибо у меня ненагруженные внутренние сервисы с Nginx вроде бы работают хорошо пока)
Апгрейд контейнеров — это да, чудесато начиная от "продуманности" интерфейса, и заканчивая управляемостью и наблюдаемостью сего чудного процесса. У меня тоже случался вечный цикл обновления из-за падающего образа, к сожалению, даже откатить нельзя, пришлось пересоздавать контейнер с нуля. Но в целом, если настроил, то уже не падало у меня ни разу, так что я пока что всё равно доволен Rancher'ом и тоже очень надеюсь, что проект разовьётся и багов станет поменьше.
Я вот тоже гоняю в тестовом режиме. Rancher мне не кажется сырым, чего я не могу сказать про RancherOS… По функциональности он по-моему всё равно на голову выше swarm, с которого я начал эксперименты ещё год назад и который очень вряд ли куда-то разовьётся, так как ограничен Docker Daemon API интерфейсом.
но многих вещей не хватает — тома, бекапы (интеграция с convoy)
Да, я читал, пожалуй, все ваши статьи. В моём случае я использую всего 1 сервис, который можно было бы действительно в systemd запихнуть, но основной функционал заключается в запуске потенциально опасного кода в песочнице, для чего я и искользую Docker для запуска процессов без доступа к сети, с read-only FS, с ограничениями памяти и ресурсов ядра, а также CPU shares.
CONFIG_USER_NS (aka User Namespaces) на данный момент представляет собой одну большую дыру. В Debian/Ubuntu эту дыру решили тестировать на пользователях и каждый месяц теперь у нас CVE благоаря этой чудной штуке. В Arch Linux, например, отложили включение этой опции ядра пока дебианщики не закончат тестирование в боевых условиях.
Это с подачи автора перевода он стал «библиотекой».
P.S. В тексте поста мне не хватило ссылки на сам Silicon, оставлю её здесь: http://siliconframework.org/
P.S. В i18next учтено много нюансов, просто для комментария выбрал один из готовых примеров.
Например: "${name}'s team" ("Vasya Pupkin's team") -> "Команда ${name}" ("Команда Васи Пупкина"), конечно, тут ещё проблема со склонением имён, но даже без проблемы склонения имён, порядок слов изменился.
Кроме того, часто нужен контекст (чтобы "name" в одних случаях переводилось как "имя", а в других — "наименование"), где можно было бы добавить в том числе и внешнюю информацию (пол {М/Ж}, число {единственное/множественное}, и тд и тп).
Можете протестировать, пожалуйста такой эффект у себя?
Апгрейд контейнеров — это да, чудесато начиная от "продуманности" интерфейса, и заканчивая управляемостью и наблюдаемостью сего чудного процесса. У меня тоже случался вечный цикл обновления из-за падающего образа, к сожалению, даже откатить нельзя, пришлось пересоздавать контейнер с нуля. Но в целом, если настроил, то уже не падало у меня ни разу, так что я пока что всё равно доволен Rancher'ом и тоже очень надеюсь, что проект разовьётся и багов станет поменьше.
Это — docs.rancher.com/rancher/rancher-services/storage-service?
А чего именно Вам не хватает?
Это да… А кто предоставляет более гибкий acl?