А был ли Сатоши?

https://www.nikcub.com/posts/craig-wright-is-not-satoshi-nakamoto/

Зачем вообще Крэйгу Райту нужно было что-то доказывать, своё авторство биткойн и блокчейн, если сеть Интернет и люди в ней так полны скептицизма и всё равно большинство не поверит!?

К этому он не был готов, для борьбы нужно много моральных сил, легче сдаться ничего не доказывая.

Вряд ли конечно объявится другой Сатоши и сможет доказать своё авторство.

Спектакль окончен!

http://drcraigwright.net/homepage.jpg

протюнинговали с ребятами различные стэки технологий и потестили фреймворки...
поюзали munin для мониторинга - не понравилось, nagios и ganglia лучше и сохранили свой приоритет в выборе
выбираем подходящий стек для реализации очередного микросервисного high-load проекта, расчётные нагрузки от 250K RPS по обработке json (сериализация/десериализация данных) запросов к api
результаты на лицо
производительность серверов приложений uwsgi и tornado оставляет желать лучшего, фреймворки flask, web2py и даже twisted - также низкопроизводительны
сервер приложений gunicorn и фреймворк meinheld идут с сильным отрывом
связка nginx-gunicorn-meinheld по прежнему самая производительная для Python
vert.x ещё более производителен, но это уже Java NIO2 фреймворк с binding'ом для Python
falcon и после него чуть ниже по производительности bottle - самые нормальные wsgi фреймворки по соотношению производительность+overhead/удобство+скорость разработки
pypy и jit не всегда дают ожидаемый прирост производительности, чаще обычный cpython3 оказывается производительнее, что удивительно
про django вообще молчу, это тихий ужас, по архитектуре и производительности - генерирует слишком много малопонятных объектных boilerplate'ов, как Java фреймворки, и как JVM имеет значительный overhead по памяти, масштабируется плохо, при росте нагрузок нужно больше железа, процесс обработки (обработчиков-воркеров) просто тупо встаёт намертво и зависает, потому что django фреймворк синхронный (и это огромный минус в современных условиях, сравнимо как apache vs nginx), реализующий архитектурный паттерн MVP, работа с БД медленна, ORM имеет не очень удачную и продуманную реализацию и лучше его вообще не использовать

