IT в России и мире в реалиях мирового кризиса

Цитата: LightElf от 19.02.2018 16:30:47Вы рассматриваете ситуацию в моменте, а надо смотреть в перспективе. Сначала вход туда, где мало конкуренции и клиентов. Там - отладка, демонстрация возможностей и тыды. Потом новый раунд инвестиций и вход в конкурентные области "в силах тяжких". Т.е. избалованному широкополосным интернетом пользователю надо предлагать сразу рабочее решение, а не участие в отладке за свои деньги. А недоверчивым богатеньким буратинам надо не только рисовать красивые графики в пауэрпоинте, но и показывать действующую модель.

Скрытый текст

По поводу бедного населения. Вы исходите из модели "продажа услуг в розницу". Хотя возможно на первых порах она и будет использована, я лично считаю такую модель нежизнеспособной в перспективе. Сбор платы с миллионов пользователей по всему миру мало того что хлопотен и дорог, так еще и подвержен политическому давлению национальных правительств. Ну например ЦБ Китая и Индии запретят платежи в адрес Маска (под любым предлогом) - и два миллиарда потенциальных пользователей пролетают мимо. Потому я предполагаю что будет использована модель "приманить халявой толпу хомячков и продавать их оптом рекламодателям". Такая модель более адекватна международным реалиям сегодняшнего дня.

Иными словами, сначала нужно влить много бабла, что бы получить рабочий продукт. Бабло отобьётся на большой клиентской базе потом. Вопрос, по-прежнему, тот же. На какой клиентской базе оно должно отбиться потом? В местах массового скопления народа оно будет работать плохо (мягко говоря), проигрывая наземным конкурентам вчистую. В остальных местах клиентской базы нет по определению.

Цитата: Lentz от 19.02.2018 16:43:45В местах массового скопления народа оно будет работать плохо (мягко говоря), проигрывая наземным конкурентам вчистую.

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

Цитата: Lentz от 19.02.2018 16:43:45Иными словами, сначала нужно влить много бабла, что бы получить рабочий продукт. Бабло отобьётся на большой клиентской базе потом. Вопрос, по-прежнему, тот же. На какой клиентской базе оно должно отбиться потом? В местах массового скопления народа оно будет работать плохо (мягко говоря), проигрывая наземным конкурентам вчистую. В остальных местах клиентской базы нет по определению.

А вообще, если так подумать, на поездах, на грузовиках, на любом джипе есть место для размещения хорошей антенны.
Если поехать на Ласточке из Москвы в Курск, инет по пути только сотовый. Через полчаса после выезда из Москвы нормальный сотовый инет появляется только рядом с остановками.

Цитата: Поверонов от 19.02.2018 22:22:57Вы пропустили в оригинале было " Смысл NoSQL в отказе от понятия и реализации централизованной транзакции ACID ради ускорения обработки масштабируемости вычислительных ресурсов, когда точностью и непротиворечивостью данных пренебрегают" Дысите глубже.

В каком таком оригинале? В педиквикии, что-ли?
Просто берем документацию на типичную nonsql СУБД BerkleyDB  /usr/share/doc/libdb-devel-doc/programmer_reference/BDB_Prog_Reference.pdf и внимательно читаем с самого начала, что пишут те, кто в базах данных всех собак поел, какими свойствами обладает большинство систем баз данных. Вот перевод на скорую руку:

Цитата3) Обработка транзакций
Транзакция обладает четырьмя свойствами.
Атомарность. Транзакция должна быть выполнена полностью, или не выполнена вообще. Это свойство позволяет, например, единой атомарной операцией осуществить денежный перевод между двумя счетами, уменьшив баланс на одном и увеличив на другом.
Согласованность. Изменения, вносимые транзакцией в базу данных, не должны повредить ее.
Изолированность. Независимо от числа пользователей, одновременно работающих с базой данных, у каждого из них должна быть иллюзия, что никаких параллельных операций над базой данных не выполняется.
Долговечность. Даже если утрачен диск, на котором хранилась база данных, должна быть возможность восстановить ее до состояния после выполнения последней согласованной транзакции.
Сочетание свойств атомарности, согласованности, изолированности и долговечности обычно обозначают сокращением ACID (atomicity, consistency, isolation, durability). Berkeley DB, как и большинство систем баз данных, обеспечивает ACID за счет набора базовых служб.
DB предлагает транзакционную подсистему, которая позволяет полную ACID-защиту процесса записи в базу данных.

