Сегодня вступил в силу объявленый ранее национальным банком Китая запрет бирж и майнеров в Пекине.
В ближайшее время их запретят по всему Китаю, кроме особой экономической зоны Гонконга.
Все операции по купле-продаже товаров за криптовалюты переводят в Telegram, что конечно плюс для мессенджера и его бот-платформы с payment API.

https://bits.media/news/kitay-zapretil-rukovoditelyam-kriptobirzh-pokidat-stranu/

https://bits.media/news/caixin-vse-kriptovalyutnye-birzhi-pekina-dolzhny-segodnya-obyavit-o-zakrytii/

https://bits.media/news/torgovlya-bitkoynami-v-kitae-perekhodit-v-telegram/

http://www.coinfox.ru/novosti/7647-kitajskoe-bitkoin-kommyuniti-massovo-pereklyuchaetsya-s-wechat-na-telegram

Интереснейшее интервью Валерия Вавилова, основателя BitFury Group, изданию Forbes Russia, полное позитивного предвидения и оптимистичного футуризма в сфере блок-чейн технологий, с рассказом о компании BitFury и её текущих успехах в развитии блок-чейн экосистемы.

http://www.forbes.ru/tehnologii/344801-valeriy-vavilov-bitfury-group-blokcheyn-industriya-na-trilliony-dollarov

Недавно компания BitFury выпустила фреймворк Exonum, написанный на Rust, для создания приватных блок-чейн экосистем и их применения в различных отраслях, государственном секторе и компаниях, где необходимо цифровое управление ценностями.

https://t.me/technologique/1028

Эффективность энергосбережения языков программирования.

https://github.com/greensoftwarelab/Energy-Languages