так что тесты фреймворков от techempower (http://www.techempower.com/benchmarks/) весьма правдивы! 👍 проверено собственными руками на собственной шкуре и в проектах

пока это будет лишь прототип проекта, имеющего микросервисную архитектуру и возможно позже этот прототип будет переписываться на Go при росте нагрузок
потом посмотрим
в зависимости от того какие нагрузки пойдут и как сервис будет держать нагрузку
но, есть несколько очень тонких и важных моментов...
для реализации данного проекта Python больше подходит, динамическая типизация всё таки рулит в некоторых задачах и алгоритмах, и многое упрощает, например рефакторинг, последующую модификацию, развитие, наращивание или наоборот сокращение функционала, его композицию в монолитную архитектуру или декомпозицию, разбивку на микросервисы

Python и Ruby замечательные языки, как две ипостаси, они мне оба очень нравятся, даже не знаю какой из них больше, в них есть много полезных, интересных и удобных фич для программирования, которые пока реализованы только в их интерпретаторах
это и сопрограммы, и динамическая типизация, и параметрический полиморфизм, и метаклассы, и т.д.
https://en.wikipedia.org/wiki/First-class_citizen#Examples
очень жаль что эти реализации интерпретаторов так неэффективны и до сих пор нет толковой реализации окружения этих языков, языковой среды, транслятора (именно компилятора), использующего возможности регистровой машины LLVM
из этого вытекает огромная неэффективность, неэкономичность, энергонеэффективность, необходимость масштабирования бОльшими экономическими затратами на хостинг, бОльшими ресурсами железа, бОльшими расходами энергии, электричества для поддержания работы серверов, сервисов
для перехода на Go очень вдохновила статья Трэвиса Ридера в блоге Iron.io:
https://www.iron.io/how-we-went-from-30-servers-to-2-go/
применяя Go это замечаешь всё больше, более остро, что всё остальное это костыли программирования, неэффективные и слишком энергозатратные
особенно это заметно в сфере криптовалют, где proof-of-work это главный принцип вычислительной сети
ещё очень жаль что производительность реализаций Ruby, MRI/YARV, JRuby, стала проседать сильно с введением в них поддержки версии 2.0 языка Ruby и его возможностей, как относительно реализаций версий 1.9 языка, так и относительно даже реализаций Python 3
Python минималистичен и этим привлекателен, Go ещё более минималистичен
хотя Ruby имеет более широкие языковые возможности (языка и стандартной библиотеки) при этом сохраняя минимализм языка, лаконичность архитектуры и реализации, как самого языка так и его окружения, языковой среды, трансляторов
огромное преимущество это объектная природа всех элементов, классов и типов языка и возможность их модификации, перегрузки, ad-hoc полиморфизма - это и есть реализация парадигмы First-class citizen, которую Ruby подчерпнул из Smalltalk
в программировании это называется интроспекцией типов и более обобщённо рефлексией и метапрограммированием, first-class object
в Python и Go такие возможности тоже есть, но они позволяют модифицировать не абсолютно все возможности языка, как в Ruby, в котором любой элемент, класс, объект и тип можно переопределить или вообще создать с помощью наследования свои типы, операторы, синтаксис, DSL для определённых задач

кстати, в Go есть динамическая идентификация (RTTI) и вывод типов (type inference) в runtime через reflect.TypeOf
https://golang.org/pkg/reflect/#TypeOf
это и есть один из аспектов реализации рефлексии (first-class object) и интроспекции типов в Go для динамического вывода, идентификации и определения типов данных

Уважаемые подписчики,
поздравляем Вас с Днём Победы!
Мирного неба всем над головой!
Помним, гордимся и чтим!

Сегодня символу Linux исполнилось 20 лет.

9 мая 1996 года официальным талисманом Linux стал пингвин Tux.

https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/Tux_Enhanced.svg/1000px-Tux_Enhanced.svg.png

https://en.wikipedia.org/wiki/Tux

Тут недавно в нескольких чатах прозвучал один и тот же вопрос.

Почему массовый проприетарный софт профессионального назначения (для графического дизайна, полиграфических и издательских систем, и другой популярный профессиональный проприетарный софт) не разрабатывается с учётом поддержки им Linux?

У многих это вызывает разочарование в Linux системах.

Но нужно осознавать и понимать, что многое зависит и от популярности Linux, качественного состава его пользовательской базы, целевой аудитории, а от этого уже желание производителей профессионального софта (Adobe, Autodesk, etc.) адаптировать его к среде Linux окружения и желание производителей железа (NVidia, AMD) поддерживать свои хардвёрные продукты в Linux.
Те же Pixar и Disney создают графику под Linux на своём софте, потому что рендеринг быстрее и открытые инструменты автоматизации (Python, etc.) доступны и хорошо поддерживаются огромным сообществом.
Linux имеет очень прочные позиции в индустрии кино - почти все эффекты, их монтаж, графика, анимация для кино создаются в Linux.

В качестве аргументов в спорах часто приводится якобы "отсутствие" некоторых "истинных" Windows технологий, типа RDP и Skype.

Под Linux есть Hanouts, Viber, Tox, как полные альтернативы Skype, более функциональные, есть десктоп-клиент Telegram в качестве более удобного мессенджера, есть управление удалённым рабочим столом через VNC или Chrome.

Также есть замечательный проект ffmpeg без которого большая часть видеохостингов и стриминговых сервисов просто не существовала бы!

Облачные инфраструктуры, кластерные фермы, сервера, мейнфреймы, суперкомпьютеры, промышленные системы, промышленный дизайн и моделирование - отрасли в которых позиции Linux традиционно очень сильны, благодаря массе открытых инструментов enterprise grade класса, работающих на Linux.

Пока ОС на ядре Linux не может быть универсальным решением для всех отраслей и причина не в самом ядре, ядро как раз таки способно поддержать любое железо и программы, и пока нет ничего более универсального, обобщённого по своей кодовой базе для многих архитектур железа, чем ядро Linux!

Про музыкальную индустрию, производство графического и издательского контента, нелинейный монтаж видео и эффекты - да, в этих отраслях позиции Apple очень сильны, потому что в них много значат патенты, лицензии, защита правообладателей и т.д.

M$ Windows традиционно держится за счёт OEM производителей и огромной массы не очень грамотных в IT людей, которым нет разницы чем пользоваться, лишь бы было проще для решения повседневных задач.

В мобильном секторе позиции Linux также сильны, за счёт Android и поддержки Linux со стороны Google, т.к. все их сервисы работают на Linux, а Android и ChromeOS, браузеры Chrome/Chromium это только средство продвижения и доставки их сервисов до конечных пользователей.

Intel например заинтересованы в Linux из-за серверного рынка и присутствия на нём, для продвижения своего, производимого ими, серверного железа, контроллеров встроенных систем и персонального профессионального железа для специалистов, во многом вовлечённых в серверный сектор, i.e. лэптопы, десктопы, рабочие станции для бэкэнд девелоперов и для разработчиков промышленной графики, создания графических эффектов в кино, графической анимации.

Oracle одной из первых увидела в Linux перспективу для продвижения своих корпоративных продуктов, СУБД и для поддержки ядром своей архитектуры SPARC в серверном сегменте рынка железа. Равно как и IBM со своими корпоративными продуктами, технологиями хранения данных, архитектурой Power, серверами и мэйнфреймами.

Вообще в мобильном и серверном секторе без поддержки и заинтересованности крупных вендоров Linux бы не имел таких сильных позиций, а вендоры доверяют Linux из-за его открытости, свободы применения и модификации под нужды бизнеса - "рука руку моет".

Где рынок был заинтересован в открытости, там позиции Linux сильны - это самый главный вывод!

Где востребована открытость, там уже востребован или будет востребован Linux - это market driven expansion!

Вот и вся правда-матка!

Всё зависит от целей и задач, применения и применимости.

Там где открытость и свободу нельзя или не получается поставить на коммерческие рельсы, там она не востребована и эта модель не работает.

Это основная мысль, почему массовый проприетарный софт для профессионального графического дизайна (и другой проприетарный софт) не разрабатывается с учётом поддержки им Linux.
Не потому что производители этого софта не могут, а потому что это требует усилий которые не окупятся, поэтому производителям софта это не выгодно.
Корпоративность, патенты, соглашения, деньги рулят потому что!

Поэтому в десктоп и мобильном секторе сподвижникам FLOSS и Linux нужно искать новые пути продвижения и монетизации, чтобы занять большую долю рынка.

Главный стратег и основатель Canonical, Марк Шаттлворт, начал продвижение Ubuntu Touch очень грамотно - с поддержки производителями устройств и операторами связи, особенно азиатскими, опытные образцы были отработаны на европейском рынке компанией BQ, девайсы BQ и Meizu с Ubuntu были продемонстрированы в Барселоне на MWC2015 (BQ) и MWC2016 (Meizu), а далее Canonical начала продвижение с азиатско-тихоокеанского региона и его рынков.
Одновременно в Canonical сконцентрировались на конвергенции разработки приложений и интерфейсов для разных типов поддерживаемых устройств, обобщённом графическом сервере Mir для этих целей, системе доставки и развёртывания приложений и обновлений прошивок/дистрибутива на базе системы управления контейнерами Snappy.

Как раз о том как Linux пришёл к лицензии GNU GPL на открытые исходники, о процессе разработки, о ядре и его создателе в интервью Линуса Торвальдса на конференции TED (Февраль 2016-го года, Ванкувер, Британская Колумбия, Канада) с её основателем и куратором Крисом Андерсоном

https://youtu.be/o8NPllzkFhE

Перевод данного интервью на русский язык

https://youtu.be/Xd4IsqrxFlA

Плюс ещё один вариант перевода на русский

https://youtu.be/_tvsaMdEEuY

В честь пятницы покажу немножко нахальный, но в целом хороший сайт с сообщением об уязвимости в драйвере управления оперативной памятью материнских плат ASUS. Тут вы найдёте всё, как будто бы оно так и должно быть: и надоедливая 8-битная музыка, и анимация в стиле демо-сцен с космосом, сделанная на модном сейчас canvas, и даже есть отсылка к твиттер-аккаунту SwiftOnSecurity. Вот так вроде бы и несложно, но вполне добротно и, главное, очень уникально можно сообщить о проблеме в безопасности - не то, что эти ваши скучные промо-странички уязвимостей, которые стали популярны после heartbleed. Радует, что творческие люди ещё остались и в этом месте, и они тратят своё время и силы, чтобы сделать что-то действительно интересное и при этом полезное для всех. :) И да, чуть не забыл, собственно код для проверки на уязвимость, как и бинарный файл, тут тоже присутствуют: всё буквально умещается в один C#-файл размером 200 строк - красота, что тут ещё скажешь. http://rol.im/asux/

Asus вновь удалось выделиться! 😂
Найдена опаснейшая уязвимость в BIOS материнских плат Asus в подсистеме инициализации и управления ОЗУ, которая фактически делает систему BIOS такой базовой!
Наикрутейшая презентация уязвимости! Такая прям ностальгическая, в духе крэкинговых команд начала нулевых, с восьмибитной музыкой! Какие наши времена! Теперь это всё на веб технологиях! Какая была классная музыка! Can't stop listening! 😂

http://rol.im/asux/

https://twitter.com/SwiftOnSecurity

Роме огромное СПАСИБО! 👍
Я наконец-то понял зачем M$ стараниями Canonical впихнула окружение GNU/Linux в Windows 10 - это же очевидно, чтобы запускать контейнеры и имеено Docker! 😂

Революция товарищи! 😂👍

https://blog.docker.com/2013/09/docker-can-now-run-within-docker/

https://github.com/jpetazzo/dind