ACID – это основные и неотъемлемые свойства любой нормальной БД, иначе она просто не будет выполнять свои две основные функции – доступ к даным и управдение ими.

Смысл не-SQL БД в том, чтобы выбросить лишний уровень – парсер SQL и универсальный планировщик SQL запросов, которые поедают до 90%  процессорного ресурса и столько же памяти, и взвалить эти функции на программиста, который хоть и будет писать приложение кратно дольше, но оно будет работать на порядок быстрее.

Цитата: adolfus от 20.02.2018 01:52:28Смысл не-SQL БД в том, чтобы выбросить лишний уровень – парсер SQL и универсальный планировщик SQL запросов, которые поедают до 90%  процессорного ресурса и столько же памяти, и взвалить эти функции на программиста, который хоть и будет писать приложение кратно дольше, но оно будет работать на порядок быстрее.

В какой СУБД парсер и планировщик жрут 90% процессора и памяти?

Цитата: adolfus от 20.02.2018 01:52:28В каком таком оригинале? В педиквикии, что-ли?
Просто берем документацию на типичную nonsql СУБД BerkleyDB  /usr/share/doc/libdb-devel-doc/programmer_reference/BDB_Prog_Reference.pdf и внимательно читаем с самого начала, что пишут те, кто в базах данных всех собак поел, какими свойствами обладает большинство систем баз данных. Вот перевод на скорую руку:


ACID – это основные и неотъемлемые свойства любой нормальной БД, иначе она просто не будет выполнять свои две основные функции – доступ к даным и управдение ими.

Смысл не-SQL БД в том, чтобы выбросить лишний уровень – парсер SQL и универсальный планировщик SQL запросов, которые поедают до 90%  процессорного ресурса и столько же памяти, и взвалить эти функции на программиста, который хоть и будет писать приложение кратно дольше, но оно будет работать на порядок быстрее.

BerkleyDB неудачный пример. Эта встраиваемая ( embedded ) СУБД просто была недоделанной реляционной ( без SQL API  а с API более низкого уровня )  Купив ее Oracle приделал к ней SQL 
"Oracle added support for SQL in 11g R2 release based on the popular SQLite API by including a version of SQLite in Berkeley DB"
Встраиваемые СУБД часто не имеют сетевого доступа и SQL-оптимизатора так как предназначены для использования внутри единственного приложения с уже оптимизированной под него организацией данных.

Цитата: LightElf от 19.02.2018 16:54:03При полностью сформированной группировке должно получиться весьма нормально и в городах тоже.

Нечем её формировать. 

Даже в 60-е с тогдашней космической лихорадкой никогда больше 150 запусков в год не случалось.
За 2017 год всеми странами было проведено 90 запусков.
Даже количество запусков возрастет обратно до 150, первые запущенные спутники умрут раньше, чем будут выведены последние.
Надеяться на то, что одной ракетой можно вытолкать в одну орбитальную плоскость десяток спутников тоже не надо, спутники немаленькие, Илошка утверждает, что размеры 4x1.8x1.2 метров, плюс солнечные батареи даже в сложенном положении тоже место занимают, а объем отсека полезной нагрузки фиксированный.

Цитата: LightElf от 19.02.2018 16:54:03А уж во всякой "одноэтажной америке" и прочих домиках из бамбука - так вообще отлично.

Я живу в таком домике. У меня D-link DIR-868L со всеми своими смартбимами с первого этажа даже до всех уголков в бейсменте не достает, а это не более 15 метров. Надо репитеры ставить. Про прием со спутника на высоте 1150 километров

без тарелки на крыше и думать нечего. 
Тарелка для приема с низкоорбитальных спутников - это отдельная история.
Передатчик для того, чтобы докричаться до спутника - еще одна отдельная история.
Маршрутизация траффика между спутниками, постоянно движущимися относительно друг друга в разных орбитальных плоскостях - целое отдельное собрание сочинений, особенно если как Илошка трендит, связь между спутниками будет в оптическом диапазоне.
А еще Илошка подал заявку на дополнительные семь с половиной тысяч спутников на орбитах высотой до 350 км, что вообще за гранью абсурда. 