Эффективность языков программирования можно замерять по различной шкале - безопасность и система типов, эффективность по скорости исполнения кода и потреблению времени CPU, эффективность по потреблению памяти (memory footprint) и автоматическому управлению выделением и освобожением памяти, скорость разработки и количество усилий которые мы программисты на неё затрачиваем.
Но что важнее и как свести все эти характеристики эффективности воедино? Какова корреляция между этими характеристиками эффективности?
Для многих разработчиков сейчас важна их личная эффективность и производительность.
С моей точки зрения такая позиция многих разработчиков крайне эгоистична и эгоцентрична - это "пессимизация" (versus оптимизация) софта.
Я всегда ратовал и радел за эффективность как разработчиков (личную и командную), так и за многогранную оптимизацию софта. И на данный момент есть языки позволяющие писать быстро (RAD) очень эффективные программы.
Для меня важна каждая характеристика эффективности языка и преимущества которые они дают совокупно.
Будучи разработчиком софта для крупномасштабных сверхвысоконагруженных систем для телеком отрасли и операторов связи я всегда полагал, что что самой важной характеристикой языка является энергоэффективность написанных на нём программ.
Это важно как в масштабах предприятия, так и в масштабах страны и нашей планеты в целом.
Энергоэффективность важна как для огромных кластерных ферм, так и для небольших IoT устройств.
Многие технологии выработки электроэнергии по прежнему негативно виляют на загрязнение окружающей среды в которой мы живём и будут жить будущие поколения и наши дети. Многие типы производства энергии и типы систем её хранения (например аккумуляторные батареи) являются грязными в производстве и загрязняют окружающую среду. Альтернативные чистые источники энергии (гелио-энергетика, геотермальная, приливная, ветровая энергетика) не являются более эффективными по выработке энергии, чем загрязняющие или более опасные (например атомные) источники энергии, несущие высокие риски для окружающей среды.
При этом не все датацентры в мире используют чистые источники энергии, а энергоэффективность многих датацентров по прежнему очень низкая (http://www.datacenterknowledge.com/archives/2014/06/02/survey-industry-average-data-center-pue-stays-nearly-flat-four-years).
В эпоху глобализации интернет-сервисов, развития блок-чейн технологий, задачи снижения стоимости выработки электроэнергии, снижения энергопотребления и при этом повышения энергоэффективности, становятся как никогда остро.
Поэтому одной из важнейших характеристик не только аппаратного обеспечения вычислений, но программного обеспечения является его энергоэффективность.

Товарищи из Green Software Lab провели исследование и сравнительный анализ энергоэффективности программ написанных на различных языках программирвания, использующих различные языковые среды исполнения и исполнительные системы (виртульные машины, интерпретаторы, компиляторы), а также провели анализ корреляции энергоэффективности с потреблением процессорного времени, и с эффективностью управления памятью и её потреблением.
За основу взяли разрабатываемые годами тестовые наборы проекта Computer Language Benchmarks Game (http://benchmarksgame.alioth.debian.org).
Результаты получились крайне интересные. Самым энергоэффективным оказался язык Rust и код, порождаемый его компилятором. При том нужно отметить, что в тестах использовались не самые последние версии компиляоров Rust, а также Go.

С результатами можно ознакомиться на сайте и в полном отчёте иследования, код доступен на GitHub:
https://github.com/greensoftwarelab/Energy-Languages

https://sites.google.com/view/energy-efficiency-languages/results

https://sites.google.com/view/energy-efficiency-languages/setup

http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf

Релиз Swift 4.

https://swift.org/blog/swift-4-0-released/

Проблему критических секций (shared mutable memory, shared mutable state) памяти потоков с общим доступом частично решили - https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md

Но полная модель контроля указателей, владений (ownership checker) и заимствований (borrow checker) памяти потоков на базе субструктурной системы типов до сих пор не внедрена и вряд ли будет, т.к. авторы языка не ставят безопасность памяти во главу угла и не отдают данной инициативе приоритет. При этом автор Rust Грейдон Хоар по прежнему работает над системой типов языка Swift в команде по его разработке в компании Apple. Возможно безопасную работу с памятью на базе borrow and ownership checking в субструктурной системе типов языка Rust внедрят и в Swift, но не ранее версии 6 в 2019 году.

https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md

A Rust-like lifetime system would not necessarily be as powerful in Swift as it is in Rust. Swift intentionally provides a language model which reserves a lot of implementation flexibility to both the authors of types and to the Swift compiler itself.

В Swift 5 в следующем году внедрят лишь элементы модели владения (ownership) в рамках стабилизации ABI интерфейсов.

https://github.com/apple/swift-evolution/blob/master/README.md#primary-focus-abi-stability

Memory ownership model. An (opt-in) Cyclone/Rust-inspired memory ownership model is strongly desirable for systems programming and for other high-performance applications that require predictable and deterministic performance. Part of this model was introduced in Swift 4 when we began to enforce exclusive access to memory. In Swift 5 our goal is to tackle the pieces of the ownership model that are key to ABI stability.

#Swift vs. #Rust:

https://medium.com/@itchyankles/memory-management-in-rust-and-swift-8ecda3cdf5b7

http://pcwalton.github.io/blog/2013/03/18/an-overview-of-memory-management-in-rust/

Links:
https://t.me/technologique/1003

Пока что Swift весьма не удобен для разработки и масштабного внедрения в производство софта.

Асинхронности на уровне языка и его испольнительной системы (фронт-энд компилятора для LLVM) нет, безопасности работы с памятью и системными нативными потоками на уровне языка, его системы типов и компилятора тоже нет, зато есть куча сырых библиотек реализующих акторы, сопрограммы, каналы, future/promise паттерн (Grand Central Dispatch, GCD), отложенные ленивые вычисления (теперь и в синтаксисе Swift для ленивых вычислений и отложенных вызовов есть ключевое слово lazy), асинхронные вычисления, неблокирующий ввод-вывод и т.д.

Но стоит внедрить средства асинхронного программирования и работы с сопрограммами на уровне компилятора, отразить эту функциональность на уровне языка, внедрив ключевые слова async/await для асинхронного кода, yield для итераторов, а также реализовать деструкторное освобождение ресурсов памяти (RAII, совместно с существующим механизмом подсчёта ссылок ARC в LLVM) и субструктурную систему типов (линейные, уникальные, аффинные, релевантные/соответствующие и упорядоченные типы) и внедрить с её помощью контроль указателей, контроль владений и заимствований памяти потоков - это будет уже совсем другой язык и отношение к нему будет совершенно иным!

А пока версию Swift можно смело делить на десять для получения реальной, а не маркетинговой, версии языка для применения в продакшене (v4/10=v0.4).

Из механизмов автоматического управления выделением и освобождением памяти в Swift имеется только механизм ARC, реализованный небезопасно (объяснение ниже), и нет механизма RAII - безопасность работы с памятью не ставилась во главу угла при проектировании языка.

В Rust используется несколько комбинированных техник и моделей управления памятью - RAII, ARC и в скором времени добавят GC (возможно аналог Boehm GC с IIRC) для разработки программ в которых нужна сборка мусора.
Всё эти техники совместить лаконично в одном языке действительно непросто, но возможно.

https://www.reddit.com/r/rust/comments/3clqta/what_motivates_the_raii_gc_reference_counting/

This allowed it to feature the large amount of complexity needed to incorporate several different kinds of memory management, which the user can pick-and-choose as appropriate. Rust features reference-counting, raw unsafe memory management, RAII, a novel automatic region-based system for passing around references to data, and in the future it will also feature garbage collection.

В Swift допускается заимствование и множественное владение, что делает возможным перекрёстные указатели друг на друга или на одну и ту же область памяти, что приводит к взаимной блокировке, препятствию сборки мусора и утечкам памяти.
Для пометки таких блоков и указателей есть два ключевых слова weak и unowned и это слабость Swift как языка.
В Swift, как и в Objective-C с некоторых пор, используется ARC (atomic/automatic reference counting), как модель управления памятью и в Swift она реализована не лучшим образом, без обёртывания указателей в типы (boxing model, как Rc и Arc в Rust), в угоду совместимости с Objective-C, такая модель опасна и сложна в ручном кодировании, в компиляции, и только усложняет управление памятью и замедляет код.

Swift пока не гарантирует thread safety, не исключает shared mutable memory/state, null references, в нём нет идиомы контроля заимствований и владений (borrow and ownership checking) при работе с указателями, т.е. нет подструктурной/линейной/аффинной системы типов со строгим контролем типов, и таким образом Swift не предотвращает утечки памяти при подсчёте ссылок, работе механизма ARC с циклическими указателями, т.к. нет borrow & ownership checker, который проверяет все strong и weak references на соответствие и наличие циклических указателей для предоствращения утечек памяти в общей памяти потоков, в критических секциях в многопоточном режиме.

Также в Swift на уровне языка нет поддержки работы с асинхронным неблокирующим вводом выводом, что порождает сейчас те же проблемы, что и при работе с JavaScript/ES5/6/7 - т.н. пирамиду вызовов обработчиков (handler pyramid of doom - call-back/closures hell более известный термин в русскоязычной среде), ситуацию с которыми в JS исправили только недавно, задекларировав в стандарте ES8 нормальную поддержку паттерна futures and promises не на уровне вызова библиотечных функций, а на языковом уровне ключевыми словами async/await, как в Python.

Ссылки на материалы:

Несколько видео с конференций Apple WWDC 2017 и 2016 о языке Swift и его областях применения:

https://youtu.be/3y42Qg6MTvk?t=46m20s

https://youtu.be/zfCZTnEZ6Dw

https://youtu.be/CRX1Zs7tIH0

https://youtu.be/AzesJrOcFDU

https://youtu.be/Jmjlmn0jHbw

Эволюция Swift:
https://github.com/apple/swift-evolution

Многопоточность и модель управления памятью в Swift:
https://www.pluralsight.com/blog/software-development/concurrency-swift-3

https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst#achieving-thread-safety

https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst#implementing-safe-go-lang-style-concurrency

https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst#implementing-actors

Multi-threaded programs in Swift should not break the safety guarantees of the language.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html

"Swift is not yet production ready for server-side cloud infrastructure development".

Крис Лэттнер, автор Swift и LLVM Compiler Toolchain, до ухода из Apple в Tesla Autopilot Software (https://t.me/technologique/686, https://t.me/technologique/748, ныне Крис работает в Google Brain - https://t.me/technologique/1046), рассказал много интересного о будущем Swift на конференции IBM Programming Languages Day (PL Day) 2016, проходившей 5 декабря 2016 года.

Слайды и контекст доклада Криса, "Swift: Challenges and Opportunity for Language and Compiler Research", с конференции PLDay 2016, весьма интересны и заслуживают особого внимания, и их содержание хочется разобрать подробнее:

http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf#page=33 - поддержка ARC - automatic/atomic reference counting

http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf#page=35 - ключевые слова weak и unowned для небезопасных указателей (unsafe pointers) - это слабость языка в shared mutable memory/state программных потоков

http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf#page=45 - заявлена будущая поддержка владений и заимствований (ownership and borrow checker) для защиты памяти в многопоточном режиме

http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf#page=49 - всё очень плохо, нет thread safety и соблюдения целостности памяти, безопасного автоматического управления памятью, нет поддержки многопоточности и асинхронных вызовов на уровне языка!

http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf#page=50 - направления улучшений - преодоление проблем handler "pyramid of doom" и shared mutable state

http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf#page=51 - поддержка многопоточности на уровне языка появится не ранее Swift 5 в 2018 году

http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf#page=52 - предлагается внедрить поддержку асинхронных примитивов в языке для сопрограмм и итерируемых типов, а также для борьбы с "handler pyramid of doom" (i.e. "call-back/closures hell")

http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf#page=54 - возможно всё будет также плохо и в дальнейшем, потому что Mutable shared state (if allowed) could be left inconsistent!

Без нормальной модели поддержки многопоточности и общей памяти (shared mutable memory, shared mutable state), которую не сделали в Swift сразу, про Server API (https://swift.org/server-apis/) и применение этого языка в разработке ПО для серверных облачных инфраструктур - можно забыть, без поддержки безопасной многопоточности это игрушечный язык не соответствующий духу времени и текущим тенденциям в разработке ПО!

На самом деле это многое объясняет, например почему в Google не выбрали Swift одним из языков разработки приложений для Android и выбор был сделан в пользу Kotlin и будущего Kotlin/Native.

Микроархитектуры Zen/Zen 2/Zen 3 и K12 от AMD и будущий выход AMD на рынок мобильных процессоров.

На самых ранних порах существования канала в начале 2016 года я писал про будущие архитектуры мобильных процессоров, которые сейчас стали уже текущими, но у мобильных ARM процессоров (в отличии от мобильных архитектур Intel и AMD) до сих пор нет изменяемого динамически во время работы множителя частоты шины процессора, из-за чего ухудшается энергоэффективность чипов и во многом благодаря чему существует архитектура разделения ядер на домены по частотам, для переключения между доменами и большего энергосбережения - архитектура ARM big.LITTLE.

Тогда же я писал про новую архитектуру ядер K12 (ARMv8-64) и Zen от AMD, которая была запущена в массовое производство только в конце 2016 года и поступила на рынки в начале этого года.
Архитектуры K12 и Zen (процессоры EPYC и RYZEN) разработал Джим Келлер, очень талантливый инженер, автор нашумевшей микроархитектуры K8 (архитектуры Claw Hammer и Sledge Hammer - процессоры Opteron и Athlon-64), в своё время выдвинувшей AMD в лидеры микропроцессорного рынка (как и Zen сейчас), а также соавтор набора инструкций x86-64 (aka AMD64), шины HyperTransport (до сих пор самой быстрой по пропускной способности), архитектуры AMD K7 (процессоры Athlon до поколения K8), процессоров Apple A4 и A5, которые Джим разработал в Apple.
Вновь возвратившись ненадолго в AMD и разработав K12 и новую х86 архитектуру Zen для AMD Джим перешёл в конце 2015 года на работу в Tesla Motors.

И вот сейчас стали известны факты, что бортовые системы электрокаров Tesla будут оснащаться мобильными процессорами K12, которые будут запущены в производство в конце этого или начале следующего года (что также означает возможный выход AMD на мобильный рынок), а машинное зрение автопилотов в будущих моделях будет работать на дискретных процессорах AMD Radeon серии Vega, которая была выпущена в августе, и будущей серии Navi, которая будет запущена в производство в следующем 2018-м году.

Предлагаю вашему вниманию видеозапись беседы с Джимом Келлером на AMD Core Innovation Summit, проходившем в мае 2014 года, которое по прежнему актуально:
https://www.youtube.com/watch?v=oZVBMfgGVb8
(https://www.youtube.com/watch?v=SOTFE7sJY-Q)
Полная запись:
https://www.youtube.com/watch?v=03jto1a1oFY

Links:
https://t.me/technologique/28

Занимаюсь Rust вплотную уже практически три года и понял, что не знаю и никогда не видел его автора, Грэйдона Хоара, в лицо.
Решил поискать - интересно ведь какой он, как выглядит, сколько лет человеку.
В социальных сетях (в Twitter) его фото нет, на GitHub и KeyBase фото нет, на конференциях не выступал (например на Lang Next часто авторы новых языков программирования выступают с докладами и с обсуждениями), записей видео на YouTube с ним нет.
Человек оказался довольно скрытным и в сети его фотографий крайне мало - всего-то две.
Оказалось он далеко не бородатый хакер, типа Кена Томпсона или Дэниса Ричи, как он мне представлялся ранее. 😄

http://venge.net/frances/frances_raftis.html - фото с супругой

https://adainitiative.org/2012/10/13/graydon-hoare-i-donated-because-id-like-to-see-the-culture-change/

https://www.infoq.com/news/2012/08/Interview-Rust

https://keybase.io/graydon

https://github.com/graydon

https://twitter.com/graydon_pub

Его блог:
http://graydon2.dreamwidth.org
http://graydon.livejournal.com

Но то, что я нашёл помимо фото, на его сайте (http://venge.net), позволило мне лучше понять какой он человек, какие базовые концепции были заложены в фундамент Rust и укрепить мою веру в большое будущее Rust.

А нашёл я две презентации - первая от 2010 года, когда проект Rust был официально анонсирован и получил публичную огласку, была непублично выпущена первая версия его компилятора, написанного на OCaml, с применением синтаксических расширений/макросов и рефлексии этого замечательного языка, а вторая от 2012 года, когда была уже публично выпущена первая версия бутстрап компилятора, переписанного на самом Rust.

Даже по духу презентаций, по тому как они написаны, хорошо ощущается какой Грэйдон человек и конечно какой он инженер - он эксперт по концепциям ЯП и инженер очень высокого ранга.
Он очень грамотно и прагматично сочетал в Rust концепции, пришедшие из очень многих языков, чтобы достигнуть цели создания безопасного и удобного в использовании языка для системного программирования и его использования в более широком круге задач. Первоначальные цели были поставлены очень амбициозные - изменить отрасль кардинально, сделать программирование крупномасштабных систем более безопасным - безопасность начинается на уровне ЯП (https://en.wikipedia.org/wiki/Language-based_security).
Боюсь представить чем он сейчас занимается в команде Swift в Apple - скорее всего в Swift 5 в 2018 году мы увидим модель многопоточности и безопасности памяти, модель владений и заимствований (borrow and ownership) для работы с указателями, подобную Rust.

Я остался под большим и очень хорошим впечатлением - очень советую их посмотреть:

http://venge.net/graydon/talks/intro-talk-2.pdf [2010]

http://venge.net/graydon/talks/rust-2012.pdf [2012]

В первой презентации очень хорошо ощущается как прагматично он мыслит, как автор языка и инженер.
Критика существующих языков и решений очень точная - могу подписаться под каждым словом!

Go seems to be barking up a different tree?
–Has coroutines, but kept shared mutable state.
–Has memory safety, but kept null pointers.
–Has unwinding, but no destructors or RAII.
–Has message passing, but no immutability.
–Has some built-in generics, but not in user code.

C++ is well past expiration date:
–Wildly unsafe in almost every way
⦁ Memory unsafe, no ownership policies, no concurrency control at all, can't even keep const values constant.
–Heavily burdened with legacy issues
⦁ Absurd compilation model, weak linkage and module system, nigh-impossible to write tools for.
–Spend more time fighting its weaknesses than seems reasonable.

#Rust

https://habrahabr.ru/post/271789/

В своей первой презентации от 2010 года по первому публичному релизу Rust (http://venge.net/graydon/talks/intro-talk-2.pdf) Грейдон Хоар очень верно отметил:

Go has coroutines, but kept shared mutable state - thread safety и безопасность общей памяти потоков нарушаются.
Есть нулевые указатели и они никак не проверяются - в Kotlin например есть проверка nullable types, т.е. обнуляемых типов благодаря flow-sensitive type system.
Нет деструкторной техники освобождения ресурсов (RAII).
Есть GC, но нет динамики вывода типов во время исполнения (в run-time) и дженериков (обобщённых типов).
Сообщения хоть и передаются синхронно через каналы, но мутабельны.

https://habrahabr.ru/post/338718/

В этом и вся проблема в Go - авторы сделали горутины по образу CSP Чарльза Энтони Хоара, чтобы исключить доступ к общей памяти потоков (shared mutable memory), её повреждение при одновременной записи (shared mutable state), состояние гонки или взаимоблокировки потоков за счёт синхронных сообщений, передаваемых через каналы, а теперь выходит что нужно пользоваться мьютексами для предотвращения повреждения данных в общей памяти потоков при одновременной записи (shared mutable state), потому что параллельные коллекции не предусмотрели.

Rust имеет более широкий спектр применения и скомпилированный им код более безопасен при работе с памятью и вводом-выводом, чем Go - Go более узкоспециализированный язык программирования.
Всё что можно сделать на Go можно сделать и на Rust, но ещё более эффективно, например писать веб-приложения с помощью фреймворка Rocket или веб-серверы на Hyper+Finchers или Tokio.
Но не наоборот - Go не системный язык и например на нём невозможно разрабатывать драйверы или модули ядра, или даже само ядро, когда Rust и это позволяет (проект Redox OS).
При том, что Rust, так же как и Go, и Python, не ограничивает программиста в производительности и скорости написания программ.

#Rust vs. #Go
#Golang

Код серверной части (server-side back-end) мессенджера Wire теперь открыт полностью!

https://medium.com/@wireapp/wire-server-code-now-100-open-source-the-journey-continues-88e24164309c

Это означает, что теперь доступно self-hosted развёртывание серверной части Wire для индивидуальных команд и бизнес клиентов на своих серверных площадках и сетях.

Wire поддерживает практически всё, что должно быть в современном клиенте для обмена информацией - передача сообщений, самоуничтожаемые по таймеру клиентом сообщения, аудио-видео звонки (испольуется WebRTC - DTLS для обмена ключами и аутентификации, SRTP для передачи зашифрованного медиа контента), screen sharing. Все эти возможности поддерживаются как для индивидуальных бесед, так и для групповых, при этом весь контент (текст, аудио, видео, файлы) между участниками передаётся клиентами с их устройств всегда в зашифрованном виде, в любом случае и без исключений.

https://wire.com/en/privacy/

https://wire.com/en/teams/

Качество связи потрясающее и не сравнимо ни с одним другим средством связи через TCP/IP сети - звук кристально чистый, для аудио-видео конференций протокол поддерживает 3D аудио (с использованием гарнитур) и шумоподавление эха в помещении.

https://github.com/wireapp/wire-server - серверная часть, relay анонсер, хранилище DHT таблиц, хранилище аккаунтов и их контента, написаны на Haskell

В мессенджере используется p2p протокол обмена сообщениями Proteus - протокол реализован на Rust, на базе протокола Axolotl (который в свою очередь разработан на базе подобного протокола, используемого в мессенджере Signal):
https://github.com/wireapp/proteus
https://github.com/trevp/double_ratchet/wiki

Все процессы шифрования контента (используется библиотека криптофункций libsodium) происходят строго в хранилище cryptobox на устройстве и далее зашифрованные хранилища могут синхронизироваться клиентами между разными устройствами, в т.ч. с задействованием серверной части:
https://github.com/wireapp/cryptobox
https://github.com/wireapp/sodiumoxide
https://github.com/wireapp/libsodium
https://github.com/wireapp/libsodium-native

Есть мобильные, веб и десктоп приложения (весь исходный код открыт):

https://app.wire.com

https://github.com/wireapp/wire-webapp

https://github.com/wireapp/wire-desktop

https://play.google.com/store/apps/details?id=com.wire

https://wire.com/en/download/

https://get.wire.com

Links:
https://t.me/technologique/939

Must read:
https://medium.com/@wireapp/wire-server-code-now-100-open-source-the-journey-continues-88e24164309c
https://medium.com/@wireapp/open-sourcing-wire-server-code-ef7866a731d5

https://medium.com/@wireapp/speeding-up-crypto-on-wire-desktop-apps-3ff37fc98c3f
https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

https://medium.com/@wireapp/a-step-forward-for-wire-for-linux-52f0538cac15
https://medium.com/@wireapp/get-your-linux-on-999403a1a4fe

https://medium.com/@wireapp/call-security-constant-bit-rate-encoding-and-improving-webrtc-a85be6caa43a
https://medium.com/@wireapp/wire-and-webrtc-2553c01bbd0a

https://medium.com/@wireapp/hello-hd-group-calls-now-in-stereo-978ac2c8e21b
https://medium.com/@wireapp/its-all-in-wire-now-with-screen-sharing-e26805c17f8f
https://medium.com/@wireapp/hello-video-calls-hello-privacy-61a189aec23d

Вся суть логических моделей многопоточности и асинхронного кода на уровне языков программирования.

Пожалуй одно из лучших и наиболее полных современных руководств по сопрограммам, многопоточному и асинхронному коду, из всех найденных за весьма долгое время, на примере Kotlin и в сравнении с другими языками программирования.

https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md

https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md

Серии лэптопов ThinkPad - 25 лет!

5 октября 1992 года IBM выпустила первый лэптоп ThinkPad, но он стал лишь самым первым, положив начало огромной серии моделей, выпускающихся на протяжении 25 лет и поныне компаниями IBM и ныне подразделением Lenovo.

В связи с данным событием Lenovo выпустили юбилейную модель, очень похожую на первый ThinkPad, в особенности раскладкой клавиатуры и классическим логотипом:
https://www.youtube.com/watch?v=4CgoI76_cfg

Unboxing юбилейной модели ThinkPad от Lenovo:
https://www.youtube.com/watch?v=EvDhuXaoL6c

"Future years - future users":
https://www.youtube.com/watch?v=pX9ZKwA-WBA

Links:
https://t.me/technologique/1060
https://t.me/technologique/914
https://t.me/technologique/913
https://t.me/technologique/274
https://t.me/technologique/244

Сегодня мировая премьера фильма "Blade Runner 2049".

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

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

Продолжение истории снятой сэром Ридли Скоттом ещё в 1982 году (http://www.kinopoisk.ru/film/403/).
"Бегущий по лезвию" давно стал классикой мировой научной фантастики и жанра киберпанк.

Обязательно перед просмотром фильма "Blade Runner 2049" найдите и посмотрите оригинальный фильм Ридли Скотта "Blade Runner" 1982-го года.

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

Это определённо один из лучших научно-фантастических фильмов нашего времени и на мой взгляд это один из лучших фильмов, которые я когда либо видел! Действительно стоящий фильм за долгое время и просто нереальная драма!
Очень советую - смотреть обязательно!

Предыдущие материалы по теме:
https://t.me/technologique/1039
https://t.me/technologique/1011
https://t.me/technologique/1062
https://t.me/technologique/968
https://t.me/technologique/653

#киберпанк
#cyberpunk

Все опубликованные материалы по фильму:

https://www.youtube.com/watch?v=7tCeft9dbNE

Сразу скажу - трейлеры и тизеры вообще имеют мало отношения к сюжету самого фильма и обыгрывают абсолютно иную альтернативную версию фильма, придуманную Дени Вильнёвом для возбуждения интереса к картине. Поэтому - готовьтесь быть удивлёнными в кино!