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

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

Самиздат: [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь|Техвопросы]
  • © Copyright Симонов Сергей (gann.lector@yandex.ru)
  • Размещен: 15/10/2014, изменен: 15/10/2014. 0k. Статистика.
  • Глава: Фантастика
  • Аннотация:
    Отрывок преобразован в тему для обсуждения. Текст отрывка внесен в основной файл книги как глава 23
    		• ОБСУЖДЕНИЯ: Фантастика (последние)
    09:53 Чернов К.Н. "Записки Империалиста Книга " (712/5)
    09:11 Родин Д.М. "Князь Барбашин 3" (843/4)
    09:08 Ким В.В. "Минимально необходимое воздействие-" (132/27)
    08:51 Баламут П. "Ша39 Бронетанковая" (460/9)
    Добавить комментарий Отсортировано по:[убыванию][возрастанию]
    Текущее Страниц (26): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... 26Архивы (2): 1 2
    ОБЩИЕ ГОСТЕВЫЕ:
    09:58 "Форум: Трибуна люду" (188/101)
    09:55 "Форум: все за 12 часов" (136/101)
    09:50 "Диалоги о Творчестве" (291/36)
    02:46 "Технические вопросы "Самиздата"" (235/2)
    25/11 "Форум: Литературные объявления" (666)
    25/11 "О блокировании "Самиздата"" (294)
    ОБСУЖДАЕМ: Симонов С.
    00:39 "Цвет сверхдержавы - красный " (552/1)
    26/11 "Создание правильного образа " (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)
    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)
    ОБСУЖДЕНИЯ: (все обсуждения) (последние)
    09:53 Чернов К.Н. "Записки Империалиста Книга " (712/5)
    09:51 Чваков Д. "К утраченному" (2/1)
    09:50 Модератор-2 "Диалоги о Творчестве" (291/36)
    09:41 Стоптанные К. "Спешились Карлсоны, их баки " (308/2)
    09:40 Калинин А.А. "Басенки 2024-11" (2/1)
    09:35 Детектив-Клуб "Арена детективов-8: Результаты " (59/1)
    09:19 Логинов Н.Г. "Дарю!" (25)
    09:18 Давыдов С.А. "Флудилка Универсальная" (604/4)
    09:17 Березина Е.Л. "Гёдель в шоке" (8/4)
    09:16 Винокур Р. "О поэтах прошлого" (16/12)
    09:14 Ив. Н. "02 декабря" (1)
    09:13 Вордин С. "Всей птичке пропасть" (14/8)
    09:11 Родин Д.М. "Князь Барбашин 3" (843/4)
    09:09 Уралов А. "Мясо "из пробирки"" (687/15)
    09:08 Ким В.В. "Минимально необходимое воздействие-" (132/27)
    08:51 Баламут П. "Ша39 Бронетанковая" (460/9)
    08:51 Седрик "Список фанфиков с моими комментариями" (383/8)
    08:29 Ролько Т. "О гносеологическом крушении " (531/6)
    08:28 Смолина А.Н. "Любопытные факты об Украине - " (1)
    07:31 Вебер А. "Полеты во сне и повелитель " (1)

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

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

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

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

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


    30/11 ПОЗДРАВЛЯЕМ:
     А.Астраханский
     Аккуратов А.С.
     Акстись А.С.
     Андрианов С.Н.
     Бахчевников В.В.
     Белокурова Е.Э.
     Болотин Д.Г.
     Быков А.В.
     Володин И.
     Герасимов А.А.
     Гордийчук А.Н.
     Грахн А.
     Грибовская И.
     Деревянченко М.
     Долгополова П.Р.
     Заболотников А.А.
     Зайкина Н.
     Ильиных С.И.
     Каретников Н.В.
     Катджит Д.
     Колентьев А.С.
     Колчанов А.
     Костенкова К.Е.
     Кравцив Р.Б.
     Красулина Н.
     Кремнев Е.А.
     Лигина В.В.
     Лобач М.П.
     Макарова Е.А.
     Мельник А.А.
     Мызников В.Е.
     Немец Л.
     Нинель Т.
     Овчинникова М.С.
     Палитко С.А.
     Певзнер М.Я.
     Перунова О.А.
     Печников В.Ю.
     Подвисоцкий Д.В.
     Попова К.А.
     Прочерк И.А.
     Раев А.М.
     Райкири
     Рыжая
     Садов М.В.
     Салий Е.
     Саранча В.П.
     Соловьева К.
     Сорокин О.В.
     Староветров Р.
     Трамонтана П.
     Фаг А.
     Чиширская Р.
     Чудинова Т.
     Alucard-Den-Engla
     Corvus
     Foxurineko
     Mur A.
     Neya B.
    ПОСЛЕДНИЕ ПОСТУПЛЕНИЯ: (7day) (30day) (Рассылка)
    00:08 Манчев В.С. "Царичина (1 часть)"
    22:10 Неизвестный А.Ф. "Часть Вторая"
    17:04 Шаповал Н.И. "Сборник стихов"
    12:34 Бирюк В. "Зверь лютый. Книга 5. Парикмахерия"
    28/11 Иевлев Г.В. "В плену горячей звезды"
    371. *Симонов Сергей (gann.lector@yandex.ru) 2015/03/03 06:48 [ответить]
      На тот момент там весь рынок связи - пара радиостанций и телефоны в госучреждениях и у 5% очень богатых. Всю инфраструктуру надо создавать с нуля.
      Но мысль интересная. Засада в том, что аппаратуры на нужды СССР - и то не хватает.
    372. Талипов Артём (eric50@yandex.ru) 2015/03/05 10:05 [ответить]
      > > 371.Симонов Сергей
      >На тот момент там весь рынок связи - пара радиостанций и телефоны в госучреждениях и у 5% очень богатых. Всю инфраструктуру надо создавать с нуля.
      
      Согласитесь, в этом есть определённый смак. Это сложно, ответственно, но приятно. Прям, как дефлорация.
      
      >Но мысль интересная. Засада в том, что аппаратуры на нужды СССР - и то не хватает.
      
      А в этом-то и смак. Нехватает нам. Нехватаит им. А вообще, кому аппаратуры хватает?
      
      Вот у вас, в книге, ударно строятся заводы железобетона, нефтеперегонки. В китае, прокачивается текстиль, пластики.
      А на счёт аппаратуры, раз, два и всё? Где заводы?
      
      Как-то попалось сравнение. Один из попаданцев рыдает перед второй мировой. "у немцев куча радиостанций, в каждом танке, в каждой роте, а у наших считанные единицы". А немного позже, он же "ну да, правильно. Ведь только под берлином две тысячи фирм, изготавливающих аппаратуру, а в союзе их всего пять".
      
      Щупал ручками советскую рацию. А заодно выслушивал лекцию, про компоненты. "а вот это трафейные лампы". "то есть они конечно нашего производства. Но копия немецких, Они их в войну, на свои радиостанции ставили. А нашим в шестедесятых, удалось их скопировать." Я выпал в осадок.
      
      Вот чесно, такое впечатление, что в ссср, все эти радиокомпоненты, делали по остаточному признаку, причём уподобляясь танкостроительству. В стране есть Харьковский и Уральский танкостроительный завод, всё хватит. Ну и ещё Ленинградский, делать электронные компоненты. И на этом хватит.
      
      Нет уж. Лучше делать сотню заводов. И пусть они специализируются, хотя бы на чём-то одном. Причём со своими лабораториями, исследовательскими и прочим. Пусть каждый завод, хорошо делает конкретный тип деталий, резисторы или конденсаторы. Но пусть делают действительно хорошо. А в случае чего, отгребают по полной и наград и наказаний. В этом смак централизации.
      А когда один громадный завод, выпускает всё сразу, причём как попало, то это тихий ужас. И что хуже, продукция, распределяется, вообще самым странным образом.
    373. Vir 2015/03/05 10:49 [ответить]
      > > 372.Талипов Артём
      >Нет уж. Лучше делать сотню заводов. И пусть они специализируются, хотя бы на чём-то одном. Причём со своими лабораториями, исследовательскими и прочим.
      
      В СССР не получится. Нет достаточного количества людей, способных там работать. В Германии и Китае с Японией таких много, потому что там веками шел отбор на генетическом уровне благодаря протестантизму и конфуцианству. В других странах или работают потомки немцев и азиатов, как в США, или успехи немногим больше СССР.
      
      Ну вот нет у людей кроме немцев, китайцев и японцев в мозге нужных структур. Изобрести могут что угодно, до чего немцы будут 100 лет доходить, а китайцы с японцами вообще никогда не додумаются. Но вот серийно производить миллионами и миллиардами другие народы умеют гораздо хуже.
      
      К счастью, у СССР есть ГДР.
    374. *Симонов Сергей (gann.lector@yandex.ru) 2015/03/05 15:35 [ответить]
      В АИ у СССР есть еще и Китай, и половина Индокитая. Вьетнам, Лаос, Камбоджа
      Сборочные операции можно вынести туда
    375. strangeserg (strangeserg@yandex.ru ) 2015/03/06 19:22 [ответить]
      > > 374.Симонов Сергей
      >В АИ у СССР есть еще и Китай, и половина Индокитая. Вьетнам, Лаос, Камбоджа
      >Сборочные операции можно вынести туда
      
       В сущности так и должно быть: в СССР 70-80-х (в РеИ)))) ЭТО называлось "международное разделение труда", - сейчас чаще используется "модный" (и многими заслуженно ненавидимый!..) термин "глобализация"!
       Её периодически "хоронят" (политики и эксперты-"предсказатели"), - НО она таки "живее всех живых": просто "мутирует" (ага... как вирус гриппа!)))), видоизменяясь в зависимости от условий и обстоятельств...
       Хотя, конечно, "глобализация" - понятие значительно более "широкое и ёмкое", чем просто "международное разделение труда": ну и пускай в АИ-мире БУДЕТ "Глобализация по-советски"!!!
      
       Что-то "можно и нужно" (в свете сказанного - "национальных особенностей психологии и менталитета", - КРАЙНЕ трудно "корректируемых"!..) "отдать"/"разместить"/"организовать" в ГДР и Чехословакии (когда-нибудь может быть и в "объединённой Германии" и во Франции/Бельгии/Голландии?.. по мере "победы социализма на континенте"?!), - что-то в ЮВА (КНР/КНДР/СРВ, Лаос, Таиланд и Камбоджа..?)...
       Единственно, должны быть в АИ "найдены"/созданы/разработаны ТАКИЕ "схемы взаимоотношений", взаимодействия и "партнёрства" внутри СЭВ и ВЭС, - ЧТОБЫ опять СССР не оказался "в итоге" в том же "неприятном положении" (из упорно приводимого "Адиком" анекдота...), что имело место в РеИ!
       А со временем, - при "тотальной" автоматизации/роботизации производств, - постепенно "разница в качестве/"культуре производства"/удельных затратах" начнёт исчезать: от собственно "человеческого фактора" непосредственно в производственного процессе будет зависеть всё меньше и меньше!..
      
    376. *Симонов Сергей (gann.lector@yandex.ru) 2015/03/06 19:34 [ответить]
      > > 375.strangeserg
      
      Эту тему предлагаю обсуждать здесь:
      http://samlib.ru/comment/s/simonow_s/02-07_proda
    377. jantar (andrat@ukr.net) 2015/03/19 14:17 [ответить]
      Не знаю поднималась ли даная тема
      
       http://topgir.com.ua/sokrovenno-chto-za-chernye-vederki-stoyat-na-avto-ukrainskoj-elity/
      
       Это о спецсвязи на автомобилях
    378. *Симонов Сергей (gann.lector@yandex.ru) 2015/03/19 18:39 [ответить]
      > > 377.jantar
      >Не знаю поднималась ли даная тема
      
      > Это о спецсвязи на автомобилях
      
      Спецсвязь "Алтай" во 2й книге упоминается, что начата разработка. Про "Пелену" узнал впервые, спасибо.
    379. Талипов Артём (eric50@yandex.ru) 2015/03/28 16:53 [ответить]
      > > 378.Симонов Сергей
      > Про "Пелену" узнал впервые, спасибо.
      Переодически подобные фичи упоминаются. Мол приехали сапёры, поставили глушылку радиосвязи... Или как в военной колонне шла машина со средствами подавления радиовзрывателей.
      
      Понятия не имею, как такое сделано. Разве что тупо глушить весь диапазон сигналов, забивая их шумом.
      
      Но, можно ведь сделать совсем тупо. Взять мобильник и подключить к нему взрыватель. Если на мобилу пошел вызов, значит взрыв. Если мобила потеряла сеть, долее чем на три секунды, опять взрыв. Если кодированное сообщение, то блокировка или разблокировка взрывателя.
      
      Можно не мобилу, а вимакс, интерсат, или даже вайфай, али блютус. Всё с тем же успехом. Если нет сети, то взрыв.
      
      По этому глушилка, должна очень быстро сканировать сети в окружающем пространстве. Всякие запароленные сети взламывать и сниферить трафик. А затем, поднимать эмуляторы этих сетей.
      
      Но, на месте минёра, можно было бы бросить шифрованный туннель, по банальному vpn. А ещё лучше, поднимать свою сеть и обмениватся пакетами udp.
      Скажем, каждые 10 секунд, должен приходить пакет, с новым кодом. А устройство отсылать ответ, с маской для следующего кода.
      А если от минёра, пакет не пришел, то взрывать нахрен.
      
      Ни один эмулятор сети, с таким не справится. Это же полный вынос мозга.
      С другой же стороны, активный мобильник засветит себя на радаре. И если это безлюдное место, то можно справоцировать взрыв заранее. Так что активные взрыватели, есть смысл ставить в людных местах. Ну или делать связь по иному принципу, к примеру инфрокрасным или ультразвуковым.
      
      Обычная борьба меча и щита. Но, я бы не стал, полностью полагатся на "пелену" или другую подобную систему. Защита сработает только от лохов, которые подключают электродетанатор, к плате снятой с радиоуправляемой модели.
    380. Поляков Дмитрий Валериевич 2015/03/28 17:39 [ответить]
      > > 379.Талипов Артём
      
      >Но, можно ведь сделать совсем тупо. Взять мобильник и подключить к нему взрыватель. Если на мобилу пошел вызов, значит взрыв. Если мобила потеряла сеть, долее чем на три секунды, опять взрыв. Если кодированное сообщение, то блокировка или разблокировка взрывателя.
      
      радиус работы у глушилок если они не ограничены стенами помещения
      зависит от мощности и обычно составляет сотни метров
      взрыв на таком расстоянии относительно безопасен
    381. Талипов Артём (eric50@yandex.ru) 2015/03/28 19:23 [ответить]
      > > 380.Поляков Дмитрий Валериевич
      >> > 379.Талипов Артём
      >взрыв на таком расстоянии относительно безопасен
      
      Это смотря что минировать. Например железнодорожный мост и ли туннель, ожидая поезд. Состав не успет затормозить. А если проедет дрезина с глушилкой, то взрыв разрушит пути.
      
      А ещё можно менировать высотные здания, нефтеные или газовые стратегические хранилища, склады боепрепасов, бомб, плотины на водохранилищах или морские дамбы, атомные электростанции, олимпийские стадионы и ещё много чего.
      
      Но если вспомнить статистику террорестических актов, то они используют пукалки.
      Взрыв в толпе людей. 15 человек убито, 70 ранено. И это считается крупным.
      Взрыв, один убит (смертник который взрывал бомбу), 3 легко ранено. Обычная картина.
      Ну или сработал фугас. Уничтожен бронетранспортёр с экипажем и пассажирами. Есть несколько раненых с других машин.
      
      А смысл для таких слабых мин, ставить серьёзный радиодетонатор?
      Я вообще не понимаю, зачем размениватся на мелочи?
      Это самый натуральный блеф. Мол "бу-у-у, мы страшные, бойтесь нас!".
      Вот я понимаю, американцы когда взорвали свои башни-близнецы 11 сентября, это было круто. Ну, дык им опять же был нужен повод начать войну. То есть, теракт их особо не интересовал, главное заключалось в информационно-психологическом воздействии на население.
      
      Если устраивать террорестический акт, то по настоящему. Чтоб усрались все. Ну, например, взять большую камету и скорректировать её траекторию несколькими тысячами мегатонных взрывов. А потом, громко глумится над всеми, пока эта комета пойдёт на перехват Земли. После встречи двух тел, глумится будет некому и плакать тоже.
      Вот это я понимаю, настоящий террорестический акт.
      Это шедевр, над которым интересно поработать.
      Кстати, я уже писал, это было бы круто прикрутить к проекту "периметр", мёртвой руке советского союза.
      
      А всё прочее, пф-ф-ф, это мелочи. Игра в песочнице.
    382. Следж Хаммер 2015/06/05 00:08 [ответить]
      На пути к ОГАС
      http://informaticslib.ru/books/item/f00/s00/z0000004/st005.shtml
    383. Scharapow Wladimir 2015/06/05 00:20 [ответить]
      > > 382.Следж Хаммер
      Наивные люди были...
    384. Следж Хаммер 2015/06/05 08:53 [ответить]
      > > 383.Scharapow Wladimir
      >> > 382.Следж Хаммер
      >Наивные люди были...
      А ведь уже 1975 год, за рубежом есть некоторые аналогичные системы
      
      
    385. *Симонов Сергей (gann.lector@yandex.ru) 2015/06/05 09:09 [ответить]
      > 382. Следж Хаммер
      
      Спасибо, полезная книга, надо использовать
    386. *Талипов Артём (eric50@yandex.ru) 2015/06/05 09:14 [ответить]
      До сих пор не сделали.
      А сейчас, это гораздо проще.
      
      Ну, пусть хоть сделают единую базу данных граждан!
      Пусть даже её фрагментируют, разные таблицы в разных датацентрах и с разными правами доступа.
      
      Например, в первой базе данных, только:
      идентификатор, фамилия, имя, отчество, дата рождения, дата смерти.
      
      Во второй базе данных:
      идентификатор, страна, регион, область, город, улица, дом, корпус, квартира, комната.
      
      В третьей:
      идентификатор, номер паспорта, серия паспорта, дата выдачи, место выдачи.
      
      В четвёртой и ещё нескольких, телефоны, домашние, рабочие, мобильные и так далее.
      
      И вот так по всему. И только идентификатор сквозной.
      А без доступа, ну, хотя бы к двум базам данных, хрен чего узнаешь.
    387. Следж Хаммер 2015/06/05 09:14 [ответить]
      Кстати, для понимания как нужны были ЭВМ, и что к 1958 нужна серийная малая машина - www.novsu.ru/file/866020 http://www.computer-museum.ru/histussr/bd_ozu_sorucom_2011.htm
      
    388. Поляков Дмитрий Валериевич 2015/06/05 09:39 [ответить]
      > > 386.Талипов Артём
      >До сих пор не сделали.
      >А сейчас, это гораздо проще.
      
      досих пор не сделали потому что так воровать проще
      технически уже в 92 году техника вполне тянула
      а сейчас вся бд по россии спокойно может работать на среднестатистическом домашнем компе
    389. *Талипов Артём (eric50@yandex.ru) 2015/06/06 11:42 [ответить]
      > > 388.Поляков Дмитрий Валериевич
      >> > 386.Талипов Артём
      >досих пор не сделали потому что так воровать проще
      
      Ну, да. Так и в 1958 году, можно сделать. Только опять возникнет проблема воровства.
      
      >а сейчас вся бд по россии спокойно может работать на среднестатистическом домашнем компе
      
      Нет. Он с нагрузкой не справится. Хранить можно. Юзать нельзя.
      
      И опять проблема воровства. Среднестатестический комп, взламывается очень быстро.
      
    390. котовск 2015/06/13 22:12 [ответить]
      > > 386.Талипов Артём
      >Ну, пусть хоть сделают единую базу данных граждан!
      есть. называется АСПИД
    391. Поляков Дмитрий Валериевич 2015/06/13 22:42 [ответить]
      > > 389.Талипов Артём
      >Нет. Он с нагрузкой не справится. Хранить можно. Юзать нельзя.
      у меня есть "сервер" на 525 атоме тысячи три sql запросов в секунду вполне выдерживает (База в озу, сеть гигабитная)
      а современные компы куда производительнее
      >И опять проблема воровства. Среднестатистический комп, взламывается очень быстро.
      взлом при правильном софте возможен только при наличии физического доступа
      
      
    392. Поляков Дмитрий Валериевич 2015/06/13 22:49 [ответить]
      > > 390.котовск
      >> > 386.Талипов Артём
      >>Ну, пусть хоть сделают единую базу данных граждан!
      >есть. называется АСПИД
      "В 1998 году в отделении идентификации и исследования неопознанных трупов Хабаровского краевого бюро судебно-медицинской экспертизы разработана и внедрена компьютерная программа 'АСПИД' (автоматизированная система первичной идентификации неопознанных трупов). Программа 'Аспид' предназначена для предварительной идентификации неопознанных трупов по признакам внешности и предоставляет пользователю следующие возможности:
      - фиксация более тридцати признаков внешности (не считая зубной формулы);
      - сортировка данных по шести признакам;
      - фильтрация данных по пятнадцати признакам;
      - распечатки опознавательной карты;
      - распечатки списка записей;
      - просмотр графических файлов формата 'bimap'."
      если она то это совсем не то
      
      
      
    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 доступа с гарантированной записью на диск.
      
      >а современные компы куда производительнее
      
      Ну... Современные компы производительнее. Но они и дороже. В смысле ультра современные. Да ещё с детскими болезнями.
      А для столь спецефичной задачи, придётся разрабатывать очень специализированное програмное обеспечение.
      
      Да, при желании, сделать упращённую хрень, можно и сейчас. Особенно если делать локальные кэширующие и проксирующие машины, для облостей и городов.
      
      Но! Тут есть ещё один ньюанс, о котором надо подумать. В идеале, надо поднимать государственную закрытую сеть, на всю страну. Такой трафик, очень не рекомендуется пускать, через часные сегменты интернета, даже если зверски зашифрованный.
      Вон, всякие датацентры гугла, фейсбука и так далее, между своими центрами, кидают свои закрытые линии, только для своего личного трафика.
      
      >взлом при правильном софте возможен только при наличии физического доступа
      
      Нельзя гарантировать. Конечно правильный софт, закроет очень много дырок. Осталось найти то волшебное место, где есть правильный софт.
      А робота, даже очень умного, можно обмануть. Порой, дыры появляются, как раз от умностей. С другой же стороны, тупой робот, даже не догадается, что его обманули. Он обработает и дружественные и вражеские запросы. Так что нужен балланс.
    394. Поляков Дмитрий Валериевич 2015/06/14 07:05 [ответить]
      > > 393.Талипов Артём
      насчет дороже
      если это будет реализовываться то будет реализовываться государством
      а там совершенно другие масштабы денег цена на любое железо будет каплей в море
      
      потолок по озу для серийно производящегося одиночного компьютера на данный момент 768 гигабайт и это ограничение не чипов а разводки материнки тоесть вполне преодолимое
      софт естественно нужно написать
      благо чем "дубовее" софт тем проще его отладить и сложнее его взломать
      особенно если он написан на нормальном языке а не на такой дыре в безопасности как си
      
      а от интернета никуда не денешься на данный момент
      слишком страна большая
      остается шифровать благо есть принципиально не взламываемые ничем кроме брутфорса алгоритмы осталось только сделать на их базе достаточно производительные крипточипы
    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++. Он хорошо изучен. Все его проблемные места известны и задокументированы. Есть множество инструментов для поиска ошибок. Главное нанять крутого разработчика.
      
      >а от интернета никуда не денешься на данный момент
      >слишком страна большая
      >остается шифровать благо есть принципиально не взламываемые ничем кроме брутфорса алгоритмы осталось только сделать на их базе достаточно производительные крипточипы
      
      Да. Это, действительно так. Сразу снимается затраты на прокладку сетей. И добавляются затраты на шифрование.
      
      Но, по факту, бахатся там и бахатся, пока это всё нормально заработает.
      
      Кроме самих баз с данными, нужны ещё программы для контроля прав доступа и ещё много чего. Я могу лишь предположить наличие трудностей. Но поскольку я темой не занимался, то не могу представить, что ещё потребуется.
    396. Поляков Дмитрий Валериевич 2015/06/14 08:16 [ответить]
      > > 395.Талипов Артём
      >От всяких sql баз данных, надо бы отказатся. Слишком они умные и непредсказуемые. В идеале, нужны простейшие базы данных, вроде berkeley db. Но с ними наоборот, проблема их дубовости. Нет разбиения столбцов. А что ещё хуже, они заточены под хранение на диске, а не в оперативке.
      SQL таки язык запросов и напрямую к архитектуре БД не относится
      если бы я реализовывал бы БД для этой задачи с нуля то сделал бы разделение функционала
      хранение/изменение/выдача по id отдельно
      всякий поиск отдельно
      тогда можно первую часть реализовать как нормированную по размеру записи таблицу в озу (скажем по 4 кб на запись а сколько конкретно на какой столбец уйдет неважно)
      а поиск сделать классическим для реляционных бд способом на основе деревьев
      это значительно поднимет производительность даже при реализации на одном компьютере, но главное что разные части поиска могут работать на разных компьютерах что поднимет производительность еще на порядок по сравнению с одиночным компьютером
    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. если центр владеет актуальными данными, то отдаёт их запрашивающему локальному прокси, помечая нового владельца.
      
      Тем самым, центр работает лишь в качестве редкоиспользуемого глобального хранилища. А в основном он просто перераспределяет данные, между локальными центрами хранения.
      
      На самом деле, можно было бы помудрить с оптимизацией трафика. Сделать распределённую сеть, чтоб локальные базы данных сразу запрашивали инфу с других локальных, не перемещая данные через центр.
      Но в таком случае, придётся уже мудрить. О дубовости и надёжности, останется лишь мечтать.
      
      Или же наоборот, дать права чтения локальным, а запись производить только на глобальный.
      Но в таком случае, нагрузка на центр дополнительно возрастёт. И что ещё хуже, придётся усложнять алгоритмы синхронизации. И опять дубовая надёжность идёт лесом.
      
      Во всех этих системах, первейшее правило:
      "чем проще, понятнее и нагляднее, тем лучше".
      За лишние функции, бьют по рукам и компостируют мозг. Например по этому, банковские терминалы, не умеют выдавать сумму произвольными купюрами.
      
      Так что о всяких разделениях функционала, для последующей синхронизации, следует забыть. Это годится для поисковых серверов, игровых серверов, сетевых энциклопедий, социальных сетей. Там подобная информация не критична.
      
    398. Поляков Дмитрий Валериевич 2015/06/14 10:07 [ответить]
      > > 397.Талипов Артём
      >Разделение, как и где?
      >Разные программы? - Не получится, ибо даже на одной машине, потом синхронизовывать данные замучаетесь. А на разных, расшибёте лоб.
      >Разные подпрограммы? Так оно так и делается.
      хранение отдельно поиск отдельно права доступа отдельно
      каждый компонент отдельная программа или вообще отдельный компьютер
      принцип тот же что у risc вместо одного сложного запроса цепочка из нескольких простых
      никакой синхронизации данные по одному человеку целиком в одной записи
      доступ к записям по банальному смещению
      сервер хранящий записи их не обрабатывает
      ему достаточно уметь
      1)выдать запись по номеру
      2)заменить запись по номеру
      3)добавить новую запись
      >Да. Это разумный шаг. Я его подразумевал. Но там есть сложности, из-за менеджеров памяти, которые фрагментируют страницы памяти. По этому прямого доступа по индексу не получится. Как вы и написали, нужны будут деревья.
      нафиг ось вместе с менеджером памяти
      точнее переписать менеджер под задачу
      >Например, если на первом компьютере лежит собственно база данных с полными фио. То на втором компьютере лежат хэши полных фио и работает поиск. Второй компьюютер работает лишь на поиск, не отвлекая первый компьютер.
      смотри выше
      >А для специализированных баз данных, вроде обсуждаемого реестра всех граждан или банковских счетов, подобная асинхронность и даже небрежность, уже сверхкретична.
      >Не правда ли, вам было бы не смешно, если бы вы захотели снять деньги, а терминал сказал бы, что вашего счёта не существует.
      а тут дублирование поможет сдохла нода и черт с ней с резерва загрузится
      
      а обработкой записей согласно прав доступа будет заниматься другой компьютер
      http://i71.fastpic.ru/big/2015/0614/da/d8866f32847b160010df0ff376a492da.png
    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. удалить запись по номеру.
      
      Но с учётом транзакционности, логирования, контрольных сум, серверу придётся поработать.
      
      >нафиг ось вместе с менеджером памяти
      >точнее переписать менеджер под задачу
      
      Ха-эм. Переписывать придётся много. А в итоге, получится почти тоже, с новыми багами и новыми глюками.
      Очень много людей, потоптались по граблям переписывания менеджеров памяти. Это любимое занятие велосепедостроителей.
      И очень много рыдали, по сему поводу.
      Современные менеджеры памяти, кажутся плохими, неудобными, медленными, тормознутыми. Но они вылизаны. И поддерживаются аппаратно.
      любой собственный велосипед, заведомо хуже. Субъективные тесты, показывают круть. Но по объективным комплексным тестам, нервно курят в сторонке, против стандартных.
      
      >а обработкой записей согласно прав доступа будет заниматься другой компьютер
      
      Естественно. Отдельная машина, только проверяющая права. Это вобще-то класика.
      Причём, логин и пароль, можно хранить в такой же базе данных!
      
    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. удалить запись по номеру.
      ИМХО хранить вечно
      
      >Ха-эм. Переписывать придётся много.
      да не такто уж и много
      только выделение блока размером со всю озу
      и фоновое сохранение на жесткий
      
    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, дырой в безопасности. Если бежать всё переделывать, даже не разобравшись в инструменте... Вобщем это антипаттерн.
    402. Поляков Дмитрий Валериевич 2015/06/14 17:35 [ответить]
      > > 401.Талипов Артём
      >С вашим подходом, я совсем не удивляюсь, что вы считаете язык программирования C, дырой в безопасности. Если бежать всё переделывать, даже не разобравшись в инструменте... Вобщем это антипаттерн.
      с чего вы взяли что не разобравшись
      просто на данный момент в программировании очень часто встречается ситуация как с первыми пароходами
       у пароходов были кирпичные трубы потому что печка же
      а в программировании паттерны лепят куда надо и не надо
      в итоге что пароходы переворачивались от легкого ветра что программы падают и хрен найдешь где потому что баг зарыт под ста слоями кода
      чтоб развиваться дальше нужно пересматривать необходимость уже изобретенных велосипедов и начинать стоит с языка программирования
      
    403. *Талипов Артём (eric50@yandex.ru) 2015/06/14 19:41 [ответить]
      > > 402.Поляков Дмитрий Валериевич
      >просто на данный момент в программировании очень часто встречается ситуация как с первыми пароходами...
      
      Ну, да. Есть такое. И к сожалению, всё ещё пока печально, даже с новыми языками.
      Более менее продуманы C#, Go, Rust. Но по моему, они ущербны.
      C# для каких-то дибилов, но сахар вкусный.
      Go - очень злобный друг, который любит пинать по поводу и без, загоняя в жёсткие рамки, даже если они не нравятся.
      Rust - забавен, но отдаёт этаким эпотажем.
      Идеи правильные, но слишком подчёркивается отличие от C.
      Из старичков, очень неплох C++. Но его наследие, действительно печалит.
      
      А у меня, по прежнему не получается создать хороший язык программирования. Трудно тягатся с большими компаниями.
      Да и привычка к старым конструкциям, не даёт покоя.
      А ведь так хочется получить, действительно продвинутый язык, одновременно удобный, простой, защищённый и быстрый.
    404. *Талипов Артём (eric50@yandex.ru) 2015/06/16 16:24 [ответить]
      Попалась занятная история. Чуваку дали ремонтировать старые советские электрические часы. Дитя, как раз описываемой эпохи. Я подобные, застал в школе. http://habrahabr.ru/post/259575/
    405. Симонов Сергей (gann.lector@yandex.ru) 2015/06/16 19:04 [ответить]
      > > 404.Талипов Артём
      
      Спасибо, необычно.
    406.Удалено написавшим. 2015/06/16 19:22
    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 АИ
      
      имхо и самим полезно и за бугор влет должно уходить
      продавать вилки розетки лампочки и выключатели
      
      идеально было бы продавить обязательность использования во всяких заведениях через какую нибудь международную комиссию по защите детей
      
    408. *Талипов Артём (eric50@yandex.ru) 2015/06/29 20:34 [ответить]
      > > 407.Поляков Дмитрий Валериевич
      >попался мне только что на радиокоте пост (Пн июн 29, 2015 17:20:20) про безопасные розетки/патроны
      
      Я об этом нудю ещё с первой книги!
      Тем более был хороший повод, смена электростандарта со 110 вольт, на 220 вольт.
    409. Поляков Дмитрий Валериевич 2015/06/29 20:37 [ответить]
      > > 408.Талипов Артём
      
      >Тем более был хороший повод, смена электростандарта со 110 вольт, на 220 вольт.
      на момент смены стандарта это могли реализовать только в варианте геркон + реле
      
      
      
    410. *Талипов Артём (eric50@yandex.ru) 2015/06/29 23:23 [ответить]
      > > 409.Поляков Дмитрий Валериевич
      >на момент смены стандарта это могли реализовать только в варианте геркон + реле
      
      Замена оборудования выполнялась долго. По некоторым сведениям, даже в 80 годах, у некоторых, в центре Москвы подводилось 110 вольт. А в жд поездах, и сейчас не редкость.
      
      К тому же далеко не сразу появились даже пластики, для проводов, розеток, вилок и прочего оборудования.
      
      
      В идеале-то надо действительно всякие плюшки. Но по началу, можно и на рэлешках делать защиту. Ибо защита нужна, даже плохая и тормозная.
      
      И ещё, надо бы и заземления делать нормальные!
    Текущее Страниц (26): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... 26Архивы (2): 1 2

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

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

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

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