Цитата: LightElf от 19.02.2018 16:54:03А дальше ...

А дальше - тишина. Это если говорить о технической стороне вопроса.
А если о курсе илошкиных акций, тогда крику будет всё больше и больше, пока лохи деньги нести не перестанут, впрочем лох не мамонт, он не вымрет.

Цитата: grizzly от 21.02.2018 00:13:33Даже в 60-е с тогдашней космической лихорадкой никогда больше 150 запусков в год не случалось.
За 2017 год всеми странами было проведено 90 запусков.
Даже количество запусков возрастет обратно до 150, первые запущенные спутники умрут раньше, чем будут выведены последние.

Количество пусков определяется количеством заказов на пусковые услуги,  а те в свою очередь - стоимостью разработки и изготовления самих спутников. Т.е. ни у кого никогда и не было задачи сделать туеву хучу спутников и выпнуть их на орбиту. Соответственно никто и не оптимизировал РН под такую эксплуатацию.

ЦитатаНадеяться на то, что одной ракетой можно вытолкать в одну орбитальную плоскость десяток спутников тоже не надо, спутники немаленькие, Илошка утверждает, что размеры 4x1.8x1.2 метров, плюс солнечные батареи даже в сложенном положении тоже место занимают, а объем отсека полезной нагрузки фиксированный.

Судя по мурзилке на сайте SpaceX высота отсека 13м при диаметре 5м (есть сужение под обтекателем). На первый взгляд 10 штук вполне влезут, и по массе тоже с учетом возврата ступени.

ЦитатаЯ живу в таком домике. У меня D-link DIR-868L со всеми своими смартбимами с первого этажа даже до всех уголков в бейсменте не достает, а это не более 15 метров. Надо репитеры ставить.

В обоих диапазонах? А что анализатор спектра показывает? Может просто соседи засрали частоты. У меня в квартире и на 10 метров работает так себе, но диапазон засран невероятно, видно порядка 40 разных сетей.

ЦитатаПро прием со спутника на высоте 1150 километров без тарелки на крыше и думать нечего.

Ну тарелка в принципе не планируется - там обещается ФАР, что позволяет сделать слежение за спутником программным путем.

ЦитатаПередатчик для того, чтобы докричаться до спутника - еще одна отдельная история.

До спутника на ГСО нормально достукивается передатчик с мощностью в 1Вт (в Ku диапазоне, с тарелкой примерно полметра диаметром), а там как бы совсем другие расстояния.

ЦитатаМаршрутизация траффика между спутниками, постоянно движущимися относительно друг друга в разных орбитальных плоскостях - целое отдельное собрание сочинений, особенно если как Илошка трендит, связь между спутниками будет в оптическом диапазоне.

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

ЦитатаА еще Илошка подал заявку на дополнительные семь с половиной тысяч спутников на орбитах высотой до 350 км, что вообще за гранью абсурда.

Столбит частоты в V-диапазоне. Вполне логично, если конечно действительно собирается обсуждаемую систему создавать.

ЦитатаА если о курсе илошкиных акций, тогда крику будет всё больше и больше, пока лохи деньги нести не перестанут, впрочем лох не мамонт, он не вымрет.

SpaceX пока на IPO не выходила и вроде не планирует в ближней перспективе. А лохи - у них судьба такая, все равно разведут на что-нибудь: кока-колу, новый айфон, пирсинг или наркоту. Развести лохов на финансирование космических исследований - явно не самый худший вариант.

Цитата: LightElf от 21.02.2018 12:55:18Количество пусков определяется количеством заказов на пусковые услуги,

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

Цитата: LightElf от 21.02.2018 12:55:18Т.е. ни у кого никогда и не было задачи сделать туеву хучу спутников и выпнуть их на орбиту. Соответственно никто и не оптимизировал РН под такую эксплуатацию.

Никто также не оптимизировал под такую эксплуатацию упомянутые космодромы и в обозримом будущем их количество существенно не увеличится.

Цитата: LightElf от 21.02.2018 12:55:18Судя по мурзилке на сайте SpaceX высота отсека 13м при диаметре 5м (есть сужение под обтекателем). На первый взгляд 10 штук вполне влезут, и по массе тоже с учетом возврата ступени.

