Как стать автором
Обновить
4
0.1

Пользователь

Отправить сообщение

Вы почему-то так же как и автор статьи не цитируете следующий пункт.

3) информация, полученная в результате декомпилирования, может использоваться лишь для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, не может передаваться иным лицам, за исключением случаев, когда это необходимо для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, а также не может использоваться для разработки программы для ЭВМ, по своему виду существенно схожей с декомпилируемой программой для ЭВМ, или для осуществления другого действия, нарушающего исключительное право на программу для ЭВМ.

И вот тут простор для трактовки огромен. Как мы видим тут есть признаки и распространения информации, и признаки разработки аналогичного функционала. Вот в этих нюансах тут можно начать судиться годами со всеми кассациями в вышестоящие суды.

В России хоть и заявлено не прецедентное право, но все равно нужно искать правоприменительную практику по этой статье. Именно для случая чтения чужих форматов данных.

Это вы про волшебные комплексы, которые ставились в организациях?
Ставили весь из себя сертифицированный прибор оповещения для ГО и ЧС,
усилитель вида Made in USSR, и маленькая коробочка с mikrotik,
поднимающая VPN-канал в какой-то рядовой хостинг.

При таких параметрах персонажа воевать невозможно. Если удается убежать без save-load это уже удача. Попробуйте, just for fun.

Где-то в интернете была статья про такое прохождение, почувствуйте себя простым ребенком девочкой в пустоши, где все ваши характеристики 1, вы не можете пользоваться оружием, вы не можете унести много вещей и тд. Мир перед вами предстает с совершенно другой стороны.

Хардкор - это пройти персонажем со всеми характеристиками равными единице. Большая часть квестов недоступна, из-за малых базовых параметров персонаж практически не развивается.

Не помню подробностей, компаньоны идти не хотят, про города никто не рассказывает. Из забавного было, что когти смерти сами нашли персонажа и отвели его в убежище.

Однажды дошел до нефтяной вышки, в каком-то моменте там застрял, не хватало интеллекта для умного решения проблемы, и не хватало физических качеств для силового решения.

>Анклав примет с распростертыми объятиями?

Убивал все живое, но уже после посещения Наварро, и после выполнения всех "добрых квестов" После ухода кармы в минус сколько-то, на мировой карте сталкиваешься с охотниками за головами, третью встречу с которыми пережить почти невозможно. Мне не удавалось. Охотники все в силовой броне и пушками типа гаусс-винтовок и лазерных гатлингов.

https://fallout.fandom.com/ru/wiki/Охотники_за_головами_(случайная_встреча)

