Да, точно 105, а я был уверен что больше. Сейчас погуглил, он умеет сохранять 512 шагов в ППЗУ, видимо раньше когда читал о нем подумал что это шаги исполнения.
Правда в наших провинциях его было невероятно трудно найти. Больше года искал. В отличии от книг по программированию под МК, они были в городской библиотеке. И что это были за книги… каждая глава была написана в таком захватывающем стиле повествования что очень трудно было оторваться. В одной из них был листинг самообучающейся программы-игры, чем-то напоминающей игру в спички только для нее нужно было нарисовать отдельное поле и передвигаться на отличное от нуля количество клеток за ход. И хоть я и не помню принцип её работы но она действительно самообучалась, использовать одну и ту же тактику второй раз для выигрыша не получалось, разве что сбросить программу и набрать её заново. Эта игра и крестики-нолики потрясли меня больше всего.
И да, был еще продвинутый вариант МК-52, в котором можно было сохранять введенные программы и количество шагов было не 105, а больше. Но о нем приходилось лишь мечтать и один раз взглянуть на витрине универмага.
Почему-то некоторые люди когда видят что для шифрования используется исключающее или, думают что это почти открытый текст, бери себе и вскрывай частотным анализом.
Но скажите откуда вы знаете что там шифруется? Может тот кусок который надо зашифровать с опасными элементами и занимает <= 4K?
Между прочим при таком исходе эта система будет обладать абсолютной криптографической стойкостью. Кроме как перехватить ключ и использовать его, других способов вскрыть защиту нет.
Да-да, это круче чем Blowfish и даже круче чем RSA, при соблюдении указанного выше условия.
Предполагаю что человек столкнулся с необходимостью создать на массе компьютеров организации ярлык на рабочем столе для какого-нибудь корп. портала или ПО размещенного где-нибудь на шаре.
Это дело видимо предполагается засунуть в логон-скрипты, с нужными параметрами.
Лучше бы просто рубились по сети, в какую-нибудь стратегию, тогда и груд металла не будет. Да и вообще, при таком раскладе, войну можно будет устраивать хоть каждую неделю, по пятницам, вечерком.
Да, вероятно вы правы, я предполагал что если случается сбой, пользователи США работавшие до этого с документом созданным пользователем Европы работают не со своей версией документа, они вообще не могут дальше работать над этим документом в угоду Consistency (пусть лучше такой возможности не будет чем возникнет несогласованность). Но могут работать с другими, которые лежат на на серверах США. Никакого мержа в таком случае не будет после восстановления связи потому что мы отказались от Partition Tolerance.
А например система совместной работы над документами вроде Google Docs. Упала скажем межконтинентальная связь, пользователи Европы работают над своими документами, Америки над своими. Avalability выполнено. Любые попытки пользователем с Европы закоммитить например ранее открытые документы которые лежат на серверах в Америке неудачны. Consistency выполнено. Partition Tolerance не выполнено.
Почему вы не можете представить себе AP или CP системы?
Первый случай: жили себе две ноды (A, B) с данными далеко друг от друга, реплицировались и все было хорошо, но в один прекрасный момент связь между ними пропала. Клиент C1 подключился к ноде A и что-то наменял, поскольку у нас система всегда доступна и терпима к разделению (AP) она это и позволила сделать. Клиент C2 в это же время подключился к ноде B и тоже что-то поменял. Данные принялись обоими нодами и доступны для клиентов которые подключаются просто они разные на разных узлах (несогласованы).
Во втором случае имеем CP систему: каждый раз при записи на любую ноду они перепроверяют согласованность данных с другими, в случае сбоя сети между теми же нодами A и B, все попытки считать данных с любой из нод закончатся успехом так как система терпима к разделению, но попытки записи будут неудачны до тех пор пока система не сможет убедиться в собственной целостности.
Жертвуя терпимостью к сбоям мы по сути горизонтально разделяем данные по нодам. Это приводит к тому что когда связь между A и B пропадает часть данных что лежит на B недоступна для клиентов подключившихся к A и наоборот. Если например пользователь обновляет данные которые лежат на A — все хорошо (доступность), любые попытки чтения или обновления даных лежащих на B — ошибка (невозможно проверить целостность).
Спасибо и за саму статью и за то что писали ее ночью, читается на одном дыхании.
Тема очень интересна, с нетерпением буду ждать продолжения, особенно про Graphic Library.
Приходилось писать похожий велосипед несколько лет назад, правда на c#, поскольку там удобно можно было вытягивать информацию с Оракла через ODP.NET и запихивать в AD (System.DirectoryServices && System.DirectoryServices.AccountManagement).
Максимальние значения атрибутов можно менять в схеме.
Но такие изменения некоторых атрибутов (в моем случае department) пришлись не очень-то по-нраву установленному Exchange.
Правда в наших провинциях его было невероятно трудно найти. Больше года искал. В отличии от книг по программированию под МК, они были в городской библиотеке. И что это были за книги… каждая глава была написана в таком захватывающем стиле повествования что очень трудно было оторваться. В одной из них был листинг самообучающейся программы-игры, чем-то напоминающей игру в спички только для нее нужно было нарисовать отдельное поле и передвигаться на отличное от нуля количество клеток за ход. И хоть я и не помню принцип её работы но она действительно самообучалась, использовать одну и ту же тактику второй раз для выигрыша не получалось, разве что сбросить программу и набрать её заново. Эта игра и крестики-нолики потрясли меня больше всего.
И да, был еще продвинутый вариант МК-52, в котором можно было сохранять введенные программы и количество шагов было не 105, а больше. Но о нем приходилось лишь мечтать и один раз взглянуть на витрине универмага.
Посыпаю голову пеплом.
Но скажите откуда вы знаете что там шифруется? Может тот кусок который надо зашифровать с опасными элементами и занимает <= 4K?
Между прочим при таком исходе эта система будет обладать абсолютной криптографической стойкостью. Кроме как перехватить ключ и использовать его, других способов вскрыть защиту нет.
Да-да, это круче чем Blowfish и даже круче чем RSA, при соблюдении указанного выше условия.
Это дело видимо предполагается засунуть в логон-скрипты, с нужными параметрами.
7xtu-wyxz-7amvw6m6-csgl-utod
dt9r-mwev-gps1
fetm-ntjm-8cxd
wunn-b98b-nhx9
Прошу прощения.
Первый случай: жили себе две ноды (A, B) с данными далеко друг от друга, реплицировались и все было хорошо, но в один прекрасный момент связь между ними пропала. Клиент C1 подключился к ноде A и что-то наменял, поскольку у нас система всегда доступна и терпима к разделению (AP) она это и позволила сделать. Клиент C2 в это же время подключился к ноде B и тоже что-то поменял. Данные принялись обоими нодами и доступны для клиентов которые подключаются просто они разные на разных узлах (несогласованы).
Во втором случае имеем CP систему: каждый раз при записи на любую ноду они перепроверяют согласованность данных с другими, в случае сбоя сети между теми же нодами A и B, все попытки считать данных с любой из нод закончатся успехом так как система терпима к разделению, но попытки записи будут неудачны до тех пор пока система не сможет убедиться в собственной целостности.
Жертвуя терпимостью к сбоям мы по сути горизонтально разделяем данные по нодам. Это приводит к тому что когда связь между A и B пропадает часть данных что лежит на B недоступна для клиентов подключившихся к A и наоборот. Если например пользователь обновляет данные которые лежат на A — все хорошо (доступность), любые попытки чтения или обновления даных лежащих на B — ошибка (невозможно проверить целостность).
По крайней мере так это понимаю я.
Тема очень интересна, с нетерпением буду ждать продолжения, особенно про Graphic Library.
Максимальние значения атрибутов можно менять в схеме.
Но такие изменения некоторых атрибутов (в моем случае department) пришлись не очень-то по-нраву установленному Exchange.
Спасибо, это именно то что я давно хотел.