Раз Вы хотите одной ракетой вытолкнуть несколько спутников на одну и ту же орбиту, но чтобы они находились на определенном расстоянии друг от друга, а в илошкином случае это порядка 950 км, придется оснащать спутники еще и маневровым блоком. Орбита не шоссе, это только в "Гравитации" всё легко с одного пинка летит в нужную сторону, а по жизни для перехода по одной и той же орбите на сотни километров надо совершить ряд маневров, для людей, незнакомых с астродинамикой, совсем неочевидных.
Эти маневровые блоки съедят места и полезной нагрузки. К тому же вплотную их не установишь. Так что вряд ли больше 4-5 спутников влезет.
И пятому придется добираться до своего места почти 4 тысячи км.
Всё это относится к этапу начального развертывания. По мере выхода спутников из строя, а они будут это делать в непредсказуемом порядке, надо будет возобновлять группировку и вот тут выводить придется по одному.

Цитата: LightElf от 21.02.2018 12:55:18Может просто соседи засрали частоты. У меня в квартире и на 10 метров работает так себе, но диапазон засран невероятно, видно порядка 40 разных сетей.

В радиусе 50 м от меня пять соседей, так что засрать они ничего особо не могут. 

Цитата: LightElf от 21.02.2018 12:55:18Ну тарелка в принципе не планируется - там обещается ФАР, что позволяет сделать слежение за спутником программным путем.

Обещания обещать Илошка мастер, печаль в том, что чем больше текущая диаграмма направленности отклонена от перпендикуляра к плоскости антенны, тем хуже чувствительность. Кстати, слежение за низкоорбитальными спутниками - это то еще удовольствие. Рядовому потенциальному потребителю масконета такое оборудование совершенно точно не по карману, тем более где-нибудь в глуши.

Цитата: LightElf от 21.02.2018 12:55:18Подробностей на эту тему я не видел, но предполагаю что оптика только для связи между спутниками в одной орбитальной плоскости, по сути простое оптической кольцо. Маршрутизация между кольцами скорее всего через наземные станции.

Подробностей никто не видел, иначе возникнет слишком много вопросов. Получается, каждый спутник должен тащить две системы связи, одну оптическую и вторую обычную радио и их как-то сопрягать надо.  Тут я профан, не буду заниматься спекуляциями.
Для оптической связи надо весьма точно направлять луч на приемник, что влечет за собой кучу последствий, в частности требования к точности системы управления ориентацией самого спутника. Если лазер(ы) жестко смонтированы в корпусе спутника, значит надо поддерживать ориентацию самого спутника, чтобы на расстоянии почти тысячи км попадать лучом (даже с учетом его расходимости) в цель размером десяток метров, координаты которой надо знать как минимум с такой же точностью. При этом любые шевеления солнечных батарей в сторону Солнца, да даже просто колебания батарей в силу их ненулевой упругости эту самую ориентацию будут сбивать и системе придется это всё отрабатывать. А чем? Какие исполнительные органы есть у илошкиных спутников? Электромаховичные двигатели, гиродины, двигатели ориентации? Это все весит, жрет энергию, имеет свои ограничения, а движки расходуют невосполнимое рабочее тело. И все эти удовольствия в 390 кг массы? Короче, там технических вопросов на книгу хватит и это только у меня с моим всего-то 5-летним опытом работы в этой области, настоящие спецы зададут вопросов кратно больше, а ответов Илошка не даст, не дурак же он в самом деле.

Цитата: LightElf от 21.02.2018 12:55:18Столбит частоты в V-диапазоне. Вполне логично, если конечно действительно собирается обсуждаемую систему создавать.

А спутники из 7-тысячной заявки на орбите высотой 340 км будут иметь срок жизни года полтора, всю группировку придется обновлять раз в полтора года, это пиздец абсурд, надо запускать около сотни в день на фазе поддержания группировки, в начальный период надо будет раза в 3 больше как минимум.
 
Так что столбить для перепродажи Илошка точно собирается, принимать предварительные заказы как на Рowerwall и теслу модель 3, с предоплатой, скорее всего попробует, а создавать? Не верю, ну разве что если он рептилоид и за Луной у него прячется космический флот вымпелов в 500, тогда потянет.

