ASUS на Computex 2016, проходящей в столице Тайваня городе Тайбэй (Taipei), родном городе для ASUS, где располагается их штаб-квартира и головной офис, 30 мая на презентации линейки своих обновлённых продуктов показали много очень интересных новинок.
Были представлены три новых фаблета Zenfone 3, Zenfone 3 Delixe и просто огромный, с дисплеем 6.8", Zenfone 3 Ultra, все в алюминиевых (aerospace grade aluminum alloy) uni-body корпусах, а базовая модель Zenfone 3 дополнительно защищена c фронтальной и тыльной сторон стеклами Corning Gorilla Glass 4. Характеристики устройств также впечатляют! Все три устройства оснащены мощными чипсетами Snapdragon от Qualcomm, ёмкими батареями (неизвлекаемыми) и большим количеством ОЗУ и ПЗУ памяти, имеют слот для двух сим-карт (обе активные, благодаря двум независимым радиомодулям, первый c подержкой 2G/3G/4G-LTE, воторой только 2G, всё как и в Zenfone 2), совмещённый со слотом для карты памяти, для которой используется SIM2 сокет (что крайне неудобно на практике), все три модели работают на ОС Android 6.0.1 Marshmallow. Матрицы дисплеев было решено оставить Full HD разрешения для большей энергоэффективности, что вполне разумно, учитывая нагрузку на графическую подсистему чипсетов для обслуживания интерфейсов и графики высоких разрешений.

Zenfone 3 ZE552KL - 5.5", IPS FullHD, Snapdragon 625, up tp 4 GB RAM, up to 64 GB Internal Memory, 3000 mAh Battery

Zenfone 3 Deluxe ZS570KL - 5.7", SAMOLED FullHD, Snapdragon 820, up to 6 GB RAM, up to 256 GB Internal Memory, 3000 mAh Battery

Zenfone 3 Ultra ZU680KL - 6.8", IPS FullHD, Snapdragon 652, up to 4 GB RAM, up to 128 GB Internal Memory, 4600 mAh Battery

Подробнее о характерисиках устройств:
http://www.gsmarena.com/asus_zenfone_3_ze552kl-8106.php

http://www.gsmarena.com/asus_zenfone_3_deluxe_zs570kl-8129.php

http://www.gsmarena.com/asus_zenfone_3_ultra_zu680kl-8130.php

Также представлен ультрабук ZenBook 3 в алюминиевом uni-body корпусе и планшеты Transformer 3 и Transformer 3 Pro.

Самой нашумевшей премьерой стал персональный ассистент, домашний интеллектуальный робот Zenbo!
По виду он похож на iMac на шасси, а название созвучно с именем очень популярного в Японии домашнего робота-собаки Aibo от Sony. 😄 Скоро вероятно следует ожидать пресс-релиз своего домашенго робота от Apple, который возможно будет называться iBo или iBot. 😂
Домашняя робототехника весьма в тренде на Computex и вообще в Тайване.
ASUS предлагает разработчикам присоединяться для развтия экосистемы домашней робототехники - zenbo.asus.com

Также очень заметен тренд на камеры с аппаратной и программной (OIS и EIS) оптической стабилизацией изображения в купе с лазерной и фазовой автофокусировкой.
Именно такими камерами оснащены три новых фаблета Zenfone 3.
На выставке многие смартфоны, любительские и профессиональные камеры, и конечно же action камеры, для любителей экстремального спорта и видеосъёмки (connected sport movement), оснащены матрицами и оптикой с OIS/EIS, а также лазерным вместе с фазовым автофокусом.

#ASUS
#Computex
#Computex2016

Быстрый обзор всей презентации технологических продуктов ASUS на Computex 2016:
https://youtu.be/66mDeW6JLck

Полное видео всей презентации:
https://youtu.be/5hnZ02Zoobg

Презентация робота Zenbo:
https://youtu.be/C_wO4vmG86w

Полный фильм про робота Zenbo и возможности его применения:
https://youtu.be/Gz5bWCna5uM

#ASUS
#Computex
#Computex2016

