Симонов Сергей : другие произведения.

Комментарии: Электронная периферия, связь, принтеры, и т.п
 ()

Самиздат: [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь|Техвопросы]
  • © Copyright Симонов Сергей (gann.lector@yandex.ru)
  • Размещен: 15/10/2014, изменен: 15/10/2014. 0k. Статистика.
  • Глава: Фантастика
  • Аннотация:
    Отрывок преобразован в тему для обсуждения. Текст отрывка внесен в основной файл книги как глава 23
  • ОБСУЖДЕНИЯ: Фантастика (последние)
    19:40 Коркханн "Угроза эволюции" (873/47)
    19:38 Кротов С.В. "Чаганов: Война. Часть 4" (280/25)
    19:21 Энвэ М. "Некуда бежать, негде спрятаться " (220/1)
    19:15 Родин Д.М. "Князь Барбашин 3" (835/10)

    Добавить комментарий Отсортировано по:[убыванию][возрастанию]
    Текущее Страниц (26): 1 ... 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Архивы (2): 1 2
    ОБЩИЕ ГОСТЕВЫЕ:
    19:17 "Форум: Трибуна люду" (973/12)
    19:17 "Форум: все за 12 часов" (328/101)
    17:02 "Диалоги о Творчестве" (249/4)
    14:22 "Технические вопросы "Самиздата"" (228/2)
    25/11 "Форум: Литературные объявления" (666)
    25/11 "О блокировании "Самиздата"" (294)
    ОБСУЖДАЕМ: Симонов С.
    20:19 "Создание правильного образа " (558/1)
    25/11 "Автомобили, мотоциклы автомотохотелки," (93/1)
    25/11 "Гражданская авиация" (1004/1)
    24/11 "Сельское хозяйство" (623)
    24/11 "Электронная периферия, связь, " (183)
    24/11 "Общественный транспорт, градостроительство" (228)
    21/11 "Коммунизм, сталинизм, троцкизм, " (961)
    18/11 "Контейнеры и грузоперевозки, " (927)
    17/11 "Новые технологии в промышленности" (624)
    16/11 "Центральный флуд" (827)
    12/11 "Вооружённые силы и техника" (970)
    06/11 "Атомная промышленность, энергетика, " (851)
    03/11 "Флот. Морские системы вооружений" (788)
    02/11 "Проект советской космической " (960)
    30/10 "Огас и Плановая экономика" (393)
    30/10 "Медицина, биология" (1007)
    26/10 "Законодательство, правоприменительная " (584)
    19/10 "Вертолёты" (820)
    14/10 "Робототехника, сложная бытовая " (279)
    13/10 "Наука и образование как ключ " (266)
    10/10 "День хризантем" (33)
    10/10 "Военная авиация" (715)
    06/10 "Химия и материалы" (347)
    04/10 "Строительство и быстровозводимые " (739)
    22/09 "Цвет сверхдержавы - красный " (527)
    13/09 "Демография и сопутствующее" (849)
    29/08 "Цвет сверхдержавы - красный " (500)
    18/08 "Цвет сверхдержавы - красный " (551)
    16/07 "Кино" (108)
    12/07 "Пво, Про, Зрк, Урвв" (1006)
    07/06 "Жизнь бесценна" (41)
    07/06 "Орион. Возможности, проблемы " (986)
    28/05 "Музыка" (577)
    25/05 "Цвет сверхдержавы - красный " (446)
    09/05 "Телевидение, фототехника, " (466)
    20/04 "Цвет сверхдержавы - красный " (234)
    19/04 "Предложения по палубной авиации " (988)
    20/02 "Дружба миров" (48)
    13/02 "Культура" (990)
    31/01 "Программирование" (361)
    25/01 "Теории заговора" (130)
    09/01 "Геология и горная промышленность" (484)
    06/01 "Четвёртый Интернационал" (44)
    26/06 "Цвет сверхдержавы - красный " (21)
    05/05 "Low Orbital Ion Cannon" (46)
    05/05 "Спираль истории Книга 1" (44)
    23/04 "Система Енонла" (11)
    21/04 "Невоенное противостояние с " (480)
    21/03 "Председатель Галактики" (111)
    20/11 "Актуальная тема - Международное " (963)
    07/11 "Цвет сверхдержавы - красный " (78)
    04/09 "Металлургия" (236)
    14/05 "Время, континуум, и параллельные " (415)
    16/03 "Цвет сверхдержавы - красный " (983)
    23/02 "Разведка и контрразведка" (605)
    22/01 "Экранопланы" (200)
    13/07 "Нетехнические фанфики" (123)
    09/07 "О магии стихий, рыжем кошаке " (96)
    24/10 "Проект конституции Аи-Ссср" (116)
    29/05 "Выставки 1959 года" (438)
    16/10 "Спираль истории Книга 2" (30)
    20/12 "Цвет сверхдержавы - красный " (30)
    ОБСУЖДЕНИЯ: (все обсуждения) (последние)
    19:40 Коркханн "Угроза эволюции" (873/47)
    19:39 Виноградов П. "Пишу рецензии. Не очень дёшево, " (205/101)
    19:38 Кротов С.В. "Чаганов: Война. Часть 4" (280/25)
    19:37 Ролько Т. "Гносеология наизнанку" (305/1)
    19:32 Динас В. "Камера молчания" (3/2)
    19:31 Куровский Э. "Рядом со Станиславом Дыгатом" (4/2)
    19:26 Ив. Н. "Весы (Libra). 23 сентября - " (1)
    19:24 Уралов А. "Мясо "из пробирки"" (657/12)
    19:21 Энвэ М. "Некуда бежать, негде спрятаться " (220/1)
    19:21 Козлов И.В. "Принимаются стихотворения " (78/4)
    19:21 Детектив-Клуб "Правила конкурса "Арена детективов" " (170/3)
    19:20 Юрченко С.Г. "Свет Беспощадный" (709/10)
    19:17 Пен-Пен "Я - Секретный Босс среди мобов!" (67/2)
    19:15 Родин Д.М. "Князь Барбашин 3" (835/10)
    19:07 Хохлюшкин И.Л. "Молодость" (13/2)
    19:04 Аль-Ру "Благословение боевого монаха " (2/1)
    18:52 Нивинная А. "Хризантемовый ноябрь" (11/3)
    18:45 Чваков Д. "В расход" (4/3)
    18:41 Ковалевская А. "Концерт "Октябрют 1917-2024"" (53/1)
    18:41 Шибаев Ю.В. "Квадробер" (23/4)

    РУЛЕТКА:
    Дикий
    Я пришла на тихий
    Книга о вкусных
    Рекомендует Ковальчук А.Ю.

    ВСЕГО В ЖУРНАЛЕ:
     Авторов: 108572
     Произведений: 1671061

    Список известности России

    СМ. ТАКЖЕ:
    Заграница.lib.ru
    | Интервью СИ
    Музыка.lib.ru | Туризм.lib.ru
    Художники | Звезды Самиздата
    ArtOfWar | Okopka.ru
    Фильм про "Самиздат"
    Уровень Шума:
    Интервью про "Самиздат"

    НАШИ КОНКУРСЫ:
    Рождественский детектив-24


    28/11 ПОЗДРАВЛЯЕМ:
     Абакумова Е.Б.
     Абрашова Е.А.
     Айа Э.А.
     Афанасьев И.С.
     Бархол Е.
     Баянова Н.А.
     Белолипецкий А.В.
     Биньковская А.А.
     Богатырёв Р.
     Булгакова И.В.
     Вильгельми А.В.
     Винокур И.
     Волк А.
     Галевская Г.
     Гаркавый В.А.
     Глушин А.В.
     Глыбина В.А.
     Гришко В.Р.
     Деева А.Н.
     Дженкинс К.
     Дорошенко И.Э.
     Дэльз С.В.
     Жгутова-Полищук В.
     Жук Т.А.
     Измайлов К.И.
     Казарян К.С.
     Климарев И.В.
     Климова Л.В.
     Кобзева Е.А.
     Коломиец Е.А.
     Коскина Т.
     Ксандер В.
     Луканина Е.В.
     Макарова А.А.
     Мамедова Л.Р.
     Морозов С.В.
     Мосиенко Ю.В.
     Нино
     Орлова Я.С.
     Павлов О.А.
     Первушина Т.В.
     Першина Л.П.
     Печенкина Л.В.
     Писакова С.Э.
     Пугнин Ю.В.
     Пугнин Ю.В.
     Риш К.
     Родионов М.В.
     Ройтберг В.И.
     Романенко Г.В.
     Роуг Л.
     Свидерский С.В.
     Сереброва Э.
     Симдянкин Е.Ю.
     Сиюткина Е.В.
     Собенков Р.И.
     Сокова Н.В.
     Суворов А.М.
     Сэй А.
     Сэр С.С.
     Толстокулакова И.Г.
     Федишин В.Е.
     Храмцова А.
     Чарторыжская А.
     Черевков А.С.
     Чмелёва Л.А.
     Шах Ю.
     Ярмолинская А.Л.
     Ariashari
     Eeshka
     Nutik
     Rabbit L.
     Richmund T.
    ПОСЛЕДНИЕ ПОСТУПЛЕНИЯ: (7day) (30day) (Рассылка)
    19:11 Иевлев Г.В. "В плену горячей звезды"
    11:40 Низовцев Ю.М. "О необходимости присутствия "
    26/11 Джонстон П. "Список смерти"
    26/11 Ледовский В.А. "Силы разные..."
    26/11 Кротков А.П. "Маски-шоу Павла Воткова"
    25/11 Небов К. "Потерянный ключ от забытой "
    25/11 Пен-Пен "Я - Секретный Босс среди мобов!"
    25/11 Петри Н.З. "Колесо превращений. Книга "
    24/11 Jackallionravenv "Омен Iv: Возбуждение"
    430. strangeserg (strangeserg@yandex.ru ) 2015/08/26 01:46 [ответить]
      > > 429.Алексей
      >> > 427.Поляков Дмитрий Валериевич
      >PIN можно подсмотреть или украсть чем-нибудь типа "накладной клавиатуры" или "высокочуствительного спецрадиоприёмника", - или записав звук (у каждой клавиши - свой!) и т.д., методов много...
      
       Думаю, из перечисленных Вами "методов завладения чужим PIN-кодом" для потенциальных злоумышленников в АИ СССР более-менее доступен "первый" (это всегда...)))) и, пожалуй, "записать звук нажатий клавиш" (для "умельцев-самоделкиных"!)... Всё-таки, - "время действия", предположительно, - вторая половина 60-х годов XX-го века (хоть и АИ...), - да и в СССР, а не на "диком Западе" (и не в "лихие 90-е" РеИ России)!
      
      >...Содержимое же чипа/"магнитной полосы" - уже так просто не получишь без контакта с карточкой (а значит, скорее всего, - и с её владельцем)... А вот перфокарту, даже маленькую, можно просто сфотографировать, - в том случае, если не предусмотрено "защитной оболочки", открываемой автоматически и только внутри банкомата!..
      
       Да, - скорее всего "как-то так" (наподобие "защиты" в дискетах 3.5"/5.25"), - до тех пор, пока не появятся "нормальные" дебетные/кредитные пластиковые карты с "магнитной полосой"/чипом...
      
      >...Я не рассматриваю серьёзно варианты - вроде "подключиться к телефонной линии банкомата и анализировать трафик" или "поставить свой подложный банкомат", - т.к. это слишком трудоёмко (по отношению к "прибыли"!) для потенциальных злоумышленников - и потому не будет иметь смысла... Да и шанс "спалиться" в таких случаях - значительно выше!..
      
       И правильно делаете, - такой уровень "оснащения/организованности" для преступных групп - вряд ли будет сколько-то "типичным"/распространённым в АИ СССР/странах-членах СЭВ/ОВД!.. Всё-таки несколько иной подход к общественной/государственной безопасности...
      
      >...Впрочем, если проводить регулярную ротацию карточек, смену PIN-кодов и внимательно расследовать сообщения о "подозрительных" происшествиях со счетами, - то проблема может "рассосаться" сама собой, толком и не возникнув...
      
       Нет, - рассчитывать только на "организационные мероприятия" и "сознательность/бдительность граждан" - не следует: ТЕМ БОЛЕЕ, что описанные Вами достаточно ПРОСТЫЕ в реализации технические меры безопасности - ЭФФЕКТИВНО эту безопасность УСИЛИВАЮТ! Как говорится, - "кашу маслом не испортишь!"))))...
      
      >...И это ещё - не считая будущих модернизаций банкоматов или вообще отказ от них, - вместе с самой денежной системой!..
      
       Модернизация САМИХ банкоматов без "модернизации" банковских карт (с переходом на "чипованные" пластиковые карты, - или ХОТЯ БЫ с "магнитной полосой"!..) - лишена большого смысла: что там можно именно В ПЛАНЕ БЕЗОПАСНОСТИ "улучшить", без совершенствования "клиентских карт"..?! Вмонтировать в каждый терминал "сканеры отпечатка пальца/сетчатки глаза" для "личностной идентификации"?.. Так ЭТО будет заведомо ДОРОЖЕ и потребует куда бОльших "процессорных мощностей", скорости/надёжности/"защищённости" линий связи и т.п.!
      
       А на скорое "наступление коммунизма" в АИ СССР и "отмену денег" в принципе - я бы уж так расчитывать не стал бы:
       - во-первых, - ЕДВА ЛИ это даже на территории самого СССР в АИ случится раньше начала XXI-го века, - во всяком случае у самого Автора чётких указаний на момент "наступления коммунистических отношений в экономике" пока НЕТ (зато трудностей/проблем "в реализации заявленного" - как раз предостаточно!);
       - во-вторых, - допустим, что "в одной отдельно взятой стране - СССР" таки ПОСТРОЕН КОММУНИЗМ: а как быть - с окружающим ОСТАЛЬНЫМ МИРОМ?..
       Там ведь пока что - "коммунизма" НЕТ, - в лучшем случае "развитой социализм" (страны-участницы СЭВ/ВЭС), - а то и просто "империалистический капитализм" (Западная Европа, США...)! Но ведь экономические отношения (торговля, туризм, научный и культурный обмен...) с ними АИ СССР вести как-то надо: значит нужны и БАНКИ со всей своей "соответствующей инфраструктурой", - включая сеть банкоматов (хотя бы для тех же "деловых партнёров/гостей страны"!), платёжных терминалов "безналичной оплаты" в магазинах/отелях/музеях/театрах/вокзалах и аэропортах и т.д...
       Кстати, нашим "АИ-согражданам" из "Светлого Будущего")))), - выезжающим на отдых/на работу за пределы "территории коммунистических отношений", - ТОЖЕ КАК-ТО ПРИДЁТСЯ "пользоваться по-старинке" платёжными системами: "там", в "заграницах", - пока что ещё "всё за деньги"!..
      
      
    429. Алексей 2015/08/23 03:16 [ответить]
      > > 427.Поляков Дмитрий Валериевич
      >а толку от копирования без пина
      >вся информация не на карте а на серверах банка
      
      Толк в получении таких же прав в банковской системе, как и у цели. Оно именно так работает и сейчас, но народ всё равно инфу с карточек тырит. См. "кардинг":
      http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%80%D0%B4%D0%B8%D0%BD%D0%B3
      
      Пин можно подсмотреть или украсть чем-нибудь типа "накладной клавиатуры" или высокочуствительного спецрадиоприёмника или записав звук (у каждой клавиши свой) и т.д., методов много. Содержимое же чипа/магнитной полосы уже так просто не получишь без контакта с карточкой (а значит, скорее всего, и с её владельцем). А вот перфокарту, даже маленькую, можно просто сфотографировать - в том случае, если не предусмотрено защитной оболочки, открываемой автоматически и только внутри банкомата.
      
      Я не рассматриваю серьёзно варианты вроде "подключиться к телефонной линии банкомата и анализировать трафик" или "поставить свой подложный банкомат", т.к. это слишком трудоёмко (по отношению к "прибыли") для потенциальных злоумышленников и потому не будет иметь смысла. Да и шанс "спалиться" в таких случаях значительно выше.
      
      Впрочем, если проводить регулярную ротацию карточек, смену пин-кодов и внимательно расследовать сообщения о "подозрительных" происшествиях со счетами, то проблема может "рассосаться" сама собой, толком и не возникнув. И это ещё не считая будущих модернизаций банкоматов или вообще отказ от них, вместе с самой денежной системой.
    428. *Симонов Сергей (gann.lector@yandex.ru) 2015/08/22 09:34 [ответить]
      > > 424.Следж Хаммер
      
      По лазерам и РЛС пригодится, спасибо. Сохранил
    427. Поляков Дмитрий Валериевич 2015/08/21 23:02 [ответить]
      > > 426.Алексей
       >Идея весьма хороша, но какая защита (помимо пин-кода) предусмотрена в системе? Перфокарту ведь можно и фотоаппаратом скопировать. Там "шторка", вроде той, что на дискетах 3.5", или ещё что-то подобное?
      а толку от копирования без пина
      вся информация не на карте а на серверах банка
      
      
    426. Алексей 2015/08/21 23:01 [ответить]
      В главе 03-15 описан некий "банкомат на основе обычного телетайпа и малогабаритной перфокарты".
      
      Идея весьма хороша, но какая защита (помимо пин-кода) предусмотрена в системе? Перфокарту ведь можно и фотоаппаратом скопировать. Там "шторка", вроде той, что на дискетах 3.5", или ещё что-то подобное?
    425. Следж Хаммер 2015/07/30 23:26 [ответить]
      Как может выглядеть РЛС СПРН в АИ с учетом достижений в электронике и строительстве из блоков и других элементов заводской готовности http://militaryrussia.ru/blog/topic-610.html
    424. Следж Хаммер 2015/07/28 02:36 [ответить]
      http://www.unionexpert.ru/index.php/2011-07-25-15-56-33/item/325-lasers-in-soi-behalf-of-the-si-vavilov-from-the-first-ruby-to-latest-developments
    423. Талипов Артём (eric50@yandex.ru) 2015/07/12 20:29 [ответить]
      > > 419.Следж Хаммер
      > я это все к тому что нужно как-то организовывать обмен информацией, своими предложениями, конференции хоть закрытые проводи в отдельных комнатах при ограничения доступа, т.к. проскальзывает, что ряд разработок удался благодаря личным знакомствам на других предприятиях, а это слишком зависит от конкретных людей, т.е. можно многие вещит ппросто не получить, ввиду изменений хода событий в АИ...
      
      Надо. Я об этом уже писал. Устраивать конференции учёных, инженеров, разработчиков, с докладами по тематикам.
      
      Лучше всего на базе отдыха, чтоб можно было организовать неформальное общение.
      
      Совсем не обязательно раскрывать саму технологию. Но рассказать, что она есть, как примерно работает. Поделится интересными мыслями, наработками...
      
      Вон, как у нас устраивают конференции по программированию. Доклады ведь делают, на очень уж разные темы. А сходишь на такой и в голове куча мыслей появляется.
      
      Ну и можно все доклады снимать на киноплёнку, а потом прокручивать их для тех, кто не смог поехать.
    422. Следж Хаммер 2015/07/12 15:11 [ответить]
      Кроме того, если вспомнить статьи по космическим измерениям с использованиям лазерной подсветки и лазерному ПРО, то можно надеятся на мощную подпитку ресурсами и кадрами хотя для реализации на начальном этапе стационарных систем измерений, где можно использовать ранние крупногабаритные изделия с последующим ужиманием размеров.
      
    421. Следж Хаммер 2015/07/12 13:17 [ответить]
      Светодальномеры пытались и американцы к середине 40-х сделать, даже в опытные танки пихали, не помню название такой прибор, так что в принципе можно сделать, я скорее указывал на сложности реализации ЛД как серийной продукции для сложных условий, например, танков.
    420. *Симонов Сергей (gann.lector@yandex.ru) 2015/07/12 12:33 [ответить]
      Изучая ссылки, заглянул в вики, нашел вот что:
      
      "Лебедев Александр Алексеевич"
      
      " Тогда же, ещё до изобретения радиолокации, под руководством А. А, Лебедева были созданы и прошли полевые испытания светодальномеры. Впоследствии были разработаны интерференционные методы высокочастотной модуляции света и значительно повышено разрешение светолокаторов. Новый толчок развитию этого направления дало появление оптических квантовых генераторов. Лазерные дальномеры были созданы в короткий срок, и уже в 1965 году на Лейпцигской ярмарке демонстрировался первый в мире дальномер с источником излучения на основе арсенида галлия, созданный А. А. Лебедевым и его сотрудниками.
      
      В 1940-е годы был разработан новый типа интерферометра - поляризационного, который сразу нашёл применение в минералогии, а также в исследованиях малых изменений показателя преломления стекол (работа Тудоровской для исследования диффузии солей при электролизе, работа Самарцевой) и в других случаях. А. А. Лебедевым была рассчитана поляризационная призма, позволяющая использовать оба поляризованных луча, что даёт значительное уменьшение потерь света - эффект использован для применения конденсаторов Керра (в телевидении). Под руководством учёного Н. Ф. Тимофеева изучала влияния поверхностных слоев стекла на коэффициент отражения, в результате чего была найдена возможность ощутимого (в 5 раз) снижения потерь в оптических системах, обусловленных отражением.
      
      ...
      
      Дальномер
      До зарождения оптической локации - в 1933 году С. И. Вавиловым, в то время руководившим ГОИ, и А. А. Лебедевым была начата разработка прибора, позволявшего измерять расстояние по времени прохождения его светом. С. И. Вавилов предлагал положить в основу такого дальномера схему Э. Гавиолы, реализованную Карлюсом и Миттельштедтом. Но этот принцип имел определённые недостатки, заключавшиеся в большой потере света при прохождении через ячейки Керра, используемые для модуляции (прерывания) света. Александр Алексеевич предложил новый тип модулятора - интерференционный. Интерферометр Майкельсона был весьма чувствителен к среде и нагрузкам, что делало его малопригодным для полевых условий - интерференционный модулятор А. А. Лебедева был в этом отношении более стоек и мобилен: он выдерживал перевозку по плохим дорогам без нарушения юстировки. Первые испытания дали точность измерения дистанции 3,5 км +2-3 м. Это явилось началом оптической локации - первые радиолокаторы появились много позже.
      
      Т.е. теоретическая основа создания светового дальномера была заложена ещё в 1930-40 гг, и замена источника света на лазер сдерживалась только исследованиями в области возбуждающихся материалов. По ним информация в АИ имеется. Остаются затраты времени на налаживание серийного выпуска - в АИ, полагаю, не более 3-х лет, максимум 5. т.е. к 1958-59 г вполне может быть опытный образец, и к 1962-му серийные дальномеры
    419. Следж Хаммер 2015/07/12 11:36 [ответить]
      > > 418.Симонов Сергей
      >> 417. Следж Хаммер
      >
      >Спасибо, много инфы, это надо скачивать и читать, если мой дохлый интернет позволит.
      В соседней электронной теме по лазерным гироскопам тоже небольшая подборка, я это все к тому что нужно как-то организовывать обмен информацией, своими предложениями, конференции хоть закрытые проводи в отдельных комнатах при ограничения доступа, т.к. проскальзывает, что ряд разработок удался благодаря личным знакомствам на других предприятиях, а это слишком зависит от конкретных людей, т.е. можно многие вещит ппросто не получить, ввиду изменений хода событий в АИ...
      
      
    418. *Симонов Сергей (gann.lector@yandex.ru) 2015/07/12 08:51 [ответить]
      > 417. Следж Хаммер
      
      Спасибо, много инфы, это надо скачивать и читать, если мой дохлый интернет позволит.
    417. Следж Хаммер 2015/07/12 02:36 [ответить]
      Еще по оптике - http://www.ak-info.ru/joomla/index.php/devices/9-optics/45-nightopthistory
      "Разработка ТПВ была начата в 1963 г. по инициативе А. И. Горячева и под его непосредственным руководством. В это время был создан один из первых в стране ТПВ, дающий изображение в реальном масштабе времени. Разработка первых ТПВ была направлена на решение задач наведения ПТУРС. С помощью ТПВ были проведены их первые пуски (А. И. Горячев, Е. И. Левин, В. А. Чеботарев и др.). Однако большие мощности излучения факела и трассера ПТУРС приводили к значительным засветкам изображения, что не позволяло успешно решить задачу, учитывая, что ТПВ работали в области спектра 3-5 мкм. Достаточно эффективно эта задача была решена при создании первого двухканального ТПВ 'Ночь-А' для наведения ПТУРС 'Конкурс' (Н. Ф. Кощавцев, Г. М. Цибулькин, В. И. Теплов). Обеспечение требуемой помехозащищенности было реализовано за счет разнесения по спектру чувствительности ТПВ (3,5- 5,5 мкм) и излучения трассера (0,8-1,1 мкм).
      В дальнейшем работы в области ТПВ начали вестись в направлении создания приборов разведки для подвижных разведывательных пунктов (ПРП) и прицела для танка. Оба прибора размещались вне боевого отделения на башне ПРП или на маске пушки из-за очень больших габаритов оптических систем. ТПВ разрабатывались на основе фоторезистора InSb с размером фоточувствительной площадки 100х100 мкм (Е. И. Левин, В. А. Чеботарев, Г. И. Потрахова). Результаты исследований начали применяться в тепловизорах для ПРП, который был принят на вооружение (участвовали в разработке от НИИ прикладной физики Н. Ф. Кощавцев, Е. И. Левин, В. А. Чеботарев). Модернизированный ТПВ для ПРП выпускается до настоящего времени.
      С появлением в 1970 г. фотоприемников CdHgTe (KPT), чувствительных в области спектра 8-14 мкм, начались работы по созданию танкового тепловизионного прицела, размещаемого в боевом отделении. Работы были начаты в ЦКБ КМЗ под научным руководством НИИ прикладной физики (научный руководитель Н. Ф. Кощавцев). Двухканальный тепловизионный прицел был размещен в боевом отделении танка и прошел весь комплекс полевых испытаний. В дальнейшем тепловизионный прицел был переработан с учетом использования фотоприемника со 128 элементами (вместо 50 в предшествующем фотоприемнике). Этот тепловизор выпускается серийно до настоящего времени."
      
      Лазерные дальномеры
      "Первые советские лазерные дальномеры были разработаны в середине 60-х годов предприятиями оборонной промышленности, имевшими огромный опыт в создании оптических приборов. НИИ 'Полюс' в это время ещё только формировался.
      Первой работой института в этом направлении была разработка рубинового элемента 5,5 х 75 для лазерного дальномера, создаваемого ЦНИИАГ. Разработка была успешно завершена в 1970 г созданием такого элемента с приёмкой заказчика.
      Отдел института, возглавляемый В.М. Кривцуном, в эти же годы разрабатывал рубиновые лазеры для космических траекторных измерений и оптической локации Луны. Был накоплен большой задел по созданию твердотельных лазеров полевого применения и их стыковке с аппаратурой заказчика. С использованием нашего лазера НИИ Космического приборостроения (Директор - Л.И. Гусев, Главный конструктор комплекса - В.Д. Шаргородский) провёл в 1972 - 73 гг успешную оптическую локацию Луноходов, доставленных советскими космическими кораблями на поверхность Луны. При этом определялось и местонахождение Луноходов на Луне методом сканирования лазерного луча. В 70-х годах эти работы были продолжены разработкой локационного лазера на гранате с неодимом ('Кандела', Главный конструктор Зверев Г.М., ведущие исполнители М.Б. Житкова, В.В. Шульженко, В.П. Мызников). Ранее намеченный для использования в авиации, этот лазер был успешно применен для оснащения и многолетней эксплоатации широкой сети лазерных станций траекторных измерений спутников на Майданаке на Памире, на Дальнем Востоке, в Крыму и в Казахстане. В настоящее время на этих станциях работает уже 3-е поколение лазеров, разработанных в НИИ 'Полюс' (И.В.Васильев, С.В.Зиновьев и др.).
      Опыт разработки лазеров военного применения дал возможность приступить к разработке непосредственно лазерных дальномеров в 'Полюсе'. Инициатива по разработке дальномеров в институте, проявленная Г.М. Зверевым, в 1970 г. возглавившим комплексное отделение института по разработке активных и нелинейных элементов, твердотельных лазеров и приборов на них, была активно поддержана директором М.Ф.Стельмахом и руководством отрасли.
      В начале 70-х годов институт единственный в стране владел технологией выращивания монокристаллов АИГ:Nd и электрооптических затворов, что дало возможность создавать приборы существенно меньшей массы и габаритов. Так, типовая энергия накачки рубинового лазера для дальномера составляла 200 Дж, а для гранатового лазера только 10 Дж. В несколько раз сокращалась и длительность импульса лазера, что повышало точность измерений.
      Первая разработка прибора началась в конце 60-х годов под руководством В.М. Кривцуна. В качестве компоновочной идеи им была выбрано схема с одним объективом, с использованием электрооптического элемента в качестве коммутатора входного и выходного каналов. Эта схема была подобна схеме радиолокатора с антенным переключателем. Был выбран лазер на кристалле АИГ:Nd, позволявший получать достаточную выходную энергию ИК излучения (20 мДж). Завершить разработку прибора В.М.Кривцуну не удалось, он тяжело заболел и в 1971 г. скончался. Завершать разработку пришлось А.Г. Ершову, ранее разрабатывавшему перестраиваемые лазеры для научных исследований. Оптическую схему пришлось сменить на классическую с раздельными объективами передатчика и приёмника, так как в совмещённой схеме не удалось справиться с засветкой фотоприёмника мощным импульсом передатчика. Успешные натурные испытания первого НИР-овского образца прибора 'Контраст- 2' прошли в июне 1971 г. Заказчиком ОКР первого в стране лазерного дальномера на АИГ:Nd выступило Военно-топографическое управление.
      Разработка была завершена в очень короткий срок. Уже в 1974 году квантовый топографический дальномер КТД-1 был принят на снабжение и передан в серийное производство на завод 'Тантал' в Саратове. При этой разработке полностью проявился талант Главного конструктора А.Г. Ершова, сумевшего правильно выбрать основные технические решения прибора, организовать разработку смежными подразделениями его блоков и узлов, новых функциональных элементов. Прибор обладал дальностью действия до 20 км с погрешностью менее 1,7 м."
      http://www.polyus.info/books/nii-polyus-50-let/chapter12/
    416. Следж Хаммер 2015/07/12 01:55 [ответить]
      По поводу применения лазеров, уже было, но для уточнения ситуации
      "В 1950 г. по инициативе А.А. Лебедева в Государственном оптическом институте (ГОИ) СССР были начаты работы по созданию первых образцов АИ-приборов наблюдения. В качестве импульсного осветителя использовался прожектор, выполненный на основе отражателя диаметром 1500 мм и разборной аргоновой импульсной лампы ГОИ с давлением 4 - 6 атм, частотой 500 - 800 Гц и средней мощностью излучения 2 - 3 кВт.
      В приемной части аппаратуры использовался объектив с фокусным расстоянием 600 мм и относительным отверстием 1:1,6, импульсный ЭОП УЗ-42 и окуляр с увеличением 4х. Была достигнута дальность распознавания объектов на морской поверхности свыше 15 км. Вместе с тем масса, габариты и энергопотребление аппаратуры оставались значительными из-за лампового прожектора. Угол расходимости его излучения также был велик, что снижало силу света и ограничивало дальность действия прибора. Поскольку увеличить яркость импульсных плазменных источников света не представлялось возможным выше определенных пределов, улучшить параметры прибора также было нереально.
      Ощутимого прогресса в развитии АИ ПНВ удалось достигнуть только в начале 60-х годов в связи с созданием лазеров. По сравнению с искровыми ламповыми источниками лазеры обладают существенными преимуществами:
      высокой яркостью и направленностью излучения;
      монохроматичностью излучения, позволяющей использовать в приемной части прибора узкополосные фильтры, отсекающие излучение световых помех;
      малой длительностью импульсов излучения (единицы и десятки герц), позволяющих получить сравнительно малые глубины просматриваемого пространства, измеряемые долями и единицами метров. Это позволяло резко повысить контраст изображения в сильно рассеивающих средах (дымка, туман, дождь, снегопад, вода и пр.). В этой связи самые благоприятные результаты были получены при использовании твердотельных лазеров, работающих в режиме модулированной добротности и генерирующих наиболее короткие мощные импульсы излучения с длительностью 20 - 50 нc.
      Первые работы с АИ-приборами, использующие лазеры, были проведены в ГОИ в 1963 г. Лазер на рубине, работавший в режиме модулированной добротности, обеспечивал энергию в импульсе 0,5 Дж при длительности импульса излучения 30 нс. В приемной части аппаратуры использовался импульсный ЭОП с компенсированным затвором и объектив с фокусным расстоянием 1000 мм и относительным отверстием 1:7. Аппаратура позволяла ночью наблюдать грузовую автомашину на дальности до 1 км. При этом ошибка измерения дальности не превышала 5 м. На расстоянии приблизительно 800 м от прибора устанавливался щит с вырезанной на нем звездой. Перед щитом была повешена занавеска из многослойной марли для имитации воздушной дымки. При наблюдении ночью в обычный пассивный прибор, а днем в оптический прибор (бинокль) изображение звезды не просматривается. Но использование АИ-режима позволило "отсечь" марлю, и появилось четкое изображение звезды. В процессе испытаний ясным солнечным днем при уровне естественной освещенности 5х104 лк объект наблюдений распознавался на дальности 1,2 км. Проводились также успешные испытания по наблюдению при сильном дожде, тумане и при наличии между прибором и объектом наблюдения облака. В приемной части аппаратуры был установлен интерференционный фильтр с полосой пропускания 3 нм.
      В дальнейшем в ГОИ использовались лазеры на стекле с неодимом с удвоенным и без удвоения частоты, работающие в частотном или моноимпульсном режиме модулированной добротности, а также и в более благоприятном режиме пичковой генерации с длительностью импульса пачки пичков 200 нс. Длительность строба составляла при этом около 1 мкс. "
      http://www.bnti.ru/showart.asp?aid=632&lvl=10.02.
      С учетом продвижения помимо лазеров, и в вопросе ЭОП можно ожидать больших успехов в целом по данному направлению.
      
      Для оптики и строек
      "В 1958 году при кафедре была организована отраслевая лаборатория Специальные оптические приборы с достаточно сильной группой конструкторов-разработчиков. Профессор С.Т. Цуккерман и А.С. Гридин руководили разработкой приборов управления по лучу (ПУЛ), предназначенных для управления движением различных подвижных объектов по прямой линии или по программе. Ими в 1967 году была написана монография "Управление машинами при помощи оптического луча".
      http://museum.ifmo.ru/?id=27
      
      http://de.ifmo.ru/bk_netra/page.php?dir=3&tutindex=31&index=34&layer=1
      
      "Различают системы автоматического контроля продольного уклона - лучевую и копировальную. Первая из них основана на физико-геометрическом методе, при котором используют прибор управления лучом (ПУЛ-3) или прибор с лазерным лучом. ПУЛ-3 обеспечивает дистанционное управление рабочим органом землеройной машины с помощью прямолинейного инфракрасного луча и состоит из двух станций: направляющей и приемной. В первую станцию входят проектор, формирующий луч, штатив, преобразователь напряжения и аккумулятор с напряжением 6 В. Направляющую станцию помещают в начале участка работ. С ее помощью формируется узконаправленный луч, разделенный горизонтально расположенной равносигнальной зоной (РСЗ) на две симметричные части. Луч проектора направляют в соответствии с проектным уклоном сооружаемого полотна."
      http://www.stroitelstvo-new.ru/dorog/sistemy-kontrolya.shtml
      
      "При планировке земляного полотна по световому лазерному лучу весьма эффективным является использование прибора управления лазерным лучом ПУЛ, состоящего из двух станций - направляющей и приемной. Направляющее устройство, устанавливаемое на штативе, создает в пространстве наклонный луч заданного уклона. Луч посредством инфракрасного фильтра и специальной призмы делится по частотам 900-1500 Кц на верхнюю и нижнюю части с четкой границей между ними в виде равносигнальной зоны РСЗ, которую используют для установки рабочего органа машины в заданное по высоте положение.
      С помощью сборного красного и зеленого фильтра световому потоку придают разную окраску с разделением по вертикали. Оператор по окраске луча может судить об отклонении строительной машины от заданного направления вправо или влево и соответственно корректировать ее движение."
      http://www.mobigeo.ru/avtomatizatsiya-upravleniya-stroitelnymi-protsessami.html
      
      "Дальнейшим развитием систем автоматического управления машинами является метод управления с высокой точностью инфракрасным модулированным лучом ПУЛ. Машины, управляемые инфракрасным модулированным лучом, при этом не требуют предварительной геодезической или иной разметки профиля сооружения, отпадает необходимость в кольях и нивелирной проволоке. Особенно эффективны ПУЛ на отделке и планировке. ПУЛ включает передающий пункт: излучатель модулированного света, в состав которого входят прожектор с постоянной установкой объектива на 500 мм и преобразователь потребляемой мощности 30 Вт напряжением источника тока 6 В (для ПУЛ-3); приемный пункт -фотоприемник с полем зрения 6R, диаметром объектива 40 мм: усилитель с коэффициентом усиления неявнее 1,2-10, напряжением питания анодных цепей 300 В постоянного тока и напряжением питания ламп накаливания 13 В; пульт управления потребляемой мощности 40 Вт, напряжением источника постоянного тока 300, 13 и 6,3 В и соединительные кабели.
      Приемную станцию устанавливают на машине (рис. 8.25), направляющую- на земляном полотне. Приемная станция принимает информацию, передаваемую по лучу направляющей станции, и вырабатывает команду гидравлической системе управления вертикальным перемещением рабочего органа машины, чтобы удержать установленный на нем фотоприемник в плоскости раздела модулированного луча. Система управления ПУЛ довольно сложная, поэтому получает распространение лазерная система - лазер.
      Лазерный луч в отличие от ПУЛ хорошо виден в любую погоду, тумане и запыленном воздухе. Его можно использовать при строительстве мостов в качестве осевой линии, а при высотном строительстве- для проверки вертикальности сооружения. Во время строительства телевизионной башни в Москве лазерный.луч благодаря своей исключительной точности служил 'отвесом', по которому проверяли вертикальность полукилометровой громады."
      http://stroy-technics.ru/article/avtomatizatsiya-proizvodstva-zemlyanykh-rabot
      http://stroy-spravka.ru/article/podgotovka-territorii-i-geodezicheskaya-razbivka-zemlyanykh-sooruzhenii
      http://www.excavatora.ru/avto_mashin4.php
    415. *Талипов Артём (eric50@yandex.ru) 2015/06/30 20:24 [ответить]
      > > 414.Поляков Дмитрий Валериевич
      >> > 412.Талипов Артём
      >у реле да и у герконов при определенных условиях контакты свариваются
      >из за этого и невозможно гарантировать отсутствие напряжения в неисправной розетке
      
      Ах... Верно. Действительно, есть такая спецефическая бяка, искранёт, да и приварится.
      
      Но, я бы делал шторку. Она вопервых защитит пальцы от прямого контакта с электропроводом.
      А во-вторых первый контакт, делать, через открытую шторку, с противодействующей пружиной, и пусть она спокойно искрит, контакты будут разрыватся механически. А гиркон или рэле, будут замыкать без искры, что защетит их от сваривания.
      
      >но тогда лампочка будет дольше включаться(ориентировочно до 2 секунд)
      
      И плевать. Пусть включается дольше. Зато без обломов.
      "Артём! Поменяй лампочку в туалете, мне не видно жопы, чтоб её подтереть"!
      "На прошлой неделе менял. Опять згарела? Больше нету. Как-нибудь куплю, если случайно зайду в магазин..."
      
      >до развития электроники и термисторы и балласт выгоднее размещать в патроне чем в лампочке
      
      
      Ага. Совершенно верно.
    414. Поляков Дмитрий Валериевич 2015/06/30 16:54 [ответить]
      > > 412.Талипов Артём
      
      >И... Я не понял, почему розетка со сломанной защитой, будет бить током? Там же контакта не будет. Значит напряжение не будет подводится.
      у реле да и у герконов при определенных условиях контакты свариваются
      из за этого и невозможно гарантировать отсутствие напряжения в неисправной розетке
      долговечные лампочки тема тоже интересная в принципе делаются несложно
      если речь о лампах накаливания нужно встраивать термистор
      но тогда лампочка будет дольше включаться(ориентировочно до 2 секунд)
      если речь о газоразрядных опять таки термистор в цепь накала и балласт обеспечивающий правильную форму тока
      со светодиодными автоматическая регулировка тока в зависимости от температуры
      до развития электроники и термисторы и балласт выгоднее размещать в патроне чем в лампочке
      
      > > 413.hcube
      >Это жесть просто. Там НЕТУ блока питания. Вся схема - это конденсаторный балласт плюс выпрямитель с электролитом на выходе в параллель светодиодам. То есть никакого импульсного источника там тупо нету :) - ломаться абсолютно нечему.
      чему ломаться найдется даже в железной чушке
      а в таких лампочках изза хренового теплового режима сохнет конденсатор и диод пробивается не говоря о светодиодах которые без ограничения по току горят как спички
      
      
    413. hcube 2015/06/30 15:46 [ответить]
      > > 412.Талипов Артём
      >Вот все говорят о долговечных лампочках. Если это возможно, то надо делать именно такие.
      
      Кстати. Я тут разобрал дешевую светодиодную китайскую лампу.
      
      Это жесть просто. Там НЕТУ блока питания. Вся схема - это конденсаторный балласт плюс выпрямитель с электролитом на выходе в параллель светодиодам. То есть никакого импульсного источника там тупо нету :) - ломаться абсолютно нечему.
      
      Зато и стоит бакс-полтора вместе с доставкой.
      
    412. *Талипов Артём (eric50@yandex.ru) 2015/06/30 15:42 [ответить]
      > > 411.Поляков Дмитрий Валериевич
      >> > 410.Талипов Артём
      >в случае лампочек защиту придется встраивать в патрон и лампочку
      >а не в выключатель как в электронной версии
      
      Вот все говорят о долговечных лампочках. Если это возможно, то надо делать именно такие. Чтоб работали, сколько могут. В таком случае и встроенная защита окупится.
      
      А ещё, повторюсь: плохая защита лучше, чем отсутствующая.
      
      И... Я не понял, почему розетка со сломанной защитой, будет бить током? Там же контакта не будет. Значит напряжение не будет подводится.
      
      И конечно же, сам дизайн розетки, надо делать максимально защищённым. В идеале высокие края. Обжимной кантакт на заземлении. Шторки на отверстиях контактов фаз.
      
      Естественно это будет дороже, но безопаснее. А кому плевать на безопастность, но очень нужна минимальная цена, может просто бросать провода на клеммы. Так например сделано в старых советских трамваях и тролейбусах. Надо подключить или отключить печку, вскрываешь панель, и отвёрточкой ослобляешь соответствующий винт, чтобы набросить или снять соответствующий провод.
    411. Поляков Дмитрий Валериевич 2015/06/29 23:52 [ответить]
      > > 410.Талипов Артём
      >В идеале-то надо действительно всякие плюшки. Но по началу, можно и на рэлешках делать защиту. Ибо защита нужна, даже плохая и тормозная.
      сама то плюшка на реле проста
      магнит в вилке геркон в розетке через него включена обмотка реле
      реле с парой нормально разомкнутых контактов
      из достоинств
      относительная безопасность нет магнита нет напряжения
      минимум искрения(реле включается после появления контакта между вилкой и розеткой)
      из недостатков
      меньшая надежность чем у незащищенной розетки
      большая цена
      возможность удара током при неисправной розетке
      
      в случае лампочек защиту придется встраивать в патрон и лампочку
      а не в выключатель как в электронной версии
      
      
    410. *Талипов Артём (eric50@yandex.ru) 2015/06/29 23:23 [ответить]
      > > 409.Поляков Дмитрий Валериевич
      >на момент смены стандарта это могли реализовать только в варианте геркон + реле
      
      Замена оборудования выполнялась долго. По некоторым сведениям, даже в 80 годах, у некоторых, в центре Москвы подводилось 110 вольт. А в жд поездах, и сейчас не редкость.
      
      К тому же далеко не сразу появились даже пластики, для проводов, розеток, вилок и прочего оборудования.
      
      
      В идеале-то надо действительно всякие плюшки. Но по началу, можно и на рэлешках делать защиту. Ибо защита нужна, даже плохая и тормозная.
      
      И ещё, надо бы и заземления делать нормальные!
    409. Поляков Дмитрий Валериевич 2015/06/29 20:37 [ответить]
      > > 408.Талипов Артём
      
      >Тем более был хороший повод, смена электростандарта со 110 вольт, на 220 вольт.
      на момент смены стандарта это могли реализовать только в варианте геркон + реле
      
      
      
    408. *Талипов Артём (eric50@yandex.ru) 2015/06/29 20:34 [ответить]
      > > 407.Поляков Дмитрий Валериевич
      >попался мне только что на радиокоте пост (Пн июн 29, 2015 17:20:20) про безопасные розетки/патроны
      
      Я об этом нудю ещё с первой книги!
      Тем более был хороший повод, смена электростандарта со 110 вольт, на 220 вольт.
    407. Поляков Дмитрий Валериевич 2015/06/29 19:29 [ответить]
      попался мне только что на радиокоте пост (Пн июн 29, 2015 17:20:20) про безопасные розетки/патроны
      http://radiokot.ru/forum/viewtopic.php?f=15&t=11512&sid=78ea75507137299fe4e45e2fd89d8017&start=4140
      а ведь тоже самое можно реализовать и без контроллеров
      причем даже в 1970 АИ
      
      имхо и самим полезно и за бугор влет должно уходить
      продавать вилки розетки лампочки и выключатели
      
      идеально было бы продавить обязательность использования во всяких заведениях через какую нибудь международную комиссию по защите детей
      
    406.Удалено написавшим. 2015/06/16 19:22
    405. Симонов Сергей (gann.lector@yandex.ru) 2015/06/16 19:04 [ответить]
      > > 404.Талипов Артём
      
      Спасибо, необычно.
    404. *Талипов Артём (eric50@yandex.ru) 2015/06/16 16:24 [ответить]
      Попалась занятная история. Чуваку дали ремонтировать старые советские электрические часы. Дитя, как раз описываемой эпохи. Я подобные, застал в школе. http://habrahabr.ru/post/259575/
    403. *Талипов Артём (eric50@yandex.ru) 2015/06/14 19:41 [ответить]
      > > 402.Поляков Дмитрий Валериевич
      >просто на данный момент в программировании очень часто встречается ситуация как с первыми пароходами...
      
      Ну, да. Есть такое. И к сожалению, всё ещё пока печально, даже с новыми языками.
      Более менее продуманы C#, Go, Rust. Но по моему, они ущербны.
      C# для каких-то дибилов, но сахар вкусный.
      Go - очень злобный друг, который любит пинать по поводу и без, загоняя в жёсткие рамки, даже если они не нравятся.
      Rust - забавен, но отдаёт этаким эпотажем.
      Идеи правильные, но слишком подчёркивается отличие от C.
      Из старичков, очень неплох C++. Но его наследие, действительно печалит.
      
      А у меня, по прежнему не получается создать хороший язык программирования. Трудно тягатся с большими компаниями.
      Да и привычка к старым конструкциям, не даёт покоя.
      А ведь так хочется получить, действительно продвинутый язык, одновременно удобный, простой, защищённый и быстрый.
    402. Поляков Дмитрий Валериевич 2015/06/14 17:35 [ответить]
      > > 401.Талипов Артём
      >С вашим подходом, я совсем не удивляюсь, что вы считаете язык программирования C, дырой в безопасности. Если бежать всё переделывать, даже не разобравшись в инструменте... Вобщем это антипаттерн.
      с чего вы взяли что не разобравшись
      просто на данный момент в программировании очень часто встречается ситуация как с первыми пароходами
       у пароходов были кирпичные трубы потому что печка же
      а в программировании паттерны лепят куда надо и не надо
      в итоге что пароходы переворачивались от легкого ветра что программы падают и хрен найдешь где потому что баг зарыт под ста слоями кода
      чтоб развиваться дальше нужно пересматривать необходимость уже изобретенных велосипедов и начинать стоит с языка программирования
      
    401. *Талипов Артём (eric50@yandex.ru) 2015/06/14 17:07 [ответить]
      > > 400.Поляков Дмитрий Валериевич
      >> > 399.Талипов Артём
      >>Но поиск, полностью отделить не получится. Он должен синхронно обновлять хэши.
      >хеши будут обновлятся за счет одновременного отправления данных на хранение и в поисковый сервер
      
      Это да. По иному сделать не получится. Но транзакционность будет сложненькой.
      
      >1) никто не мешает шифровать данные внутри ячеек паролем который знает только сервер обрабатывающий данные да и можно сделать так что и сервер не сможет ничего расшифровать без подписи под запросом
      
      Шифровать и расшифровывать, всё равно придётся. И действительно, надо шифровать двойным ключём, полным и публичным. Полный на чтение и запись, а публичный, только на чтение.
      
      >то есть даже захватив цод целиком не получится извлечь информацию
      
      Ну, хаки есть. Главное захватить цод по тихому. А дальше дамп памяти, на работающем серваке. А уже в дампе, лежит публичный ключ.
      Можно конечно поизвращатся на счёт аппаратного модуля шифрования. В этом случае придётся втыкать снифер, перехватывающий ключ.
      Если вам кто-то говорит, что защита на все 100%, то неверьте. Было бы желание, а подломить можно всё что угодно.
      И каждая дополнительная мера безопасности, лишней не будет.
      Разнесение данных по разным серверам или даже цодам, безопасность повышает. А значит это хорошо.
      
      >2)захват захват любых двух компонентов из трех не даст доступа к базе
      
      Надо увеличивать число компонентов. И например, захват 2 компонентов из 12 тем более ничего не даст.
      
      >3)государство таки будет все это охранять
      
      Естественно. И специальные системы защиты. И вооружённая охрана и ещё много чего.
      
      >>2. никакого суперкомпьютера или даже кластера не хватит. Я делал расчёты, исключительно для таблицы id, first_name, midle_name, last_name. Если иначе, то не влезет!
      >кластера за глаза
      
      Я уже писал о том, что возникнет проблема синхронизации машин в кластере. Для нестрогих систем хранения, это не столь важно. Но для критических данных очень даже желательно.
      Можно, конечно, поизвращатся, и разместить всё на кластере.
      
      >>3. время операции увеличится, ибо придётся ворочать слишком большими данными.
      >время операции зависит исключительно от быстродействия озу и количества запросов таблицу естественно можно разделить на несколько серверов но именно с хранением всей инфы в одной ячейке
      
      Проблема в том, что наши современные машины, слишком медленные. Ну вот не могут они быстро работать! Хоть самое дорогое железо покупай.
      
      >>4. количество запросов увеличится, ибо всё лежит в одном месте.
      >зато выполнятся будут очень быстро
      
      А не вы ли говорили, о том, что система должна быть дубовой и простой?
      Быстроты не получится, хотя бы из-за того, что совсем дубовая система будет отдавать все данные о пользователе, перегружая сеть избыточной инфой. А для более умной, потребуется сложный запрос, как-то выбирающий нужные данные из записи.
      
      >>5. добавление новых столбцов или переконфигурирование старых, станет слишком дорогим действием. Придётся останавливать систему на пару дней.
      >никаких проблем в этом не будет
      >лимитирован размер а не структура записи
      >можно выделить сразу с запасом памяти
      >даже по мегабайту на человека на Россию хватит 150 тб
      
      Ну вот. Начинается. Сразу вспоминается "для любых задачь хватит 64 килобайт".
      По мегабайту? Как вы считали? Я же говорю, аппетит приходит во время еды.
      В базу захотят засунуть всё. Не только медецинские дела, судебные, штрафы, налоги, отпечатки пальцев, но фотографии, звукозаписи и так далее.
      Уже существуют системы распознования людей по лицам. Есть системы распознавания по голосу. А по отпечатку пальцев и ресунку глаза, уже встраивают в обычные гаджеты.
      Нет. Нельзя ставить ограничений. Система должна быть легко расширяема и маштабируема.
      
      >>6. взламав общую систему защиты, или даже получив пароль, злоумышленник получит доступ сразу ко всей информации
      >и хрен что в ней найдет
      
      Ну, в вашем случае, вероятность того, что он чего-то найдёт, несколько выше, чем в моём.
      
      >>если по моему, разносить на разные базы, то получаем:
      >тормоза и увеличение количества запросов
      
      Увеличение числа запросов со стороны клиента, это да. Но как раз это не страшно. А даже в плюс. Клиент будет запрашивать, только действительно нужные данные, до которых у него есть право доступа.получит немного быстрее. Обычный браузер, открывая обычную страницу, в среднем посылает 50 различных запросов.
      
      А вот запросов серверу, будет наоборот меньше. И уменьшится трафик цода, с какой-то одной информацией. Хотя бы по тому что, серваку не придётся отдавать фотографии и звукозаписи, если клиента интересует всего лишь адрес или телефон.
      
      >а также проблемы с синхронизацией
      >
      В вашем варианте, синхронизация потребуется перпендекулярная и сквозная. А она гораздо сложнее и обременительнее, для параллельных жёстко связанных машин.
      В моём же случае, потребуется параллельная синхронизация, которая достаточно проста для параллельных малозависимых машин.
      
      >>Умений надо гораздо больше. Самое простое:
      >>4. удалить запись по номеру.
      >ИМХО хранить вечно
      
      Если делать программу базы данных узкопрофильной, то она быстро загнётся.
      Гораздо практичнее, делать программу, более универсальной, подходящий для разных случаев. Ну вот например для авторизации.
      Технологии двойного назначения или даже тройного, выйгрывают против чисто военных.
      
      А ещё, удаление, нужно для транзакционности.
      Ну и так... Мало ли что потребуется. Например по программе защиты свидетелей.
      
      А вот про "хранить вечно" тут я согласен. Обязательно бэкапы и всё такое.
      
      >>Ха-эм. Переписывать придётся много.
      >да не такто уж и много
      >только выделение блока размером со всю озу
      >и фоновое сохранение на жесткий
      
      Такого выделения, сделать невозможно, чисто физически.
      В оперативке хранится операционка, драйвера, программы, всякие стеки и буфера устройств.
      Да и с выделением большого сплошного куска памяти, тоже обломс.
      Адресация, то есть указатели, делаются короткими и длинными, из-за процессора. Короткий адрес, содержит лишь номер ячейки в текущей странице. А длинный указатель содержит номер страницы и номер ячейки. Там ещё много всяких путаниц. Обойти, переделать можно.
      Но, по моему, проще будет переделать процессор. Или же сделать специальную плату расширения с оперативной памятью.
      
      
      С вашим подходом, я совсем не удивляюсь, что вы считаете язык программирования C, дырой в безопасности. Если бежать всё переделывать, даже не разобравшись в инструменте... Вобщем это антипаттерн.
    400. Поляков Дмитрий Валериевич 2015/06/14 14:37 [ответить]
      > > 399.Талипов Артём
      >Но поиск, полностью отделить не получится. Он должен синхронно обновлять хэши.
      хеши будут обновлятся за счет одновременного отправления данных на хранение и в поисковый сервер
      >> данные по одному человеку целиком в одной записи
      >А вот это, ни в коем случае! Наоборот, максимально разделять и разносить в разных таблицах, разных баз данных, на разные компьютеры.
      >
      >Если делать по вашему, всё в одной записи, то получится:
      >1. все яйца в одной корзине. При утечке огребём кучу проблем.
      тут да но
      1) никто не мешает шифровать данные внутри ячеек паролем который знает только сервер обрабатывающий данные да и можно сделать так что и сервер не сможет ничего расшифровать без подписи под запросом
      то есть даже захватив цод целиком не получится извлечь информацию
      2)захват захват любых двух компонентов из трех не даст доступа к базе
      3)государство таки будет все это охранять
      >2. никакого суперкомпьютера или даже кластера не хватит. Я делал расчёты, исключительно для таблицы id, first_name, midle_name, last_name. Если иначе, то не влезет!
      кластера за глаза
      >3. время операции увеличится, ибо придётся ворочать слишком большими данными.
      время операции зависит исключительно от быстродействия озу и количества запросов таблицу естественно можно разделить на несколько серверов но именно с хранением всей инфы в одной ячейке
      >4. количество запросов увеличится, ибо всё лежит в одном месте.
      зато выполнятся будут очень быстро
      >5. добавление новых столбцов или переконфигурирование старых, станет слишком дорогим действием. Придётся останавливать систему на пару дней.
      никаких проблем в этом не будет
      лимитирован размер а не структура записи
      можно выделить сразу с запасом памяти
      даже по мегабайту на человека на Россию хватит 150 тб
      >6. взламав общую систему защиты, или даже получив пароль, злоумышленник получит доступ сразу ко всей информации
      и хрен что в ней найдет
      >если по моему, разносить на разные базы, то получаем:
      тормоза и увеличение количества запросов
      а также проблемы с синхронизацией
      
      >Умений надо гораздо больше. Самое простое:
      >4. удалить запись по номеру.
      ИМХО хранить вечно
      
      >Ха-эм. Переписывать придётся много.
      да не такто уж и много
      только выделение блока размером со всю озу
      и фоновое сохранение на жесткий
      
    399. *Талипов Артём (eric50@yandex.ru) 2015/06/14 11:03 [ответить]
      > > 398.Поляков Дмитрий Валериевич
      >> > 397.Талипов Артём
      >каждый компонент отдельная программа или вообще отдельный компьютер
      
      Ах... Не сразу вас понял. Да, разумеется, лучше разделять.
      Но поиск, полностью отделить не получится. Он должен синхронно обновлять хэши.
      
      >принцип тот же что у risc вместо одного сложного запроса цепочка из нескольких простых
      
      Ага. Это конечно лучше.
      
      > данные по одному человеку целиком в одной записи
      
      А вот это, ни в коем случае! Наоборот, максимально разделять и разносить в разных таблицах, разных баз данных, на разные компьютеры.
      
      Если делать по вашему, всё в одной записи, то получится:
      1. все яйца в одной корзине. При утечке огребём кучу проблем.
      2. никакого суперкомпьютера или даже кластера не хватит. Я делал расчёты, исключительно для таблицы id, first_name, midle_name, last_name. Если иначе, то не влезет!
      3. время операции увеличится, ибо придётся ворочать слишком большими данными.
      4. количество запросов увеличится, ибо всё лежит в одном месте.
      5. добавление новых столбцов или переконфигурирование старых, станет слишком дорогим действием. Придётся останавливать систему на пару дней.
      6. взламав общую систему защиты, или даже получив пароль, злоумышленник получит доступ сразу ко всей информации.
      
      если по моему, разносить на разные базы, то получаем:
      1. если злоумышленник, каким либо образом получит доступ к одной из баз, то информация для него будет бесполезной.
      2. можно будет использовать обыкновеннные компьютеры, разве что до упора заряженные.
      3. минимальное время, ничего лишнего.
      4. запрашивается только то что нужно, не отвлекая другие машины.
      5. добавление новых столбцов или переконфигурирование старых выполняется почти безболезненно и достаточно оперативно.
      6. упращается разделение прав доступа. Для доступа к двум разным таблицам, нужны два разных пароля. Предоставляется только нужная информация, не более.
      
      >никакой синхронизации
      
      Согласен. Но я подразумевал чуток другое.
      
      >доступ к записям по банальному смещению
      
      На прямую не получится. У менеджера памяти, там двусвязные списки.
      Проще и главное быстрее, сразу делать сразу древовидную структуру.
      
      >сервер хранящий записи их не обрабатывает
      
      Правильно. Нефиг. Лишняя работа. Вынести обработку на другой сервер.
      
      >ему достаточно уметь
      >1)выдать запись по номеру
      >2)заменить запись по номеру
      >3)добавить новую запись
      
      Умений надо гораздо больше. Самое простое:
      4. удалить запись по номеру.
      
      Но с учётом транзакционности, логирования, контрольных сум, серверу придётся поработать.
      
      >нафиг ось вместе с менеджером памяти
      >точнее переписать менеджер под задачу
      
      Ха-эм. Переписывать придётся много. А в итоге, получится почти тоже, с новыми багами и новыми глюками.
      Очень много людей, потоптались по граблям переписывания менеджеров памяти. Это любимое занятие велосепедостроителей.
      И очень много рыдали, по сему поводу.
      Современные менеджеры памяти, кажутся плохими, неудобными, медленными, тормознутыми. Но они вылизаны. И поддерживаются аппаратно.
      любой собственный велосипед, заведомо хуже. Субъективные тесты, показывают круть. Но по объективным комплексным тестам, нервно курят в сторонке, против стандартных.
      
      >а обработкой записей согласно прав доступа будет заниматься другой компьютер
      
      Естественно. Отдельная машина, только проверяющая права. Это вобще-то класика.
      Причём, логин и пароль, можно хранить в такой же базе данных!
      
    398. Поляков Дмитрий Валериевич 2015/06/14 10:07 [ответить]
      > > 397.Талипов Артём
      >Разделение, как и где?
      >Разные программы? - Не получится, ибо даже на одной машине, потом синхронизовывать данные замучаетесь. А на разных, расшибёте лоб.
      >Разные подпрограммы? Так оно так и делается.
      хранение отдельно поиск отдельно права доступа отдельно
      каждый компонент отдельная программа или вообще отдельный компьютер
      принцип тот же что у risc вместо одного сложного запроса цепочка из нескольких простых
      никакой синхронизации данные по одному человеку целиком в одной записи
      доступ к записям по банальному смещению
      сервер хранящий записи их не обрабатывает
      ему достаточно уметь
      1)выдать запись по номеру
      2)заменить запись по номеру
      3)добавить новую запись
      >Да. Это разумный шаг. Я его подразумевал. Но там есть сложности, из-за менеджеров памяти, которые фрагментируют страницы памяти. По этому прямого доступа по индексу не получится. Как вы и написали, нужны будут деревья.
      нафиг ось вместе с менеджером памяти
      точнее переписать менеджер под задачу
      >Например, если на первом компьютере лежит собственно база данных с полными фио. То на втором компьютере лежат хэши полных фио и работает поиск. Второй компьюютер работает лишь на поиск, не отвлекая первый компьютер.
      смотри выше
      >А для специализированных баз данных, вроде обсуждаемого реестра всех граждан или банковских счетов, подобная асинхронность и даже небрежность, уже сверхкретична.
      >Не правда ли, вам было бы не смешно, если бы вы захотели снять деньги, а терминал сказал бы, что вашего счёта не существует.
      а тут дублирование поможет сдохла нода и черт с ней с резерва загрузится
      
      а обработкой записей согласно прав доступа будет заниматься другой компьютер
      http://i71.fastpic.ru/big/2015/0614/da/d8866f32847b160010df0ff376a492da.png
    397. *Талипов Артём (eric50@yandex.ru) 2015/06/14 09:29 [ответить]
      > > 396.Поляков Дмитрий Валериевич
      >SQL таки язык запросов и напрямую к архитектуре БД не относится
      
      Согласен. Но, хрен его оторвёш от субд. А ведь, он частенько мешает.
      
      >если бы я реализовывал бы БД для этой задачи с нуля то сделал бы разделение функционала
      >хранение/изменение/выдача по id отдельно
      >всякий поиск отдельно
      
      Разделение, как и где?
      Разные программы? - Не получится, ибо даже на одной машине, потом синхронизовывать данные замучаетесь. А на разных, расшибёте лоб.
      Разные подпрограммы? Так оно так и делается.
      
      >тогда можно первую часть реализовать как нормированную по размеру записи таблицу в озу (скажем по 4 кб на запись а сколько конкретно на какой столбец уйдет неважно)
      
      Да. Это разумный шаг. Я его подразумевал. Но там есть сложности, из-за менеджеров памяти, которые фрагментируют страницы памяти. По этому прямого доступа по индексу не получится. Как вы и написали, нужны будут деревья.
      
      >а поиск сделать классическим для реляционных бд способом на основе деревьев
      
      Ну разумеется. Бинарный поиск, это простейший вид поиска по дереву.
      Просто, я ещё предлагал, в дополнение, делать специальные хэши текстовых записей. Чтобы не сравнивать каждый раз, ячейку с образцом. А заранее вычислить хэши образца и выполнять поиск этих хэшей. И только потом, уже сравнить образец со значением.
      
      Причём, для текста, нужны специализированные, лингвистические хэши, учитывающие ошибки написания, специфику фонетики и так далее.
      
      >это значительно поднимет производительность даже при реализации на одном компьютере, но главное что разные части поиска могут работать на разных компьютерах что поднимет производительность еще на порядок по сравнению с одиночным компьютером
      
      Опять же не совсем.
      Действительно, что-то можно разделить, раздробить. Но задача там гораздо хитрее.
      Например, если на первом компьютере лежит собственно база данных с полными фио. То на втором компьютере лежат хэши полных фио и работает поиск. Второй компьюютер работает лишь на поиск, не отвлекая первый компьютер.
      
      Поисковики, вроде yandex, google, фрагментируют свои базы, распределяя их по нодам.
      Данные подсасываются с нужных нод.
      Только, следует учитывать специфику этих машин.
      Они работают на постоянное чтение и эксклюзивную запись от поисковых роботов.
      А конечный пользователь, не будет рвать волосы на жопе, если нода отдаст старые данные или вобще потеряет часть ответа.
      В справке яндекса, так прямо и написано, что если нода перегружена, то она отклоняет новые входящие запросы.
      
      А для специализированных баз данных, вроде обсуждаемого реестра всех граждан или банковских счетов, подобная асинхронность и даже небрежность, уже сверхкретична.
      Не правда ли, вам было бы не смешно, если бы вы захотели снять деньги, а терминал сказал бы, что вашего счёта не существует.
      Или ещё веселее, бугалтерия, не смогла бы перевести вам зарплату, поскольку счёта опять же нет.
      Ну, а так же, возможна была бы ситуация, если бы на ваш счёт, одновременно клали бы 10 рублей и 100000 рублей. А на счёте, допустим всего 100 рублей. В ситуации гонки, первый поток считал бы текущее значение, просумировал бы и получил бы 110 рублей. В это время, второй поток, считал бы значение и получил бы 100100 рублей и записал бы это значение. А после на это же место, записал бы значение второй поток. А ваши кровные 100000 рублей, уплыли бы в пустоту, будучи бонально затёрты.
      По этому, разнесение на разные компьютеры кретически опасно.
      
      В случае с проксирующими базами данных, тоже фрагментирующих данные, можно делать трюк с передачей прав на владение актуальными данными.
      То есть в центре, ставится ещё одна база данных, в которой записывается, кто в данный момент, владеет актуальным вариантом записи.
      
      Работает это так:
      1. клиент запрашивает данные у локального прокси.
      2. локальный прокси проверяет, знает ли он нужные данные.
      3. если знает и владеет, то отдаёт сразу.
      4. если не знает, то запрашивает их у центра.
      5. если центр не владеет актуальными данными, то отзывает право владения и обновляет собственные данные, от стороннего прокси.
      6. если центр владеет актуальными данными, то отдаёт их запрашивающему локальному прокси, помечая нового владельца.
      
      Тем самым, центр работает лишь в качестве редкоиспользуемого глобального хранилища. А в основном он просто перераспределяет данные, между локальными центрами хранения.
      
      На самом деле, можно было бы помудрить с оптимизацией трафика. Сделать распределённую сеть, чтоб локальные базы данных сразу запрашивали инфу с других локальных, не перемещая данные через центр.
      Но в таком случае, придётся уже мудрить. О дубовости и надёжности, останется лишь мечтать.
      
      Или же наоборот, дать права чтения локальным, а запись производить только на глобальный.
      Но в таком случае, нагрузка на центр дополнительно возрастёт. И что ещё хуже, придётся усложнять алгоритмы синхронизации. И опять дубовая надёжность идёт лесом.
      
      Во всех этих системах, первейшее правило:
      "чем проще, понятнее и нагляднее, тем лучше".
      За лишние функции, бьют по рукам и компостируют мозг. Например по этому, банковские терминалы, не умеют выдавать сумму произвольными купюрами.
      
      Так что о всяких разделениях функционала, для последующей синхронизации, следует забыть. Это годится для поисковых серверов, игровых серверов, сетевых энциклопедий, социальных сетей. Там подобная информация не критична.
      
    396. Поляков Дмитрий Валериевич 2015/06/14 08:16 [ответить]
      > > 395.Талипов Артём
      >От всяких sql баз данных, надо бы отказатся. Слишком они умные и непредсказуемые. В идеале, нужны простейшие базы данных, вроде berkeley db. Но с ними наоборот, проблема их дубовости. Нет разбиения столбцов. А что ещё хуже, они заточены под хранение на диске, а не в оперативке.
      SQL таки язык запросов и напрямую к архитектуре БД не относится
      если бы я реализовывал бы БД для этой задачи с нуля то сделал бы разделение функционала
      хранение/изменение/выдача по id отдельно
      всякий поиск отдельно
      тогда можно первую часть реализовать как нормированную по размеру записи таблицу в озу (скажем по 4 кб на запись а сколько конкретно на какой столбец уйдет неважно)
      а поиск сделать классическим для реляционных бд способом на основе деревьев
      это значительно поднимет производительность даже при реализации на одном компьютере, но главное что разные части поиска могут работать на разных компьютерах что поднимет производительность еще на порядок по сравнению с одиночным компьютером
    395. *Талипов Артём (eric50@yandex.ru) 2015/06/14 07:45 [ответить]
      > > 394.Поляков Дмитрий Валериевич
      >> > 393.Талипов Артём
      >насчет дороже
      >если это будет реализовываться то будет реализовываться государством
      >а там совершенно другие масштабы денег цена на любое железо будет каплей в море
      
      Сами сервера , да, не очень дорого. Но понадобится ещё много рабочих станций (в прочим они уже много где есть). Основные траты пойдут на прокладку сети и собственно поддержку оборудования.
      
      >потолок по озу для серийно производящегося одиночного компьютера на данный момент 768 гигабайт и это ограничение не чипов а разводки материнки тоесть вполне преодолимое
      
      Ха! аппетит приходит во время еды. И всё же, действительно оперативка не столь критична. Критична её тормознутость.
      
      >софт естественно нужно написать
      >благо чем "дубовее" софт тем проще его отладить и сложнее его взломать
      
      Эх. А вот тут проблема. Дубовый софт будет тормозить. И не всё так просто с написанием. Типичный спагети-код, это яркий пример именно дубового софта. То есть сам по себе, источник проблем.
      
      От всяких sql баз данных, надо бы отказатся. Слишком они умные и непредсказуемые. В идеале, нужны простейшие базы данных, вроде berkeley db. Но с ними наоборот, проблема их дубовости. Нет разбиения столбцов. А что ещё хуже, они заточены под хранение на диске, а не в оперативке.
      По моему, нужна концептуально промежуточная база данных. Чтоб работала с одной таблицей, но с несколькими столбцами. Чтоб писала на диск, но могла целиком или частично, висеть в оперативной памяти.
      И ещё, всякие операции, вставки/изменения, требуют, тоже не очень простой логики. Дубовость не проходит.
      Да и поддержка логгирования, реплецирования, транзакционности, очень нужны, но не так-то просты в реализации.
      
      >особенно если он написан на нормальном языке а не на такой дыре в безопасности как си
      
      Да, C, в кривых руках, это дыра безопасности. Но в кривых руках, дырой безопастности будет что угодно. Я бы предложил более защищённый C++, но он многое уноследовал от C, и криворукий, обязательно отстрелит себе ноги.
      
      Но если отбросить asm, c, c++, то что остаётся? Язык d, плохо сбалансирован и подчищен от артефактов. Язык rust всё ещё сырой.
      Всякие интерпретируемые языки, не совсем дубовые. Код более защищён, а вот интерпретатор и фреймворки нужно вылизывать ещё долго. Да и хрень там упороли, во всех. Разве что, вот dot net, более-менее грамотно сделан. Только вот, проприетарный язык, на проприетарной платформе, тоже дыра в безопасности, причём секретная!
      К тому же, интерпретируемые языки, пусть более гибкие, более защищённые, но они более ресурсоёмкие.
      Остаётся, всё же C++. Он хорошо изучен. Все его проблемные места известны и задокументированы. Есть множество инструментов для поиска ошибок. Главное нанять крутого разработчика.
      
      >а от интернета никуда не денешься на данный момент
      >слишком страна большая
      >остается шифровать благо есть принципиально не взламываемые ничем кроме брутфорса алгоритмы осталось только сделать на их базе достаточно производительные крипточипы
      
      Да. Это, действительно так. Сразу снимается затраты на прокладку сетей. И добавляются затраты на шифрование.
      
      Но, по факту, бахатся там и бахатся, пока это всё нормально заработает.
      
      Кроме самих баз с данными, нужны ещё программы для контроля прав доступа и ещё много чего. Я могу лишь предположить наличие трудностей. Но поскольку я темой не занимался, то не могу представить, что ещё потребуется.
    394. Поляков Дмитрий Валериевич 2015/06/14 07:05 [ответить]
      > > 393.Талипов Артём
      насчет дороже
      если это будет реализовываться то будет реализовываться государством
      а там совершенно другие масштабы денег цена на любое железо будет каплей в море
      
      потолок по озу для серийно производящегося одиночного компьютера на данный момент 768 гигабайт и это ограничение не чипов а разводки материнки тоесть вполне преодолимое
      софт естественно нужно написать
      благо чем "дубовее" софт тем проще его отладить и сложнее его взломать
      особенно если он написан на нормальном языке а не на такой дыре в безопасности как си
      
      а от интернета никуда не денешься на данный момент
      слишком страна большая
      остается шифровать благо есть принципиально не взламываемые ничем кроме брутфорса алгоритмы осталось только сделать на их базе достаточно производительные крипточипы
    393. *Талипов Артём (eric50@yandex.ru) 2015/06/14 05:01 [ответить]
      > > 391.Поляков Дмитрий Валериевич
      >> > 389.Талипов Артём
      >у меня есть "сервер" на 525 атоме тысячи три sql запросов в секунду вполне выдерживает (База в озу, сеть гигабитная)
      
      Хо! Нашли с чем сравнивать. Да ещё как сравнивать! :-)
      Понятно, что ваш малыш, справляется с подобной игрушечной задачей.
      
      во-первых база в оперативки, это очень круто. И на 64-битной архитектуре, вполне реализуемо. Где бы только найти столько планок памяти? Вы представьте себе, объём базы, ну, даже просто с полным фио? Для 143 миллиона записей, надо 34 гига, как минимум! Действительно, это кажется реальным. Но, я считал лишь минимум. На такую базу, по совести, надо 256 гигов, чтоб разрешить длинные фамилии, добавить индексы всех столбцов и специальные упращённые представления текста. Но это хорошо лишь для баз read only.
      
      во-вторых, чем база больше, тем медленнее работает поиск. Выдернуть запись по id, это плёвое дело. А поиск по тексту, уже сложнее. Если текстовые столбцы проиндексированы и тем более сделаны специальные представления записей, то бинарным поиском можно относительно быстро найти нужную запись. И всё равно, этодолго. O(log2n), где n - число записей.
      
      В третьих число запросов... Эм-эм-эм. Область спецефичная, но всяко будет очень много! К примеру сбербанк, держит базу данных всех клиентов на очень мощном компьютере малосерийной сборки, и всё равно мощности машинки, хватает не всегда. Это простому банку, достаточно обычной машины, со стандартной конфигурацией. При этом, и на специальных и на обычных машинах, скорость доступа к памяти, существенно не отличается.
      
      И даже, как предложил я, поднимая базу данных, на отдельной машине, для отдельных таблиц, не так-то просто получится облегчить задачу. А ведь, придётся, что-то думать, на счёт полноценного read and write доступа с гарантированной записью на диск.
      
      >а современные компы куда производительнее
      
      Ну... Современные компы производительнее. Но они и дороже. В смысле ультра современные. Да ещё с детскими болезнями.
      А для столь спецефичной задачи, придётся разрабатывать очень специализированное програмное обеспечение.
      
      Да, при желании, сделать упращённую хрень, можно и сейчас. Особенно если делать локальные кэширующие и проксирующие машины, для облостей и городов.
      
      Но! Тут есть ещё один ньюанс, о котором надо подумать. В идеале, надо поднимать государственную закрытую сеть, на всю страну. Такой трафик, очень не рекомендуется пускать, через часные сегменты интернета, даже если зверски зашифрованный.
      Вон, всякие датацентры гугла, фейсбука и так далее, между своими центрами, кидают свои закрытые линии, только для своего личного трафика.
      
      >взлом при правильном софте возможен только при наличии физического доступа
      
      Нельзя гарантировать. Конечно правильный софт, закроет очень много дырок. Осталось найти то волшебное место, где есть правильный софт.
      А робота, даже очень умного, можно обмануть. Порой, дыры появляются, как раз от умностей. С другой же стороны, тупой робот, даже не догадается, что его обманули. Он обработает и дружественные и вражеские запросы. Так что нужен балланс.
    392. Поляков Дмитрий Валериевич 2015/06/13 22:49 [ответить]
      > > 390.котовск
      >> > 386.Талипов Артём
      >>Ну, пусть хоть сделают единую базу данных граждан!
      >есть. называется АСПИД
      "В 1998 году в отделении идентификации и исследования неопознанных трупов Хабаровского краевого бюро судебно-медицинской экспертизы разработана и внедрена компьютерная программа 'АСПИД' (автоматизированная система первичной идентификации неопознанных трупов). Программа 'Аспид' предназначена для предварительной идентификации неопознанных трупов по признакам внешности и предоставляет пользователю следующие возможности:
      - фиксация более тридцати признаков внешности (не считая зубной формулы);
      - сортировка данных по шести признакам;
      - фильтрация данных по пятнадцати признакам;
      - распечатки опознавательной карты;
      - распечатки списка записей;
      - просмотр графических файлов формата 'bimap'."
      если она то это совсем не то
      
      
      
    391. Поляков Дмитрий Валериевич 2015/06/13 22:42 [ответить]
      > > 389.Талипов Артём
      >Нет. Он с нагрузкой не справится. Хранить можно. Юзать нельзя.
      у меня есть "сервер" на 525 атоме тысячи три sql запросов в секунду вполне выдерживает (База в озу, сеть гигабитная)
      а современные компы куда производительнее
      >И опять проблема воровства. Среднестатистический комп, взламывается очень быстро.
      взлом при правильном софте возможен только при наличии физического доступа
      
      
    Текущее Страниц (26): 1 ... 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Архивы (2): 1 2

    Связаться с программистом сайта.

    Новые книги авторов СИ, вышедшие из печати:
    О.Болдырева "Крадуш. Чужие души" М.Николаев "Вторжение на Землю"

    Как попасть в этoт список

    Кожевенное мастерство | Сайт "Художники" | Доска об'явлений "Книги"