Цитата: Поверонов от 20.02.2018 10:14:41BerkleyDB неудачный пример. Эта встраиваемая ( embedded ) СУБД просто была недоделанной реляционной ( без SQL API  а с API более низкого уровня )  Купив ее Oracle приделал к ней SQL 
"Oracle added support for SQL in 11g R2 release based on the popular SQLite API by including a version of SQLite in Berkeley DB"
Встраиваемые СУБД часто не имеют сетевого доступа и SQL-оптимизатора так как предназначены для использования внутри единственного приложения с уже оптимизированной под него организацией данных.

BerkleyDB – наверное самая лучшая nosql (пока оракл ее не убил еще). Вот список вещей, которые сложно найти вместе у других:
1) поддержка вторичных ключей.
2) транзакции вдоль (по записям одной "таблицы") и поперек (по группе "таблиц")
3) курсоры
Токийский шкаф, например, вторичные ключи не умеет,а без них ничего серьезного нельзя написать.
Что касается термина "встраиваемая", то он означает тот факт, что BDB можно использовать в таком режиме, но не означает, что это ее единственный или основной режим использования. Ничто не мешает ее использовать в модели "клиент-сервер".
BDB поддерживает исчерпывающий набор атомарных операций над базой данных, вторичные ключи, блокировки и транзакции. Собственно, это тот самый набор атомарных операций, который присутствует во всех без исключения СУБД. Вопрос лишь в том, что и как раализовано поверх этого множества, и доступен ли этот набор на прикладном уровне. В т.н. реляционных БД он недоступен, в nosql – это основной интерфейс. Поверх него никто не мешает разработать протокол обмена между сервером и клиентами, написать свой сериализатор запросов и вперед.
У оракла есть своя NoSQL (ЕМНИП), котроую они двигают на место BDB, так вот там в документации все подробно расписано, когда следует использовать SQL, а когда "add-get-put-del".  SQL нгезаменим только в ожном случае, когда схема данных меняется клиентами в процессе текущего штатного функционирования системы. Т.е. когда от пользователей идет непрерывный поток запросов alter table. Во всех остальных случаях имеет смысл обратить внимание на nosql  СУБД. В 95% случаев система будет кратно шустрее и меньше жрать ресурсов. Разного рода склады и прочая логистика отлично живут себе на nonsql.

Цитата: adolfus от 22.02.2018 01:25:49BerkleyDB – наверное самая лучшая nosql (пока оракл ее не убил еще). Вот список вещей, которые сложно найти вместе у других:
1) поддержка вторичных ключей.
2) транзакции вдоль (по записям одной "таблицы") и поперек (по группе "таблиц")
3) курсоры
Токийский шкаф, например, вторичные ключи не умеет,а без них ничего серьезного нельзя написать.
Что касается термина "встраиваемая", то он означает тот факт, что BDB можно использовать в таком режиме, но не означает, что это ее единственный или основной режим использования. Ничто не мешает ее использовать в модели "клиент-сервер".
BDB поддерживает исчерпывающий набор атомарных операций над базой данных, вторичные ключи, блокировки и транзакции. Собственно, это тот самый набор атомарных операций, который присутствует во всех без исключения СУБД. Вопрос лишь в том, что и как раализовано поверх этого множества, и доступен ли этот набор на прикладном уровне. В т.н. реляционных БД он недоступен, в nosql – это основной интерфейс. Поверх него никто не мешает разработать протокол обмена между сервером и клиентами, написать свой сериализатор запросов и вперед.
У оракла есть своя NoSQL (ЕМНИП), котроую они двигают на место BDB, так вот там в документации все подробно расписано, когда следует использовать SQL, а когда "add-get-put-del".  SQL нгезаменим только в ожном случае, когда схема данных меняется клиентами в процессе текущего штатного функционирования системы. Т.е. когда от пользователей идет непрерывный поток запросов alter table. Во всех остальных случаях имеет смысл обратить внимание на nosql  СУБД. В 95% случаев система будет кратно шустрее и меньше жрать ресурсов. Разного рода склады и прочая логистика отлично живут себе на nonsql.

Так в том то и смысл субд, что в ней работают все сотрудники, онлайн. У нас около сотни линейных процессов и более 4 миллионов событий за год .

Цитата: mark.76 от 22.02.2018 02:55:53Так в том то и смысл субд, что в ней работают все сотрудники, онлайн. У нас около сотни линейных процессов и более 4 миллионов событий за год .

Что такое "линейный процесс?"
Что представляет собой "событие"?

