Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

Автор: AlekXL
Дата сообщения: 14.03.2014 08:37

Цитата:
К дельфям нативные библиотеки легко и прозрачно цепляются только на Win32. На всех других платформах будут проблемы.
во-первых, максимальная производительность математики нужна только на декстопе(а не в мобайл).

Что же до других платформ: я сомневаюсь, что так уж трудно подцепить C++ *.so либу, скажем, на ARM. Не специалист в этом вопросе, но что,трудно загрузить библиотеку и вызвать по указателю функцию? Где там может быть трудность? Или для тебя "трудность" -- это динамическое связывание?
Автор: HeMet
Дата сообщения: 14.03.2014 08:50

Цитата:
Где там может быть трудность?

ООП и прочие навороты с++ рантайма.
Автор: deks
Дата сообщения: 14.03.2014 10:16
AlekXL

Сложность во взаимодействии объектных моделей Delphi и ObjC/C++ ну и Android. Дельфи сделана так, что требует врапперов для работы с нативными объектами мобильных платформ, потому как живет в параллельном режиме к рантайму и iOS и Андроида. Такого как было с COM объектами на Win больше нету.
Автор: Frodo_Torbins
Дата сообщения: 14.03.2014 11:09
deks
Не все сразу. Если бы они сразу пытались такое реализовать, то Андроид мы бы увидели в лучшем случае этой осенью.
Плюс лично мне не понятно, как такое сделать, что бы оно при этом было удобно, и не пришлось отказыватся от нативного кода и существующей RTL.
Автор: deks
Дата сообщения: 14.03.2014 15:59
Frodo_Torbins

Пока к теме кросс-платформы есть несколько разных подходов - у дельфей самый категоричный: идем на платформу со своим самоваром, уставом и вообще живем в своей песочнице. То есть, свой GUI, свой RTL, все свое. Платформенное тискаем через врапперы-адаптеры. У ксамаринов тоже врапперы и .NET RTL. Зато GUI биндится к нативным контрольям (как у iCL в дельфях). У ремобджектовского оксигена наблюдается максимальная прозрачность интеропа на платформе (создаем нативные для платформы объекты) плюс кросс-платформенная RTL в виде Sugar, плюс only нативный GUI, плюс какая-то задумка про порт .NET RTL (может, допиливание Sugar?). Но интересно в целом, да, как будут жить и развиваться такие разные подходы) Qt кстати еще есть, ага.

Big17

Цитата:
Так вообще сейчас нет такой универсальной платформы... засилье фрейворков...


Про универсальность я имел ввиду, что раньше на дельфях можно было для Win32 написать любое приложение, хоть драйвер. Любители даже вирусы писали. А сейчас на дельфях для OSX например свою панельку в Системные настройки не напишешь - нету x64. Ну и в Win8 Store не берут дельфовые приложения. И тп
Автор: AlekXL
Дата сообщения: 14.03.2014 16:08
HeMet

Цитата:
ООП и прочие навороты с++ рантайма.

это мелочи. Опытного программиста не остановит. А где нужно -- создаешь COM-подобную обертку, и пользуешься. Конечно, задача посложнее формочки с кнопочкой. Но вызовы можно сделать в тысячи раз быстрее JNI или чего там у first-class java citizens.
Для жабы -- бетонная стена, у нас лишь картонка, которую матерый дельфист вынесет одним ударом. Вплоть до подмены менеджера памяти на дельфийский.
deks


Цитата:
Дельфи сделана так, что требует врапперов для работы с нативными объектами мобильных платформ
ой перестань. Мы не о "нативных" объектах (какая в них к лешему нативность?)

Мы вообще говорим о подключении сторонних высокопроизводительных библиотек C++, большинство которых не заточено под андроид или макось. Там обычно есть очень необременительный интерфейс, к-й требует минимального допиливания под дельфи.


Добавлено:
Frodo_Torbins


Цитата:
Плюс лично мне не понятно, как такое сделать

знаешь, поддержа MS COM технологии в дельфи на голову выше чем в старом VB или каноничном C++ . Почему? Да потому , что был изменен язык и компилятор, чтобы все это поддерживалось наилучшим образом.

