Тысячелетняя народная мудрость мира сего по этому поводу гласит "Заставь дурака молиться..." и "Благими намерениями вымощена дорога в ...". Немощные они на этой стезе, что уж с них взять. Но в остальном - жутко прагматичные. Этого у них не отнять. И так у них это почти везде. В том же FB однажды, хохмы ради картинку одну исказил, запостил. Так они, болезненные, на полном серьёзе потом ярлык к посту приклеили, мол картинка сия есть фейк 😲 Ясен пень - фейк, это ж и ежу понятно! Народ потом больше с самого ярлыка ржал, чем с картинки, Задорного цитировал ))) Эх. Ну да ладно.
Ага 😉 406-ти летний, бронзовый "ребёнок" 🤪 А вообще, это показатель качества исходных данных на которых обучаются всякие "передовые" модели ИИ. Но информация, это ведь тоже пища, только для головы. Что-то не хочется мне с такими моделями "общаться". Совсем. А то ж: с кем поведёшься, от того и наберёшься.
Помнится, году эдак в 2014, я загрузил себе в облако OneDrive фотку скульптуры Писающий мальчик. На следующий день из Microsoft пришло гневное письмо о нарушении "Условия". Картинку удалил, OneDrive с тех пор не пользовался ни разу.
И всё же есть разница между TTFB (elapsed содержит именно это значение) и собственно скоростью передачи данных по каналу.
Последнее обычно требует более изощрённых методов.
Обычно производят несколько (последовательных или параллельных) измерений полного времени передачи данных (то есть до последнего байта, как в примере автора) после чего вычисляют медиану полученных замеров, что впоследствии и подаётся, как реальная, практическая скорость передачи данных по каналу. Такой метод, к примеру, используется в iperf3. Такие замеры будут носить более объективных характер, так как могут сглаживать такие моменты, как Burst-технологии. Технология Burst предназначена для подачи увеличенной скорости при назначенном лимите на короткое время. Такие технологии широко используются в различных машрутизаторах, например, в Mikrotik.
Но даже в этом случае, реальная, практическая скорость передачи данных по каналу может быть необъективной и зависеть де-факто ещё и от прочих условий. Например, от типа данных (типа трафика). Скорость передачи определённых данных может регулироваться, например QoS.
Но если целью ставится измерение TTFB HTTP-запроса, то тогда лучше всё-таки так:
response.history[0].elapsed.total_seconds()
а то ж, можно и на 301 наткнуться и тогда де-факто, просто response.elapsed будет содержать значение, отличное от самого первого отклика от сервера, например, второе, после редиректа, то есть response.history[1].elapsed.
А вообще, измерять скорость канала данных лучше не через HTTP.
Суть TTFB
import datetime
import requests
n = datetime.datetime.now()
r = requests.get("https://habr.com", stream=False)
print(
f"h\t:{r.history}\n"
f"he\t:{r.history[0].elapsed.total_seconds()}\n"
f"ce\t:{r.elapsed.total_seconds()}\n"
f"fe\t:{(datetime.datetime.now()-n).total_seconds()}"
)
Вы измеряете не скорость отдачи файла на сервер, а скорость отдачи файла на сервер плюс побочные действия, не связанные непосредственно с измерением требуемой скорости.
Измерять временные интервалы необходимо непосредственно перед началом http-запроса и сразу по его окончанию.
Измерять временные интервалы лучше при помощи time.monotonic(). time() использует системные часы, которые могут быть изменены пользователем или системными службами, например, при автоматической корректировке часов при переходе на летнее или зимнее время соответствующего региона, на который настроена операционная система. monotonic() же лишён этого изъяна, связанного с переводом системных часов и всегда возвращает актуальное действительное значение больше предыдущего.
def upload(id, url):
file_name = str(id) + 'random7000x7000.jpg'
if os.path.exists(file_name):
size = os.path.getsize(file_name)
with open(file_name, 'r+b') as f:
files = {'file': (file_name, f.read())}
start = time.monotonic()
r = requests.post(url, files=files)
end = time.monotonic()
if r.status_code == 200:
duration = end - start
sp = (((size * 8) / 1024) / 1024) / duration
return sp
else:
print("Requests status code is '{}'".format(r.status_code), file=sys.stderr)
return -1
else:
print("No such file '{}'".format(file_name), file=sys.stderr)
return -1
Это буквально — API сервисов MS DOS для приложений доступен через int 21h. Который не используется Windows 3.1, но вы вольны обращаться к нему из приложений.
Ошибаетесь.
Семейство Windows 3.x могло функционировать в трёх различных режимах работы с памятью:
Реальный режим, предназначенный для старых компьютеров (8086, 8088, 80186).
Стандартный режим, предназначенный для компьютеров с процессором 80286.
Расширенный режим 386, предназначенный для компьютеров с процессором 80386.
В реальном режиме Windows 3.x полностью полагался на MS DOS.
В стандартном режиме использовался DOS-extender (dosx.exe).
А в расширенном — VMM.
DOS-extender (расширитель DOS) предоставляет прикладной программе различные сервисы по управлению памятью и прочими ресурсами через программные прерывания.
В свою очередь всем расширителям DOS приходится вызывать DOS API для доступа к диску, сети и т. д.
VMM же всегда разрабатывался как надстройка над MS-DOS.
В Windows, основанных на VMM навсегда остались 16-битные подсистемы USER и GDI. Настоящая вытесняющая многозадачность в VMM была только между виртуальными машинами MS-DOS, которые по очевидным причинам не знали о USER и GDI и никогда туда не обращались.
Что касается устройств, то приложения DOS обычно содержали в себе весь код для работы со "своими" устройствами, и VMM потому первоначально также не включал в себя драйверы устройств.
Таким образом, Ваше утверждение о том, что Windows 3.1 не использовал MS DOS — является ошибкой.
Если пойти дальше, то Windows 3.11 for Workstation использует 21-е прерывание MS DOS, полностью подменяя его своим программным кодом.
Итого.
Windows 3.x требует предварительно установленной копии MS-DOS, которая должна загружаться при включении компьютера. Windows 3.x затем запускается как приложение, и её работа может быть прервана в любое время, в результате чего происходит возврат в обычную командную оболочку MS-DOS.
Кроме того, драйверы для некоторых устройств (включая драйверы для дисководов для компакт-дисков и доступа к сети) предоставляются только MS-DOS.
Windows 95 не требует предварительно установленной полноценной копии MS-DOS для своего запуска, а загружается сразу загрузчиком ОС. При завершении работы Windows 95 возврата в обычную командную оболочку MS-DOS не происходит за отсутствием таковой на этапе, предшествующем загрузке Windows 95. Но при этом мы помним, что часть программного кода MS DOS заимствована в программном коде Windows 95 (например, всё в том же VMM со своим 16-битным наследием). Но MS DOS, как таковая, здесь уже не представлена в независимом, выделенном, автономном и полноценном виде. По сути — MS DOS уже как таковой тут нет. Поэтому назвать Windows 95 неполноценной ОС уже нельзя (хотя следы MS DOS в линейке Windows 9x (95,98,ME) будут тянуться ещё долго).
Но вернёмся к Windows 3.x.
Программа в среде MS-DOS имеет возможность выполнять любые действия, в том числе заменять или пропускать код MS-DOS или его часть, временно или постоянно. Это основа написания резидентных программ (прости мне Господи все мои прегрешения тех лет).
И Windows 3.x как раз и использует эту возможность (предоставленную MS DOS) в своих собственных целях. Однако, уровень пропуска стандартного кода MS-DOS возрастал с каждой новой версией Windows.
Windows 3.1 и её 32-разрядный доступ к диску заменял код BIOS для доступа к дискам через перехват int 13h и частично код MS DOS через перехват int 21h, подменяя собой, например, такие функции этого прерывания, как 13H, 1bH, 1dH, 21H и 22H (и другие), если помните. Перехват стандартного десятого прерывания BIOS активно использовался GDI (двумерная графика) для обеспечения работы USER (пользовательский интерфейс, менеджер окон), а Windows для рабочих групп 3.11 заменяла родной код MS-DOS для обращения к файлам полностью (и опять же, через перехват int 21h и ряда функций MS DOS этого прерывания).
И вот Вам таки вопрос.
Перехват уже существующего прерывания, изначально установленного программным кодом предшественника, то есть подмена адреса обработчика данного прерывания адресом начала своего программного кода (с возможным запоминанием его и последующим восстановлением) — это по Вашему что?
Это полноценная операционная система или операционная система (или приложение) поверх другой полноценной операционной системы? Считается ли такое поведение взаимодействием, особенно в свете использования Windows 3.x драйверов для дисководов для компакт-дисков и доступа к сети, которые предоставляются MS DOS и без которых Windows 3.x становится бесполезным ПО? Что является причиной и что является следствием?
Давайте вернёмся к основе вопроса — может ли операционная система считаться полноценной, если для её функционирования обязательно требуется наличие другой полноценной операционной системы и никак иначе?
Речь не идёт о микропрограммном коде, например, базовой системы ввода/вывода или драйверов устройств, потому что ни те ни другие не обеспечивают полного комплекса взаимодействия пользователя или приложения с аппаратной частью устройства. Этим занимается посредник (дирижёр) — операционная система (или сервис), которая, объединяя все части системы в целое, оперирует (дирижирует) ими, устанавливая некоторые правила и возможности. Именно поэтому — она и называется операционной.
Если Вы действительно писали системное ПО под MS DOS, Windows 3.x и Windows 95, то должны понимать, как именно влияют котлеты на поведение мух.
P.S. Извините, если чем-то кого-то обидел. 51 год. В ИТ с 1989 года.
Никак не взаимодействуя с сервисами MS DOS, лишь предоставляя к ним доступ — это как?
DrPass, Вы когда-нибудь писали системные программы для MS DOS (например, резидентные), для Windows 3.x и далее?
Когда кажется - креститься надо
Архитектура
Windows 95 была спроектирована так, чтобы быть максимально совместимой с существующими 16-битными Windows и MS-DOS программами, а также с драйверами устройств, в то же время предоставляя более быструю и стабильную работу. Архитектура Windows 95 есть эволюция расширенного 386 режима работы Windows for Workgroups. Самый нижний уровень операционной системы состоит из большого числа драйверов виртуальных устройств (virtual device drivers VxDs), запускаемых в 32-битном защищенном режиме, и одной или более виртуальных DOS машин, запускаемых в виртуальном 8086 режиме. Драйвера виртуальных устройств отвечают за обработку физических устройств (таких как видео и сетевые карты), эмулирование виртуальных устройств, используемых виртуальными машинами, или обеспечение различных системных сервисов. Ниже перечислены три наиболее важных драйвера виртуальных устройств:
Менеджер виртуальных машин (Virtual Machine Manager VMM32.VXD)
Отвечает за управление памятью, обработку событий и прерываний, загрузку и инициализацию драйверов виртуальных устройств, создание новых виртуальных машин и управление потоками.
Конфигурационный менеджер (Configuration Manager CONFIGMG)
Отвечает за реализацию функционала “Plug and play”; мониторинг изменений конфигурации аппаратных средств; обнаружение устройств, используя нумераторы шин; назначение портов ввода/вывода, запросов на прерывание (IRQs), каналов прямого доступа к памяти (DMA) и обеспечение бесконфликтной работы с памятью.
Устанавливаемый диспетчер файловой системы (Installable File System Manager) (подсистема ввода/вывода)
Координирует доступ к поддерживаемым файловым системам. Windows 95 изначально поставлялась с поддержкой FAT12, FAT16, расширения VFAT, ISO 9660 (CDFS) и сетевых перенаправителей (network redirectors). Позже была выпущена поддержка FAT32.
Запросы доступа к физическим носителям отправляются к супервизору ввода/вывода (Input/Output Supervisor), компоненту, ответственному за планирование запросов. Каждый физический носитель имеет свой собственный драйвер устройства: доступ к диску осуществляется с помощью драйвера порта (port driver), тогда как доступ к SCSI устройству обрабатывается минипорт-драйвером (miniport driver), который работает поверх уровня SCSI. Драйвера порта и минипорта осуществляют операции ввода/вывода в 32-битном защищенном режиме, минуя MS-DOS и BIOS, обеспечивая значительное улучшение производительности. В случае, если для некоторого запоминающего устройства нет родного драйвера Windows, или если устройство вынужденно запускаться в режиме совместимости, Real Mode Mapper может обращаться к ним через MS-DOS.
32-битные Windows программам назначаются их собственные сегментам памяти, которые могут быть приведены к любому желаемому размеру. Доступ к памяти вне сегмента невозможен. Если в программе происходит сбой, то ничего другое не повреждается. До этого в программах использовались фиксированные невыносимые (non-exclusive) сегменты размером 64 КБ. Хотя размер 64 КБ был серьезным препятствием для DOS и Windows 3.x, отсутствие гарантии выносисмости стало причиной проблем со стабильностью, поскольку программы иногда перезаписывали сегменты друг друга. Аварийная программа Windows 3.x может выбить окружающие процессы.
Win32 API реализован тремя модулями, каждый состоит из 16-ти и 32-битного компонентов:
Kernel
Обеспечивает высокоуровневый доступ к памяти, управление процессами и доступ к файловой системе. Состоит из KRNL386.EXE, KERNEL32.DLL и VWIN32.VXD.
User
Данный модуль ответственен за управление и отрисовку различных компонентов пользовательского интерфейса, таких как окна, меню и кнопки.
Graphics Device Interface (GDI)
Отвечает за отрисовку изображений способом, независимым от конкретного устройства вывода. Состоит из GDI.EXE и GDI32.DLL.
Зависимость от MS-DOS
Для конечных пользователей MS-DOS выступает в качестве основного компонента Windows 95. Например, можно предотвратить загрузку графического пользовательского интерфейса и загрузить систему в среду реального времени MS-DOS. Это вызвало споры среди пользователей и специалистов по вопросу о том, в какой мере Windows 95 является операционной системой или просто графической оболочкой, которая работает поверх MS-DOS.
Когда графический интерфейс пользователя запущен, диспетчер виртуальной машины берет на себя функции, связанные с файловой системой и диском. Сама MS-DOS понижена до уровня совместимости c 16-разрядными драйверами устройств. Это контрастирует с более ранними версиями Windows, которые полагаются на MS-DOS для доступа к файлам и диску (Windows for Workgroups 3.11 также может в значительной степени обойти MS-DOS, когда включены 32-разрядный доступ к файлам и 32-разрядный доступ к диску). Сохранение MS-DOS в памяти позволяет Windows 95 использовать драйверы устройств DOS, когда подходящие драйверы Windows недоступны. Windows 95 способна использовать все 16-разрядные драйверы Windows 3.x.
В отличие от Windows 3.1x, работающие в Windows 95 программы DOS не нуждаются в драйверах DOS для мыши, CD-ROM и звуковой карты. Вместо этого используются драйверы Windows. HIMEM.SYS по-прежнему требуется для загрузки Windows 95. EMM386 и другие менеджеры памяти, однако, используются только старыми программами DOS. Кроме того, настройки CONFIG.SYS и AUTOEXEC.BAT (кроме HIMEM.SYS) не оказывают влияния на программы Windows. Игры DOS, которые не могли быть запущены на Windows 3.x, могут запускаться внутри Windows 95 (игры, как правило, блокируют Windows 3.x или вызывают другие проблемы). Как и в Windows 3.x, программы DOS, которые используют графические режимы EGA или VGA, работают в оконном режиме (программы CGA и текстового режима могут продолжать работать).
При запуске Windows 95 компонент MS-DOS реагирует на нажатие клавиши F8, временно приостанавливая процесс загрузки по умолчанию и представляя меню параметров загрузки DOS, позволяя пользователю продолжать нормально запускать Windows, запускать Windows в безопасном режиме или выйти в режим DOS. Как и в предыдущих версиях MS-DOS, тут нет 32-разрядной поддержки и драйверы DOS должны быть загружены для мыши и другого оборудования.
Будучи основанной на DOS, Windows 95 должна поддерживать внутренние структуры данных DOS, синхронизированные с структурами Windows 95. При запуске программы, даже собственной 32-разрядной программы Windows, MS-DOS кратковременно выполняет создание структуры данных, такой как Program Segment Prefix (префикс сегмента программы). Возможно, MS-DOS даже не использует обычную память, что препятствует запуску программы. Windows 3.x выделяет фиксированные сегменты в обычной памяти. Поскольку сегменты были распределены как фиксированные, Windows не могла их перемещать, что могло бы помешать запуску других программ.
Microsoft частично удалила поддержку File Control Blocks (блоки управления файлами) в Windows 95 OSR2 (OEM Service Release 2). Функции FCB могут читать только тома FAT32, но не записывать их.
Системы Windows (не только 3.x и ниже, но также и Windows 9x: 95, 98 и Me) имеют сложную, оригинальную, гибридную и не полностью документированную внутреннюю структуру. Прежде всего, для их работы требуется MS-DOS, то есть они выполняются как бы «над» MS-DOS. По этой причине трудно определить, являются ли они операционными системами или всего лишь оболочками-расширениями для MS-DOS. Многие пользователи считают их операционными системами, поскольку они выглядят так же, как и многие полноценные ОС. В то же время другие не считают это семейство Windows настоящими операционными системами.
Windows 3.x требует предварительно установленной копии MS-DOS, которая должна загружаться при включении компьютера. Windows затем запускается как приложение, и её работа может быть прервана в любое время, в результате чего пользователь возвращается в обычную командную оболочку MS-DOS. (Для сравнения: в UNIX-подобных операционных системах (в том числе и Linux) так запускается и работает X Window System — графический сервер, реализующий GUI.) Кроме того, драйверы для некоторых устройств (включая драйверы для дисководов для компакт-дисков и доступа к сети) предоставляются MS-DOS. С другой стороны, Windows требует специальным образом написанных приложений и имеет особый формат для исполняемых файлов, который значительно сложнее, чем аналогичный формат в MS-DOS. Windows имеет большое количество собственных драйверов и по большей части собственную систему управления памятью.
Помимо этого, MS-DOS не изолирует приложения от аппаратного обеспечения и не защищает себя саму от приложений. Резидентная часть MS-DOS сродни библиотеке функций, предназначенных для работы с дисковыми накопителями и для загрузки приложений с них. Программа в среде MS-DOS имеет возможность выполнять любые действия, в том числе заменять или пропускать код MS-DOS или его часть, временно или постоянно. Windows использует эту возможность в своих собственных целях, и уровень пропуска стандартного кода MS-DOS возрастал с каждой новой версией. Windows 3.1 и её 32-разрядный доступ к диску заменял код BIOS для доступа к дискам, а Windows для рабочих групп 3.11 заменяла «родной» код MS-DOS для обращения к файлам. Это впоследствии сделало возможной поддержку длинных имён файлов в Windows 95, в результате чего файловый код DOS оказался устаревшим.
Кроме того, программа MS-DOS, работающая в среде Windows, могла использовать те возможности Windows, которые не поддерживались MS-DOS. Программа MS-DOS, выполняющаяся в Windows для рабочих групп 3.11, автоматически использовала 32-разрядный доступ к файлам вместо обычных функций доступа к файлам и дискам, имеющихся в MS-DOS. Аналогично, особым образом написанная программа для MS-DOS, работающая в Windows 95, может использовать длинные имена файлов.
Такие же принципы работы характерны для Windows 98 и Windows Me, в которых по-прежнему смешаны 16-разрядный и 32-разрядный код. Тем не менее, с каждой последующей версией 16-разрядный код становился всё менее заметным.
Семейство Windows NT состоит из операционных систем, которые полностью отделены от MS-DOS и целиком составлены из 32-разрядного кода. Программы MS-DOS и Win16 работают в специальных виртуальных машинах DOS, которые реализованы посредством обыкновенного API Win32.
Тем не менее Windows 3.x может быть успешно запущена поверх DosBox, в том числе на мобильных устройствах: телефонах Motorola MotoMagx, карманных компьютерах с операционными системами Windows Mobile, Android и Symbian OS 9.
Операционная система — это комплекс взаимосвязанных программ, предназначенных для управления ресурсами компьютера и организации взаимодействия с пользователем.
В логической структуре типичной вычислительной системы операционная система занимает положение между устройствами с их микроархитектурой, машинным языком и, возможно, собственными (встроенными) микропрограммами (BIOS и драйверами) — с одной стороны — и прикладными программами с другой.
Разработчикам программного обеспечения операционная система позволяет абстрагироваться от деталей реализации и функционирования устройств, предоставляя минимально необходимый набор функций.
BIOS (от англ. basic input/output system — «базовая система ввода-вывода») — это набор микропрограмм, реализующих API для работы с аппаратурой компьютера и подключёнными к нему устройствами.
BIOS относится к системному программному обеспечению (ПО).
В современных компьютерах процесс начальной загрузки начинается с выполнения процессором команд, расположенных в постоянной памяти (например на IBM PC — команд BIOS), начиная с предопределённого адреса (процессор делает это после перезагрузки без какой бы то ни было помощи). Данное программное обеспечение может обнаруживать устройства, подходящие для загрузки, и загружать со специального раздела выбранного устройства (чаще всего загрузочного сектора данного устройства) загрузчик ОС.
Загрузчик операционной системы — системное программное обеспечение, обеспечивающее загрузку операционной системы непосредственно после включения компьютера (процедуры POST) и начальной загрузки.
Исходя из вышеприведённой терминологии, Windows 3.x считаться полноценной ОС не может, так в свою очередь напрямую зависит от наличия другой ОС — MS DOS.
В случае Windows 3.x первой загружается MS DOS. Windows 3.x не подменяет собой MS DOS. При завершении работы Windows 3.x, управление возвращается MS DOS.
А вот начиная с Windows 95 ситуация меняется кардинально. Для работы Windows 95 другая ОС уже не нужна. Более того, Windows 95 при необходимости самостоятельно эмулирует MS DOS.
Эмуляция (англ. emulation) в вычислительной технике — комплекс программных, аппаратных средств или их сочетание, предназначенное для копирования (или эмулирования) функций одной вычислительной системы (гостя) на другой, отличной от первой, вычислительной системе (хосте) таким образом, чтобы эмулированное поведение как можно ближе соответствовало поведению оригинальной системы (гостя).
При включении компьютера с установленной Windows 95, загрузчик ОС загружает собственное ядро Windows 95. Windows 95 является полноценной и самостоятельной операционной системой. А вот с Windows 3.x так не получится — сперва MS DOS, потом всё остальное.
Считаю, что подобные статьи не несут в себе ничего плохого.
Большое спасибо за ссылки по теме!
TL;DR
Остальное, простите — вода, не имеющая к теме никакого отношения.
Когда идёт обсуждение тех или иных персональных качеств авторов статей, это угнетает не только авторов статей, но и читателей. А хотелось бы конкретных замечаний по теме статьи. Какие ошибки допустил автор, какие имеются пути для оптимизации, для масштабирования, какое прикладное решение в той или иной области можно найти, отталкиваясь конкретно от этой (или иной) статьи, примеры кода… То есть всё то, чем так и славен этот ресурс. И без навешивания ярлыков.
Я читаю хаб с 2006 года. Но темой «Машинное обучение» начал интересоваться только в 2019 году. Поэтому, в первую очередь (и это логично) читаю самые свежие статьи на эту тему, особенно те, где показываются рабочие примеры современного программирования. Теория хорошо. Но интерес многих читателей лежит в области современного практического применения. Вот именно это и есть то важное, что делает подобные статьи полезными, раз Вы об этом спросили. Если аргументировать обобщённо, все физические процессы — это процессы во времени. Не исключение и языки программирования, которые со временем развиваются и меняются. И порой на столько, что примеры из кучи уже имеющихся по той или иной тематике статей становятся или устаревшими или уже не рабочими.
По этой причине, считаю приток «свежей крови» — делом полезным во всех отношениях.
Простите. Ничего личного. Это замечание касается всех нас (и меня в том числе).
Простите, а при чём здесь когнитивное искажение автора?
Уверен, Амос Тверски и Даниэль Канеман с Вами бы не согласились, обратив внимание на принадлежность именно Вашего суждения к обозначенному Вами же понятию. Впрочем, Герд Гигеренцер сказал бы, что в этом нет никакого изъяна.
Я читаю хаб с 2006 года, и вижу, что статьи выходят с завидной регулярностью. И это хорошо, потому что всегда есть, что почитать.
Вы плохо искали.
Утверждение будет иметь ценность, только если Вы сами укажете ссылки на статьи,
где были бы описаны теория и код с нуля до полностью работающей модели.
Не сочтите, пожалуйста, за труд — поделитесь полезной информацией.
Считаю, что подобные статьи не несут в себе ничего плохого.
Спасибо.
Нет, у пня. Пень ясен. От слова "ясный", а не от "ясеня-древа пень".
Ясно солнышко. Финист (сиречь - Феникс) - ясный сокол. Ну а ежу просто понятно.
У пня спросит.
Тысячелетняя народная мудрость мира сего по этому поводу гласит "Заставь дурака молиться..." и "Благими намерениями вымощена дорога в ...". Немощные они на этой стезе, что уж с них взять. Но в остальном - жутко прагматичные. Этого у них не отнять. И так у них это почти везде. В том же FB однажды, хохмы ради картинку одну исказил, запостил. Так они, болезненные, на полном серьёзе потом ярлык к посту приклеили, мол картинка сия есть фейк 😲
Ясен пень - фейк, это ж и ежу понятно! Народ потом больше с самого ярлыка ржал, чем с картинки, Задорного цитировал )))
Эх. Ну да ладно.
Ага 😉
406-ти летний, бронзовый "ребёнок" 🤪
А вообще, это показатель качества исходных данных на которых обучаются всякие "передовые" модели ИИ. Но информация, это ведь тоже пища, только для головы. Что-то не хочется мне с такими моделями "общаться". Совсем. А то ж: с кем поведёшься, от того и наберёшься.
Помнится, году эдак в 2014, я загрузил себе в облако OneDrive фотку скульптуры Писающий мальчик. На следующий день из Microsoft пришло гневное письмо о нарушении "Условия". Картинку удалил, OneDrive с тех пор не пользовался ни разу.
Жером Дюкенуа Старший, Писающий мальчик. 1619
Я бы заменил paramiko на parallel-ssh.
Paramiko не умеет работать с кодировками отличными от строгого utf8
Нет.
Написано же в самом начале:
Автор оригинала: Eden Au
path = os.path.abspath(file)[:-11] # из абсолютного пути удаляем имя файлаpath = os.path.dirname(os.path.abspath(file))
Лениться вредно ;)
За карму спасибо!
И всё же есть разница между TTFB (elapsed содержит именно это значение) и собственно скоростью передачи данных по каналу.
Последнее обычно требует более изощрённых методов.
Обычно производят несколько (последовательных или параллельных) измерений полного времени передачи данных (то есть до последнего байта, как в примере автора) после чего вычисляют медиану полученных замеров, что впоследствии и подаётся, как реальная, практическая скорость передачи данных по каналу. Такой метод, к примеру, используется в iperf3. Такие замеры будут носить более объективных характер, так как могут сглаживать такие моменты, как Burst-технологии. Технология Burst предназначена для подачи увеличенной скорости при назначенном лимите на короткое время. Такие технологии широко используются в различных машрутизаторах, например, в Mikrotik.
Но даже в этом случае, реальная, практическая скорость передачи данных по каналу может быть необъективной и зависеть де-факто ещё и от прочих условий. Например, от типа данных (типа трафика). Скорость передачи определённых данных может регулироваться, например QoS.
Но если целью ставится измерение TTFB HTTP-запроса, то тогда лучше всё-таки так:
а то ж, можно и на 301 наткнуться и тогда де-факто, просто response.elapsed будет содержать значение, отличное от самого первого отклика от сервера, например, второе, после редиректа, то есть response.history[1].elapsed.
А вообще, измерять скорость канала данных лучше не через HTTP.
В дополнение к уже озвученной критике.
Вы измеряете не скорость отдачи файла на сервер, а скорость отдачи файла на сервер плюс побочные действия, не связанные непосредственно с измерением требуемой скорости.
Измерять временные интервалы необходимо непосредственно перед началом http-запроса и сразу по его окончанию.
Измерять временные интервалы лучше при помощи time.monotonic().
time() использует системные часы, которые могут быть изменены пользователем или системными службами, например, при автоматической корректировке часов при переходе на летнее или зимнее время соответствующего региона, на который настроена операционная система.
monotonic() же лишён этого изъяна, связанного с переводом системных часов и всегда возвращает актуальное действительное значение больше предыдущего.
Ошибаетесь.
Семейство Windows 3.x могло функционировать в трёх различных режимах работы с памятью:
В реальном режиме Windows 3.x полностью полагался на MS DOS.
В стандартном режиме использовался DOS-extender (dosx.exe).
А в расширенном — VMM.
DOS-extender (расширитель DOS) предоставляет прикладной программе различные сервисы по управлению памятью и прочими ресурсами через программные прерывания.
В свою очередь всем расширителям DOS приходится вызывать DOS API для доступа к диску, сети и т. д.
VMM же всегда разрабатывался как надстройка над MS-DOS.
В Windows, основанных на VMM навсегда остались 16-битные подсистемы USER и GDI. Настоящая вытесняющая многозадачность в VMM была только между виртуальными машинами MS-DOS, которые по очевидным причинам не знали о USER и GDI и никогда туда не обращались.
Что касается устройств, то приложения DOS обычно содержали в себе весь код для работы со "своими" устройствами, и VMM потому первоначально также не включал в себя драйверы устройств.
Таким образом, Ваше утверждение о том, что Windows 3.1 не использовал MS DOS — является ошибкой.
Если пойти дальше, то Windows 3.11 for Workstation использует 21-е прерывание MS DOS, полностью подменяя его своим программным кодом.
Итого.
Windows 3.x требует предварительно установленной копии MS-DOS, которая должна загружаться при включении компьютера. Windows 3.x затем запускается как приложение, и её работа может быть прервана в любое время, в результате чего происходит возврат в обычную командную оболочку MS-DOS.
Кроме того, драйверы для некоторых устройств (включая драйверы для дисководов для компакт-дисков и доступа к сети) предоставляются только MS-DOS.
Windows 95 не требует предварительно установленной полноценной копии MS-DOS для своего запуска, а загружается сразу загрузчиком ОС. При завершении работы Windows 95 возврата в обычную командную оболочку MS-DOS не происходит за отсутствием таковой на этапе, предшествующем загрузке Windows 95. Но при этом мы помним, что часть программного кода MS DOS заимствована в программном коде Windows 95 (например, всё в том же VMM со своим 16-битным наследием). Но MS DOS, как таковая, здесь уже не представлена в независимом, выделенном, автономном и полноценном виде. По сути — MS DOS уже как таковой тут нет. Поэтому назвать Windows 95 неполноценной ОС уже нельзя (хотя следы MS DOS в линейке Windows 9x (95,98,ME) будут тянуться ещё долго).
Но вернёмся к Windows 3.x.
Программа в среде MS-DOS имеет возможность выполнять любые действия, в том числе заменять или пропускать код MS-DOS или его часть, временно или постоянно. Это основа написания резидентных программ (прости мне Господи все мои прегрешения тех лет).
И Windows 3.x как раз и использует эту возможность (предоставленную MS DOS) в своих собственных целях. Однако, уровень пропуска стандартного кода MS-DOS возрастал с каждой новой версией Windows.
Windows 3.1 и её 32-разрядный доступ к диску заменял код BIOS для доступа к дискам через перехват int 13h и частично код MS DOS через перехват int 21h, подменяя собой, например, такие функции этого прерывания, как 13H, 1bH, 1dH, 21H и 22H (и другие), если помните. Перехват стандартного десятого прерывания BIOS активно использовался GDI (двумерная графика) для обеспечения работы USER (пользовательский интерфейс, менеджер окон), а Windows для рабочих групп 3.11 заменяла родной код MS-DOS для обращения к файлам полностью (и опять же, через перехват int 21h и ряда функций MS DOS этого прерывания).
И вот Вам таки вопрос.
Перехват уже существующего прерывания, изначально установленного программным кодом предшественника, то есть подмена адреса обработчика данного прерывания адресом начала своего программного кода (с возможным запоминанием его и последующим восстановлением) — это по Вашему что?
Это полноценная операционная система или операционная система (или приложение) поверх другой полноценной операционной системы? Считается ли такое поведение взаимодействием, особенно в свете использования Windows 3.x драйверов для дисководов для компакт-дисков и доступа к сети, которые предоставляются MS DOS и без которых Windows 3.x становится бесполезным ПО? Что является причиной и что является следствием?
Давайте вернёмся к основе вопроса — может ли операционная система считаться полноценной, если для её функционирования обязательно требуется наличие другой полноценной операционной системы и никак иначе?
Речь не идёт о микропрограммном коде, например, базовой системы ввода/вывода или драйверов устройств, потому что ни те ни другие не обеспечивают полного комплекса взаимодействия пользователя или приложения с аппаратной частью устройства. Этим занимается посредник (дирижёр) — операционная система (или сервис), которая, объединяя все части системы в целое, оперирует (дирижирует) ими, устанавливая некоторые правила и возможности. Именно поэтому — она и называется операционной.
Если Вы действительно писали системное ПО под MS DOS, Windows 3.x и Windows 95, то должны понимать, как именно влияют котлеты на поведение мух.
P.S. Извините, если чем-то кого-то обидел. 51 год. В ИТ с 1989 года.
Никак не взаимодействуя с сервисами MS DOS, лишь предоставляя к ним доступ — это как?
DrPass, Вы когда-нибудь писали системные программы для MS DOS (например, резидентные), для Windows 3.x и далее?
Архитектура
Windows 95 была спроектирована так, чтобы быть максимально совместимой с существующими 16-битными Windows и MS-DOS программами, а также с драйверами устройств, в то же время предоставляя более быструю и стабильную работу. Архитектура Windows 95 есть эволюция расширенного 386 режима работы Windows for Workgroups. Самый нижний уровень операционной системы состоит из большого числа драйверов виртуальных устройств (virtual device drivers VxDs), запускаемых в 32-битном защищенном режиме, и одной или более виртуальных DOS машин, запускаемых в виртуальном 8086 режиме. Драйвера виртуальных устройств отвечают за обработку физических устройств (таких как видео и сетевые карты), эмулирование виртуальных устройств, используемых виртуальными машинами, или обеспечение различных системных сервисов. Ниже перечислены три наиболее важных драйвера виртуальных устройств:
Менеджер виртуальных машин (Virtual Machine Manager VMM32.VXD)
Отвечает за управление памятью, обработку событий и прерываний, загрузку и инициализацию драйверов виртуальных устройств, создание новых виртуальных машин и управление потоками.
Конфигурационный менеджер (Configuration Manager CONFIGMG)
Отвечает за реализацию функционала “Plug and play”; мониторинг изменений конфигурации аппаратных средств; обнаружение устройств, используя нумераторы шин; назначение портов ввода/вывода, запросов на прерывание (IRQs), каналов прямого доступа к памяти (DMA) и обеспечение бесконфликтной работы с памятью.
Устанавливаемый диспетчер файловой системы (Installable File System Manager) (подсистема ввода/вывода)
Координирует доступ к поддерживаемым файловым системам. Windows 95 изначально поставлялась с поддержкой FAT12, FAT16, расширения VFAT, ISO 9660 (CDFS) и сетевых перенаправителей (network redirectors). Позже была выпущена поддержка FAT32.
Запросы доступа к физическим носителям отправляются к супервизору ввода/вывода (Input/Output Supervisor), компоненту, ответственному за планирование запросов. Каждый физический носитель имеет свой собственный драйвер устройства: доступ к диску осуществляется с помощью драйвера порта (port driver), тогда как доступ к SCSI устройству обрабатывается минипорт-драйвером (miniport driver), который работает поверх уровня SCSI. Драйвера порта и минипорта осуществляют операции ввода/вывода в 32-битном защищенном режиме, минуя MS-DOS и BIOS, обеспечивая значительное улучшение производительности. В случае, если для некоторого запоминающего устройства нет родного драйвера Windows, или если устройство вынужденно запускаться в режиме совместимости, Real Mode Mapper может обращаться к ним через MS-DOS.
32-битные Windows программам назначаются их собственные сегментам памяти, которые могут быть приведены к любому желаемому размеру. Доступ к памяти вне сегмента невозможен. Если в программе происходит сбой, то ничего другое не повреждается. До этого в программах использовались фиксированные невыносимые (non-exclusive) сегменты размером 64 КБ. Хотя размер 64 КБ был серьезным препятствием для DOS и Windows 3.x, отсутствие гарантии выносисмости стало причиной проблем со стабильностью, поскольку программы иногда перезаписывали сегменты друг друга. Аварийная программа Windows 3.x может выбить окружающие процессы.
Win32 API реализован тремя модулями, каждый состоит из 16-ти и 32-битного компонентов:
Kernel
Обеспечивает высокоуровневый доступ к памяти, управление процессами и доступ к файловой системе. Состоит из KRNL386.EXE, KERNEL32.DLL и VWIN32.VXD.
User
Данный модуль ответственен за управление и отрисовку различных компонентов пользовательского интерфейса, таких как окна, меню и кнопки.
Graphics Device Interface (GDI)
Отвечает за отрисовку изображений способом, независимым от конкретного устройства вывода. Состоит из GDI.EXE и GDI32.DLL.
Зависимость от MS-DOS
Для конечных пользователей MS-DOS выступает в качестве основного компонента Windows 95. Например, можно предотвратить загрузку графического пользовательского интерфейса и загрузить систему в среду реального времени MS-DOS. Это вызвало споры среди пользователей и специалистов по вопросу о том, в какой мере Windows 95 является операционной системой или просто графической оболочкой, которая работает поверх MS-DOS.
Когда графический интерфейс пользователя запущен, диспетчер виртуальной машины берет на себя функции, связанные с файловой системой и диском. Сама MS-DOS понижена до уровня совместимости c 16-разрядными драйверами устройств. Это контрастирует с более ранними версиями Windows, которые полагаются на MS-DOS для доступа к файлам и диску (Windows for Workgroups 3.11 также может в значительной степени обойти MS-DOS, когда включены 32-разрядный доступ к файлам и 32-разрядный доступ к диску). Сохранение MS-DOS в памяти позволяет Windows 95 использовать драйверы устройств DOS, когда подходящие драйверы Windows недоступны. Windows 95 способна использовать все 16-разрядные драйверы Windows 3.x.
В отличие от Windows 3.1x, работающие в Windows 95 программы DOS не нуждаются в драйверах DOS для мыши, CD-ROM и звуковой карты. Вместо этого используются драйверы Windows. HIMEM.SYS по-прежнему требуется для загрузки Windows 95. EMM386 и другие менеджеры памяти, однако, используются только старыми программами DOS. Кроме того, настройки CONFIG.SYS и AUTOEXEC.BAT (кроме HIMEM.SYS) не оказывают влияния на программы Windows. Игры DOS, которые не могли быть запущены на Windows 3.x, могут запускаться внутри Windows 95 (игры, как правило, блокируют Windows 3.x или вызывают другие проблемы). Как и в Windows 3.x, программы DOS, которые используют графические режимы EGA или VGA, работают в оконном режиме (программы CGA и текстового режима могут продолжать работать).
При запуске Windows 95 компонент MS-DOS реагирует на нажатие клавиши F8, временно приостанавливая процесс загрузки по умолчанию и представляя меню параметров загрузки DOS, позволяя пользователю продолжать нормально запускать Windows, запускать Windows в безопасном режиме или выйти в режим DOS. Как и в предыдущих версиях MS-DOS, тут нет 32-разрядной поддержки и драйверы DOS должны быть загружены для мыши и другого оборудования.
Будучи основанной на DOS, Windows 95 должна поддерживать внутренние структуры данных DOS, синхронизированные с структурами Windows 95. При запуске программы, даже собственной 32-разрядной программы Windows, MS-DOS кратковременно выполняет создание структуры данных, такой как Program Segment Prefix (префикс сегмента программы). Возможно, MS-DOS даже не использует обычную память, что препятствует запуску программы. Windows 3.x выделяет фиксированные сегменты в обычной памяти. Поскольку сегменты были распределены как фиксированные, Windows не могла их перемещать, что могло бы помешать запуску других программ.
Microsoft частично удалила поддержку File Control Blocks (блоки управления файлами) в Windows 95 OSR2 (OEM Service Release 2). Функции FCB могут читать только тома FAT32, но не записывать их.
Чтобы прекратить споры.
Полная ОС или оболочка для MS-DOS?
Системы Windows (не только 3.x и ниже, но также и Windows 9x: 95, 98 и Me) имеют сложную, оригинальную, гибридную и не полностью документированную внутреннюю структуру. Прежде всего, для их работы требуется MS-DOS, то есть они выполняются как бы «над» MS-DOS. По этой причине трудно определить, являются ли они операционными системами или всего лишь оболочками-расширениями для MS-DOS. Многие пользователи считают их операционными системами, поскольку они выглядят так же, как и многие полноценные ОС. В то же время другие не считают это семейство Windows настоящими операционными системами.
Windows 3.x требует предварительно установленной копии MS-DOS, которая должна загружаться при включении компьютера. Windows затем запускается как приложение, и её работа может быть прервана в любое время, в результате чего пользователь возвращается в обычную командную оболочку MS-DOS. (Для сравнения: в UNIX-подобных операционных системах (в том числе и Linux) так запускается и работает X Window System — графический сервер, реализующий GUI.) Кроме того, драйверы для некоторых устройств (включая драйверы для дисководов для компакт-дисков и доступа к сети) предоставляются MS-DOS. С другой стороны, Windows требует специальным образом написанных приложений и имеет особый формат для исполняемых файлов, который значительно сложнее, чем аналогичный формат в MS-DOS. Windows имеет большое количество собственных драйверов и по большей части собственную систему управления памятью.
Помимо этого, MS-DOS не изолирует приложения от аппаратного обеспечения и не защищает себя саму от приложений. Резидентная часть MS-DOS сродни библиотеке функций, предназначенных для работы с дисковыми накопителями и для загрузки приложений с них. Программа в среде MS-DOS имеет возможность выполнять любые действия, в том числе заменять или пропускать код MS-DOS или его часть, временно или постоянно. Windows использует эту возможность в своих собственных целях, и уровень пропуска стандартного кода MS-DOS возрастал с каждой новой версией. Windows 3.1 и её 32-разрядный доступ к диску заменял код BIOS для доступа к дискам, а Windows для рабочих групп 3.11 заменяла «родной» код MS-DOS для обращения к файлам. Это впоследствии сделало возможной поддержку длинных имён файлов в Windows 95, в результате чего файловый код DOS оказался устаревшим.
Кроме того, программа MS-DOS, работающая в среде Windows, могла использовать те возможности Windows, которые не поддерживались MS-DOS. Программа MS-DOS, выполняющаяся в Windows для рабочих групп 3.11, автоматически использовала 32-разрядный доступ к файлам вместо обычных функций доступа к файлам и дискам, имеющихся в MS-DOS. Аналогично, особым образом написанная программа для MS-DOS, работающая в Windows 95, может использовать длинные имена файлов.
Такие же принципы работы характерны для Windows 98 и Windows Me, в которых по-прежнему смешаны 16-разрядный и 32-разрядный код. Тем не менее, с каждой последующей версией 16-разрядный код становился всё менее заметным.
Семейство Windows NT состоит из операционных систем, которые полностью отделены от MS-DOS и целиком составлены из 32-разрядного кода. Программы MS-DOS и Win16 работают в специальных виртуальных машинах DOS, которые реализованы посредством обыкновенного API Win32.
Тем не менее Windows 3.x может быть успешно запущена поверх DosBox, в том числе на мобильных устройствах: телефонах Motorola MotoMagx, карманных компьютерах с операционными системами Windows Mobile, Android и Symbian OS 9.
Операционная система — это комплекс взаимосвязанных программ, предназначенных для управления ресурсами компьютера и организации взаимодействия с пользователем.
В логической структуре типичной вычислительной системы операционная система занимает положение между устройствами с их микроархитектурой, машинным языком и, возможно, собственными (встроенными) микропрограммами (BIOS и драйверами) — с одной стороны — и прикладными программами с другой.
Разработчикам программного обеспечения операционная система позволяет абстрагироваться от деталей реализации и функционирования устройств, предоставляя минимально необходимый набор функций.
BIOS (от англ. basic input/output system — «базовая система ввода-вывода») — это набор микропрограмм, реализующих API для работы с аппаратурой компьютера и подключёнными к нему устройствами.
BIOS относится к системному программному обеспечению (ПО).
В современных компьютерах процесс начальной загрузки начинается с выполнения процессором команд, расположенных в постоянной памяти (например на IBM PC — команд BIOS), начиная с предопределённого адреса (процессор делает это после перезагрузки без какой бы то ни было помощи). Данное программное обеспечение может обнаруживать устройства, подходящие для загрузки, и загружать со специального раздела выбранного устройства (чаще всего загрузочного сектора данного устройства) загрузчик ОС.
Загрузчик операционной системы — системное программное обеспечение, обеспечивающее загрузку операционной системы непосредственно после включения компьютера (процедуры POST) и начальной загрузки.
Исходя из вышеприведённой терминологии, Windows 3.x считаться полноценной ОС не может, так в свою очередь напрямую зависит от наличия другой ОС — MS DOS.
В случае Windows 3.x первой загружается MS DOS. Windows 3.x не подменяет собой MS DOS. При завершении работы Windows 3.x, управление возвращается MS DOS.
А вот начиная с Windows 95 ситуация меняется кардинально. Для работы Windows 95 другая ОС уже не нужна. Более того, Windows 95 при необходимости самостоятельно эмулирует MS DOS.
Эмуляция (англ. emulation) в вычислительной технике — комплекс программных, аппаратных средств или их сочетание, предназначенное для копирования (или эмулирования) функций одной вычислительной системы (гостя) на другой, отличной от первой, вычислительной системе (хосте) таким образом, чтобы эмулированное поведение как можно ближе соответствовало поведению оригинальной системы (гостя).
При включении компьютера с установленной Windows 95, загрузчик ОС загружает собственное ядро Windows 95. Windows 95 является полноценной и самостоятельной операционной системой. А вот с Windows 3.x так не получится — сперва MS DOS, потом всё остальное.
Большое спасибо за ссылки по теме!
Остальное, простите — вода, не имеющая к теме никакого отношения.
Когда идёт обсуждение тех или иных персональных качеств авторов статей, это угнетает не только авторов статей, но и читателей. А хотелось бы конкретных замечаний по теме статьи. Какие ошибки допустил автор, какие имеются пути для оптимизации, для масштабирования, какое прикладное решение в той или иной области можно найти, отталкиваясь конкретно от этой (или иной) статьи, примеры кода… То есть всё то, чем так и славен этот ресурс. И без навешивания ярлыков.
Я читаю хаб с 2006 года. Но темой «Машинное обучение» начал интересоваться только в 2019 году. Поэтому, в первую очередь (и это логично) читаю самые свежие статьи на эту тему, особенно те, где показываются рабочие примеры современного программирования. Теория хорошо. Но интерес многих читателей лежит в области современного практического применения. Вот именно это и есть то важное, что делает подобные статьи полезными, раз Вы об этом спросили. Если аргументировать обобщённо, все физические процессы — это процессы во времени. Не исключение и языки программирования, которые со временем развиваются и меняются. И порой на столько, что примеры из кучи уже имеющихся по той или иной тематике статей становятся или устаревшими или уже не рабочими.
По этой причине, считаю приток «свежей крови» — делом полезным во всех отношениях.
Простите. Ничего личного. Это замечание касается всех нас (и меня в том числе).
Простите, а при чём здесь когнитивное искажение автора?
Уверен, Амос Тверски и Даниэль Канеман с Вами бы не согласились, обратив внимание на принадлежность именно Вашего суждения к обозначенному Вами же понятию. Впрочем, Герд Гигеренцер сказал бы, что в этом нет никакого изъяна.
Я читаю хаб с 2006 года, и вижу, что статьи выходят с завидной регулярностью. И это хорошо, потому что всегда есть, что почитать.
Утверждение будет иметь ценность, только если Вы сами укажете ссылки на статьи,
Не сочтите, пожалуйста, за труд — поделитесь полезной информацией.
Считаю, что подобные статьи не несут в себе ничего плохого.
Спасибо.