Цитата: adolfus от 22.02.2018 01:25:49BerkleyDB – наверное самая лучшая nosql (пока оракл ее не убил еще). Вот список вещей, которые сложно найти вместе у других:
1) поддержка вторичных ключей.
2) транзакции вдоль (по записям одной "таблицы") и поперек (по группе "таблиц")
3) курсоры
Токийский шкаф, например, вторичные ключи не умеет,а без них ничего серьезного нельзя написать.
Что касается термина "встраиваемая", то он означает тот факт, что BDB можно использовать в таком режиме, но не означает, что это ее единственный или основной режим использования. Ничто не мешает ее использовать в модели "клиент-сервер".
BDB поддерживает исчерпывающий набор атомарных операций над базой данных, вторичные ключи, блокировки и транзакции. Собственно, это тот самый набор атомарных операций, который присутствует во всех без исключения СУБД. Вопрос лишь в том, что и как раализовано поверх этого множества, и доступен ли этот набор на прикладном уровне. В т.н. реляционных БД он недоступен, в nosql – это основной интерфейс. Поверх него никто не мешает разработать протокол обмена между сервером и клиентами, написать свой сериализатор запросов и вперед.
У оракла есть своя NoSQL (ЕМНИП), котроую они двигают на место BDB, так вот там в документации все подробно расписано, когда следует использовать SQL, а когда "add-get-put-del".  SQL нгезаменим только в ожном случае, когда схема данных меняется клиентами в процессе текущего штатного функционирования системы. Т.е. когда от пользователей идет непрерывный поток запросов alter table. Во всех остальных случаях имеет смысл обратить внимание на nosql  СУБД. В 95% случаев система будет кратно шустрее и меньше жрать ресурсов. Разного рода склады и прочая логистика отлично живут себе на nonsql.

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

Цитата: grizzly от 22.02.2018 00:57:50Раз Вы хотите одной ракетой вытолкнуть несколько спутников на одну и ту же орбиту, но чтобы они находились на определенном расстоянии друг от друга, а в илошкином случае это порядка 950 км, придется оснащать спутники еще и маневровым блоком. Орбита не шоссе, это только в "Гравитации" всё легко с одного пинка летит в нужную сторону, а по жизни для перехода по одной и той же орбите на сотни километров надо совершить ряд маневров, для людей, незнакомых с астродинамикой, совсем неочевидных.
Эти маневровые блоки съедят места и полезной нагрузки. К тому же вплотную их не установишь. Так что вряд ли больше 4-5 спутников влезет.
И пятому придется добираться до своего места почти 4 тысячи км.
Всё это относится к этапу начального развертывания. По мере выхода спутников из строя, а они будут это делать в непредсказуемом порядке, надо будет возобновлять группировку и вот тут выводить придется по одному.

Не возьмусь прикидывать требуемые орбитальные маневры, но исходный посыл "спутники разбегаются из одной точки" мне как-то не очевиден. Носитель может двигаться ниже целевой орбиты (и соответственно быстрее) и сгружать спутники по-одному. Далее спутник может подняться своим ходом на целевую орбиту. Маневровый блок у них по определению есть, т.к. NASA требует  отработавшие спутники ронять на землю.
Орбитальный резерв тоже изначально предусматривается, так что совсем по одному выводить не придется.

ЦитатаВ радиусе 50 м от меня пять соседей, так что засрать они ничего особо не могут.

Надо смотреть чего там в спектре происходит. В промзоне (где не засрано) обычная точка на 2,4ГГц спокойно пробивает более 100 метров. 

ЦитатаОбещания обещать Илошка мастер, печаль в том, что чем больше текущая диаграмма направленности отклонена от перпендикуляра к плоскости антенны, тем хуже чувствительность. Кстати, слежение за низкоорбитальными спутниками - это то еще удовольствие. Рядовому потенциальному потребителю масконета такое оборудование совершенно точно не по карману, тем более где-нибудь в глуши.

Для ФАР это не совсем так, насколько я ничего не понимаю. Чувствительность под углом конечно снижается, но не так драматично. Всякие атмосферные явления больше влияют. Да и следить за спутником с помощью ФАР, на первый взгляд, не особо сложно - никакой механики, сугубая электроника. Конечно разработка ее не фунт изюма, но изготовление в серии не думаю что дорого.
Вот тут есть мурзилка по связным ФАР близких частотных диапазонов https://www.mics.ece.vt.edu/co…2isscc.pdf

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