Если нам нужен андроид(а похоже, он нам нужен, это всерьез и надолго), то нам нужны маленькие хитрости на стороне компилятора и system.pas .
Автор: deks
Дата сообщения: 14.03.2014 16:38
AlekXL


Цитата:
знаешь, поддержа MS COM технологии в дельфи на голову выше чем в старом VB или каноничном C++ . Почему? Да потому , что был изменен язык и компилятор, чтобы все это поддерживалось наилучшим образом.
 
Если нам нужен андроид(а похоже, он нам нужен, это всерьез и надолго), то нам нужны маленькие хитрости на стороне компилятора и system.pas .


Вот это - святые слова. Вот именно это сделали ремобджекты для Cocoa - ввели nullable types, multipart method names, bridging и тп. Вот поэтому через оксиген работать с Cocoa довольно легко и просто. Вот так же и надо было приходить и дельфи на платформы.


Цитата:
Мы вообще говорим о подключении сторонних высокопроизводительных библиотек C++

Я то лично говорил про подключение нативных библиотек, имея ввиду Objective-C библиотеки на Cocoa и Java на Android ))) Про C++ вопросов не имею, но в моих задачах они не нужны, разьве что для баловства я бы OpenCV покрутил (и то есть ObjC binding).
Автор: Frodo_Torbins
Дата сообщения: 14.03.2014 20:09

Цитата:
Если нам нужен андроид(а похоже, он нам нужен, это всерьез и надолго), то нам нужны маленькие хитрости на стороне компилятора и system.pas .
Джава обьекты + нативные обьекты делфи - как это можно подружить "наилучшим образом"? Даже с учетом хитростей компилятора и прочего, максимум что получится - это удобная, но такая же тормозная как и через чистый JNI, обертка. Можно конечно еще добавить компилятор паскаля в байт-код JVM, и позволить програмисту самостоятельно решать, какая часть его програмы будет нативной, а какая нет. Но взаимодействие между этими частями все-равно будет тормозным. Плюс реализация этой штуки потребует явно больше года.


Цитата:
Зато GUI биндится к нативным контрольям (как у iCL в дельфях).
Ага, и прощай кросплатформеность в один клик. Зачем тогда было создавать делфи? Все варианты попроще уже активно осваиваются конкурентами. Если вам не лень разрабатывать отдельные решения под каждую платформу, и изучать ее рантайм, то для вас есть бесплатная альтернатива в лице FPC.

Ембаркадеровцы заняли пустовавшую нишу максимально легко портируемых предложений и тем самым предоставили любителям паскаля весьма широкий выбор. Теперь каждый может найти инструмент под свой проект.
Разве что WinRT остается за бортом, но его создатели сами железных занавесов понастроили.
Автор: sergionn
Дата сообщения: 14.03.2014 20:46

Цитата:
Ембаркадеровцы заняли пустовавшую нишу максимально легко портируемых предложений и тем самым предоставили любителям паскаля весьма широкий выбор. Теперь каждый может найти инструмент под свой проект.

"Чешутся" руки посмотреть и ОЦЕНИТЬ Вашу программу, созданную этим ИНСТРУМЕНТОМ!
Если ее нет (или она схожего качества с конкурсными демо-"поделками") - тогда призываю не заниматься здесь прикладным словоблудием
- ибо то, что представила упомянутая вами фирма, с космически большой натяжкой можно назвать инструментом, ЭТО больше похоже на ВЫСТАВОЧНЫЙ образец - о нем можно ПИСАТЬ, можно ПОКАЗЫВАТЬ то что он производит, ИНОГДА можно даже это запускать, НО строго на ОГРАНИЧЕННОМ оборудовании и непродолжительное ВРЕМЯ!
Использовать ЭТО в продакшене без СЕРЬЕЗНОЙ доработки НЕЛЬЗЯ!
Поэтому все произнесенные с величественным апломбом лозунги, можно смело оставить при себе, они уже порядком достали!


Добавлено:

Цитата:
Разве что WinRT остается за бортом, но его создатели сами железных занавесов понастроили.

