Программируемые калькуляторы СССР
Развитие вычислительной техники в СССР имело свои особенности и разительно отличалось от ситуации на Западе. Если там компьютеры широко шагнули в массовый сегмент в конце 70-х годов, то в СССР практически до самого его распада компьютер был средством роскоши и ни о какой массовой доступности их говорить не приходилось.
На этом фоне достаточно ярким и самобытным явлением оказался феномен программируемых калькуляторов, которые оказались единственной доступной заменой компьютерной технике и использовались далеко не по прямому назначению.
Надо сказать, что программируемый калькулятор не был в те годы чем-то необычным, на Западе это был один из утилитарных инструментов призванный облегчить сложные инженерные и финансовые расчеты там, где применение компьютеров было экономически нецелесообразно.
В СССР, выпуская программируемые калькуляторы (ПМК) руководствовались ровно теми же соображениями, но советская реальность заставила посмотреть на использование ПМК совершенно с иной стороны.
В условиях отсутствия на рынке доступных моделей бытовых ПК и дефицита радиодеталей для их самостоятельной сборки по чертежам энтузиастов, что помимо деталей требовало еще определенного опыта, программируемые калькуляторы оказались единственными доступными для широких масс экземплярами вычислительной техники.
Ну как сказать доступными, средняя заплата инженера на производстве в середине 80-х составляла 120-180 руб., тогда как стоимость программируемых калькуляторов лежала в пределах 65-100 руб. Достаточно недешевое удовольствие, сравнимое с покупкой современного ПК среднего уровня.
А дальше произошло то, что и должно было произойти в условиях дефицита и способности советских граждан выкручиваться, опираясь на доступные средства. Программируемый калькулятор вместо прикладного инструмента стал выполнять роль бытового компьютера, взяв на себя не только вычислительные, но и развлекательные функции.
По сути, это один из советских феноменов, на Западе никому и в голову не могло прийти использовать ПМК в качестве развлекательного устройства, для этих целей там давно существовал рынок компьютеров и приставок.
А у нас приходилось приспосабливать под эти цели то, что имелось в наличии, хотя и отечественных разработчиков ПМК такое применение их продукции тоже должно было удивить.
Тем не менее именно ПМК открыли многим дорогу в мир вычислительной техники и позволили самостоятельно освоить навыками программирования и выработать алгоритмическое мышление. А достаточно жесткие ограничения по ресурсам заставили крайне серьёзно подойти к вопросам оптимизации.
✅ Читать далее: https://interface31.ru/post/istoriya-vychislitelnoy-tehniki-programmiruemye-kalkulyatory-sssr/
Развитие вычислительной техники в СССР имело свои особенности и разительно отличалось от ситуации на Западе. Если там компьютеры широко шагнули в массовый сегмент в конце 70-х годов, то в СССР практически до самого его распада компьютер был средством роскоши и ни о какой массовой доступности их говорить не приходилось.
На этом фоне достаточно ярким и самобытным явлением оказался феномен программируемых калькуляторов, которые оказались единственной доступной заменой компьютерной технике и использовались далеко не по прямому назначению.
Надо сказать, что программируемый калькулятор не был в те годы чем-то необычным, на Западе это был один из утилитарных инструментов призванный облегчить сложные инженерные и финансовые расчеты там, где применение компьютеров было экономически нецелесообразно.
В СССР, выпуская программируемые калькуляторы (ПМК) руководствовались ровно теми же соображениями, но советская реальность заставила посмотреть на использование ПМК совершенно с иной стороны.
В условиях отсутствия на рынке доступных моделей бытовых ПК и дефицита радиодеталей для их самостоятельной сборки по чертежам энтузиастов, что помимо деталей требовало еще определенного опыта, программируемые калькуляторы оказались единственными доступными для широких масс экземплярами вычислительной техники.
Ну как сказать доступными, средняя заплата инженера на производстве в середине 80-х составляла 120-180 руб., тогда как стоимость программируемых калькуляторов лежала в пределах 65-100 руб. Достаточно недешевое удовольствие, сравнимое с покупкой современного ПК среднего уровня.
А дальше произошло то, что и должно было произойти в условиях дефицита и способности советских граждан выкручиваться, опираясь на доступные средства. Программируемый калькулятор вместо прикладного инструмента стал выполнять роль бытового компьютера, взяв на себя не только вычислительные, но и развлекательные функции.
По сути, это один из советских феноменов, на Западе никому и в голову не могло прийти использовать ПМК в качестве развлекательного устройства, для этих целей там давно существовал рынок компьютеров и приставок.
А у нас приходилось приспосабливать под эти цели то, что имелось в наличии, хотя и отечественных разработчиков ПМК такое применение их продукции тоже должно было удивить.
Тем не менее именно ПМК открыли многим дорогу в мир вычислительной техники и позволили самостоятельно освоить навыками программирования и выработать алгоритмическое мышление. А достаточно жесткие ограничения по ресурсам заставили крайне серьёзно подойти к вопросам оптимизации.
✅ Читать далее: https://interface31.ru/post/istoriya-vychislitelnoy-tehniki-programmiruemye-kalkulyatory-sssr/
👍13❤2😢2👎1
Zilog Z80 — 48 лет в строю
Относительно недавно, 14 июня 2024 года, была принята последняя заявка на производство легендарного процессора Zilog Z80, что завершило его 48-летнюю историю.
48 лет по меркам IT-индустрии — огромный срок. Далеко не каждый продукт может похвастаться даже в несколько раз меньшим, но Z80 это удалось.
А начиналось всё в далёком 1974 году. 31 октября из компании Intel уволились инженер Федерико Фаджин и его коллега Ральф Унгерманн — разработчики Intel 4004 и 8080 (последний вышел незадолго до их ухода).
Сегодня это может показаться странным, но причиной увольнения стал низкий интерес руководства Intel к разработке процессоров и внутренние разногласия. В середине 70-х основной бизнес Intel составляло производство памяти, а процессоры воспринимались лишь как сопутствующее направление.
После ухода из Intel инженеры создали собственную компанию — Zilog (отсылка к «последнему слову» Z в Iнтегральной LOGике).
Возможно, история на этом бы и закончилась, если бы на новую компанию не обратила внимание венчурная фирма Exxon Enterprises — дочка нефтяного гиганта Exxon.
В результате сделки Zilog получила финансирование в размере 1,5 млн долларов (около 9 млн по нынешнему курсу) в обмен на контрольный пакет акций в 51%.
Вскоре к команде присоединился ещё один блестящий специалист — Масатоси Сима, стоявший у истоков разработки 4004, затем перешедший в Intel и в итоге поддержавший проект Zilog.
В то время Intel уже выпустила 8080, и в Zilog решили спроектировать его аналог, но гораздо более совершенный.
Интересно, что изначально Федерико Фаджин предлагал руководству Intel создать усовершенствованный 8080 на контрактной основе, но его предложение отвергли.
В итоге Zilog занялась проектированием самостоятельно. Команда состояла всего из 12 человек, включая только трёх инженеров: Фаджина, Унгерманна и Симу. Работать приходилось по 80 часов в неделю.
Стоит отметить, что никаких систем автоматизированного проектирования (САПР) тогда не существовало: весь дизайн микросхемы и топология слоёв чертились вручную. Затем чертежи неделями перепроверял Сима с обычной линейкой, следя за соблюдением норм техпроцесса.
Изначально Zilog позиционировала себя как бесфабричная компания: производством чипов должен был заниматься Mostek, откуда в марте 1976 года поступили первые кристаллы. В июле того же года состоялся официальный анонс Z80.
Новый процессор получился быстрее и архитектурно удачнее Intel 8080 и моментально завоевал популярность. При финансовой поддержке Exxon Enterprises компания запустила собственные производственные мощности, а её штат разросся до 2000 сотрудников.
Z80 нашёл широчайшее применение в игровой индустрии (чип использовали Sega и Nintendo), стал «сердцем» музыкальных синтезаторов, станков, персональных компьютеров и десятков видов встраиваемых систем.
На постсоветском же пространстве главная ассоциация с Z80 — это легендарный ZX Spectrum, культовый домашний компьютер начала 90-х. Для многих именно Spectrum открыл дорогу в IT-профессию.
Кроме того, Z80 активно применялся в радиолюбительской практике: тематические журналы публиковали сотни любительских схем на его базе.
Не обошлось и без клонирования, что лишний раз доказало успешность архитектуры. Чип производили как по лицензии, так и без неё (включая предприятия СССР, Восточной Европы и Азии). По общим оценкам, нелицензионные копии Z80 составляли до 50% от общего парка выпущенных чипов.
Повторить феноменальный триумф Z80 компания Zilog не смогла: в начале 80-х её покинули отцы-основатели, а вектор сместился в сторону специализированных микроконтроллеров — в качестве производителя которых компания благополучно существует и сегодня.
И хотя выпуск оригинального Z80 официально завершён, на смену ему предлагается линейка eZ80: полностью двоично совместимая со своим предком, но куда более производительная и современная.
Относительно недавно, 14 июня 2024 года, была принята последняя заявка на производство легендарного процессора Zilog Z80, что завершило его 48-летнюю историю.
48 лет по меркам IT-индустрии — огромный срок. Далеко не каждый продукт может похвастаться даже в несколько раз меньшим, но Z80 это удалось.
А начиналось всё в далёком 1974 году. 31 октября из компании Intel уволились инженер Федерико Фаджин и его коллега Ральф Унгерманн — разработчики Intel 4004 и 8080 (последний вышел незадолго до их ухода).
Сегодня это может показаться странным, но причиной увольнения стал низкий интерес руководства Intel к разработке процессоров и внутренние разногласия. В середине 70-х основной бизнес Intel составляло производство памяти, а процессоры воспринимались лишь как сопутствующее направление.
После ухода из Intel инженеры создали собственную компанию — Zilog (отсылка к «последнему слову» Z в Iнтегральной LOGике).
Возможно, история на этом бы и закончилась, если бы на новую компанию не обратила внимание венчурная фирма Exxon Enterprises — дочка нефтяного гиганта Exxon.
В результате сделки Zilog получила финансирование в размере 1,5 млн долларов (около 9 млн по нынешнему курсу) в обмен на контрольный пакет акций в 51%.
Вскоре к команде присоединился ещё один блестящий специалист — Масатоси Сима, стоявший у истоков разработки 4004, затем перешедший в Intel и в итоге поддержавший проект Zilog.
В то время Intel уже выпустила 8080, и в Zilog решили спроектировать его аналог, но гораздо более совершенный.
Интересно, что изначально Федерико Фаджин предлагал руководству Intel создать усовершенствованный 8080 на контрактной основе, но его предложение отвергли.
В итоге Zilog занялась проектированием самостоятельно. Команда состояла всего из 12 человек, включая только трёх инженеров: Фаджина, Унгерманна и Симу. Работать приходилось по 80 часов в неделю.
Стоит отметить, что никаких систем автоматизированного проектирования (САПР) тогда не существовало: весь дизайн микросхемы и топология слоёв чертились вручную. Затем чертежи неделями перепроверял Сима с обычной линейкой, следя за соблюдением норм техпроцесса.
Изначально Zilog позиционировала себя как бесфабричная компания: производством чипов должен был заниматься Mostek, откуда в марте 1976 года поступили первые кристаллы. В июле того же года состоялся официальный анонс Z80.
Новый процессор получился быстрее и архитектурно удачнее Intel 8080 и моментально завоевал популярность. При финансовой поддержке Exxon Enterprises компания запустила собственные производственные мощности, а её штат разросся до 2000 сотрудников.
Z80 нашёл широчайшее применение в игровой индустрии (чип использовали Sega и Nintendo), стал «сердцем» музыкальных синтезаторов, станков, персональных компьютеров и десятков видов встраиваемых систем.
На постсоветском же пространстве главная ассоциация с Z80 — это легендарный ZX Spectrum, культовый домашний компьютер начала 90-х. Для многих именно Spectrum открыл дорогу в IT-профессию.
Кроме того, Z80 активно применялся в радиолюбительской практике: тематические журналы публиковали сотни любительских схем на его базе.
Не обошлось и без клонирования, что лишний раз доказало успешность архитектуры. Чип производили как по лицензии, так и без неё (включая предприятия СССР, Восточной Европы и Азии). По общим оценкам, нелицензионные копии Z80 составляли до 50% от общего парка выпущенных чипов.
Повторить феноменальный триумф Z80 компания Zilog не смогла: в начале 80-х её покинули отцы-основатели, а вектор сместился в сторону специализированных микроконтроллеров — в качестве производителя которых компания благополучно существует и сегодня.
И хотя выпуск оригинального Z80 официально завершён, на смену ему предлагается линейка eZ80: полностью двоично совместимая со своим предком, но куда более производительная и современная.
👍22❤6
Перенаправление и права в Linux
Если нам нужно что-либо записать или дописать в файл, то мы обычно делаем так:
Или
В первом случае мы перепишем содержимое файла, во втором – допишем в конец. Кстати, это важный момент, запомните и не путайте!
Но как быть, если нужно выполнить запись в файл, который не принадлежит текущему пользователю?
Напрашивается привычное:
Но неожиданно получим «Отказано в доступе», почему? Давайте разбираться, кто за что отвечает. При входе пользователя в систему в ней сразу запускается командная оболочка, тоже самое происходит, если мы запускаем эмулятор терминала.
Оболочка запускается от имени текущего пользователя, и именно она позволяет нам выполнять команды, она же занимается перенаправлениями и конвейером.
Команда sudo позволяет нам выполнить команду с правами суперпользователя и этой командой будет echo, которая выведет указанный текст в стандартный поток вывода. На этом ее работа закончилась. Перенаправлением потока будет заниматься оболочка, которая запущена от обычного пользователя.
Чтобы все-таки выполнить запись в файл мы можем сделать так:
В этом случае мы запустим с повышенными правами еще один экземпляр оболочки, который выполнит указанную команду и завершит свою работу. А так как оболочка запущена с повышенными правами, то и проблем с перенаправлением у нас не возникнет.
Аналогичная ситуация возникает и с конвейером, так как этим занимается оболочка, то все команды в цепочке будут выполняться от имени того пользователя, кто запустил оболочку, если не указано иного.
Например, для решения нашей задачи можно использовать:
Если мы напишем:
То с повышенными правами будет выполнено только echo, а tee получит отказ в доступе, так как запустивший ее пользователь не имеет прав доступа.
Правильно:
Для выполнения первой команды нам повышенные права не нужны, а вот tee нужно дать доступ к файлу и поэтому мы запускаем ее через sudo.
Поэтому, работая с оболочкой, всегда помните, кто выполняет те или иные действия и какие права при этом имеет, что поможет избежать подобных ошибок и недоразумений.
Если нам нужно что-либо записать или дописать в файл, то мы обычно делаем так:
echo “Hello” > file.txt
Или
echo “Hello” >> file.txt
В первом случае мы перепишем содержимое файла, во втором – допишем в конец. Кстати, это важный момент, запомните и не путайте!
Но как быть, если нужно выполнить запись в файл, который не принадлежит текущему пользователю?
Напрашивается привычное:
sudo echo “Hello” >> file.txt
Но неожиданно получим «Отказано в доступе», почему? Давайте разбираться, кто за что отвечает. При входе пользователя в систему в ней сразу запускается командная оболочка, тоже самое происходит, если мы запускаем эмулятор терминала.
Оболочка запускается от имени текущего пользователя, и именно она позволяет нам выполнять команды, она же занимается перенаправлениями и конвейером.
Команда sudo позволяет нам выполнить команду с правами суперпользователя и этой командой будет echo, которая выведет указанный текст в стандартный поток вывода. На этом ее работа закончилась. Перенаправлением потока будет заниматься оболочка, которая запущена от обычного пользователя.
Чтобы все-таки выполнить запись в файл мы можем сделать так:
sudo bash -c ‘echo “Hello” >> file.txt’
В этом случае мы запустим с повышенными правами еще один экземпляр оболочки, который выполнит указанную команду и завершит свою работу. А так как оболочка запущена с повышенными правами, то и проблем с перенаправлением у нас не возникнет.
Аналогичная ситуация возникает и с конвейером, так как этим занимается оболочка, то все команды в цепочке будут выполняться от имени того пользователя, кто запустил оболочку, если не указано иного.
Например, для решения нашей задачи можно использовать:
echo “Hello” | tee -a file.txt
Если мы напишем:
sudo echo “Hello” | tee -a file.txt
То с повышенными правами будет выполнено только echo, а tee получит отказ в доступе, так как запустивший ее пользователь не имеет прав доступа.
Правильно:
echo “Hello” | sudo tee -a file.txt
Для выполнения первой команды нам повышенные права не нужны, а вот tee нужно дать доступ к файлу и поэтому мы запускаем ее через sudo.
Поэтому, работая с оболочкой, всегда помните, кто выполняет те или иные действия и какие права при этом имеет, что поможет избежать подобных ошибок и недоразумений.
🔥17❤3👌2👍1
Советские ПК
Компьютеризация в Советском союзе – тема сложная и неоднозначная. И сейчас, когда многое уже забылось и выросло поколение никогда Союза в глаза не видевшая, появляются мнения, что советская компьютерная индустрия — это то, что мы потеряли.
На самом деле все было совсем по-другому и советские компьютеры вполне закономерно пришли туда, куда пришли и причин тому было множество. Чтобы не быть голословными мы будем опираться на публикации тех лет, в частности журнала Радио.
Необходимость компьютеризации на уровне широких масс в СССР поняли уже в первой половине 80-х. К этому времени на Западе уже был развитый рынок недорогих 8-битных ПК и делал свои первые шаги IBM PC.
Рынок в СССР в первую очередь состоял из образовательных заведений и спроса частных лиц, который был прежде всего от ИТР и энтузиастов. Чтобы понимать потребности выполним небольшие вычисления.
На 90 год в СССР было 135,9 тыс. школ и 4556 СУЗов. Даже если брать по одному компьютерному классу на 25 машин, то получаем емкость рынка в 3,5 млн. ПК.
Количество рабочей силы в СССР было 152,3 млн человек. Даже если мы поделим его на шесть (средний размер семьи + бабушки-дедушки) и прикинем, что ПК был нужен только 10% оставшихся, то получим еще 2,5 млн ПК. Таким образом общий рынок можно оценивать в 6 млн. ПК.
Что у нас было на этом рынке? Начнем с БК-0010, это был 16-разрядный ПК по системе команд полностью совместимый с PDP-11 и частично совместимый с ним по архитектуре и многие считают его лучшим из бытовых ПК советской эпохи.
Производство ПК началось в 1985 году и всего было выпущено 162 тыс. ПК. Это при емкости рынка около 6 млн. Просто брызги. А если учесть, что большая часть выпушенных ПК уходила в учебные заведения до розницы, доходили единицы, не способные решить вопрос дефицита.
При этом цена компьютера составляла 600 руб. (позже 650 руб.), что равнялось трем месячным зарплатам инженера.
А что писала советская пресса, Радио №6 87, интервью с директором завода производителя «Тернистый путь БК в наш дом».
Но это еще не все, палки в колеса и так буксующей отрасли начали вставлять родные бюрократы:
Ну да ладно, не прекратили и худо-бедно продолжили выпускать в целом неплохую машину, но в очень и очень малых количествах. Но для ПК нужно ПО, а где его взять?
При этом отрасль в очередной раз сталкивалась с бюрократическими препонами:
В общем писать софт вроде бы и способны, но как его выпустить на рынок? В результате для БК было написано около 800 программ, преимущественно энтузиастами любителями.
И только в последние годы Союза кооперативами было выполнено, говоря современным языком, портирование приблизительно около 4000 программ со Spectrum, преимущественно игр.
Фактически БК, имея неплохой технический задел так и не смог выполнить своей главной задачи. Компьютеров было выпущено очень мало, еще хуже обстояла ситуация с ПО к ним.
Компьютеризация в Советском союзе – тема сложная и неоднозначная. И сейчас, когда многое уже забылось и выросло поколение никогда Союза в глаза не видевшая, появляются мнения, что советская компьютерная индустрия — это то, что мы потеряли.
На самом деле все было совсем по-другому и советские компьютеры вполне закономерно пришли туда, куда пришли и причин тому было множество. Чтобы не быть голословными мы будем опираться на публикации тех лет, в частности журнала Радио.
Необходимость компьютеризации на уровне широких масс в СССР поняли уже в первой половине 80-х. К этому времени на Западе уже был развитый рынок недорогих 8-битных ПК и делал свои первые шаги IBM PC.
Рынок в СССР в первую очередь состоял из образовательных заведений и спроса частных лиц, который был прежде всего от ИТР и энтузиастов. Чтобы понимать потребности выполним небольшие вычисления.
На 90 год в СССР было 135,9 тыс. школ и 4556 СУЗов. Даже если брать по одному компьютерному классу на 25 машин, то получаем емкость рынка в 3,5 млн. ПК.
Количество рабочей силы в СССР было 152,3 млн человек. Даже если мы поделим его на шесть (средний размер семьи + бабушки-дедушки) и прикинем, что ПК был нужен только 10% оставшихся, то получим еще 2,5 млн ПК. Таким образом общий рынок можно оценивать в 6 млн. ПК.
Что у нас было на этом рынке? Начнем с БК-0010, это был 16-разрядный ПК по системе команд полностью совместимый с PDP-11 и частично совместимый с ним по архитектуре и многие считают его лучшим из бытовых ПК советской эпохи.
Производство ПК началось в 1985 году и всего было выпущено 162 тыс. ПК. Это при емкости рынка около 6 млн. Просто брызги. А если учесть, что большая часть выпушенных ПК уходила в учебные заведения до розницы, доходили единицы, не способные решить вопрос дефицита.
При этом цена компьютера составляла 600 руб. (позже 650 руб.), что равнялось трем месячным зарплатам инженера.
А что писала советская пресса, Радио №6 87, интервью с директором завода производителя «Тернистый путь БК в наш дом».
- О трудностях с приобретением персональных бы¬товых компьютеров в нынешнем году нам известно. А станет ли легче купить их в ближайшем будущем!
- Не думаю, хотя и планируется значительно увеличить выпуск БК-0010. Главная наша задача — обеспечить машинами школы, ПТУ, техникумы.
Но это еще не все, палки в колеса и так буксующей отрасли начали вставлять родные бюрократы:
Но может так случиться, что БК вообще перестанет выпускаться. С 1 июля 1987 г. вводится ГОСТ… Так что если с 1 июля от час будут требовать выполнения ГОСТа, то производство микро-ЭВМ нам придется прекратить.
Ну да ладно, не прекратили и худо-бедно продолжили выпускать в целом неплохую машину, но в очень и очень малых количествах. Но для ПК нужно ПО, а где его взять?
- Больной вопрос для многих пользователей БК — ПО. Далеко не каждый может написать программы сам, а купить их пока негде.
- Проблема выпуска ПО из технической пере¬росла в социальную. Ведь для ликвидации компьютерной неграмотности надо дать возможность пользоваться вычислительной техникой всем желающим. Пока же использовать бытовые компьютеры могут лишь те, кто спосо¬бен самостоятельно создать программное обеспечение.
При этом отрасль в очередной раз сталкивалась с бюрократическими препонами:
На программы, например, до сих пор нет авторского права. До сих пор не известно, кто же должен определять воспитательный и идеологический уровень программ (особенно это важно для … игр). Нет и прейскуранта, позволяющего определить цены на программы.
В общем писать софт вроде бы и способны, но как его выпустить на рынок? В результате для БК было написано около 800 программ, преимущественно энтузиастами любителями.
И только в последние годы Союза кооперативами было выполнено, говоря современным языком, портирование приблизительно около 4000 программ со Spectrum, преимущественно игр.
Фактически БК, имея неплохой технический задел так и не смог выполнить своей главной задачи. Компьютеров было выпущено очень мало, еще хуже обстояла ситуация с ПО к ним.
👍12🔥4❤2👎1
SMB over QUIC
Каждый админ знает, что использование SMB через интернет – это еще та головная боль. Во-первых, для обеспечения безопасности соединения требуется организовать защищенный канал связи – VPN или туннель.
Во-вторых, основной проблемой на нестабильных каналах связи будет крайне низкая производительность протокола. В SMB используется транспортный протокол TCP, и потеря даже одного пакета полностью блокирует поток.
Это доставляло серьезные проблемы, особенно при передаче крупных файлов и приводило к созданию обходных путей разной степени костыльности.
Новый протокол призван устранить все эти недостатки и сделать доступ к SMB ресурсам через интернет столь же простым, как локальный доступ. Впервые SMB over QUIC был представлен в Windows Server 2022 Azure Edition, а начиная с Windows Server 2025 стал доступен всем желающим.
Также его поддержка реализована в Samba начиная с версии 4.23 и теперь вы можете реализовать эффективное файловое хранилище полностью на свободных технологиях.
К ключевым особенностям реализации относится шифрование TLS 1.3, являющееся неотъемлемой частью протокола QUIC, что делает не нужным VPN и прочие методы защиты канала.
Также QUIC внешне мало отличим от обычного HTTPS и использует стандартный 443 порт, что делает решение универсальным и устойчивым к различным ограничениям (скажем, гостиничный интернет, где кроме HTTP(S) все закрыто).
Внутри шифрованного туннеля используется SMB 3.1.1 со всеми его возможностями по управлению доступом и защите целостности, включая подписывание SMB-пакетов, только теперь все это, включая аутентификацию надежно защищено TLS 1.3.
Вторая важная особенность – транспорт, QUIC использует UDP и эффективно управляет мультиплексированием соединений. Теперь потерянный пакет не блокирует поток, что способствует серьезному повышению производительности, а мультиплексирование позволяет максимально эффективно использовать канал.
Для тех, кому нужно больше безопасности SMB over QUIC поддерживает Client Access Control – проверку подлинности клиента на основе сертификатов. Теперь не только клиент может убедиться в подлинности сервера используя его сертификат, но и наоборот.
Причем для этого не требуется обязательно поднимать собственную инфраструктуру открытых ключей, можно использовать даже самоподписанные клиентские сертификаты, явно указав серверу их отпечатки.
Отзывы реальных пользователей подтверждают, что новый протокол работает отлично, обеспечивая простую и прозрачную работу с файловыми ресурсами для удаленных клиентов.
Но при всех его достоинствах SMB over QUIC – это дело будущего, возможно не столь отдаленного, но тем не менее. Из ОС семейства Windows кроме Windows Server 2025 его поддерживает только Windows 11, в Windows 10 ввиду окончания срока поддержки данная возможность добавляться не будет.
Samba 4.23 выпущена 12 сентября 2025 года и не присутствует ни в одном LTS – дистрибутиве. Ближайший кандидат на ее появление – это Ubuntu 26.04 и Debian 14. Возможно, поддержка появится и раньше, в промежуточных дистрибутивах или backports, но особой погоды это не сделает.
Поэтому массовое внедрение SMB over QUIC следует ожидать не ранее, чем через несколько лет, как минимум после массовой замены Windows 10 более современными редакциями ОС и появлению пакетов Samba c поддержкой этой технологии в основных LTS-дистрибутивах Linux.
Каждый админ знает, что использование SMB через интернет – это еще та головная боль. Во-первых, для обеспечения безопасности соединения требуется организовать защищенный канал связи – VPN или туннель.
Во-вторых, основной проблемой на нестабильных каналах связи будет крайне низкая производительность протокола. В SMB используется транспортный протокол TCP, и потеря даже одного пакета полностью блокирует поток.
Это доставляло серьезные проблемы, особенно при передаче крупных файлов и приводило к созданию обходных путей разной степени костыльности.
Новый протокол призван устранить все эти недостатки и сделать доступ к SMB ресурсам через интернет столь же простым, как локальный доступ. Впервые SMB over QUIC был представлен в Windows Server 2022 Azure Edition, а начиная с Windows Server 2025 стал доступен всем желающим.
Также его поддержка реализована в Samba начиная с версии 4.23 и теперь вы можете реализовать эффективное файловое хранилище полностью на свободных технологиях.
К ключевым особенностям реализации относится шифрование TLS 1.3, являющееся неотъемлемой частью протокола QUIC, что делает не нужным VPN и прочие методы защиты канала.
Также QUIC внешне мало отличим от обычного HTTPS и использует стандартный 443 порт, что делает решение универсальным и устойчивым к различным ограничениям (скажем, гостиничный интернет, где кроме HTTP(S) все закрыто).
Внутри шифрованного туннеля используется SMB 3.1.1 со всеми его возможностями по управлению доступом и защите целостности, включая подписывание SMB-пакетов, только теперь все это, включая аутентификацию надежно защищено TLS 1.3.
Вторая важная особенность – транспорт, QUIC использует UDP и эффективно управляет мультиплексированием соединений. Теперь потерянный пакет не блокирует поток, что способствует серьезному повышению производительности, а мультиплексирование позволяет максимально эффективно использовать канал.
Для тех, кому нужно больше безопасности SMB over QUIC поддерживает Client Access Control – проверку подлинности клиента на основе сертификатов. Теперь не только клиент может убедиться в подлинности сервера используя его сертификат, но и наоборот.
Причем для этого не требуется обязательно поднимать собственную инфраструктуру открытых ключей, можно использовать даже самоподписанные клиентские сертификаты, явно указав серверу их отпечатки.
Отзывы реальных пользователей подтверждают, что новый протокол работает отлично, обеспечивая простую и прозрачную работу с файловыми ресурсами для удаленных клиентов.
Но при всех его достоинствах SMB over QUIC – это дело будущего, возможно не столь отдаленного, но тем не менее. Из ОС семейства Windows кроме Windows Server 2025 его поддерживает только Windows 11, в Windows 10 ввиду окончания срока поддержки данная возможность добавляться не будет.
Samba 4.23 выпущена 12 сентября 2025 года и не присутствует ни в одном LTS – дистрибутиве. Ближайший кандидат на ее появление – это Ubuntu 26.04 и Debian 14. Возможно, поддержка появится и раньше, в промежуточных дистрибутивах или backports, но особой погоды это не сделает.
Поэтому массовое внедрение SMB over QUIC следует ожидать не ранее, чем через несколько лет, как минимум после массовой замены Windows 10 более современными редакциями ОС и появлению пакетов Samba c поддержкой этой технологии в основных LTS-дистрибутивах Linux.
2🤔15❤5👍4🔥1
Утилизация CPU в Linux
Правильная интерпретация показателей утилизации процессора в Linux важна для каждого системного администратора. Данная информация помогает быстро понять характер нагрузки и может указать на потенциально узкое место.
Чтобы получить данную информацию мы будем использовать команду
В данном случае нас интересует строка, выделенная желтым маркером на скриншоте. Она показывает, как используется процессорное время вашей системы в процентном соотношении.
🔹 us (User CPU time) – время потраченное на пространство пользователя. Это основная рабочая нагрузка и именно сюда попадает процессорное время, которое наши программы или службы тратят на полезную работу. Высокие значения говорят о том, что мы интенсивно нагружаем систему и не являются какой-либо аномалией.
🔹 sy (System CPU time) – время потраченное на пространство ядра. В пространстве ядра работают драйвера оборудования, системные вызовы и т.п. Нормальны умеренные значения этого показателя, высокие значения могут говорить о проблемах с оборудованием, высокую нагрузку на системы ввода-вывода или являться признаком DDoS-атаки на систему.
🔹 ni (Nice CPU time) - время потраченное на процессы пользовательского пространства запущенные с пониженным приоритетом. Для данного показателя справедливо все то, что было сказано для us. Данный показатель нужен для оценки того, как система перераспределяет ресурсы и анализируется в совокупности с us.
🔹 id (Idle) — время простоя (бездействия).
🔹 wa (I/O wait) — время на ожидание операций ввода-вывода, высокие значения показывают на то, что система много времени тратит на ожидание дисковых операций. Может служить показателем выхода из строя накопителей, но также высокие значения могут быть нормальными при интенсивной дисковой нагрузке. Продолжительные высокие значения являются признаком того, что система ввода-вывода не справляется с текущей нагрузкой.
🔹 hi (Hardware IRQ) — время, потраченное на обработку аппаратных прерываний. В обычных сценариях значение этого показателя должно быть близким к нулю, высокие значения указывают на возможную неисправность оборудования либо на крайне высокую нагрузку на устройства ввода-вывода.
🔹 si (Software IRQ) — аналогично, время, потраченное на обработку программных прерываний, умеренные значения этого показателя являются нормой, высокие значения в первую очередь показывают на высокую сетевую нагрузку, неисправность сетевого оборудования или DDoS-атаку.
🔹 st (Steal Time) - время «украденное» гипервизором у виртуальной машины, имеет значение внутри виртуальной машины и показывает какое количество процессорного времени она недополучила от гипервизора. Указывает на наличие конкуренции за процессорное время между виртуальными машинами или виртуальными машинами и процессами гипервизора.
Правильная интерпретация показателей утилизации процессора в Linux важна для каждого системного администратора. Данная информация помогает быстро понять характер нагрузки и может указать на потенциально узкое место.
Чтобы получить данную информацию мы будем использовать команду
top, которая есть из коробки практически в каждом дистрибутиве. В данном случае нас интересует строка, выделенная желтым маркером на скриншоте. Она показывает, как используется процессорное время вашей системы в процентном соотношении.
🔹 us (User CPU time) – время потраченное на пространство пользователя. Это основная рабочая нагрузка и именно сюда попадает процессорное время, которое наши программы или службы тратят на полезную работу. Высокие значения говорят о том, что мы интенсивно нагружаем систему и не являются какой-либо аномалией.
🔹 sy (System CPU time) – время потраченное на пространство ядра. В пространстве ядра работают драйвера оборудования, системные вызовы и т.п. Нормальны умеренные значения этого показателя, высокие значения могут говорить о проблемах с оборудованием, высокую нагрузку на системы ввода-вывода или являться признаком DDoS-атаки на систему.
🔹 ni (Nice CPU time) - время потраченное на процессы пользовательского пространства запущенные с пониженным приоритетом. Для данного показателя справедливо все то, что было сказано для us. Данный показатель нужен для оценки того, как система перераспределяет ресурсы и анализируется в совокупности с us.
🔹 id (Idle) — время простоя (бездействия).
🔹 wa (I/O wait) — время на ожидание операций ввода-вывода, высокие значения показывают на то, что система много времени тратит на ожидание дисковых операций. Может служить показателем выхода из строя накопителей, но также высокие значения могут быть нормальными при интенсивной дисковой нагрузке. Продолжительные высокие значения являются признаком того, что система ввода-вывода не справляется с текущей нагрузкой.
🔹 hi (Hardware IRQ) — время, потраченное на обработку аппаратных прерываний. В обычных сценариях значение этого показателя должно быть близким к нулю, высокие значения указывают на возможную неисправность оборудования либо на крайне высокую нагрузку на устройства ввода-вывода.
🔹 si (Software IRQ) — аналогично, время, потраченное на обработку программных прерываний, умеренные значения этого показателя являются нормой, высокие значения в первую очередь показывают на высокую сетевую нагрузку, неисправность сетевого оборудования или DDoS-атаку.
🔹 st (Steal Time) - время «украденное» гипервизором у виртуальной машины, имеет значение внутри виртуальной машины и показывает какое количество процессорного времени она недополучила от гипервизора. Указывает на наличие конкуренции за процессорное время между виртуальными машинами или виртуальными машинами и процессами гипервизора.
1👍26❤1
Уязвимости в MikroTik RouterOS, допускающие удалённый доступ по SSH без аутентификации
В операционной системе RouterOS, применяемой в маршрутизаторах MikroTik, выявлено 6 уязвимостей. Комбинация двух из них позволяет удалённо получить полный контроль над устройством с правами администратора при условии его доступности по SSH.
Зафиксированы факты эксплуатации отмеченных уязвимостей. Патчи от MikroTik доступны с 3 сентября (RouterOS 7.25 beta 3, 7.24.2, 7.23.4, 6.49.21) и, вероятно, атакующие смогли определить суть уязвимостей по этим патчам.
Уязвимостям CVE-2026-67276 и CVE-2026-86060 присвоен критический уровень опасности (9.2 из 10). Первая проблема вызвана некорректной проверкой открытых ключей RSA, применяемых при аутентификации через SSH.
Зная имя пользователя и параметры открытого ключа пользователя, атакующий мог сформировать фиктивный ключ и подключиться по нему через SSH без доступа к закрытому ключу. Вторая проблема связана с отсутствием фильтрации недопустимых символов в начале имени пользователя при обработке входа через SSH.
Успешную эксплуатацию уязвимостей можно отследить по записям в логе RouterOS:
✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=66224
В операционной системе RouterOS, применяемой в маршрутизаторах MikroTik, выявлено 6 уязвимостей. Комбинация двух из них позволяет удалённо получить полный контроль над устройством с правами администратора при условии его доступности по SSH.
Зафиксированы факты эксплуатации отмеченных уязвимостей. Патчи от MikroTik доступны с 3 сентября (RouterOS 7.25 beta 3, 7.24.2, 7.23.4, 6.49.21) и, вероятно, атакующие смогли определить суть уязвимостей по этим патчам.
Уязвимостям CVE-2026-67276 и CVE-2026-86060 присвоен критический уровень опасности (9.2 из 10). Первая проблема вызвана некорректной проверкой открытых ключей RSA, применяемых при аутентификации через SSH.
Зная имя пользователя и параметры открытого ключа пользователя, атакующий мог сформировать фиктивный ключ и подключиться по нему через SSH без доступа к закрытому ключу. Вторая проблема связана с отсутствием фильтрации недопустимых символов в начале имени пользователя при обработке входа через SSH.
Успешную эксплуатацию уязвимостей можно отследить по записям в логе RouterOS:
login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>
✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=66224
👍11🤷♂5❤3
Почему мы ничего не пишем про "защиту" от DDoS и прочую подобную ерунду на Mikrotik?
Время от времени нам задают подобный вопрос, на что мы отвечаем, что даже не собираемся. Почему? Да потому что это не работает.
Причем это касается не только MikroTik, но и остального железа пользовательского и начального уровня, включая x86 сервера.
Все это можно читать сугубо от нечего делать в одном небольшом спокойном кабинете, уединившись там по неотложным делам.
А помочь это может сугубо в одном случае - если вас решил атаковать кружок юных хакеров начальных классов при сельском клубе.
В остальных случаях вы только зря потратите время, а, возможно, и деньги.
Сегодня одного заказчика серьезно заДДоСили, положили канал в 100 Мбит/с и RB4011 на нем. Половину дня его представитель еще что-то пытался делать сам, хотя мы сразу сказали — это безнадежная задача.
К обеду убедился. Провайдер развел руками и сказал, что ничего предложить не может, не располагает возможностями.
В итоге обратились в Ростелеком, чей канал на территории есть, но не используется.
Там выслушали, спросили про оконечное оборудование, посмеялись и предложили два варианта.
🔹 Защита от них, примерно 30 тыс. руб. месяц.
🔹 Eltex ESR-20 FSTEC - цена вопроса примерно 500 тыс. руб. Срок поставки от месяца. И поставят они его у себя.
А из всех советов полезным оказался только один, от того же безопасника из РТ: поставить для входящего трафика на внешнем интерфейсе простую очередь, начиная от 1-2 Мбит/с и при необходимости увеличивая.
Атаку это не отобьет, но хотя бы позволит как-то работать роутеру, а вам анализировать ситуацию.
Но если брать ситуацию по факту, то вы или платите за защиту провайдеру, или сидите и рассматриваете пакеты в Wireshark, когда ваши сервисы лежат. Альтернативой можете купить провайдеру за свой счет железку.
Почему? А потому что трафик к вам уже пришел, и он полностью забил весь канал, пытаться как-то его обработать – это выстрел себе в голову. Мы сделаем только хуже и увеличим нагрузку на оконечное оборудование.
Время от времени нам задают подобный вопрос, на что мы отвечаем, что даже не собираемся. Почему? Да потому что это не работает.
Причем это касается не только MikroTik, но и остального железа пользовательского и начального уровня, включая x86 сервера.
Все это можно читать сугубо от нечего делать в одном небольшом спокойном кабинете, уединившись там по неотложным делам.
А помочь это может сугубо в одном случае - если вас решил атаковать кружок юных хакеров начальных классов при сельском клубе.
В остальных случаях вы только зря потратите время, а, возможно, и деньги.
Сегодня одного заказчика серьезно заДДоСили, положили канал в 100 Мбит/с и RB4011 на нем. Половину дня его представитель еще что-то пытался делать сам, хотя мы сразу сказали — это безнадежная задача.
К обеду убедился. Провайдер развел руками и сказал, что ничего предложить не может, не располагает возможностями.
В итоге обратились в Ростелеком, чей канал на территории есть, но не используется.
Там выслушали, спросили про оконечное оборудование, посмеялись и предложили два варианта.
🔹 Защита от них, примерно 30 тыс. руб. месяц.
🔹 Eltex ESR-20 FSTEC - цена вопроса примерно 500 тыс. руб. Срок поставки от месяца. И поставят они его у себя.
А из всех советов полезным оказался только один, от того же безопасника из РТ: поставить для входящего трафика на внешнем интерфейсе простую очередь, начиная от 1-2 Мбит/с и при необходимости увеличивая.
Атаку это не отобьет, но хотя бы позволит как-то работать роутеру, а вам анализировать ситуацию.
Но если брать ситуацию по факту, то вы или платите за защиту провайдеру, или сидите и рассматриваете пакеты в Wireshark, когда ваши сервисы лежат. Альтернативой можете купить провайдеру за свой счет железку.
Почему? А потому что трафик к вам уже пришел, и он полностью забил весь канал, пытаться как-то его обработать – это выстрел себе в голову. Мы сделаем только хуже и увеличим нагрузку на оконечное оборудование.
1👍28👀9🔥5❤4
Управление серверами 1С:Предприятие
Начинающие (да и не только) администраторы системы 1С:Предприяите часто спрашивают, а есть ли кроссплатформенный аналог MMC-оснастке Администрирование серверов 1С Предприятия.
Обычно это происходит в свете перехода на Linux, но и не только. У стандартной MMC-консоли есть существенный недостаток – она использует COM-технологию и привязана к версии платформы.
Если у вас есть несколько серверов на разных версиях платформы, то вам постоянно придется перерегистрировать COM-компоненту на разные версии или использовать разные рабочие станции.
Альтернативой этому может служить веб-приложение от сторонних разработчиков – ПУСК, которое использует современный механизм управления серверами 1С:Предприятие – сервер администрирования RAS.
Как установить и настроить ПУСК мы рассказывали в этой статье:
🔹 Устанавливаем и настраиваем ПУСК - Панель Управления Сервисами и Компонентами для 1С:Предприятие
Но это тоже не всегда удобно, потому что требует специального развертывания и поддержки отдельного серверного приложения. Иногда надо что-то быстро и просто.
И такой инструмент есть, причем, что называется, из коробки. Но по странному стечению обстоятельств знают о нем очень немногие.
Речь идет о встроенной в платформу обработке Управление серверами. Для того, чтобы ее использовать вам потребуется любая информационная база 1С:Предприятие, даже полностью чистая, без конфигурации, в т.ч. файловая.
В ней переходим в Функции для технического специалиста – Стандартные – Управление серверами.
Работает она, как и ПУСК, через RAS, т.е. не зависит от установленной версии платформы. По функциям и возможностям она полностью повторяет стандартную MMC-консоль.
Начинающие (да и не только) администраторы системы 1С:Предприяите часто спрашивают, а есть ли кроссплатформенный аналог MMC-оснастке Администрирование серверов 1С Предприятия.
Обычно это происходит в свете перехода на Linux, но и не только. У стандартной MMC-консоли есть существенный недостаток – она использует COM-технологию и привязана к версии платформы.
Если у вас есть несколько серверов на разных версиях платформы, то вам постоянно придется перерегистрировать COM-компоненту на разные версии или использовать разные рабочие станции.
Альтернативой этому может служить веб-приложение от сторонних разработчиков – ПУСК, которое использует современный механизм управления серверами 1С:Предприятие – сервер администрирования RAS.
Как установить и настроить ПУСК мы рассказывали в этой статье:
🔹 Устанавливаем и настраиваем ПУСК - Панель Управления Сервисами и Компонентами для 1С:Предприятие
Но это тоже не всегда удобно, потому что требует специального развертывания и поддержки отдельного серверного приложения. Иногда надо что-то быстро и просто.
И такой инструмент есть, причем, что называется, из коробки. Но по странному стечению обстоятельств знают о нем очень немногие.
Речь идет о встроенной в платформу обработке Управление серверами. Для того, чтобы ее использовать вам потребуется любая информационная база 1С:Предприятие, даже полностью чистая, без конфигурации, в т.ч. файловая.
В ней переходим в Функции для технического специалиста – Стандартные – Управление серверами.
Работает она, как и ПУСК, через RAS, т.е. не зависит от установленной версии платформы. По функциям и возможностям она полностью повторяет стандартную MMC-консоль.
👍25👌2❤1
Игровой порт
Сегодня уже далеко не каждый коллега готов сказать для чего предназначен желтый порт DB15 на материнской плате или звуковой карте. Но это не удивительно, потому как данный порт вышел из употребления примерно 20 лет назад.
История игрового порта началась одновременно с историей IBM PC, который предполагал в том числе и игровые возможности. А так как отдельной отрасли компьютерных игр к тому времени еще не сложилось, то большинство игр разрабатывались для приставок и только потом портировались на разнообразные компьютеры.
В качестве элементов управления играми использовались джойстики или геймпады, классической схемой к тем временам был контроллер на две оси (джойстик или крестовина) и две кнопки. Однако никакого общего стандарта не было, и каждый производитель разрабатывал и внедрял собственные, несовместимые между собой контроллеры.
В IBM хорошо проанализировали существующий рынок и выпустили свое решение, которое оказалось ближе всего к контроллерам Atari, но было более простым и, следственно, более дешевым. Что было важно для массового продукта.
Игровые контроллеры IBM требовали наличия специальной платы расширения Game Control Adapter стоимостью 55 USD (сегодня это около 185 USD), не самое дешевое удовольствие, но вполне доступное широким покупательским массам.
С этой платой к нам и пришел разъем игрового порта в достаточно компактном по тем временам формате DB15. Порт поддерживал аналоговые сигналы для четырех осей и четырех кнопок, что позволяло подключить два стандартных контроллера. А также он был стандартизирован и обеспечивал совместимость оборудования и контроллеров разных производителей.
Но игровой контроллер продолжал оставаться достаточно редким оборудованием, так как требовал отдельного слота расширения, которых было не очень много, а родных возможностей материнской платы, наоборот, мало.
Поэтому хотите подключить модем? Нужна плата расширения. Принтер? Еще одна плата. И т.д. и т.п.
К середине 80-х ситуация стала выправляться, когда текущие возможности вычислительной техники стали позволять размещать на одной плате расширения сразу несколько контроллеров, подобные платы у нас назывались «мультикарты».
Но все изменилось в 1989 году с выходом ставшей потом культовой Sound Blaster от Creative Labs. Инженеры компании здраво рассудили, что звуковая карта берется чаще всего для игр и поэтому наличие на ней игрового контроллера будет дополнительным конкурентным преимуществом продукта.
По факту они произвели маленькую революцию, так как идею подхватили производители других звуковых карт и очень скоро игровой порт стал неотъемлемой частью именно звуковой карты.
Кроме того, в Creative взяли свободные пины разъема и вывели туда последовательный интерфейс для работы с MIDI. MIDI оборудование и раньше можно было подключить к ПК, но это требовало отдельного дорогого контроллера, теперь стало достаточно дешевого переходника.
Выход Windows 95 добавил нативную поддержку игрового порта со стороны операционной системы, также он был поддержан и со стороны DirectX, что облегчило его интеграцию с программным обеспечением и играми.
Именно на 90-е пришелся расцвет игрового порта, который появился практически в каждой звуковой карте, а выбор контроллеров к нему был на любой вкус, цвет и кошелек.
По мере интеграции контроллеров на материнскую плату туда переехал и игровой порт, надолго прописавшись рядом с аудиоразъемами. Но уже в начале нулевых прозвенели первые звоночки.
Все шире и шире стал применяться универсальный порт USB, а также стало все больше производиться периферии к нему, включая игровые контроллеры. Очень скоро USB начали вытеснять с задних панелей ПК остальные разъемы, включая игровой.
Окончательный закат игрового порта произошел с выпуском Windows Vista, в котором была прекращена его поддержка.
Сегодня единственный способ подключить к современному ПК контроллеры для игрового порта – это использование специальных USB-переходников.
Сегодня уже далеко не каждый коллега готов сказать для чего предназначен желтый порт DB15 на материнской плате или звуковой карте. Но это не удивительно, потому как данный порт вышел из употребления примерно 20 лет назад.
История игрового порта началась одновременно с историей IBM PC, который предполагал в том числе и игровые возможности. А так как отдельной отрасли компьютерных игр к тому времени еще не сложилось, то большинство игр разрабатывались для приставок и только потом портировались на разнообразные компьютеры.
В качестве элементов управления играми использовались джойстики или геймпады, классической схемой к тем временам был контроллер на две оси (джойстик или крестовина) и две кнопки. Однако никакого общего стандарта не было, и каждый производитель разрабатывал и внедрял собственные, несовместимые между собой контроллеры.
В IBM хорошо проанализировали существующий рынок и выпустили свое решение, которое оказалось ближе всего к контроллерам Atari, но было более простым и, следственно, более дешевым. Что было важно для массового продукта.
Игровые контроллеры IBM требовали наличия специальной платы расширения Game Control Adapter стоимостью 55 USD (сегодня это около 185 USD), не самое дешевое удовольствие, но вполне доступное широким покупательским массам.
С этой платой к нам и пришел разъем игрового порта в достаточно компактном по тем временам формате DB15. Порт поддерживал аналоговые сигналы для четырех осей и четырех кнопок, что позволяло подключить два стандартных контроллера. А также он был стандартизирован и обеспечивал совместимость оборудования и контроллеров разных производителей.
Но игровой контроллер продолжал оставаться достаточно редким оборудованием, так как требовал отдельного слота расширения, которых было не очень много, а родных возможностей материнской платы, наоборот, мало.
Поэтому хотите подключить модем? Нужна плата расширения. Принтер? Еще одна плата. И т.д. и т.п.
К середине 80-х ситуация стала выправляться, когда текущие возможности вычислительной техники стали позволять размещать на одной плате расширения сразу несколько контроллеров, подобные платы у нас назывались «мультикарты».
Но все изменилось в 1989 году с выходом ставшей потом культовой Sound Blaster от Creative Labs. Инженеры компании здраво рассудили, что звуковая карта берется чаще всего для игр и поэтому наличие на ней игрового контроллера будет дополнительным конкурентным преимуществом продукта.
По факту они произвели маленькую революцию, так как идею подхватили производители других звуковых карт и очень скоро игровой порт стал неотъемлемой частью именно звуковой карты.
Кроме того, в Creative взяли свободные пины разъема и вывели туда последовательный интерфейс для работы с MIDI. MIDI оборудование и раньше можно было подключить к ПК, но это требовало отдельного дорогого контроллера, теперь стало достаточно дешевого переходника.
Выход Windows 95 добавил нативную поддержку игрового порта со стороны операционной системы, также он был поддержан и со стороны DirectX, что облегчило его интеграцию с программным обеспечением и играми.
Именно на 90-е пришелся расцвет игрового порта, который появился практически в каждой звуковой карте, а выбор контроллеров к нему был на любой вкус, цвет и кошелек.
По мере интеграции контроллеров на материнскую плату туда переехал и игровой порт, надолго прописавшись рядом с аудиоразъемами. Но уже в начале нулевых прозвенели первые звоночки.
Все шире и шире стал применяться универсальный порт USB, а также стало все больше производиться периферии к нему, включая игровые контроллеры. Очень скоро USB начали вытеснять с задних панелей ПК остальные разъемы, включая игровой.
Окончательный закат игрового порта произошел с выпуском Windows Vista, в котором была прекращена его поддержка.
Сегодня единственный способ подключить к современному ПК контроллеры для игрового порта – это использование специальных USB-переходников.
👍8❤4🔥1🤮1
Custom Resolution Utility (CRU)
Небольшая, но полезная утилита по установке произвольных значений разрешения монитора.
Для чего это надо? Рассказываем. Сегодня на одной точке поменяли ПК, как водится, разъема VGA в новом ПК нет, а в старом мониторе нет HDMI. Ну да это не проблема, купили переходник.
С этого момента и начались приключения, монитор имеет рабочее разрешение 1366x768, а переходник выдает стандартные 1920×1080, 1280×720 и 1024x768. Понятно, что картинка на экране выглядит растянутой и смазанной.
Что делать? Искать переходник с поддержкой 1366x768? Так это занятие бесполезное, с учетом того, что производятся они в китайских подвалах и нигде подобных данных не указывают.
В общем, без особой надежды стали искать информацию по подобным переходникам и нашему разрешению и наткнулись на описанную утилиту.
Скачали, попробовали и у нас все получилось. Утилита считала данные монитора (даже через переходник) и на их основе добавила данные в реестр, после чего в настройках видеоадаптера стало возможно выбрать родное разрешение.
Ситуация довольно редкая, но время от времени случается. Поэтому берите на заметку.
✅ https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU
Небольшая, но полезная утилита по установке произвольных значений разрешения монитора.
Для чего это надо? Рассказываем. Сегодня на одной точке поменяли ПК, как водится, разъема VGA в новом ПК нет, а в старом мониторе нет HDMI. Ну да это не проблема, купили переходник.
С этого момента и начались приключения, монитор имеет рабочее разрешение 1366x768, а переходник выдает стандартные 1920×1080, 1280×720 и 1024x768. Понятно, что картинка на экране выглядит растянутой и смазанной.
Что делать? Искать переходник с поддержкой 1366x768? Так это занятие бесполезное, с учетом того, что производятся они в китайских подвалах и нигде подобных данных не указывают.
В общем, без особой надежды стали искать информацию по подобным переходникам и нашему разрешению и наткнулись на описанную утилиту.
Скачали, попробовали и у нас все получилось. Утилита считала данные монитора (даже через переходник) и на их основе добавила данные в реестр, после чего в настройках видеоадаптера стало возможно выбрать родное разрешение.
Ситуация довольно редкая, но время от времени случается. Поэтому берите на заметку.
✅ https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU
👍51🔥2❤1
Осваиваем эффективную работу в Midnight Commander
Midnight Commander - популярный двухпанельный файловый менеджер, широко распространенный в UNIX-like операционных системах, он должен быть знаком каждому, кто хоть раз работал в консоли.
Но, как показывает практика, не все администраторы в полной мере используют все возможности данного приложения, ограничиваясь только базовыми, что может приводить к определенным неудобствам.
Поэтому сегодня ы расскажем о возможностях Midnight Commander и приемах, способных сделать работу в нем удобной и эффективной.
✅ Читать далее: https://interface31.ru/post/osvaivaem-effektivnuyu-rabotu-v-midnight-commander/
Midnight Commander - популярный двухпанельный файловый менеджер, широко распространенный в UNIX-like операционных системах, он должен быть знаком каждому, кто хоть раз работал в консоли.
Но, как показывает практика, не все администраторы в полной мере используют все возможности данного приложения, ограничиваясь только базовыми, что может приводить к определенным неудобствам.
Поэтому сегодня ы расскажем о возможностях Midnight Commander и приемах, способных сделать работу в нем удобной и эффективной.
✅ Читать далее: https://interface31.ru/post/osvaivaem-effektivnuyu-rabotu-v-midnight-commander/
👍15❤4
Трассировка TCP
В комментариях уже несколько раз спрашивали, как сделать трассировку по порту. Это нужно если у вас есть проблемы с доступностью сетевой службы, но при этом сетевая связность с конечным узлом присутствует и этот узел принимает соединения на указанных портах.
В этом случае проблема может быть где-то посередине, например, на пограничном роутере или провайдер фильтрует исходящие соединение по определенным портам (что очень часто бывает с почтой).
Поэтому именно такая трассировка поможет найти проблемный узел. В Linux все очень просто, достаточно поставить утилиту tcptraceroute, которая есть в репозиториях.
Потом все просто:
Чтобы узнать все поддерживаемые ключи запустите утилиту без параметров.
Для Windows все немного сложнее, потребуются сторонние утилиты, например, Tcproute.exe, которая требует установки Pcap.Net.
После чего разместите утилиту в удобном месте и используйте:
Для получение большей информации используйте запуск с ключом -?
В комментариях уже несколько раз спрашивали, как сделать трассировку по порту. Это нужно если у вас есть проблемы с доступностью сетевой службы, но при этом сетевая связность с конечным узлом присутствует и этот узел принимает соединения на указанных портах.
В этом случае проблема может быть где-то посередине, например, на пограничном роутере или провайдер фильтрует исходящие соединение по определенным портам (что очень часто бывает с почтой).
Поэтому именно такая трассировка поможет найти проблемный узел. В Linux все очень просто, достаточно поставить утилиту tcptraceroute, которая есть в репозиториях.
Потом все просто:
tcptraceroute ya.ru 443
Чтобы узнать все поддерживаемые ключи запустите утилиту без параметров.
Для Windows все немного сложнее, потребуются сторонние утилиты, например, Tcproute.exe, которая требует установки Pcap.Net.
После чего разместите утилиту в удобном месте и используйте:
tcproute ya.ru 443
Для получение большей информации используйте запуск с ключом -?
👍19❤1
Что такое Azure Stack HCI и почему это вам не нужно
По мере того, как тикают часы и последней версии бесплатного Hyper-V Server 2019 остаются считанные годы до окончания поддержки (в 2029 году) возникает все больше и больше вопросов – как же жить дальше?
И вот уже не один человек спросил меня про Azure Stack HCI, во многом благодаря ряду статей на Хабре, на наш взгляд – вредных, поэтому ссылки не приводим, кому надо – сами найдут.
Если подходить к вопросу поверхностно, то кажется, что перед нами аналог бесплатного Hyper-V Server – активация не нужна, в основе тот же Windows Core, а для кого это большая проблема, то там и GUI прикрутить можно.
Но отсутствие требования активации еще не означает правомерного использования, лицензирование данной системы подразумевает подписную модель (примерно $10 за ядро в месяц) и обязательное требование хотя бы один раз в 30 дней связаться с Azure Arc.
Последнее легко лечится патчами, но, по сути, это ничем не отличается от «активации» через «левые KMS» или MAS. Тем более, что Azure Stack HCI нет долгосрочных версии, новые сборки ОС выходят каждый год.
Фактически с этим подходом вы будете сидеть на пороховой бочке, сделаю ли «энтузиасты» патч или устанут, вам легче не станет, инфраструктура ваша, вам с ней жить и вам нести за нее ответственность.
И вообще, Azure Stack HCI, это последнее, что стоит тащить в локальную инфраструктуру, но кроме случаев, когда вы активно пользуетесь Azure и вам требуется развернуть ряд возможностей локально.
А как быть остальным? А тут есть только два сценария:
🔸 У вас основная нагрузка – это системы Windows Server, современная система лицензирования завязана на ядра хостовой машины и не важно, что там, Hyper-V или Proxmox.
Если ваш экземпляр Windows Server просто обслуживает виртуальные машины с ролью Hyper-V, то все свои лицензии он передает виртуалкам, т.е. обходится вам бесплатно.
Поэтому если у вас основная рабочая нагрузка Windows – то лицензирование хоста виртуализации погоды не делает, так, на сдачу. Если же у вас там Linux, то зачем вам Hyper-V.
🔸 Если же основная нагрузка – Linux, то смело переходим на Proxmox, родная среда в родной среде, плюс доступны LXC-контейнеры.
Поэтому в целом никакой беды от прекращения поддержки бесплатного Hyper-V нет, в Windows-мире вам даже не потребуются дополнительные лицензии, а в Linux вам проще перейти на родные средства виртуализации и контейнеризации.
По мере того, как тикают часы и последней версии бесплатного Hyper-V Server 2019 остаются считанные годы до окончания поддержки (в 2029 году) возникает все больше и больше вопросов – как же жить дальше?
И вот уже не один человек спросил меня про Azure Stack HCI, во многом благодаря ряду статей на Хабре, на наш взгляд – вредных, поэтому ссылки не приводим, кому надо – сами найдут.
Если подходить к вопросу поверхностно, то кажется, что перед нами аналог бесплатного Hyper-V Server – активация не нужна, в основе тот же Windows Core, а для кого это большая проблема, то там и GUI прикрутить можно.
Но отсутствие требования активации еще не означает правомерного использования, лицензирование данной системы подразумевает подписную модель (примерно $10 за ядро в месяц) и обязательное требование хотя бы один раз в 30 дней связаться с Azure Arc.
Последнее легко лечится патчами, но, по сути, это ничем не отличается от «активации» через «левые KMS» или MAS. Тем более, что Azure Stack HCI нет долгосрочных версии, новые сборки ОС выходят каждый год.
Фактически с этим подходом вы будете сидеть на пороховой бочке, сделаю ли «энтузиасты» патч или устанут, вам легче не станет, инфраструктура ваша, вам с ней жить и вам нести за нее ответственность.
И вообще, Azure Stack HCI, это последнее, что стоит тащить в локальную инфраструктуру, но кроме случаев, когда вы активно пользуетесь Azure и вам требуется развернуть ряд возможностей локально.
А как быть остальным? А тут есть только два сценария:
🔸 У вас основная нагрузка – это системы Windows Server, современная система лицензирования завязана на ядра хостовой машины и не важно, что там, Hyper-V или Proxmox.
Если ваш экземпляр Windows Server просто обслуживает виртуальные машины с ролью Hyper-V, то все свои лицензии он передает виртуалкам, т.е. обходится вам бесплатно.
Поэтому если у вас основная рабочая нагрузка Windows – то лицензирование хоста виртуализации погоды не делает, так, на сдачу. Если же у вас там Linux, то зачем вам Hyper-V.
🔸 Если же основная нагрузка – Linux, то смело переходим на Proxmox, родная среда в родной среде, плюс доступны LXC-контейнеры.
Поэтому в целом никакой беды от прекращения поддержки бесплатного Hyper-V нет, в Windows-мире вам даже не потребуются дополнительные лицензии, а в Linux вам проще перейти на родные средства виртуализации и контейнеризации.
👍12❤2
Ошибка: Не удалось записать RSA сертификат. Попробуйте еще раз
Достаточно редкая ошибка ЕГАИС и не все знают куда бежать и что делать. Прежде всего смотрим в лог, файл utm/transport/l/transport_info.log
И находим там строки:
Вместо трех может стоять другое число, по числу ошибочных сертификатов.
Проблема достаточно редкая и найти ее описание не просто, хотя оно есть в базе знания Рутокен: https://dev.rutoken.ru/display/KB/RU1009
Суть проблемы в том, что при формировании нового RSA-ключа старый не удаляется и возникает задвоение ключей, о чем и написано в логе. В результате на ключе оказывается три объекта: ГОСТ и 2 RSA ключа. Попытка ручного удаления RSA-ключей также завершается ошибкой.
Если вы будете продолжать попытки формирования ключа с помощью УТМ ЕГАИС дублей станет больше (и число в сообщении лога увеличится).
Решение простое – скачать и применить утилиту, указанную на странице базы знаний Рутокен.
Достаточно редкая ошибка ЕГАИС и не все знают куда бежать и что делать. Прежде всего смотрим в лог, файл utm/transport/l/transport_info.log
И находим там строки:
java.security.KeyStoreException: invalid KeyStore state: found 3 private keys sharing
Вместо трех может стоять другое число, по числу ошибочных сертификатов.
Проблема достаточно редкая и найти ее описание не просто, хотя оно есть в базе знания Рутокен: https://dev.rutoken.ru/display/KB/RU1009
Суть проблемы в том, что при формировании нового RSA-ключа старый не удаляется и возникает задвоение ключей, о чем и написано в логе. В результате на ключе оказывается три объекта: ГОСТ и 2 RSA ключа. Попытка ручного удаления RSA-ключей также завершается ошибкой.
Если вы будете продолжать попытки формирования ключа с помощью УТМ ЕГАИС дублей станет больше (и число в сообщении лога увеличится).
Решение простое – скачать и применить утилиту, указанную на странице базы знаний Рутокен.
👍14
САП "Клавдий" - архивация электронной почты для организаций любого масштаба!
• сбор писем с почтовых серверов, архивов и из SMTP-трафика
• поиск по письмам и вложениям
• дедупликация и сжатие
• доступ к архивной почте через веб или любой почтовый клиент
• кластеризация и хранилище с настраиваемой длительностью хранения
• бесплатная версия до 50 почтовых ящиков
САП "Клавдий" - решение для тех, у кого:
• почтовый сервер, который задыхается от старых писем
• возникает необходимость найти и восстановить старое письмо
• есть кладбище PST-файлов и почтовых ящиков уволенных сотрудников
• есть обязательство сохранять всю переписку за несколько лет
• планируется переезд на другой почтовый сервер
• ограниченный бюджет на решение этих проблем
Подключайтесь к онлайн-демо.
Среда, 16 сентября, в 12:00 по Москве.
Ссылка для регистрации: Регистрация на вебинар
Также подключайтесь к нашему тг-каналу: Ссылка на канал
#реклама
О рекламодателе
• сбор писем с почтовых серверов, архивов и из SMTP-трафика
• поиск по письмам и вложениям
• дедупликация и сжатие
• доступ к архивной почте через веб или любой почтовый клиент
• кластеризация и хранилище с настраиваемой длительностью хранения
• бесплатная версия до 50 почтовых ящиков
САП "Клавдий" - решение для тех, у кого:
• почтовый сервер, который задыхается от старых писем
• возникает необходимость найти и восстановить старое письмо
• есть кладбище PST-файлов и почтовых ящиков уволенных сотрудников
• есть обязательство сохранять всю переписку за несколько лет
• планируется переезд на другой почтовый сервер
• ограниченный бюджет на решение этих проблем
Подключайтесь к онлайн-демо.
Среда, 16 сентября, в 12:00 по Москве.
Ссылка для регистрации: Регистрация на вебинар
Также подключайтесь к нашему тг-каналу: Ссылка на канал
#реклама
О рекламодателе
👀3👍1