Там четыре системы связи: спутник-клиент, спутник-спутник, спутник-наземный гейт и спутник-станция управления.

ЦитатаДля оптической связи надо весьма точно направлять луч на приемник, что влечет за собой кучу последствий, в частности требования к точности системы управления ориентацией самого спутника. Если лазер(ы) жестко смонтированы в корпусе спутника, значит надо поддерживать ориентацию самого спутника, чтобы на расстоянии почти тысячи км попадать лучом (даже с учетом его расходимости) в цель размером десяток метров, координаты которой надо знать как минимум с такой же точностью. При этом любые шевеления солнечных батарей в сторону Солнца, да даже просто колебания батарей в силу их ненулевой упругости эту самую ориентацию будут сбивать и системе придется это всё отрабатывать. А чем? Какие исполнительные органы есть у илошкиных спутников? Электромаховичные двигатели, гиродины, двигатели ориентации? Это все весит, жрет энергию, имеет свои ограничения, а движки расходуют невосполнимое рабочее тело. И все эти удовольствия в 390 кг массы? Короче, там технических вопросов на книгу хватит и это только у меня с моим всего-то 5-летним опытом работы в этой области, настоящие спецы зададут вопросов кратно больше, а ответов Илошка не даст, не дурак же он в самом деле.

Управляемая в двух плоскостях головка с оптикой и лазер со световодом в передатчике. Матрица фотодиодов в приемнике (один полноценный для приема данных по центру и 4-8 штук более тупых вокруг). Узкополосный радиоканал по которому приемник командует передатчику "майна-вира" - я бы с чего-то такого начал .

ЦитатаА спутники из 7-тысячной заявки на орбите высотой 340 км будут иметь срок жизни года полтора, всю группировку придется обновлять раз в полтора года, это пиздец абсурд, надо запускать около сотни в день на фазе поддержания группировки, в начальный период надо будет раза в 3 больше как минимум.

Нигде не говорилось, что спутники такие же. За счет V-диапазона можно заметно уменьшить габариты антенн, а за счет высоты орбиты  - мощность передатчика. Так что спутники возможно могут быть поменьше и полегче.

ЦитатаТак что столбить для перепродажи Илошка точно собирается, принимать предварительные заказы как на Рowerwall и теслу модель 3, с предоплатой, скорее всего попробует, а создавать? Не верю, ну разве что если он рептилоид и за Луной у него прячется космический флот вымпелов в 500, тогда потянет.

Столбить частоты на продажу нельзя. Если в установленные сроки система не развернута - частоты просто отнимут и все.

Цитата: adolfus от 22.02.2018 01:25:49Во всех остальных случаях имеет смысл обратить внимание на nosql  СУБД. В 95% случаев система будет кратно шустрее и меньше жрать ресурсов. Разного рода склады и прочая логистика отлично живут себе на nonsql.

Боже, развели тут полемики...
У меня тут в соседнем кабинете DBA отдел сидит, трем за жизнь в курилке. Так вот, чтобы понимать, как оно унутрях работает и зачем оно вообще надо - нужно знать немножко истории. Ибо ничто зазря не появляется.
adolfus, вы просто не понимаете, что кроется под термином nosql. Это не "No SQL", а "Not Only SQL". 
Так вот, NOSQL базы родились по одной единственной причине. В один прекрасный момент одна железка тупо уперлась в производительность по записи. Если у вас большое количество "пользователей" много пишут/изменяют в базе, вы не можете гарантировать согласованность данных после разноса на разные железки. Технически невозможно - упираемся в сеть/процессор/доступ к данным. А распилить на много железок - можно, но в ограниченом виде ака репликация, общая хранилка и т.д. И все эти методы не подходят для какого-нить гугла.
Потому все NOSQL базы жертвуют согласованностью данных.
Заменяется она на "согласованность в конечном счете". Если базу ее не нагружать - со временем данные станут согласованными.
Надеюсь понятно, что в ваше "во всех остальных случаях" попадают ВСЕ случаи, когда при запросе нужно получить истинный ответ? NOSQL применим и применяется только в проектах типа того же гугла - когда прилетает огромное количество разнообразных запросов на изменение данных и обработать их, не жертвуя согласованностью физически невозможно.
Рекламируемая Вами BerkeleyDB представляет собой простой ассоциативный массив ключ-значение. Фактически - та же таблица из двух столбцов ключ-значение. Со всеми вытекающими отсюда особенностями. Плюсы-минусы такого ограничения есть, но боюсь что минусы очень многих не устроят. И да, BerkeleyDB никаким боком не относится к NOSQL.