и да, интересный "железный занавес", видимо его НЕ могут преодолеть только "помеченные маркетологией",
а все остальные кроссплатформенно-заинтересованные лица, хоть и логично оставили поддержку WinRT+Windows Phone на потом, но как не странно смогли этот занавес поднять:
http://blog.qt.digia.com/blog/2014/03/05/experimental-version-of-qt-creators-winrt-plugin/
Автор: kaz_av
Дата сообщения: 14.03.2014 22:45
Frodo_Torbins

Цитата:
Ага, и прощай кросплатформеность в один клик.

Ошибаешься. В LCL используются нативные контролы платформы и при этом обеспечивается кроссплатформенность в один клик. Все зависит от того, как это делать. Рисовать самому конечно проще, но за "проще" приходится платить.
Автор: Frodo_Torbins
Дата сообщения: 14.03.2014 23:42
sergionn

Цитата:
и да, интересный "железный занавес", видимо его НЕ могут преодолеть только "помеченные маркетологией",
а все остальные кроссплатформенно-заинтересованные лица, хоть и логично оставили поддержку WinRT+Windows Phone на потом, но как не странно смогли этот занавес поднять
Поднять его смогли только те, кто способен заменить свой родной рантайм на рантайм MS C++ либо .Net. Я не видел ни одного языка, который смог бы пролезть туда со своим рантаймом.


Цитата:
"Чешутся" руки посмотреть и ОЦЕНИТЬ Вашу программу, созданную этим ИНСТРУМЕНТОМ!
Я реалист, и понимаю, что из ниоткуда родить мега технологию невозможно. Но думаю на XE6 уже можно будет начинать делать мобильный клиент, юзеры его давно ждут. Правда посмотреть на него можно будет разве что на скриншотах ибо он корпоративный.
И прошу не капсить, вашей работы я тоже не видел.

kaz_av
Была в LCL попытка заюзать родные контролы, да загнулась, на сколько я знаю. Остались только LCL CustomDrawn, но нативными эти контролы не являются. Под Андроид еще можно на FPC JVM писать, но тогда LCL использовать нельзя.
Автор: kaz_av
Дата сообщения: 15.03.2014 00:00
Frodo_Torbins

Цитата:
Поднять его смогли только те, кто способен заменить свой родной рантайм на рантайм MS C++ либо .Net.

Что-то странное ты говоришь. Если есть возможность запустить нативный код, то какая разница чей это рантайм?


Цитата:
Была в LCL попытка заюзать родные контролы, да загнулась, на сколько я знаю.

Я не про Android говорю, а про десктопные ОС, где используются именно нативные контролы. Но принципиальной-то разницы нет. LCL не поддерживает мобильные ОС просто потому, что официальная поддержка Android в FPC появилась только-только. А так, помимо LCL, энтузиастами уже делаются нативные контролы под Android (на форуме Lazarus даже топик со скриншотами есть). И под iOS тоже, кстати, даже на скриншотах это есть (по ссылке выше). Вот, кстати, иметь customDraw в дополнение к нативным контролам очень правильное решение.
Автор: Frodo_Torbins
Дата сообщения: 15.03.2014 22:06
kaz_av

Цитата:
Если есть возможность запустить нативный код, то какая разница чей это рантайм?
WinRT приложениям запрещено вызывать многие низкоуровневые системные функции (типа VirtualAlloc), за них это должен делать рантайм. Да вот только на данный момент нету способа установить в систему сторонний рантайм. Можно использовать только те, что уже предустановлены.


Цитата:
LCL не поддерживает мобильные ОС просто потому, что официальная поддержка Android в FPC появилась только-только. А так, помимо LCL, энтузиастами уже делаются нативные контролы под Android (на форуме Lazarus даже топик со скриншотами есть). И под iOS тоже, кстати, даже на скриншотах это есть (по ссылке выше).
Это не D.P.F Delphi Android? Они же вроде только делфи поддерживают. Ссылочка была бы очень кстати.
Вообще, первые бинарники под андроид FPC научился делать еще в 2011. Тогда же и LCL начали под него пилить. Но в те времена (2.2) Андроид был слишком плохо развит, и тему с нативными контролами забросили.
Автор: kaz_av
Дата сообщения: 16.03.2014 01:45
Frodo_Torbins

Цитата:
Да вот только на данный момент нету способа установить в систему сторонний рантайм. Можно использовать только те, что уже предустановлены.