О наболевшем...
Плазма уже не падает (по крайней мере не так часто, как раньше 😄), зато MATE периодически падает с завершением всех дочерних процессов и вылетает в системную авторизацию.
Очень хорошо падает при запуске HTML5-Video роликов на YouTube в Firefox. 😂
Вероятнее всего у меня это зависит от железа и его поддержки драйверами, в частности от стека ядро - драйвер - кадровый буфер (freamebuffer) - X.org - DM.
Всё из-за утечек памяти в /usr/bin/mate-settings-daemon
И это опять же в стабильной ветке Debian 8.4 Jessie!
Сам MATE пока не так стабилен, но вероятно скоро пофиксят, товарищи из проекта уже в курсе.

PS: Plasma не падает? Как пропатчить KDE под FreeBSD? 😂

#DM

Приветствую!

На этой неделе онлайн митап будет в субботу на тему "Open Source Software". Проведут его @rkononov, @andrcmdr и @kerimdzhanov. Если есть вопросы, просим заполнить форму ниже.

Форма для вопросов: http://goo.gl/forms/8Tf1ihrcAQYqWqU12
Дата: 04.06.2016 в 19:00 (GMT+6)

Будем поговорить, чем помогает проектам принцип открытости и для каких проектов эта модель распространения подходит
Как на этом строить бизнес и зарабатывать реальные деньги
Про свободу распространения софта, лицензию GPL, чем они помогают в сохранении последующей открытости проекта и форков, основанных на коде этого родительского проекта, в защите интеллектуальной ёмкоти проекта (заметьте, не собственности!)
Тема интересная...

Пишите в форму свои вопросы ребята!

У нас был прокол на ранних этапах с неграмотным выбором лицензии для некоторых модулей продукта (BSD - альтруисты, чтоб их за ногу трижды!) и неконтролируемой утечкой нашего кода в другой, закрытый продукт.
Практически это привело к сворачиванию инвестирования и самого стартапа.
У нас был rolling release, как и у многих сейчас, благодаря CI/CD системам и практикам.
Поэтому тут ещё вопрос в релиз-цикле и поставке продукта.
И нужно выбирать адекватную модель распространения и лицензию для этого, чтобы все взаимоотношения оставались в правовом поле, а игнорировать эти вопросы сейчас уже как минимум не профессионально, к примеру инвесторы и юристы с их стороны сейчас внимательно изучают лицензионный и патентный портфель любого интересного им стартапа, во многих инкубаторах есть штатные юристы, т.к. стартаперы о своих правах не думают (думают только о взятых обязательствах на инвестиции 😂), а защита проектов и помощь командам нужна, тем более это ещё и защита коммерческих интересов самого инкубатора!

Как писал Виктор Пелевин: "В наше время любой имидж имеет чёткое коммерческое выражение, даже если он подчёркнуто некоммерческий". 😄

Как мне сказал один очень грамотный человек из инвесторов, он бывший океанограф из aussie и занимался долго изучением экосистемы большого барьерного рифа, на мой взгляд он привёл отличную аналогию:

Сейчас, как и всегда, бизнес это длинная цепочка надбавочной стоимости, обработки и переработки...

Тут вы либо киты и акулы, которые питаются сами кем-то и никого не спрашивают (для таких китов либо GPL либо проприетарные лицензии для акул) 😂

Либо вы коралл, который строит экосистему - очень выгодно быть нынче кораллом и строить что-то своё 😂

Либо вы рыбка, коих большинство, которая чистит китам усы и акулам зубки, пасётся на кораллах и строит бизнес на партнёрстве и сервисе 😂

Но без рыбок никак, они важны, именно такие ловкие рыбки 😂, потребители B2B услуг, организующие свой SMB сервис

Доходчиво объяснил! 😂👍

По части Open Source, коммерческого и проприетарного софта в Linux, а также выбора открытой модели распространения и лицензии GPL Линусом Торвальдсом для проекта Linux, а это самый большой Open Source проект в истории, я буквально недавно постил свои соображения и его интервью на TED - рекомендую пересмотреть и перечитать перед митапом

https://telegram.me/technologique/327
https://telegram.me/technologique/328
https://telegram.me/technologique/329
https://telegram.me/technologique/330

Про многопоточность и сборку мусора (GC) в Go относительно реализаций Python, Ruby, JS и Lua...

Python, Ruby, JS и Lua, как динамически типизированные языки, поддерживающие сопрограммы для поддержки псевдомногопоточности, требуют автоматического управления памятью и сборщика мусора