Цитата: mark.76 от 22.02.2018 02:55:53Так в том то и смысл субд, что в ней работают все сотрудники, онлайн. У нас около сотни линейных процессов и более 4 миллионов событий за год .

Счастливчики...
Самая толстая MySQL база из наших - больше 10 терабайт, многие тысячи запросов в секунду... Проблемы с производительностью бывают, но очень редко и только по причине всяких очень "умных" пользователей БД.

Цитата: Andrew Carleet от 23.02.2018 02:31:39Загадкой назвать это сложно, скорее тест. Тут либо знаешь, либо нет.

Итак, для чего применяется это устройство в компьютерах SUN Microsystems?


Подсказка: Для него даже есть специальное место в корпусе.

В сановских блейдах такого не было 100%
В sunfire тоже такого не помню в тех моделях, что сталкивался.
Так что это совершенно не обязательный атрибут sun.
 
Ну а так эта штука с вероятностью в 90% предназначена для нажатия скрытых кнопок, типа кнопки извлечения диска в дисководе.
Ну а так, могли запихнуть что угодно, вон HP в своё время держала звёздочкообразный ключ в корпусах некоторых серверов.

Цитата: Andrew Carleet от 23.02.2018 02:31:39Загадкой назвать это сложно, скорее тест. Тут либо знаешь, либо нет.

Итак, для чего применяется это устройство в компьютерах SUN Microsystems?


Подсказка: Для него даже есть специальное место в корпусе.

Могу предположить, что этой фиговиной нажимается Reset.

Цитата: Podli от 22.02.2018 17:28:54adolfus, вы просто не понимаете, что кроется под термином nosql. Это не "No SQL", а "Not Only SQL".

У Вас ретроактивное понимание термина. Nosql появился задолго до твиттера, гугля и прочей бигдаты и никакого отношения не имеет к хештегу #NoSQL, именно который есть этот Ваш "Not only SQL". Но #NoSQL -- это не NoSQL.
Процитирую из одной умной книги: "Целью реляционной модели было скрыть детали реализации под более ясным интерфейсом" (конец цитаты).
NoSQL – это то, что лежит под этим самым "ясным интерфейсом" и дает программисту реально неограниченные возможности, поскольку не заставляет его думать в терминах реляционной модели. 

Цитата: adolfus от 02.03.2018 03:34:19У Вас ретроактивное понимание термина. Nosql появился задолго до твиттера, гугля и прочей бигдаты и никакого отношения не имеет к хештегу #NoSQL, именно который есть этот Ваш "Not only SQL". Но #NoSQL -- это не NoSQL.
Процитирую из одной умной книги: "Целью реляционной модели было скрыть детали реализации под более ясным интерфейсом" (конец цитаты).
NoSQL – это то, что лежит под этим самым "ясным интерфейсом" и дает программисту реально неограниченные возможности, поскольку не заставляет его думать в терминах реляционной модели. 

Во-первых, NoSQL не дает неограниченных возможностей. Основные преимущества: гибкая схема модели данных с возможностью изменения в любой момент (в базе данных вы не сможете просто так удалить колонку из таблицы с миллиардом записей) и иногда чуть большая производительность.
Во-вторых, она действительно не заставляет его думать в терминах реляционной модели. Но почему-то часто программисты используя NoSQL выкидывают проработку модели данных вообще (а зачем? потом поменяем в любой момент). Это всегда вылазит боком.

Цитата: Oleg K. от 02.03.2018 11:37:05Во-первых, NoSQL не дает неограниченных возможностей.

Согласен, перегнул немного. Неограниченные возможности дает только чистый (bare) ISAM + ACID.  И тут ... барабанная дробь.... на сцене появляется Berkeley DB, у которой именно это в наличии в чистом виде, плюс вторичные индексы (secondary databases), обновляемые автоматически. Хотя никто не мешает актуализацию индексов устроить по своему разумению.