На МК88 можно было рабоать с дискетами на 720 (80 дорожек), но нужен был драйвер типа 800.com. Конкретно 800.com на нём не работал (но работал вроде на EC1840). Для МК88 был другой драйвер. Правда загрузиться с дискеты на 720 всё-равно было нельзя, поэтому дискеты с системой могли быть только на 360.
Альфа-ДОС, это по-моему реверснутый MS-DOS 2.x и руссифицированный, как и basicm86 который прилагался был реверснутый и руссифицированный gwbasic.
Ещё МК88 был примечателен тем, что CGA адаптер умел в перепрограммирование знакогенератора, т.е. содержал ОЗУ для этих целей и дополнительные команды. В отличие от оригинального CGA где знакогенерато был намертво вшит. Почему это важно? МК88 имел кодировку кирилицы (т.н. основная кодировка ГОСТ), которая не совпадала с CP866. Псевдографика всех нормальных программ из-за этого была поломана, так как коды этих символов в основной кодировке не совпадали с кодировкой OEM-US или 850.
МК88 не имелл контроллера HDD, но сзади можно было воткнуть через широкий разъем нечто, имеющее шину ISA8. Теоритически, туда можно было воткнуть ST506 c ПЗУ на борту и выбором "передача управления картриджу" в меню загрузки. Может кто-то пробовал?
Ещё там был режим дебагера в меню загрузки, где можно было изучать основы ассемблера X86 в отсвутвие загрузочной дискеты :)
Распространённая проблема - битые РУ7. Проявлялось внезапно возникающей "ошибкой чётности" и глубоким зависанием. (лечилось перепайкой либо перехватом NMI, чтоб избежать внезапного виса)
Вы сделали неверный вывод из моих коментариев. Речь идёт о том, что перед человечеством ещё очень и очень много работы, чтобы понять как всё устроено. Сегодня это только мизерные (пусть даже и бесценные) зачатки, и говорить, что мы вот тут геном просеквентировали и прямо по дампу, как гадалки, сейчас нагадаем - это очень поверхностно. Кроме BRCA есть туевы хучи других генов и их вариантов которые тоже могут что-то значить. Но сложнее всего - это полная картина, их взаимодействие, влияние других факторов, внешней среды. Тут поле непаханное. Совсем.
Эт с чего это вдруг не понимаем? Например, вот тут вполне конкретно говорится о шансах получить конкретные виды рака при зловредных поломках BRCA1/2 в сравнении с теми, у кого нормальные варианты.
Ну это всё обсервационные данные, в среднем по больнице. Причинно-следственная связь сложнее гораздо. Какова вороятность онко-исхода при активных других генах супрессорах? Каких именно? Как эпигеном влияет на риск? Какие экстра-генетические факторы имеют негативное или позитивное влияние на исход?
Задача ведь стоит минимизировать риск неблагоприятного исхода при наличие триггерного фактора. Это значит, что можно воздействовать на неДНК-обусловленные факторы и свести изначально априорный 60% риск к например 10%-ному или даже 1%-ному. Какие это факторы?
Дело в не в том, рассматриваем ли мы процессы с точки зрения формальной логики или с точки зрения теории вероятности. Не имея возможности смоделировать каждую молекулу (или элементарную частицу) отдельно мы переходим к вероятностной модели. Такой из себя чёрный ящик с огромным количеством входов и скрытых сотояний. А на выходе вероятность - выстрелит или нет. Но даже тут мы не понимаем что именно и как влияет на итоговую вероятность. В общих чертах только.
Возьмём всеми любимый BRCA1 и его полиморфизмы. Почему у кого-то развивается онкология, а у кого-то нет при одном и том же варианте? Другие факторы и другие гены? А какие?
Изучая геном вы всё-равно ничего не поёмете. Это как смотреть отдельные байты машинного кода в огромном экзешнике. Отдельно взятые изолированные полиморфизмы очень мало что могут рассказать (кроме очень ограниченного и хорошо изученного их числа, но есть тоже нюансы). В живом огранизме очень много компенсаторных механизмов, в тех же ферментных системах например. Нет ни одной достоверной базы данных где описавались бы сложные комбинации полиморфизмов. Совсем. Так как количество комбинаций и возможных взаимодействий бесчисленно. Даже по отдельным полиморфизмам данные противоречивы (см. базы типа GWAS).
Ещё эпигеном забыли. А это как конфиг файл, где можно заметилировтать заацетилировать отдельные гены, выключить или наоборот включить их транскрипцию. Клиника всегда важнее. Наличие полиморфизма не означает, что система не работает. Иначе мы бы давно и очень быстро умерли.
Функция складывания 2 + 2 теперь находится внутри супер крутого фреймворка, который умеет не только складывать, но ещё и делить! Но постойте, ведь вызвать функцию запихнув операнды в регистры - это всего на пару тактов больше. Ха! Супер мега крутой фрейморк, он оказывается написан на супер мега крутом интерпретируемом языке. А интерпретатор... хм... На неком байт-коде, который JIT должен переварить, и будучи сытым и довольным, запустить на выполнение. Ой, а счётчик тактов совсем забыли, но уже по-моему 6-значное число. Подождите, ещё не всё :). Наш супр классный переваренный джитом машинный код, он оказыватеся выполняется на виртуальной машине! (да! яйцо в утке, утка в зайце и дальше по списку), которая мамой клянётся, что не интерпретатор, а всего-лишь гипервизор (но это не точно). Зато как классно деплоится в облако, в виде образа в 100500 мегабайт.
Просто в статье сначала идёт речь о "преобладающем элементе" (который будет в случае моего примера 1), потом о "преобладающем элементе, встречающемся более n/2 раз". Это может вводить в заблуждение..
Это всё понятно, вопрос не про UI поток. У меня нет UI потока. У меня Web-Service. Он на запрос должен прочитать файл на 100500 гигабайт и вернуть ответ. Какое преимущество async IO в данном случае, вопрос был об этом.
Интересно бы понять преимущества async операций ввода-вывода. Ведь данные диск нам всё-равно быстрее, чем может, не вернёт. Соответственно, продолжать дальше мы по-любому не можем. Ну ладно, мы освободили текущий поток для чего-то ещё. Если этого чего-то ещё нет - то и освобождать некому. Если наш дргуой код (который не ждёт данные, а делает что-то ещё) мы и так забросили в другой поток, тут опять мы ничего не выигрываем. А async вызов - это лишнее переключение контекста и просто так не даётся (ну смотря как оно реализовано, может быть через WinAPI overlapped i/o).
Есть там ещё какая-то заморочка со therad pool когда мы реализуем web сервис например. Вместо создание нового потока для нового запроса фреймворк может как-то заиспользовать уже имеющийся, который висит на ожидании данных. Но это всё туманно. Может есть benchmark'и какие-нибудь с циферками, где можно выйгрыш посмотреть?
Можно и человека с его "интеллектом" редуцировать до набора детерминированных инструкций. Поступил нужный сигнал выше текущего(!) порога срабатывания на нейрон - нейрон переключился. Как чайник. Или 1.00500Е+09 чайников. Всё дело в сложности модели. С живым нейроном, правда, хитро. Там тепловой и прочий квантовый шум играет ну очень уж большую роль.
Интересно конечно на клеточном уровне, на уровне ферментативных реакций бы посмотреть, почему так происходит... Но наверное до этого ещё не скоро дойдут.
С проводами кстати, для справки, китайцы очень любят использовать CCS (меднёная сталь). На вид выглядит как медь, но на самом деле сталь. Сопротивление на DC или на низкой частоте AC можно себе представить (это в разы выше, чем у меди или даже алюминия). Проверяется очень просто, внезапно, магнитом :)
Один раз вся лаборатория ломала голову, почему в серевере отваливается SSD периодически. Просто вылетает в ошибку и больше не определяется. Оказалось дешевый китайский удлинитель питания ATX. На проводах всё красиво, AWG сколько-то там, прямо толсто толсто. Но чуть нагрузку давали и на шине 3.3В падало что-то порядка 0.5В. И как оказалось для SSD было фатально. Заменили на нормальный (с таким же AWG, но чистокоровной меди) - всё стало на свои места.
Наверное всё-таки не квадрат расстояния. У нас расхождение волны не на все, как говорится, 4 стороны. Волна остаётся в сферическом слое, т.е. по сути в плоскости. Соответвенно степень не 2, а 1. Линейно эгергия будет уменьшаться, а не квадратично.
Человечество выпилит само себя. ИИ - это всего-лишь мощный инструмент в неумелых руках.
Сложно даже представить, спрогнозировать, какие социальные потрясения это всё спровоцирует. Достаём поп-корн. Гранату обезъяне уже выдали. Ждём, что будет дальше.
На МК88 можно было рабоать с дискетами на 720 (80 дорожек), но нужен был драйвер типа 800.com. Конкретно 800.com на нём не работал (но работал вроде на EC1840). Для МК88 был другой драйвер. Правда загрузиться с дискеты на 720 всё-равно было нельзя, поэтому дискеты с системой могли быть только на 360.
Альфа-ДОС, это по-моему реверснутый MS-DOS 2.x и руссифицированный, как и basicm86 который прилагался был реверснутый и руссифицированный gwbasic.
Ещё МК88 был примечателен тем, что CGA адаптер умел в перепрограммирование знакогенератора, т.е. содержал ОЗУ для этих целей и дополнительные команды. В отличие от оригинального CGA где знакогенерато был намертво вшит. Почему это важно? МК88 имел кодировку кирилицы (т.н. основная кодировка ГОСТ), которая не совпадала с CP866. Псевдографика всех нормальных программ из-за этого была поломана, так как коды этих символов в основной кодировке не совпадали с кодировкой OEM-US или 850.
МК88 не имелл контроллера HDD, но сзади можно было воткнуть через широкий разъем нечто, имеющее шину ISA8. Теоритически, туда можно было воткнуть ST506 c ПЗУ на борту и выбором "передача управления картриджу" в меню загрузки. Может кто-то пробовал?
Ещё там был режим дебагера в меню загрузки, где можно было изучать основы ассемблера X86 в отсвутвие загрузочной дискеты :)
Распространённая проблема - битые РУ7. Проявлялось внезапно возникающей "ошибкой чётности" и глубоким зависанием. (лечилось перепайкой либо перехватом NMI, чтоб избежать внезапного виса)
С влажностью главное не переусердствовать. А то на стенах, за мебелью вырастет аспергилла, вот это будет пипец-пипец. Будет прощё всё сжечь...
Интересно, Т отрицательный... А это какое отведение?
Вы сделали неверный вывод из моих коментариев. Речь идёт о том, что перед человечеством ещё очень и очень много работы, чтобы понять как всё устроено. Сегодня это только мизерные (пусть даже и бесценные) зачатки, и говорить, что мы вот тут геном просеквентировали и прямо по дампу, как гадалки, сейчас нагадаем - это очень поверхностно. Кроме BRCA есть туевы хучи других генов и их вариантов которые тоже могут что-то значить. Но сложнее всего - это полная картина, их взаимодействие, влияние других факторов, внешней среды. Тут поле непаханное. Совсем.
Ну это всё обсервационные данные, в среднем по больнице. Причинно-следственная связь сложнее гораздо. Какова вороятность онко-исхода при активных других генах супрессорах? Каких именно? Как эпигеном влияет на риск? Какие экстра-генетические факторы имеют негативное или позитивное влияние на исход?
Задача ведь стоит минимизировать риск неблагоприятного исхода при наличие триггерного фактора. Это значит, что можно воздействовать на неДНК-обусловленные факторы и свести изначально априорный 60% риск к например 10%-ному или даже 1%-ному. Какие это факторы?
Дело в не в том, рассматриваем ли мы процессы с точки зрения формальной логики или с точки зрения теории вероятности. Не имея возможности смоделировать каждую молекулу (или элементарную частицу) отдельно мы переходим к вероятностной модели. Такой из себя чёрный ящик с огромным количеством входов и скрытых сотояний. А на выходе вероятность - выстрелит или нет. Но даже тут мы не понимаем что именно и как влияет на итоговую вероятность. В общих чертах только.
Что-то можно, но о-о-чень мало.
Возьмём всеми любимый BRCA1 и его полиморфизмы. Почему у кого-то развивается онкология, а у кого-то нет при одном и том же варианте? Другие факторы и другие гены? А какие?
Изучая геном вы всё-равно ничего не поёмете. Это как смотреть отдельные байты машинного кода в огромном экзешнике. Отдельно взятые изолированные полиморфизмы очень мало что могут рассказать (кроме очень ограниченного и хорошо изученного их числа, но есть тоже нюансы). В живом огранизме очень много компенсаторных механизмов, в тех же ферментных системах например. Нет ни одной достоверной базы данных где описавались бы сложные комбинации полиморфизмов. Совсем. Так как количество комбинаций и возможных взаимодействий бесчисленно. Даже по отдельным полиморфизмам данные противоречивы (см. базы типа GWAS).
Ещё эпигеном забыли. А это как конфиг файл, где можно заметилировтать заацетилировать отдельные гены, выключить или наоборот включить их транскрипцию. Клиника всегда важнее. Наличие полиморфизма не означает, что система не работает. Иначе мы бы давно и очень быстро умерли.
Сколько тактов занимает 2 + 2 ?
1 такт? - Ответ не верен!
Функция складывания 2 + 2 теперь находится внутри супер крутого фреймворка, который умеет не только складывать, но ещё и делить! Но постойте, ведь вызвать функцию запихнув операнды в регистры - это всего на пару тактов больше. Ха! Супер мега крутой фрейморк, он оказывается написан на супер мега крутом интерпретируемом языке. А интерпретатор... хм... На неком байт-коде, который JIT должен переварить, и будучи сытым и довольным, запустить на выполнение. Ой, а счётчик тактов совсем забыли, но уже по-моему 6-значное число. Подождите, ещё не всё :). Наш супр классный переваренный джитом машинный код, он оказыватеся выполняется на виртуальной машине! (да! яйцо в утке, утка в зайце и дальше по списку), которая мамой клянётся, что не интерпретатор, а всего-лишь гипервизор (но это не точно). Зато как классно деплоится в облако, в виде образа в 100500 мегабайт.
/сарказм=off
Просто в статье сначала идёт речь о "преобладающем элементе" (который будет в случае моего примера 1), потом о "преобладающем элементе, встречающемся более n/2 раз". Это может вводить в заблуждение..
Для последовательности 1,2,3,1,4,5,1,6,7,1,8,9 должно находить 1 ?
Это всё понятно, вопрос не про UI поток. У меня нет UI потока. У меня Web-Service. Он на запрос должен прочитать файл на 100500 гигабайт и вернуть ответ. Какое преимущество async IO в данном случае, вопрос был об этом.
Интересно бы понять преимущества async операций ввода-вывода. Ведь данные диск нам всё-равно быстрее, чем может, не вернёт. Соответственно, продолжать дальше мы по-любому не можем. Ну ладно, мы освободили текущий поток для чего-то ещё. Если этого чего-то ещё нет - то и освобождать некому. Если наш дргуой код (который не ждёт данные, а делает что-то ещё) мы и так забросили в другой поток, тут опять мы ничего не выигрываем. А async вызов - это лишнее переключение контекста и просто так не даётся (ну смотря как оно реализовано, может быть через WinAPI overlapped i/o).
Есть там ещё какая-то заморочка со therad pool когда мы реализуем web сервис например. Вместо создание нового потока для нового запроса фреймворк может как-то заиспользовать уже имеющийся, который висит на ожидании данных. Но это всё туманно. Может есть benchmark'и какие-нибудь с циферками, где можно выйгрыш посмотреть?
Из личного опыта. Во многоих, очень многих случаях скрам превращается в карго культ.
Можно и человека с его "интеллектом" редуцировать до набора детерминированных инструкций. Поступил нужный сигнал выше текущего(!) порога срабатывания на нейрон - нейрон переключился. Как чайник. Или 1.00500Е+09 чайников. Всё дело в сложности модели. С живым нейроном, правда, хитро. Там тепловой и прочий квантовый шум играет ну очень уж большую роль.
Интересно конечно на клеточном уровне, на уровне ферментативных реакций бы посмотреть, почему так происходит... Но наверное до этого ещё не скоро дойдут.
С проводами кстати, для справки, китайцы очень любят использовать CCS (меднёная сталь). На вид выглядит как медь, но на самом деле сталь. Сопротивление на DC или на низкой частоте AC можно себе представить (это в разы выше, чем у меди или даже алюминия). Проверяется очень просто, внезапно, магнитом :)
Один раз вся лаборатория ломала голову, почему в серевере отваливается SSD периодически. Просто вылетает в ошибку и больше не определяется. Оказалось дешевый китайский удлинитель питания ATX. На проводах всё красиво, AWG сколько-то там, прямо толсто толсто. Но чуть нагрузку давали и на шине 3.3В падало что-то порядка 0.5В. И как оказалось для SSD было фатально. Заменили на нормальный (с таким же AWG, но чистокоровной меди) - всё стало на свои места.
Красивая пропаганда CBDC. Спасибо, но нет...
Наверное всё-таки не квадрат расстояния. У нас расхождение волны не на все, как говорится, 4 стороны. Волна остаётся в сферическом слое, т.е. по сути в плоскости. Соответвенно степень не 2, а 1. Линейно эгергия будет уменьшаться, а не квадратично.
Человечество выпилит само себя. ИИ - это всего-лишь мощный инструмент в неумелых руках.
Сложно даже представить, спрогнозировать, какие социальные потрясения это всё спровоцирует. Достаём поп-корн. Гранату обезъяне уже выдали. Ждём, что будет дальше.