CPython, PyPy и тем более Jython под JVM - имеют сборщик мусора (GC - garbage collector)
То же касается MRI/YARV, Rubinius, JRuby под JVM, для языка Ruby, V8 (Node.js/IO.js), Nashorn под JVM, для языка Java Script и CLua, LuaJIT для языка Lua

Реальная многопоточность в Python (как и в Ruby, в JS и в Lua) недоступна из-за GIL и боязни авторов эталонных реализаций (CPython, MRI/YARV, V8, CLua) повредить данные в других потоках, т.к. в языке нет адекватных средств и встроенного синтаксиса для простой и ясной работы с потоками, есть только async/await в Python, future/promise в JS/ES6, fibers/call-cc/continuations в Ruby и ключевое слово yield для создания итераторов и генераторов на базе сопрограмм и продолжений (continuations), но это всё не истинная многопоточность, а в лучшем случае green threads управяемые интерпретатором и GC

В Go же используется модель CSP (communicating sequential processes, взаимодействующие ПОСЛЕДОВАТЕЛЬНЫЕ процессы), основанная на модели механизма акторов и развивающая эту идею
Используюется специальный вид сопрограмм (coroutines), которые называются goroutines или go-сопрограммы (игра слов), для создания которых используется ключевое слово go
Go-сопрограммы по модели CSP используют передачу сообщений через каналы в другие go-сопрограммы для организаии многопоточности, многопоточного исполнения, синхронизации между потоками, ожидания приёма и передачи данных через каналы между потоками (go-сопрограммами)
Сами же go-сопрограммы являются потоками green threads (или fibers), которые управляются сборщком мусора (GC) и существуют внутри потока исполнения скомпилированной и запущенной программы на Go

Все эти реализации - Python (кроме Jython под JVM), Ruby (кроме JRuby, использующего Java threads в JVM, которые основаны также на модели акторов, но имеют параллельную природу и весьма сложны при обращении с ними в реальной разработке), JS (кроме Nashorn в JVM), Lua (СLua и LuaJIT) - однопоточны и их интерпретатор выстраивает внутренние потоки (green threads, fibers) в коде, при интерпретации порождаемого им байт-кода, в очередь событий, event loop, организованную на кольцевых буферах, низкоуровнево реализованных на стеке, которую обрабатывает в одном потоке, но асинхронно, поэтому складывается обманчивое впечатление некоторой одновременности выполения разных потоков, но не для машины, а для человека
Для машины же эта последовательность событий с микросекундными разницами в итоге складывается в миллисекунды задержек (latency) при реальном исполнении программы, что непотребно для высоконагруженных проектов

Python, Ruby, JS, Lua - по своей сути внутри интерпретатора имеют объектную природу и любой транслятор этих языков должен содержать GC основанный на алгоритме подсчёта указателей на объекты в памяти, это требование стандартов языков (например PEP в Python)

Поэтому в данных языках если неграмотно организовать работу с переменными и объектами в коде так, что они постоянно используются и не освобождаются после использования, например при помощи интроспекции типов и рефлексии объектов, тогда GC не будет их вычищать, пока имеется хотя бы один указатель-ссылка переменной на объект-контейнер типа данных в памяти
Это приводит к зависшим потокам (green threads), перерасходу и утечкам памяти - память не будет освобождаться GC и потоки (green threads) будут просто висеть в памяти
Такой эффект называется постоянство памяти (persistence of memory) и напоминает одноимённую картину Сальвадора Дали (http://66.media.tumblr.com/67083591376832e41f6955187cbede74/tumblr_o5euotF2r71ugyavxo1_1280.png), где течёт не только память, но и время, что в принципе верно и для программирования, учитывая те же задержки (latency) в GC и интерпретаторах 😆

В Go то же самое с каналами, их нужно освобождать, но в Go с версии 1.5 новый GC написанный на самом Go и работающий на несколько иных алгоритмах, чем простой подсчёт ссылок и он теперь более агрессивно работеат с неактивными потоками и каналами

Нужно учиться программировать без сохранения состояния (stateless) в потоках исполнения - это хорошо подготовит вас к микросервисной разработке на Go с применением контейнеризации (Docker, LXC).