В чем, собственно, проблема? Все что требуется от Delphi RTL это осуществлять вызовы низкоуровневых функций не напрямую, а через сишный рантайм/DLL (условно говоря, использовать msvcrt.dll вместо, скажем, kernel.dll). Это не весть какая проблема, если конечно все это дело документировано. Поддержку POSIX они же осилили. Проблема не похожа на техническую, честно говоря.


Цитата:
Это не D.P.F Delphi Android? Они же вроде только делфи поддерживают. Ссылочка была бы очень кстати.

Нет, я не про DPF, я вот про это.


Цитата:
Вообще, первые бинарники под андроид FPC научился делать еще в 2011.

Это была экспериментальная поддержка. С выходом 2.6.4 объявили об официальной поддержке Android, правда с сайта почему-то убрали упоминание об этом.
Автор: Frodo_Torbins
Дата сообщения: 16.03.2014 13:52
kaz_av

Цитата:
Нет, я не про DPF, я вот про это.
Ага, это нечто свежее. Жаль скриншоты не видны без регистрации.


Цитата:
В чем, собственно, проблема? Все что требуется от Delphi RTL это осуществлять вызовы низкоуровневых функций не напрямую, а через сишный рантайм/DLL (условно говоря, использовать msvcrt.dll вместо, скажем, kernel.dll). Это не весть какая проблема, если конечно все это дело документировано. Поддержку POSIX они же осилили. Проблема не похожа на техническую, честно говоря.
Функций, которые требуется так вызывать довольно много. И некоторые из них весьма глубоко закопаны в msvcrt.dll. Короче говоря, это не выход для комерческого продукта.
Если хотите, можете сами Алана Бауэра почитать: https://forums.embarcadero.com/message.jspa?messageID=484819
Автор: sergionn
Дата сообщения: 16.03.2014 14:24

Цитата:
можете сами Алана Бауэра почитать:

не читайте на ночь Алана Бауэра, он редко, но периодически строчит опусы почему сложно сделать то это, то то,
пользуясь фразами маректологов emb при продвижения failmonkey, скажем так:
"пока одни пишут ПОЧЕМУ ЭТО сделать НЕВОЗМОЖНО, другие просто ДЕЛАЮТ ЭТО!"
Автор: kaz_av
Дата сообщения: 16.03.2014 15:03
Frodo_Torbins

Цитата:
Жаль скриншоты не видны без регистрации.

Скопировал парочку: 1, 2


Цитата:
Если хотите, можете сами Алана Бауэра почитать

Это я уже читал. На отмазку больше похоже, общие слова и только. Общий смысл - "yа новой платформе придется работать не так как на Windows, и делать к ней полноценную обвязку". Ну нихрена себе новости. Впрочем, поддержка WinRT не является сколь нибудь важной, учитывая положение самой WinRT. Как бы там нибыло, формальная поддержка еще одной платформы была бы хороша только для маркетологов, а не для нас.

sergionn

Цитата:
пока одни пишут ПОЧЕМУ ЭТО сделать НЕВОЗМОЖНО, другие просто ДЕЛАЮТ ЭТО!

А кто-то уже поддерживает натив на WinRT, помимо МС?
Автор: HeMet
Дата сообщения: 16.03.2014 15:46

Цитата:
пока одни пишут ПОЧЕМУ ЭТО сделать НЕВОЗМОЖНО, другие просто ДЕЛАЮТ ЭТО!

Кто кроме МС уже сделал поддержку WinRT из нативного (для процессора) кода?
Автор: sergionn
Дата сообщения: 16.03.2014 16:26

Цитата:
А кто-то уже поддерживает натив на WinRT, помимо МС?

стоп! про нативную генерацию кода для WinRT я ничего не писал!, акромя грядущей поддержки winrt в qt.
А какая она там будет: нативная или вообще через js мне пофиг!- тема winrt как таковая уже не интересна вообще.......
А писал я про Алена и его периодические выступления как что-то сложно сделать.
Навскидку - вот так он ответил мне год назад на вопрос возможности генерации кода для x86 через llvm:
https://forums.embarcadero.com/thread.jspa?messageID=531114&#531114
всю эту лабуду я расцениваю как отмазки....