И самое неинтересное: после прохождения нефтяной вышки, тот факт, что в игре убиты все ключевые NPC не меняет состояние игры. Все положительные квесты выполнены, в мире мир и гармония (

>Интересно, меня одного удивляет следующий момент?

>Какой поинт запускать компилятор на каждой машине отдельно перед отправкой заказчику?

Кстати, ответы очень простые.

По надуманным и не очень причинам нужно обязать пользователей проводить регулярное обслуживание. Для этого придумывается простая схема запуска на целевых системах под видом служебного ПО некоей утилиты. Чтобы в явном виде не было видно предназначение этой утилиты, рядом с ней не должно быть никаких дат в конфигах и реестре.

В итоге предполагалось, что сервисные инженеры будут получать эту сервисную утилиту для каждого обслуживания, и после обслуживания копировать ее в целевую систему. В данной схеме выездным инженерам даже можно не говорить, зачем нужна эта утилита.

Сама эта уникальная утилита вообще может компилиться неким специальным ПО, которое запускается только в головном офисе, и высылается по почте/факсе конечному инженеру, да как угодно.

В какой-то момент эта схема сломалась, кому-то было лень этим всем заниматься, и кусок генерации утилиты переполз из компьютера сервисного инженера в целевую систему.

Вы можете мне не верить, но вот читайте дальше.

Есть куча приборов, в которые чтобы зайти в сервис нужен пароль. Далее пароль к прибору генерируется по определенному алгоритму из комбинации серийный номер прибора+текущая дата+ уровень доступа. Сервисный инженер звонит на базу и говорит, прибор модель такая-то, серийный номер-такой-то, дайте пароль. Ему присылают пароль. Пароль действует только сегодня. Если на приборе сбросилась дата, то инженер начинает страдать и идет проверять дату в биосе. А на биосе другой пароль, который он не знает. Пароль записан в сервисной документации на неизвестной странице.

Далее, на базе есть комплект сервисного ПО от вендора, в котором есть вкладочки модели прибора, каталоги запчастей, сервисные доки, генерация паролей.

Рано или поздно этот сервисный комплект ПО начинает утекать в поля через этих самых service field engineer-ов, которым осточертело звонить по каждому чиху на базу, которая всем составом ушла на обед.

Вендоры борятся с тем, чтобы этот уникальный софт не утекал в поля, и ставит защиту на комплект софта, всякие там аппаратные ключи и прочие зонды. Но тогда начинают утекать отдельные компоненты, которые смогли отодрать от вендорского софта.

Вот как-то так.

В автомобильной отрасли, кстати, похожая схема. Там тоже после некоторого пробега в машине может загораться лампочка check engine, сбросить которую можно либо через вендорский софт, либо сторонние утилиты, привет elm 327.

Я лично находил исходники медицинского ПО на одном из компьютеров одного из комплексов. Правда исходники были немножко от устаревшей версии и не совпадали с версией рабочего ПО. И не было компилятора, из-за чего я несколько лет задавался вопросом, а зачем они там лежали. Хотя возможно компилятор там и был, либо я его не нашел тогда, либо просто не помню этого.

Ну и отвечу на ваш соседний комментарий.

>Во-первых - речь идёт о компании, которая "обслуживает серьёзное оборудование", какие там фрилансеры?

О сколько нам открытий чудных..

Электроника это наука о контактах. Нет контакта, там где он должен быть, и есть контакт там, где его быть не должно. (с)

Разъемы окисляются, безсвинцовый припой отваливается, пыль коротит дорожки. Конденсаторы от старости теряют емкость, и если их пошевелить в неопределенный момент окончательно уходят параметры в эл цепях.

Для некоторых моделей старость наступает раньше 5 лет.

Огромные платы покрытые толстым слоем лака ушли в прошлое очень давно.

Процент не могу сказать, но можно привести (очередную неудачную) аналогию. Количество людей попадающих в ДТП. Некоторые за всю жизнь ни разу. А некоторым не везет и в них въезжают три раза за три года.

>Мой пойнт в том, что в среднем системник переживет хоть кругосветное путешествие, если его нормально зафиксировать.

Вот только почему-то те кто, реально будут использовать этот системник в кругосветном путешествии, возьмут еще как минимум два запасных.

Привожу пример, медицинский аппарат УЗИ, который как бы допускает штатную транспортировку, он же на колесиках, перевозят в другой кабинет или другой этаж. И он там уже не включается. Или включается, но через пару минут после самодиагностики говорит, у меня ошибка 0х00325, я выключаюсь, обратитесь в сервис.

А дальше как обычно, разборка, вытаскивание всех плат, протирка контактов, сборка. Все работает. Иногда.

А иногда бывают микротрещины в платах, когда аппарат может работать только после прогрева, если его неправильно пошевелить, то работать перестанет.

К слову, во многих УЗИ, стоят обычные такие стандартные компьютерные компоненты, процессоры, память, материнки, видеокарты, блоки питания компьютерной части.

Был случай, когда для рентеновского томографа выкатили стоимость запчасти в несколько миллионов рублей. Сами разобрали сломанный блок, внутре неонка, обычный компьютерный блок питания, который сгорел. И нескольких жестких дисков, обычных SCSI. Причем на тот момент модели этих дисков был уже очень устаревшими. А сам БП был из каких-то самых дешевых, в которых половины элементов нет на плате, уж не знаю кто сэкономил, поставщик или сам производитель.

Или например, классика жанра, тут приходили "ваши мальчики" на прошлой неделе (месяце, году) и после них все сломалось. А потом выясняется, что мальчики были вообще не наши, и никто не знает, кто же это был, и почему сервисный инженер приходил мимо заведующего отделением/старшей медсестры/главного инженера ЛПУ.

В идеальном мире, каждый аппарат должен быть на обслуживании сертифицированной фирмой, ибо здоровье людей. Условный неправильно работающий рентген, из-за которого врач не увидит чего-то фатального в пациенте, а тот потом умрет.

Но в реальной жизни, в которой уровень квалификации фирменных инженеров оставляет желать лучшего, и иногда они эти аппараты вообще первый раз видели, и никакой документации к нему не имели.

В итоге руководители ЛПУ сами принимают решение, которое в теории может привести к уголовной ответственности. Чинить аппарат своими несертифицированными силами и продолжать прием, либо не вести прием неизвестное количество времени, платить деньги за выезд инженера, который напишет потом формальную бумажку, что нужен ремонт (а то мы не знаем, что нужен ремонт) и в итоге вообще терять врача, которому не платят ЗП потому, что нет пациентов, или все деньги ушли на ремонт.

В целом можно долго дискутировать можно ли простой УЗИ чинить самим, где риск для пациента минимален. И какой класс оборудования не трогать вообще, какой-нибудь позитронно-эмиссионый облучатель. И опять-таки иметь в виду, что приезжающие инженеры иногда делают только хуже. Не хочу никого обидеть, но даже и такие случаи были, когда оборудование на официальном обслуживании, но чинили сами.

А уж что привело к такой ситуации, так это вообще отдельная тема...

Хотел написать несколько подробных историй из собственного опыта, но потом передумал, напишу без деталей.

Чинили УЗИ, МРТ, рентгены, были бэдблоки на жестких дисках, битые реестры Windows, ломали/подбирали пароли/автозагрузки на вход в ОС систем.

Из общих советов, на каждый аппарат после окончания гарантии должен быть образ диска. В какой момент делать образ диска, каждый решал сам. В идеале считается за месяц до окончания гарантии или сервисного договора.

Но на практике, обычно образ диска приходилось снимать уже через dd_rescue.

Один из примеров, который вспомнился. УЗИ-аппарат, на котором примерно через год заканчивалось место на системном диске. В каталог c:\temp клались картинки предпросмотра снимков и не удалялись. Основные же снимки лежали на большом диске D

Каждый год приезжал специалист от вендора и просто раскатывал образ системы с нуля, не разбираясь, что там и как.

Рентгеновская система, в котором управляющий компьютер периодически лаборантами выключался через общий рубильник питания установки. Как результат после включения или битая БД управляющего софта или нерабочая Windows. В инструкции для лаборантов не было пункта, что завершать работу нужно через кнопку в управляющем ПО.

Много всякого было...

А вот еще вспомнил.

Система на базе windows, в которой стоял срок действия пароля БД 365 дней. После этого софт переставал работать. (Наверное, все-таки продолжал работать, но часть функционала там отваливалась)

В фаргусовской версии старкрафта был баг: в компании Терранов на пятом уровне (Terran Mission 5: Revolution) отсутствовал мост. И миссию невозможно было пройти.

Как возник этот баг, загадка. Одна из версий, что так боролись с пиратством, но ведь...

Если пароли хранятся во внешнем hashicorp vault, то можно использовать такую схему.

в конфиге ansible.cfg прописываем адрес хранилища

[lookup_hashi_vault]
url = https://vault.example.com

ставим один раз плагин, если используется старая версия ansible

ansible-galaxy collection install community.hashi_vault
pip3 install hvac

создаем файлик secrets.yaml для хоста или группы

Переменной postgres_password пользуемся как обычной переменной в ansible

---
#install to use
#ansible-galaxy collection install community.hashi_vault
#pip3 install hvac

#set ANSIBLE_HASHI_VAULT_USERNAME env var or ansible_hashi_vault_username ansible var for username option
#set ANSIBLE_HASHI_VAULT_PASSWORD env var or ansible_hashi_vault_password ansible var for password option
#set ANSIBLE_HASHI_VAULT_TOKEN env var or ansible_hashi_vault_token ansible var for token option

postgres_password: "{{ lookup('community.hashi_vault.hashi_vault', 'secret=infrastructure/data/Endpoints_Secrets:db01_postgres') }}"

Перед запуском плейбука указываем реквизиты доступа или токен к vault, например.

export ANSIBLE_HASHI_VAULT_TOKEN=blablalba
ansible-playbook myplay.yml -DC

>https://ru.wikipedia.org/wiki/PACS

Так вот выхода с PACS-сервера, никакого не должно быть, только сеть.

>Есть ли альтернативные решения
В принципе их полно, любое видеоборудование, которое имеет несколько видеовходов, и которое может как-то отправлять его в сеть. Начиная от профессионального ВКС-оборудования, и заканчивая простой платой видеозахвата со стримингом через браузер в условный youtube

В медицине к тому же начинаются проблемы с совмещением вышеуказанного. Когда обычные рентгеновские, УЗИ, МРТ аппараты умеют отправлять снимки в DICOM-формате. А вот всякие эндоскопы и операционные камеры имеют просто некий видеовыход, а запись организовывается всякими кривыми программами, без какой-либо стандартизации и без всяких условных dicom.

Обычно, когда говорят аббревиатуру PACS то имеют в виду именно софт, который работает с протоколом DICOM. Но в маркетинговых статьях используют это слово просто для обозначения архива, который может быть примитивно сделан как общий каталог на сервере, куда все могут копировать файлы, и в которой вместо строгой структуры просто образуется файлопомойка.

А на картинке тут, конечно, накидано все подряд, HDMI-кабель идущий напрямую в PACS. Получается на сервере должен быть еще один видеозахват потока, но зачем...

А расскажите как записи попадают на PACS-сервер? Или как обычно врачи ручками ведут архивы видеофайлов, ручками переименовывют файлы из 2022-12-01-12-37-40.avi в 2022-12-01-12-37-40_Иванов_АА.avi и копируют в обычную сетевую папку, при этом периодически путая записи и имена больных.

И при этом периодически забывают вообще включать саму запись.

Или прибор для записи выключают не штатно кнопкой, а просто выдергивают из питания, так что при следующем включении 10 минут делается проверка файловой системы, а медсестра как ошпаренная звонит в ИТ-отдел с руганью, что ОПЯТЬ НИЧЕГО НЕ РАБОТАЕТ.

>Уровни производительности даже дешёвых SSD давно уже недостижимы для HDD

Вам просто не попадались такие дешевые SSD, которые ставят пользователям в компьютеры класса "4 ядра-4 гига". Так вот в таких дисках память состоит из двух типов чипов, быстрого квази-кэша и медленного. После постоянной записи определенного объема 4-8Гб, скорость записи падает до неприличных 40мб/с, что 2-3 раза хуже древних шпинделей. Причем в диспетчере производительности видно как скорость работы с диском прыгает то ноль, то 100мб/с.

Встречался с такими SSD на работе пару лет назад, какие-то модели на 120Гб.

Конечно можно сказать, что "обычный" пользователь такого не заметит, но мы обнаружили такое поведение практически сразу. Скачали какую-то свежую игрушку того периода обьемом примерно в 40Гб, и начали ее устанавливать.

В итоге WhatsApp на Iphone 5 перестал работать через две недели после "необновляемого обновления" от 31 августа.

Начнется rebuild массива, это значит, что с первого диска прочитаются ВСЕ данные, и запишутся на вставленный заново диск. mdraid понятия не имеет какие сектора с данными у вас изменились с момента отключения диска.

Если на рабочем диске, с которого будет чтение, найдутся bad-блоки, то raid не соберется.

В идеале вам нужен третий диск, который вставите вместо одного старого, на него и делайте rebuild.

В крайнем случае перед "операцией" можно сделать resync массива, который возможно найдет дефекты на дисках, если они есть.

Информация

В рейтинге
2 811-й
Зарегистрирован
Активность