Первый пост темы: dedivan Post: #471944 От:06.06.2015 (00:41) 21 августа 1991 года закончился августовский путч в СССР-
24 августа 1991 в центре Киева. Люди приветствуют провозглашение независимости
25 августа 1991 года Линус Товальдс опубликовал ядро Linux Date: 25 Aug 91 20:57:08 GMT
Просто совпадение? Можно быть, но есть еще много других совпадений.
Главное- это одинаковая методика зомбирования адептов Линукса и Нэзалежной.
Линуксоидов в мире точно столько же сколько и укропов- около 1 %.
О чем не спросишь линуксоида- ответ : хто нескаче тотмастдай
НЕ ПОДДЕРЖИВАЕТ выполнение множество конкурирующих запросов одновременно!
Код читал???? а конфигурацию, да когдато действительно конкурирующие запросы могли както влиять на структуру БД.
НО потом это исправлено, а в качестве перестраховки была введена функция очередности запросов!
Вы вначале код прочитайте, умник такой
По второму вопросу, уважаемому идиоту. [ссылка]
Система управления базами данных
это дублирую если у долбоеба не хватит мозгов.
Что такое система управления, уважаемый, долбоеб, ВЫ ДОЛБОЕБ должны знать, и не понимая кода, и не написав ни ОДНОЙ строчки кода, долбоеб, Вы не можете мне говорить оскорблений с ВАШЕЙ, ДОЛБАЕБ стороны.
Девил, код приведен выше, поэтому о каком СВОЕМ ВРЕМЕНИ????? Вы говорите?????
А для ДОЛБАЕБА, привожу
"// конфигурация базы данных
$base_safe_mode="off"; // Принимает значения (on/off) Безопатный режим работы БД, это такой режим
// в котором выполняются команды пользователей последовательно
// тем самым исключается одновременное использование базой данный двух или более пользователей
// однако включение этого режима повлечет увеличение СРЕДНЕГО времени генерации страниц
// так как все пользователи будут выстроены с очередь.
// отключение режима (off) позволяет пользователям многопоточно работать с БД,"
Вот когда прочтет, этот, долбаеб, текст, а еще бы замечательно поймет код.
Вот когда этот ДОЛБАЕБ и если он еще код поймет...............
Но ДОЛБАЕБАМ это не дано, они все дауны.
НО потом это исправлено, а в качестве перестраховки была введена функция очередности запросов!
Слушай ты умник... Очередно уже только ты один выполняешь запросы. Во всем мире давно применяются и в современных СУБД кстати, технологии для конкурентного выполнения запросов. Этим и отличаются доморощенные технологии от профессиональных. То, что ты о них нихрена не знаешь и говорит о твоей низкой квалификации.
НО потом это исправлено, а в качестве перестраховки была введена функция очередности запросов!
Слушай ты умник... Очередно уже только ты один выполняешь запросы. Во всем мире давно применяются и в современных СУБД кстати, технологии для конкурентного выполнения запросов. Этим и отличаются доморощенные технологии от профессиональных. То, что ты о них нихрена не знаешь и говорит о твоей низкой квалификации.
ДИБИЛОИД, посмотри самый низ сайта, и кто там что выполняет.
Меня еще ниодна технология не смогла переплюнуть, но это уже вне темы обсуждения.
Нужно, задавай отдельную ветку ДИБИЛОИД и там поговорим
Вот когда прочтет, этот, долбаеб, текст, а еще бы замечательно поймет код.
Вот как раз именно этот текст и рассмешил сразу. Можно его прочитать иначе. Так-как я, proggi, тупой совсем, то я не знаю, как запросы выполнять параллельно, поэтому в свою супер-пупер базу, я ввел охрененный параметр, чтобы моя база не валилась на параллельных запросах, то я буду запросы выполнять последовательно. Пофик, что у меня серверх на 8-ми ядерных ксеонах и все работает всего в один поток, зато она быстрая настолько, я в это верю, что все запросы обработает моментально и проблем не будет никаких. Я лучше то время, которое мог бы потратить на concurrency, потрачу на бухло и везде буду постить какой я крутой программер и какие все дебилы, что не хотят использовать мой бредокод.
proggi Пост: 506449 От 27.Aug.2016 (12:42)
обсуждения.
Нужно, задавай отдельную ветку ДИБИЛОИД и там поговорим
Не о чем нам с тобою говорить. Твой, или я не знаю чей, код говорит сам за себя. Вот смастери сперва свой кэш, который с shared данными межсессионными. И обеспеч конкуррентный доступ и обновление кэша из 1000 конкурирующих потоков одновременно. Создай стратегию доступа и блокировки данных и не на уровне вхождения процедуру, а на уровне отдельных записей. Когда ты пройдешь этот путь, тогда с тобой будет интересно поговорит. А сейчас ты просто понятия не имеешь, насколько ты туп.
Уважаемый Долбоеб Дибилоевич Долбоеб.
Вы, Дибилоевич, даже не запустили мою базу, а предпочитаете критиковать, того чего не пробовали.
Это, Долбоеб Дибилоевич, как в дедстве, "мне не нравится но я еще не попробовал". Долбоев Дибилоевич.
proggi Пост: 506460 От 27.Aug.2016 (18:03)
Уважаемый Долбоеб Дибилоевич Долбоеб.
Вы, Дибилоевич, даже не запустили мою базу, а предпочитаете критиковать, того чего не пробовали.
Это, Долбоеб Дибилоевич, как в дедстве, "мне не нравится но я еще не попробовал". Долбоев Дибилоевич.
ты знаешь... один и тот же код и один и тот-же алгоритм обыглывается в самых разных ракурсах и вариантах. Этих и им подобных кусков может в сети валяться тысячами штук. Все не перепробывать. Зато я знаю, ЧТО в нем должно быть, чтобы система могла успешно работать. И этого в нем нет. Например то, что твой код использует хранение данных в файлах и каждый раз обращаешься к файлам. Т.е. тот же самый код, но заточенный под работу с промежуточными данными в памяти будет работать гораздо быстрее. Это же очевидно...
Т.е. если я вижу, что ты данные свои развозишь на трамваях, то для меня сразу понятно, что скорости феррари тут не добьешся...
proggi Пост: 506460 От 27.Aug.2016 (18:03)
Уважаемый Долбоеб Дибилоевич Долбоеб.
Вы, Дибилоевич, даже не запустили мою базу, а предпочитаете критиковать, того чего не пробовали.
Это, Долбоеб Дибилоевич, как в дедстве, "мне не нравится но я еще не попробовал". Долбоев Дибилоевич.
ты знаешь... один и тот же код и один и тот-же алгоритм обыглывается в самых разных ракурсах и вариантах. Этих и им подобных кусков может в сети валяться тысячами штук. Все не перепробывать. Зато я знаю, ЧТО в нем должно быть, чтобы система могла успешно работать. И этого в нем нет. Например то, что твой код использует хранение данных в файлах и каждый раз обращаешься к файлам. Т.е. тот же самый код, но заточенный под работу с промежуточными данными в памяти будет работать гораздо быстрее. Это же очевидно...
Т.е. если я вижу, что ты данные свои развозишь на трамваях, то для меня сразу понятно, что скорости феррари тут не добьешся...
Уважаемый Долбоеб Дибилоевич Долбоеб.
ВЫ Долбоеб Дибилоевич Долбоеб, мне сказали что я не прав, хочю АРГУМЕНТИРОВАННО услышать ответ!
С уважением Александр. Для Долбоеб Дибилоевичу Долбоебу
Ищите строчку кода конфига, где указано о
О ТОМ ЧТО ВЫ МНЕ НАПИСАЛИ В ЛИЧКУ.
Вы ТРУС не можете писать напрямую, уважаемый Долбоеб Дибилоевич Долбоебов.
proggi Пост: 506496 От 28.Aug.2016 (14:23)
Вы ТРУС не можете писать напрямую, уважаемый Долбоеб Дибилоевич Долбоебов.
Я не трус. И могу разобрать твой код в деталях, если хочешь. Для этого нужно прекратить оскорбления и войти в конструктивное русло. Без этого я с тобой разговаривать не буду. Понял?
proggi Пост: 506496 От 28.Aug.2016 (14:23)
Вы ТРУС не можете писать напрямую, уважаемый Долбоеб Дибилоевич Долбоебов.
Я не трус. И могу разобрать твой код в деталях, если хочешь. Для этого нужно прекратить оскорбления и войти в конструктивное русло. Без этого я с тобой разговаривать не буду. Понял?
Ну Разберите... А писать того чего не понимаете или иное не надо.
Ок. Разберу сегодня вечером после работы. А вот для начала взгляни на взрослую базу нереляционную с исходным кодом: [ссылка]
Т.е. взглянув на код этой БД СРАЗУ видно, что это БД ориентирована на конкурентную работу и все необходимые механизмы (кэши например) в ней присутствуют. А в твоей, извини, но не нашел...
Поясняю второй раз, psih (Как Видите уже на ВЫ с вами.)
Моя база, в виду специфики PHP работает иначе чем база которая работает ВСЕГДА на сервере, как скажем, торрент, или прочее.
PHP Формально не имеет возможности полноценно хранить хеши, там есть такая возможность, я не спорю.
Но повторюсь у меня сервера при нагрузке около 70 ТЫСЯЧ (СЕМЬДЕСЯТ) не падают, и все работает.
Код, согласен нет некоторых опций.
НО!!!!!!!!!!
Дефрагментация на лету, но в оракле, нет такого, такие настройки скрыты, и обычный пользователь, не сможет сконфигурировать базу нормально, но работать она конечно будет.
В общем-то понятно. Сделал собственную поделку для собственных целей. При этом назвал это базой. А всех, что пытается это оспорить, посылаем значит, понятно куда. Ну флаг в руки - барабан на шею. Пиши дальше. Просто нефиг этой штуке диферамбы петь. Ничего в ней такого нет. Вполне заурядная штуковина. Моя проблема в том, что я в ней попытался найти то, чего в ней нет и никогда не будет, ориентируясь на твой анонс. Тут не то, чтобы все дебилы, которые критикуют твою вещь. На самом деле ты дал ей неправильное описание. Впрочем веса и масштаба тебе это не добавляет. Скорее наоборот - я не встречал людей, которые ТАК кичаться своими разработками начального уровня...
psih Пост: 506559 От 29.Aug.2016 (12:24)
В общем-то понятно. Сделал собственную поделку для собственных целей. При этом назвал это базой. А всех, что пытается это оспорить, посылаем значит, понятно куда. Ну флаг в руки - барабан на шею. Пиши дальше. Просто нефиг этой штуке диферамбы петь. Ничего в ней такого нет. Вполне заурядная штуковина. Моя проблема в том, что я в ней попытался найти то, чего в ней нет и никогда не будет, ориентируясь на твой анонс. Тут не то, чтобы все дебилы, которые критикуют твою вещь. На самом деле ты дал ей неправильное описание. Впрочем веса и масштаба тебе это не добавляет. Скорее наоборот - я не встречал людей, которые ТАК кичаться своими разработками начального уровня...
Группа исследователей из Бингемтонского и Калифорнийского университетов опубликовали технику атаки, позволяющую восстановить раскладку памяти при использовании механизма защиты ASLR (Address space layout randomization) на системах с процессорами Intel. Атака успешно продемонстрирована на системе с Linux и процессором Intel Haswell для предсказания рандомизированных адресов как для ядра, так и для пространства пользователя. В результате эксперимента смещение ASLR в ядре Linux удалось восстановить за 60 мс. Исследователи считают, что атака не специфична для Linux и также может быть применена к реализациям ASLR в Windows и macOS.
Метод является разновидностью атак по сторонним каналам (side-channel attacks) и основан на косвенном определении адресов, на которые осуществляется переход в процессе ветвления в коде программы, через инициирование коллизий в буфере предсказания ветвлений (Branch Target Buffer, BTB), используемом в процессоре для предсказания переходов и хранения таблицы истории переходов.
Циклично формируя переходы по различным адресам памяти атакующий отслеживает возникновение коллизии хэша, используемого в качестве индекса при записи в таблицу BTB. Далее, подобная коллизия отслеживается в процессе с ASLR. Пользуясь тем, что команды перехода по разным виртуальным адресам в результате коллизии хэша могут быть сопоставлены с одной и той же записью в BTB, ссылающейся на один целевой адрес перехода. В результате оценки времени срабатывания перехода, единичные факты существенного увеличения времени отклика воспринимаются как признак коллизии, что позволяет определить местоположение известных команд перехода в адресном пространстве ядра или другого пользовательского процесса.
sw1972 Пост: 513419 От 20.Oct.2016 (15:03)
Найдена очередная закладка (лазейка)
Кэш всегда был слабым местом в интелловских камнях.
Если проц перед этим проверял пароль на вход, потом выгрузил программу проверки, то кэш не стирается- весь пароль так и лежит в нем открытый.
Хитрая програмка всегда может прочитать незатертый кэш.
sw1972 Пост: 513419 От 20.Oct.2016 (15:03)
Найдена очередная закладка (лазейка)
Кэш всегда был слабым местом в интелловских камнях.
Если проц перед этим проверял пароль на вход, потом выгрузил программу проверки, то кэш не стирается- весь пароль так и лежит в нем открытый.
Хитрая програмка всегда может прочитать незатертый кэш.
Это, скорее всего, не слабое место, а "недокументированная возможность".
proggi |
Post:506440 - Date: 27.08.16(14:52)