p.s. Кстати помните "чувака" Tom Gerdes который покинул emb в районе грандиозного запуска fmx:
http://www.thomgerdes.com/2011/12/writing-hello-world-for-winrt-in-delphi.html
Автор: kaz_av
Дата сообщения: 16.03.2014 17:22
sergionn

Цитата:
стоп! про нативную генерацию кода для WinRT я ничего не писал!
...
А писал я про Алена и его периодические выступления как что-то сложно сделать.

Тогда прошу пардона Неправильно понял твои слова.


Цитата:
http://www.thomgerdes.com/2011/12/writing-hello-world-for-winrt-in-delphi.html

Помню эту демку, да. В общем, экономическую нецелесообразность абракадабра прикрывает словами о технической сложности.
Автор: Frodo_Torbins
Дата сообщения: 17.03.2014 00:23
kaz_av

Цитата:
Помню эту демку, да. В общем, экономическую нецелесообразность абракадабра прикрывает словами о технической сложности.
Попробуйте сейчас эти демки запустить. Уверен, что у вас ничего не получится, так как та система, на которой эти демки тестировались, очень существенно отличалась от релизной. Я не зря предлагал почитать Алана Бауэра. Он писал, что на девелопер превью восьмерки у них тоже все работало почти сходу. А потом, в бете и релизе, МС воздвигла новые стены, и начались проблемы с RTL.


Цитата:
всю эту лабуду я расцениваю как отмазки....
А по-моему человек вполне ясно пишет, что основная работа - это обеспечение нормальной работы дебагера (которой так нехватает Лазарусу). И работа эта весьма серьезная. Основная ее часть конечно уже сделана, но даже сейчас добавить поддержку LLVM x86 это наверняка не две кнопки нажать. И как мне кажется, сейчас это не особо нужно. Пусть лучше потратят свое время на устранение проблем со всем тем зоопарком Андроидов, которые формально поддерживаются уже сейчас. А для x86 Андроидов Интел вон бинарный транслятор придумал, так что вполне возможно, что там Обезьяна и так нормально работает.
Автор: deks
Дата сообщения: 17.03.2014 09:22
Начинаю думать над созданием своего тестового набора приложений, чтобы не спорить про разные технологии. Типа - вышла новая версия - сделал приложение, замерил параметры в профайлере и ок: есть объективные цифры. Пока видел тестовые приложения типа Mandelbrot / hash, но в моей практике нету таких активных мат вычислений. Я больше слоняюсь к клиент-серверу (по нынешним временам видимо HTTP REST client) и что то типа master-detail UI. Примерно ясно как сделать это и на Oxygene Cocoa/android и на Delphi Cocoa/Android. На десктопа не вижу смысла тестить - видимо, любая хрень работать будет при i7 и 16gb памяти то.. Наверное, надо еще ксамарин как платформу добавить. Ну и видимо придумать тестовый кейс для SQLite3 - немного поворочать тестовую БД в локальном режиме. Хостинг тестовых прилад - GitHub. Ну вот такие идеи.

Есть идеи, мысли, предложения по тематике?

Зоопарк тестовых дивайсов - iPhone, iPad mini, nexus 7. Телефона на дроиде нету (как появится Experia Z2 / Z2 mini, то может и будет ). В принципе, дроидовский APK можно загрузить на любой дивайс, а .app желающим потестить придется компилировать руками. А Может, получится заюзать TestFlight
Автор: sergionn
Дата сообщения: 17.03.2014 09:25

Цитата:
А потом, в бете и релизе, МС воздвигла новые стены, и начались проблемы с RTL.


Цитата:
А по-моему человек вполне ясно пишет, что основная работа - это обеспечение нормальной работы дебагера

Уважаемый, а что он ДОЛЖЕН был написать правду: что под моим руководством работают всего 4 аутсорсера из Индии и какие-то 4,5 раздолбая из России, которые не могут довести до ума готовый продукт и которые перед релизом даже не УДОСУЖИВАЮТСЯ "погонять" свои же демки???????????????????? И с такой рабочей силой мы просто физически не можем ничего сделать? А на лучших разработчиков денег не дают, только на маркетологов которые смогут продать любую хрень! Или он должен был написать, что боссы ЗАПРЕТИЛИ мне включать в готовый продукт весь llvm функционал, ибо в следующих версиях предложить БУДЕТ НЕЧЕГО, поскольку изрядно поредевшая команда девелоперов-аутсорсеров сделать ничего НОВОГО не может!

