Задал вопрос техподдержке Телеграм об ограничениях на количество сообщений

Ребята весёлые, с юмором, шутят, отвечают очень быстро, буквально сразу

Heya! There are no restrictions if I remember correctly, however there is a 1 million message bug, where Telegram will only be able to display up to 1 million messages. This doesn't affect the cloud at all, and 1 million+ messages wil still be inside the cloud. This is a bug we are aware of, We are looking into getting this fixed. I hope this helps!

Sometimes there are examples where server response times drop a wee bit. This could have caused your messages not to load as quickly as you might have expected... Also... if I may, I'm guessing furry?

Увидев статистику и зная, что количество людей использующих Linux в нашей стране намного больше, было решено создать группу для поддержки Linux LoCo (Local Community) в Кыргызстане.
Главным образом группа создана для объединения людей использующих Linux для работы и для решения повседневных задач, для взаимопомощи и оказания поддержки друг другу, для обсуждения технологий и инфраструктурных решений построенных вокруг Linux и FOSS движения - all about Linux and FOSS!

https://telegram.me/KGLUG

Group based on existent chat of highly involved and long-term experienced Linux developers, infrastructure specialists and Linux sysadmins, not only from Kyrgyzstan.
The main target is to create and build vibrant and helpful local community.

Хорошее обсуждение получилось! 👍
В целом все принципы очень хорошо понятны!
Чётко выстраивать зоны ответственности и организационную структуру в проекте, иерархию, если проект крупный.
Сокращать коммуникации и задержки в них - больше самостоятельности локальных групп разработки благодаря чёткому распределению задач и зон ответственности.
Руководствоваться разумом и здравым смыслом! 😄👍

https://www.youtube.com/watch?v=R5m5BsaeB44

Уважаемые подписчики,
поздравляем Вас с праздником Пасхи и с Днем Труда!
Будьте счастливы, берегите себя и близких!

Наша подборка интересных художественных фильмов на майские праздники по IT тематике - про IT технологии и людей специалистов в IT 👍

http://www.kinopoisk.ru/film/301/

http://www.kinopoisk.ru/film/592/

http://www.kinopoisk.ru/film/660/

http://www.kinopoisk.ru/film/849/

http://www.kinopoisk.ru/film/1086/

http://www.kinopoisk.ru/film/3800/

http://www.kinopoisk.ru/film/4134

http://www.kinopoisk.ru/film/4551

http://www.kinopoisk.ru/film/6132/

http://www.kinopoisk.ru/film/13343/

http://www.kinopoisk.ru/film/17463/

http://www.kinopoisk.ru/film/95636/

http://www.kinopoisk.ru/film/103861/

http://www.kinopoisk.ru/film/197532/

http://www.kinopoisk.ru/film/399959/

http://www.kinopoisk.ru/film/427198/

http://www.kinopoisk.ru/film/607152/

http://www.kinopoisk.ru/film/634679/

http://www.kinopoisk.ru/film/635772/

http://www.kinopoisk.ru/film/677798/

http://www.kinopoisk.ru/film/739892/

http://www.kinopoisk.ru/film/779602/

http://www.kinopoisk.ru/film/843103/

http://www.kinopoisk.ru/film/859908/

Поступают интересные разные данные и новости о том, что в следующих версиях Android будет внедрена Java VM на базе OpenJDK, и ART уйдёт как и Dalvik в прошлое.
С другой стороны Google объявили о намерении активного внедрения Swift в разработку под Android - это требует разработки API, интеграции с текущими API NDK/SDK, интеграции LLVM в эту инфраструктуру разработки.
Rust также использует LLVM и активно продвигается под Android компанией Mozilla, а с публичным выходом браузера на Servo layout engine этот процесс только ускорится.
Go также продвигается Google как системный язык разработки приложений, использующий Android NDK.
В общем, всех нас ждёт очень интересное и весьма увлекательное мультиязыковое мобильное будущее! 😄

неделю назад столкнулся с фундаментальным ограничением в JRuby (bottle-neck) при тюнинге производительтности - код поддержки coroutine based fibers оказывается выпилен из JRuby до лучших времён

https://github.com/jruby/jruby/wiki/PerformanceTuning#enable-coroutine-based-fibers

https://github.com/jruby/jruby/wiki/DifferencesBetweenMriAndJruby#continuations-and-fibers

https://github.com/jruby/jruby/wiki/PerformanceTuning#enabling-invokedynamic

https://github.com/jruby/jruby/wiki/JRubyCompiler
https://github.com/jruby/jruby/wiki/StaticCompiler
https://github.com/jruby/jruby/wiki/Testingjrubyinvokedynamic

