| |
| 2.2, h31 (ok), 00:36, 23/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 В данном случае прослойка - это плюс, так как увеличивает гибкость.
| | |
| |
| 3.4, Толстый (ok), 00:41, 23/11/2011 [^] [^^] [^^^] [ответить]
| +4 +/– |
 С прослойками обычно проблема в том, что они являются наибольшим общим знаменателем всех поддерживаемых систем, а посему довольно ограниченные.
| | |
| 3.6, trdm (ok), 00:59, 23/11/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
 гибкость обычно обратно пропорциональна стабильности.
и последующий оратор тебе насчет гибкости уже сказал, что ты не прав.
| | |
| 3.7, Anonym1 (?), 01:05, 23/11/2011 [^] [^^] [^^^] [ответить]
| +10 +/– | |
> В данном случае прослойка - это плюс, так как увеличивает гибкость.
Ага, самая лучшая прослойка была ODBC... Если еще кто-то это помнит... Одинаково скверная для любого SQL "диалекта" прослойка...
| | |
| |
| 4.22, ананим (?), 11:03, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
как и jdbc, ado.net и тд, и тп
более того, практически любое современное корпоративное ПО по доступу к б/д использует ту или иную прослойку
зыж
2Аноним
>Как? Ещё одна прослойка? Может хватит уже прослоек в линуксах?
а при чём тут линух?
вот в чём проблема то.
| | |
| 4.35, h31 (ok), 18:15, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> В данном случае прослойка - это плюс, так как увеличивает гибкость.
> Ага, самая лучшая прослойка была ODBC... Если еще кто-то это помнит... Одинаково
> скверная для любого SQL "диалекта" прослойка...
Ну это уже проблема ODBC, а не всех прослоек. Задач у Ubuntu One весьма ограниченное количество, это сильно упрощает ситуацию.
| | |
|
|
|
| 1.5, Аноним (-), 00:46, 23/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
> Вместо CouchDB планируется создать собственную прослойку U1DB для синхронизации данных
Реализация этой прослойки будет, конечно же, проприетарной?
| | |
| 1.8, XoRe (ok), 02:49, 23/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Чет ближе к новому году компании потянуло на кардинальные перемены.
То ту подсистему выкинут, то от этой откажутся, то вон ту назовут устаревшей и непотребной.
И бегом писать анонсы о том, какие прекрасные вещи они наваяют взамен.
По факту ничего плохого в этом нет, но тенденция интересная.
| | |
| |
| 2.9, Graved (?), 05:35, 23/11/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
 К ним сотрудники из Фэйсбука не переходили? У тех тоже тяга к инновациям(tm) и постоянная головная боль с DB, ибо пользователей миллионы, серверов сотни и всё такое.
| | |
| |
| 3.20, Andrew Kolchoogin (?), 10:50, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> К ним сотрудники из Фэйсбука не переходили? У тех тоже тяга к
> инновациям(tm)
И у них неплохо получается: видимо, всё-таки кто-то вспомнил про теорему о циркуляции и решил снизить бесполезный расход электроэнергии на излучение электромагнитного поля, подняв напряжение питания с 220 до 440 вольт.
Заказное оборудование быстро окупится.
> и постоянная головная боль с DB, ибо пользователей миллионы, серверов сотни и всё такое.
Ну, это да. Базы данных масштабируются плохо. ;)
| | |
|
|
| 1.12, iZEN (ok), 08:31, 23/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Erlang, на котором написано ядро СУБД, оказался не под силу программистам из Canonical. View-сервер, написанный на языке Си и базирующийся на JavaScript-движке Mozilla Spidermonkey, видимо тоже оказался не под силу JavaScript-программистам из Canonical.
Вывод: мультипарадигменное программирование в одном проекте не работает.
Почему сразу не выбрать NoSQL СУБД, написанную на одном языке программирования — Java?! У Apache их есть.
| | |
| |
| 2.13, namefields (?), 08:59, 23/11/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
изенчик, ты тока не матерись, но накой им на жаве писать? Есть и лучьше решения.
| | |
| |
| |
| |
| 5.36, anony (?), 00:59, 24/11/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
не, просто глупые хомячки везде его пиарят и пропихивают, ничего личного
| | |
|
|
|
| 2.29, letsmac (ok), 13:54, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
 >>Erlang, на котором написано ядро СУБД,