Вы же не в совке живете, НУЖНО начинать относиться ко ВСЕМУ с должным скепсисом, а не СВЯТО верить в то, что напишут функционеры и маркетологи, которым деньги то и платят за то, что одни чего-то не договаривают, а другие говорят, то что не соответствует действительности!


Цитата:
Но думаю на XE6 уже можно будет начинать делать мобильный клиент


Цитата:
так что вполне возможно, что там Обезьяна и так нормально работает.

и опять сорок пять откуда столько ПРЕДПОЛОЖЕНИЙ плавно перетекающих в веру? Мы же не футурологи какие-нибудь, а программисты - сделайте годную программу, а потом рассказывайте всем, что все ок!

p.s. И да Вы же не думаете, что если-бы эмба, как давний партнер мс обратилась бы с просьбой убрать "пресловутые" административные барьеры хотя бы в виде спец-соглашения, то последняя бы ей отказала, учитывая почти полный фейл с популярностью платформы, и необходимостью хоть какой-то "движухи" вокруг winrt и привлечению новых разработчиков на платформу.......

Автор: LGTeam
Дата сообщения: 17.03.2014 10:50
>> Frodo_Torbins, "А для x86 Андроидов Интел вон бинарный транслятор придумал"

не могли бы подробнее?
Автор: kaz_av
Дата сообщения: 17.03.2014 13:44
Frodo_Torbins

Цитата:
Он писал, что на девелопер превью восьмерки у них тоже все работало почти сходу. А потом, в бете и релизе, МС воздвигла новые стены, и начались проблемы с RTL.

Как тут уже правильно сказали, не в интересах МС воздвигать стены вокруг своей платформы, которой и так популярности не хватает.


Цитата:
обеспечение нормальной работы дебагера (которой так нехватает Лазарусу)

А что не так с дебагером в Lazarus? Пользуюсь периодически.
Автор: Arioch1
Дата сообщения: 17.03.2014 13:53
LGTeam intel HAXM

* http://habrahabr.ru/company/intel/blog/146114/
* http://stackoverflow.com/questions/10761696/running-the-new-intel-emulator-for-android
* http://www.javacodegeeks.com/2013/12/android-boost-up-the-android-emulator-speed-up-to-400-on-intel-based-architecture.html
Автор: sergionn
Дата сообщения: 17.03.2014 14:09

Цитата:
intel HAXM

ты пишешь про эмулятор, а речь шла о бинарной трансляции arm кода в x86 для запуске на атомных андроид девайсах - на самом деле решение глючное, спорное и медленное, и "идет" оно в комплекте с самим девайсом в виде либы:
http://blog.apedroid.com/2013/05/binary-translation-vs-native-x86-code.html
а про запуск firemonkey аппов в "боевом" режиме у меня вообще большие сомнения, что это за гибридный уродец получится, учитывая что fmx проги жрут память не по-детски, глючат, и вываливаются даже в благоприятной нативной среде....

Добавлено:

Цитата:
А что не так с дебагером в Lazarus?

я бы задал вопрос иначе - а при чем тут Лазарус ВООБЩЕ, за него не просят полторы штуки зеленых!!!!!!!
Автор: kaz_av
Дата сообщения: 17.03.2014 14:52
sergionn

Цитата:
я бы задал вопрос иначе - а при чем тут Лазарус ВООБЩЕ, за него не просят полторы штуки зеленых!!!

Это уже следующий вопрос. Для начала, неплохо бы узнать, что не так с дебагером в Lazarus.
Автор: sergionn
Дата сообщения: 17.03.2014 17:33
AppMethod
http://www.engadget.com/2014/03/12/appmethod-ide-hands-on/
Автор: SolidSnakeRU
Дата сообщения: 17.03.2014 22:05
Как ведущая нервно тыкает по 10 раз на кнопки)
Оно и понятно, пока приложение отзовется на действие, успеваешь подумать что приложение не работает...

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129

Предыдущая тема: Отмена встречи в Outlook из Excel VBA


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.