причина - GC и байт-код JVM не заточены под сопрограммы
при том JRuby запускается в режиме JIT компиляции со включёной опцией invokedynamic
забавность в том что почву для реализации сопрограмм в MLVM для JVM подготовили уже давно, реализовав continuations, а уже на их основе можно кодить coroutines (сопрограммы)

http://openjdk.java.net/projects/mlvm/subprojects.html#StackContinuations

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6655643

http://openjdk.java.net/projects/mlvm/subprojects.html#InvokeDynamic

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6655646

но внедряется это всё крайне медленно, а комьюнити стандарты JSR вырабатываются ещё дольше
такими темпами JVM просто добьют современные фичи, пришедшие из функционального программирования (динамическая типизация, лямбда функции, параметрический полиморфизм, сопрограммы, функции как объекты первого класса, замыкания, анонимные функции) и она загнётся за ненадобностью - разработчики просто уйдут на LLVM, уже уходят, Rust и Swift используют LLVM как оптимизирующий бэкэнд JIT-компилятор

и вот тут я крепко и глубоко задумался о причинах, почему с 2007-го года нет видимых подвижек в реализации continuations и соответственно сопрограмм в JVM
в JVM есть собственная реализация тредов, которая основана на модели акторов
а сопрограммы нужны для реализации парадигмы CSP (Communicating Sequential Processes), что и сделано в Go (goroutines) и его GC
но почему этого же нельзя сделать в стековой машине JVM и её GC, реализовать в байт-коде, для лучшей поддержки возможностей функциональных языков и компиляторов/интерпретаторов для JVM языков с динамической типизацией - это большой вопрос!
неделю, с 24 апреля по 1 мая, изучал проблему, читал литературу, смотрел видео курсы Coursera и всё таки нашёл ответ, докопался до истинной сути!
всё потому что машина стековая и её архитектура (stack-based dynamic memory allocation, управление динамической памятью основанное на использовании стековых структур данных) ограничивает высокоуровневые языки
при реализации сопрограмм проявляется архитектурная проблема функциональных аргументов (funarg, даже не знаю на сколько правильно это можно перевести на русский, информации в русскоязычной литературе об этой проблеме крайне мало) в языках, окружение (трансляторы) которых используют стек как структуру данных для управления памятью и стек вызова (call stack, call/cc) для сохранения контекста функций, вызываемых по цепочке при реализации сопрограмм на низком уровне

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

продолжение следует...

#funarg
#coroutines
#goroutines

В Java 9 Oracle готовится выпустить новый JIT компилятор для JVM на смену HotSpot - GraalVM
Заявлена поддержка всех возможностей Ruby (JRuby+Truffle) и JavaScript (Graal.JS, Node.js), и полная их интеграция со всей инфраструктурой JavaVM

http://openjdk.java.net/projects/graal/
http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html
https://github.com/jruby/jruby/wiki/Downloading-GraalVM
https://github.com/jruby/jruby/wiki/Building-Graal
https://wiki.openjdk.java.net/display/Graal/Instructions
https://github.com/jruby/jruby/wiki/Using-Graal-in-JDK-9-EA-Builds

https://github.com/jruby/jruby/wiki/Truffle
https://github.com/jruby/jruby/wiki/Truffle-FAQ
https://github.com/jruby/jruby/wiki/Developing-with-JRuby-Truffle
https://github.com/jruby/jruby/wiki/JRuby-and-Truffle-Interop
https://github.com/jruby/jruby/wiki/Truffle-Module

https://gist.github.com/smarr/d1f8f2101b5cc8e14e12

JLua+Truffle:
https://github.com/lucasallan/LuaTruffle
http://www.luatruffle.org

ZipPy - fast and lightweight Python 3 implementation built using the Truffle framework
https://bitbucket.org/ssllab/zippy
https://bitbucket.org/ssllab/zippy/wiki/Home

Последнее время много пишут про 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)

Про него столько писали зарубежные СМИ, выдвигали спекулятивные предположения, что он автор 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-ти биткойнов, которая сформировала начальный генезис-блок в базе блокчейн.

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

чем меньше вы следов оставляете и информации испускаете в сети - тем сложнее её связать для установления фактов

поэтому, если бы Крэйг Райт сам не раскрылся и не предоставил доказательства авторства, то это оставило бы пространство для догадок и тайна Сатоши осталась бы тайной

почему в 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

Быстрое руководство в виде code-snippets по языку Solidity для создания смарт-контрактов под EthereumVM в сети криптовалюты Ethereum

https://github.com/adambard/learnxinyminutes-docs/blob/master/solidity.html.markdown