>>написанный на языке Си
>>JavaScript-движке Mozilla Spidermonkey
Осталось еще что-нить на питоне и перле туда написать для полного счастья.
>>Почему сразу не выбрать NoSQL СУБД, написанную на одном языке программирования — Java?!
А чем сама идея LINQ плоха?
| | |
| |
| 3.37, anony (?), 01:00, 24/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Осталось еще что-нить на питоне и перле туда написать для полного счастья.
Perl весьма неплох, как язык в целом, но не здесь, конечно
| | |
|
|
| 1.15, Nomad (??), 10:17, 23/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>отказаться от использования CouchDB из-за нескольких принципиально нерешаемых проблем, связанных с невозможностью обеспечить должный уровнь масштабируемости в системах, обслуживающих запросы от миллионов пользователей.
Подождит-подождите. Она же написана на Erlang! Том самом Erlang, о супермасштабируемости приложений на котором так любят вопить его красноглазые фанатики. Как же так получилося?
| | |
| |
| 2.19, Andrew Kolchoogin (?), 10:40, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Масштабируемость Erlang плоха для больших распределённых систем.
Масштабируемость Erlang хороша для одной маленькой системы с сумасшедшим количеством потоков исполнения.
Erlang -- Ericsson Language -- был разработан с оглядкой на то, что фирма Ericsson производит. А производит она АТС. Вот и представьте, сколько потоков исполнения в АТС, скажем, на 300 000 номеров. Что, Erlang не супермасштабируем?
Идея отказа от синхронизации и работы с сообщениями хороша в том случае, если есть среда передачи этих сообщений с нулевой latency (читай: внутренняя магистраль АТС).
Если у нас Ethernet, всё становится заметно хуже.
| | |
| |
| 3.21, Nomad (??), 11:01, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Во, интересно очень! А скажите, пожалуйста, есть ли смысл делать высоконагруженный сайт на Erlang? Фреймворки вроде есть специализированные. Просто я знаю один стартап, там всё носятся с этой самой масштабируемостью, говорят любые проблемы с нагрузкой можно будет решить втыканием дополнительного сервера. А насколько я вас понял - облом получается, связаны-то они по ethernet будут. Или масштаб не тот, что бы проблем огрести?
| | |
| |
| 4.33, Andrew Kolchoogin (?), 17:26, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Erlang будет плохо работать, если latency для инфраструктуры передачи сообщений велика. Я бы не стал делать что-то на Erlang, если это "что-то" связано Ethernet'ом.
Можно поэкспериментировать с чем-нибудь более вменяемым, например, со связкой OpenMPI -> RDMA -> InfiniBand. Ну, для начала InfiniBand можно заменить на FireWire, он тоже умеет RDMA.
| | |
|
| 3.28, Аноним (-), 13:09, 23/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Что за рассуждения о сферичиском эрланге в вакууме?
CouchDB маштабируется/реплицируется по протоколу http, причем данные передаются в json.
| | |
| |
| 4.34, Andrew Kolchoogin (?), 17:26, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Что за рассуждения о сферичиском эрланге в вакууме?
> CouchDB маштабируется/реплицируется по протоколу http, причем данные передаются в json.
Да-да, всё именно так и есть. Поэтому Erlang плохо и работает. :)
| | |
|
|
| 2.25, Аноним (-), 11:34, 23/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Подождит-подождите. Она же написана на Erlang! Том самом Erlang, о супермасштабируемости
> приложений на котором так любят вопить его красноглазые фанатики. Как же
> так получилося?
И что ? U1DB тоже планируют на Erlang написать. Насколько я понял, проблема не в возможностях CouchDB по одновременному обслуживанию большого числа запросов, а в том, что CouchDB не заточен под ведения огромного числа _разных_ баз. Так как у каждого пользователя своя база, то для каждого пользователя приходится запускать свой экземпляр серверного процесса CouchDB.
| | |
|
| |
| 2.39, develop7 (ok), 15:04, 07/12/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Одобряю, erlang-сервис на десктопе это я считаю перебор.
почему «перебор» именно erlang-сервис?
| | |
|
| 1.31, антоним (?), 16:07, 23/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Лучше бы работу через прокси реализовали. С первых дней обещают, а воз и ныне там.
Does Ubuntu One support access behind proxy servers?
No. We are adding proxy support for some Ubuntu One features in future versions of Ubuntu but users behind proxy servers will currently have issues connecting to a variety of Ubuntu One services including files and contacts sync.
| | |
|
