Последнее время много пишут про DL/ML (deep learning, machine learning)
Для машинного обучения есть фреймворки
Torch, Leaf, Theano и MXNet весьма круты! 👍
Google DeepMind использует Torch
https://en.wikipedia.org/wiki/Comparison_of_deep_learning_software
https://github.com/autumnai/leaf (Rust)
http://autumnai.com
https://github.com/dmlc/mxnet (multilanguage - JavaScript, Go, Python, Julia, R, Scala)
http://mxnet.readthedocs.io/en/latest/
https://github.com/torch/torch7 (Lua, LuaJIT)
http://torch.ch
https://en.wikipedia.org/wiki/Torch_(machine_learning)
Для машинного обучения есть фреймворки
Torch, Leaf, Theano и MXNet весьма круты! 👍
Google DeepMind использует Torch
https://en.wikipedia.org/wiki/Comparison_of_deep_learning_software
https://github.com/autumnai/leaf (Rust)
http://autumnai.com
https://github.com/dmlc/mxnet (multilanguage - JavaScript, Go, Python, Julia, R, Scala)
http://mxnet.readthedocs.io/en/latest/
https://github.com/torch/torch7 (Lua, LuaJIT)
http://torch.ch
https://en.wikipedia.org/wiki/Torch_(machine_learning)
Wikipedia
Comparison of deep learning software
comparison
Про него столько писали зарубежные СМИ, выдвигали спекулятивные предположения, что он автор BitСoin и вот наконец он сам в этом признался! И не просто признался, а доказал своё авторство криптографически!
http://www.drcraigwright.net/jean-paul-sartre-signing-significance/
http://gavinandresen.ninja/satoshi
Создатель идеи BitCoin - австралиец Craig Wright (http://www.drcraigwright.net/about/).
Сам протокол BitCoin и технология базы транзакций Blockchain была создана им в соавторстве с криптографом Hal Finney и другими инженерами.
Нужно полагать, что во многом такой шаг Крэйга направлен на популяризацию BitCoin, вывод его из тени финансового мира и повышение доверия к нему.
http://www.bbc.com/news/technology-36168863
Забавно, что это событие совпало с началом приёма Bitcoin в качестве электронной криптовалюты для оплаты игр в Steam.
Интересен факт, каким количеством биткойнов владеет сам Крэйг Райт, ведь он был вовлечён в процесс формирования блокчейна и майнинга с самого начала его существования и сгенерировал первую транзакцию из 10-ти биткойнов, которая сформировала начальный генезис-блок в базе блокчейн.
http://www.drcraigwright.net/jean-paul-sartre-signing-significance/
http://gavinandresen.ninja/satoshi
Создатель идеи BitCoin - австралиец Craig Wright (http://www.drcraigwright.net/about/).
Сам протокол BitCoin и технология базы транзакций Blockchain была создана им в соавторстве с криптографом Hal Finney и другими инженерами.
Нужно полагать, что во многом такой шаг Крэйга направлен на популяризацию BitCoin, вывод его из тени финансового мира и повышение доверия к нему.
http://www.bbc.com/news/technology-36168863
Забавно, что это событие совпало с началом приёма Bitcoin в качестве электронной криптовалюты для оплаты игр в Steam.
Интересен факт, каким количеством биткойнов владеет сам Крэйг Райт, ведь он был вовлечён в процесс формирования блокчейна и майнинга с самого начала его существования и сгенерировал первую транзакцию из 10-ти биткойнов, которая сформировала начальный генезис-блок в базе блокчейн.
https://telegram.me/g33ks/161
длительная анонимность возможна
анонимность можно сохранять до тех пор и так долго пока сам не решишь раскрыться или сам не совершишь ошибку с утечкой данных, через контрагентов, посредников например
однако, даже TOR уже не последняя фантазия для сокрытия - кто контролирует выходные шлюзы, тот контролирует содержимое трафика, а кто контролирует входные шлюзы, тот контролирует адреса источников трафика
end-to-end шифрование (ассиметричные шифры) также не всегда решают проблему сокрытия данных
для сокрытия адреса источника трафика со времён трассировки Шимомуры-Митника было придумано много весьма изощрённых методик, обфускации, стеганографии и т.п.
суть анонимности в слабой связности и слабой зависимости фактов для установления источника или личности
этим и занимается компьютерная криминалистика (форензика, forensics), анализ и расследование инцидентов информационной безопасности и киберпреступлений
http://www.infowatch.ru
http://infowatch.livejournal.com
http://forensics.ru
http://forensics.ru/InFuWo.htm
http://geektimes.ru/post/136816/
http://bezopasnik.org/article/book/95_0.pdf
чем меньше вы следов оставляете и информации испускаете в сети - тем сложнее её связать для установления фактов
поэтому, если бы Крэйг Райт сам не раскрылся и не предоставил доказательства авторства, то это оставило бы пространство для догадок и тайна Сатоши осталась бы тайной
Однозначно же в этой истории можно сделать только один вывод: анонимности нет, и Сатоши Накамото тому - последнее прямое цифровое подтверждение.
длительная анонимность возможна
анонимность можно сохранять до тех пор и так долго пока сам не решишь раскрыться или сам не совершишь ошибку с утечкой данных, через контрагентов, посредников например
однако, даже TOR уже не последняя фантазия для сокрытия - кто контролирует выходные шлюзы, тот контролирует содержимое трафика, а кто контролирует входные шлюзы, тот контролирует адреса источников трафика
end-to-end шифрование (ассиметричные шифры) также не всегда решают проблему сокрытия данных
для сокрытия адреса источника трафика со времён трассировки Шимомуры-Митника было придумано много весьма изощрённых методик, обфускации, стеганографии и т.п.
суть анонимности в слабой связности и слабой зависимости фактов для установления источника или личности
этим и занимается компьютерная криминалистика (форензика, forensics), анализ и расследование инцидентов информационной безопасности и киберпреступлений
http://www.infowatch.ru
http://infowatch.livejournal.com
http://forensics.ru
http://forensics.ru/InFuWo.htm
http://geektimes.ru/post/136816/
http://bezopasnik.org/article/book/95_0.pdf
чем меньше вы следов оставляете и информации испускаете в сети - тем сложнее её связать для установления фактов
поэтому, если бы Крэйг Райт сам не раскрылся и не предоставил доказательства авторства, то это оставило бы пространство для догадок и тайна Сатоши осталась бы тайной
Telegram
Geeks
Создатель Bitcoin, скрывавшийся под именем Сатоши Накамото, раскрыл свою личность, - им оказался (*по его же пока не подтверждённым заявлениям*) австралийский предприниматель Крег Райт. Фактически его вынудили выйти на публику: ему даже пришлось в спешке…
Technologique
неделю назад столкнулся с фундаментальным ограничением в JRuby (bottle-neck) при тюнинге производительтности - код поддержки coroutine based fibers оказывается выпилен из JRuby до лучших времён https://github.com/jruby/jruby/wiki/PerformanceTuning#enable…
почему в Java и в реализациях окружений (трансляторов) языков под JVM (Scala, Kotlin, Groovy, JRuby, Jython), в C и в C++, нет нативной поддержки сопрограмм (coroutines) до сих пор?
я был в поиске ответа на этот вопрос из-за ограничений производительности coroutine based fibers и в целом сопрограмм в JRuby под JVM, т.к. в JRuby код поддержки сопрограмм был выпилен, потому что на уровне байт-кода JVM нет их нативной реализации и поддержки, а текущая реализация fibers в JRuby основана на green и native тредах JVM
до сих пор реализация тредов (от Java до Rust) была единственным мэйнстрим решением параллелизма основанного на модели акторов, но не на её более развитой модели CSP (Communicating Sequential Processes), на которой основан Go и которая сама является развитием идеи акторов, и базируется на парадигме сопрограмм
после долгих поисков в литературе и лекций Coursera я наконец таки нашёл ответ
краткий правильный ответ очень простой, но довольно малоизвестный широкому кругу программистов и потому достаточно неожиданный:
из-за проблемы фунарга (проблемы функциональных аргументов)
https://en.wikipedia.org/wiki/Funarg_problem
если более подробно:
во всём виноват аппаратный (процессорный) и программный стэк (в кэше и динамической памяти), т.к. в отличии от деревьев (структур данных), стэк это одна из самых неэффективных структур данных для хранения аргументов (call stack) при множественном объединённом (chained) вызове функций по цепочке, что на самом деле и происходит на низком уровне при реализации сопрограмм
в свою очередь большинство виртуальных машин и их JIT компиляторов реализованы именно как стековые машины и основаны на использовании стэка и стэковых структур данных (cactus stack) для компиляции программы в байт-код, а самого байт-кода в машинный код и трансляции специальных инструкций байт-кода в вызовы виртуальной машины (invokedynamic, invokestatic, invokevirtual, etc.), потому что стэк, особенно аппаратный, это самая быстрая структура данных по производительности операций с ней
JVM и MLVM (Da Vinci Machine) это стековые виртуальные машины, не регистровые, как например LLVM, Parrot, Dalvik, ART, LuaJIT, V8, которые активно используют быстрые регистровые операции, хранение структур данных в кэше процессора и в динамической памяти, динамическое управление памятью на основе кучи, деревья (кучи, heap) для хранения контекста, окружения (scopes, closures, cactus stack) и аргументов вызова функций
https://en.wikipedia.org/wiki/Comparison_of_application_virtualization_software
поэтому так важно глубокое понимание основ computer science, знание структур данных и оценки их эффективности, архитектур компьютеров и низкоуровневого программирования, алгоритмов и оценки их сложности, для глубокого понимания современного программирования и для того, чтобы стать более лучшим программистом-разработчиком
продолжение следует...
#funarg
#coroutines
#goroutines
я был в поиске ответа на этот вопрос из-за ограничений производительности coroutine based fibers и в целом сопрограмм в JRuby под JVM, т.к. в JRuby код поддержки сопрограмм был выпилен, потому что на уровне байт-кода JVM нет их нативной реализации и поддержки, а текущая реализация fibers в JRuby основана на green и native тредах JVM
до сих пор реализация тредов (от Java до Rust) была единственным мэйнстрим решением параллелизма основанного на модели акторов, но не на её более развитой модели CSP (Communicating Sequential Processes), на которой основан Go и которая сама является развитием идеи акторов, и базируется на парадигме сопрограмм
после долгих поисков в литературе и лекций Coursera я наконец таки нашёл ответ
краткий правильный ответ очень простой, но довольно малоизвестный широкому кругу программистов и потому достаточно неожиданный:
из-за проблемы фунарга (проблемы функциональных аргументов)
https://en.wikipedia.org/wiki/Funarg_problem
если более подробно:
во всём виноват аппаратный (процессорный) и программный стэк (в кэше и динамической памяти), т.к. в отличии от деревьев (структур данных), стэк это одна из самых неэффективных структур данных для хранения аргументов (call stack) при множественном объединённом (chained) вызове функций по цепочке, что на самом деле и происходит на низком уровне при реализации сопрограмм
в свою очередь большинство виртуальных машин и их JIT компиляторов реализованы именно как стековые машины и основаны на использовании стэка и стэковых структур данных (cactus stack) для компиляции программы в байт-код, а самого байт-кода в машинный код и трансляции специальных инструкций байт-кода в вызовы виртуальной машины (invokedynamic, invokestatic, invokevirtual, etc.), потому что стэк, особенно аппаратный, это самая быстрая структура данных по производительности операций с ней
JVM и MLVM (Da Vinci Machine) это стековые виртуальные машины, не регистровые, как например LLVM, Parrot, Dalvik, ART, LuaJIT, V8, которые активно используют быстрые регистровые операции, хранение структур данных в кэше процессора и в динамической памяти, динамическое управление памятью на основе кучи, деревья (кучи, heap) для хранения контекста, окружения (scopes, closures, cactus stack) и аргументов вызова функций
https://en.wikipedia.org/wiki/Comparison_of_application_virtualization_software
поэтому так важно глубокое понимание основ computer science, знание структур данных и оценки их эффективности, архитектур компьютеров и низкоуровневого программирования, алгоритмов и оценки их сложности, для глубокого понимания современного программирования и для того, чтобы стать более лучшим программистом-разработчиком
продолжение следует...
#funarg
#coroutines
#goroutines
Быстрое руководство в виде code-snippets по языку Solidity для создания смарт-контрактов под EthereumVM в сети криптовалюты Ethereum
https://github.com/adambard/learnxinyminutes-docs/blob/master/solidity.html.markdown
https://github.com/adambard/learnxinyminutes-docs/blob/master/solidity.html.markdown
GitHub
learnxinyminutes-docs/solidity.html.markdown at master · adambard/learnxinyminutes-docs
Code documentation written as code! How novel and totally my idea! - learnxinyminutes-docs/solidity.html.markdown at master · adambard/learnxinyminutes-docs
Друзья, внимательней с мессенджером Телеграм, используйте номер и сим-карты операторов стран с независимой юрисдикцией для привязки к аккаунту, обязательно используйте двухфакторную авторизацию (cloud password в клиентах) и секретные чат-комнаты с end-to-end шифрованием, проверяйте сессии других устройств в клиентах - безопасность должна быть безопасной! Think securely - keep safety!
Уведомления о новых авторизациях и новых сессиях на других устройствах приходят массовой рассылкой во все активные сессии клиентов от сервиса нотификаций Telegram: +42777
https://geektimes.ru/post/275204/
https://telegram.org/blog/sessions-and-2-step-verification
Уведомления о новых авторизациях и новых сессиях на других устройствах приходят массовой рассылкой во все активные сессии клиентов от сервиса нотификаций Telegram: +42777
https://geektimes.ru/post/275204/
https://telegram.org/blog/sessions-and-2-step-verification
Хабр
Спецслужбы начали перехватывать SMS-коды авторизации Telegram
Похоже, авторизация по SMS в мессенджере Telegram скомпрометирована. Об этом сегодня предупредил пользователей сам Павел Дуров. «Судя по всему, спецслужбы РФ решили начать давить на операторов связи,...
Technologique
А был ли Сатоши? https://www.nikcub.com/posts/craig-wright-is-not-satoshi-nakamoto/
Зачем вообще Крэйгу Райту нужно было что-то доказывать, своё авторство биткойн и блокчейн, если сеть Интернет и люди в ней так полны скептицизма и всё равно большинство не поверит!?
К этому он не был готов, для борьбы нужно много моральных сил, легче сдаться ничего не доказывая.
Вряд ли конечно объявится другой Сатоши и сможет доказать своё авторство.
Спектакль окончен!
http://drcraigwright.net/homepage.jpg
К этому он не был готов, для борьбы нужно много моральных сил, легче сдаться ничего не доказывая.
Вряд ли конечно объявится другой Сатоши и сможет доказать своё авторство.
Спектакль окончен!
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/) весьма правдивы! 👍 проверено собственными руками на собственной шкуре и в проектах
поюзали 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/) весьма правдивы! 👍 проверено собственными руками на собственной шкуре и в проектах
www.techempower.com
TechEmpower Framework Benchmarks
Performance comparison of web application frameworks using community-contributed test implementations.
пока это будет лишь прототип проекта, имеющего микросервисную архитектуру и возможно позже этот прототип будет переписываться на 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 для определённых задач
потом посмотрим
в зависимости от того какие нагрузки пойдут и как сервис будет держать нагрузку
но, есть несколько очень тонких и важных моментов...
для реализации данного проекта 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 для динамического вывода, идентификации и определения типов данных
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
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
Forwarded from Andrew Bednoff
Keybase.io делают шифрованное облачное хранение, клиент и vfs для этого...
крутяк! 👍
крутяк! 👍
Forwarded from Andrew Bednoff
Keybase mounts end-to-end encrypted folders in /keybase/private
есть приватные с шифрованием и публичные с подписью директории в облачном хранилище
есть приватные с шифрованием и публичные с подписью директории в облачном хранилище
Тут недавно в нескольких чатах прозвучал один и тот же вопрос.
Почему массовый проприетарный софт профессионального назначения (для графического дизайна, полиграфических и издательских систем, и другой популярный профессиональный проприетарный софт) не разрабатывается с учётом поддержки им 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?
У многих это вызывает разочарование в 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.
Не потому что производители этого софта не могут, а потому что это требует усилий которые не окупятся, поэтому производителям софта это не выгодно.
Корпоративность, патенты, соглашения, деньги рулят потому что!
Поэтому в десктоп и мобильном секторе сподвижникам FLOSS и Linux нужно искать новые пути продвижения и монетизации, чтобы занять большую долю рынка.
Главный стратег и основатель Canonical, Марк Шаттлворт, начал продвижение Ubuntu Touch очень грамотно - с поддержки производителями устройств и операторами связи, особенно азиатскими, опытные образцы были отработаны на европейском рынке компанией BQ, девайсы BQ и Meizu с Ubuntu были продемонстрированы в Барселоне на MWC2015 (BQ) и MWC2016 (Meizu), а далее Canonical начала продвижение с азиатско-тихоокеанского региона и его рынков.
Одновременно в Canonical сконцентрировались на конвергенции разработки приложений и интерфейсов для разных типов поддерживаемых устройств, обобщённом графическом сервере Mir для этих целей, системе доставки и развёртывания приложений и обновлений прошивок/дистрибутива на базе системы управления контейнерами Snappy.