Скорее всего сойдут практически любые параметры. Начиная с определённого времени (гуглите LBA) диски перестали обращать внимание на параметры сектор/цилиндр/головка или что ещё там, и просто преобразовывало эти данные в линейный номер сектора.
Понятно, что IDE-конвертор CF-карт делает то же самое.
Т.е. достаточно подобрать такие параметры, чтобы размер диска был не больше размера карты.
Вообще-то есть такие компании. Делают ПО для прямого управления АЭС, железнодорожной автоматикой, авионикой, энергетикой, медицинским оборудованием. Но - ценник конский, работают медленно, свистелки и перделки не добавляют, к интернету подключать запрещают...
Вообще-то тот софт, который реально управляет системами, от которых зависит жизнь и здоровье людей - он как раз лицензированный, доказанный и чрезвычайно дорогой. И обновляется редко и с большим скрипом. А антивирус на такое в принципе не ставят - идиотов нет.
Всё, что упало сегодня - это сервисы, от которых ничего существенного не зависит.
Обратите внимание: обломались системы резервирования авиабилетов, но вот диспетчера связь с самолётами не потеряли, и самолёты экстренно не садились.
Ага. Молодые и горячие студенты годик поработают, и убегут куда-нибудь. А 50-летний разработчик под Турбо паскаль будет работать в этой конторе ещё лет 20.
Это всё-таки промышленность, а не вебка - тут не переписывают ПО каждые полгода из-за того, что модной стала другая технология.
Единственный 100% надёжный вариант защиты данных - это текущий лог изменений (например, в SQL-базу) перенаправлять через односторонний интерфейс (диод данных) в хранилище, которое никаких других связей с любыми сетями не имеет.
Самое забавное: вот такой промпт - это ведь не чёткое программирование, что можно - и что нельзя. По определению, нейросетка всегда может наплевать/игнорировать вот так заложенные ограничения. Т.е всё это - благие пожелания.
Ну например, выложив в Perforce бинарный файл (который не получиться смержить) вы сможете поставить ему тип "binary+l". Так как Perforce - система централизованная, после этого данный файл сможет редактировать только один человек за один раз. Соответственно, необходимости "сливать" конкурентные изменения - не будет.
Разумеется, скорее всего для git можно сколхозить что-то подобное. Или использовать отдельную систему "управления документацией" - но это, как надеюсь вы понимаете, набор из резиновых костылей.
Ещё раз - в git можно сделать всё. Но предназначен git для специфической модели разработки и специфических целей - как только вы пытаетесь его приспособить за пределы его исходной концепции - получается хреново.
Кстати, с этой точки зрения точно то же самое и в Perforce. Разрабатывать классический опенсоурсный продукт в Perforce - с получением патчей от неопределённого круга лиц, с разработчиками работающими независимо и самостоятельно - ну, больше всего похоже на мазохизм.
Perforce, например. Разумеется, изменения в бинарных файлах произвольного типа просмотреть/объединить сама система не может (точнее, может для ограниченного количества форматов, в основном картинки) - но если есть внешние средства - можно использовать их.
При этом, например, хранение проектной документации в том же Word/Autocad/Visio - запросто. Одна возможность хранить историю изменений бинарных файлов (и сами файлы) - это уже очень много.
Концепция гит: куча ветвей, сделанная программистами неизвестного качества, которые интегрирует в мастер-ветвь гуру продукта. В принципе, неплохо ложиться на процесс разработки в компании, которые постоянно нанимают джунов, немного их эксплуатируют и заменяют на новых. Плохо ложиться на организацию, которая нанимает опытных программистов, в случае, когда над отдельным подпродуктом работает 1-2 программиста максимум.
Распределённая разработка в гит не имеет особого смысла для корпоративного применения (скорее, опасна и неудобна для корпораций), но очень востребована в опенсоурсе.
Концепция гит: один репозитарий - один продукт. Ветвление репозитария целиком. Отлично подходит для опенсоурсной разработки, но в корпоративной среде возникают проблемы с зависимостями: продукты не являются независимыми. Т.е. крупные организации очень редко разрабатывают самодостаточный продукт, использующий только "чужие" библиотеки. Обычно он состоит их кучи библиотек и кучи экзешников, каждый из которых - отдельные подпродукты с собственным циклом выпуска релизов. В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях.
Гит может работать с бинарными файлами. Но - всегда криво и с косяками, с дополнительными нашлёпками.
В общем и целом, гит отлично подходит для компаний, чьи разработки не требуют системы управления конфигурации (сonfiguration management).
Т.е. если версия вашего продукта "живёт" полгода, релизы выпускаются часто-часто, долгосрочной поддержки нет, цена ошибки низкая - гит для этого отлично подходит.
Отлично гит подходит для веб-разработки, когда конечный продукт вы же и поддерживаете (т.е. предоставляете доступ к своему хостингу, но не даёте клиенту автономный хостинг).
Если ваш цикл технической поддержки продукта - десятилетия, если продукты сложные и взаимно-зависимые, если вам в любой момент может понадобиться точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик, и вы не можете заставить заказчика обновиться на текущую версию продукта, потому что обновление стоит очень больших ресурсов, если вместе с продуктом вы разрабатываете документацию в разных форматах (бинарных форматах редакторов и CADов) - гит не для вас.
С моей точки зрения, идеальной системой управления версиями была бы централизованная система с кластером серверов, похожая на Perforce или SVN, но с возможностью выделять/маркировать отдельные папки/подпродукты/каталоги так, чтобы слияние изменений можно было выполнять только на папку целиком.
По крайней мере, я пойму, что операционная система проверяет/ремонтирует файловые системы. Что она не зависла наглухо, что прогресс идёт, и можно оценить, что это займет ещё час/день/неделю.
Пользователи (и я тоже) в таких ситуациях довольно часто просто не дожидаются завершения процесса - и, например, перезагружают машину питанием. Что, естественно, проблему усугубляет.
Американские астронавты уже были на Луне, и бегали, и прыгали - и никакие "роборуки" им были не нужны.
Более того, эти крутые парни даже не горбились под тяжестью системы жизнеобеспечения на спине, полностью игнорируя необходимость поддерживать проекцию центра тяжести внутри периметра ступней.
Так что бессмысленную задачу решает, не нужно этого на Луне.
Внутри такого скафандра всё равно давление минимум 1/3 земного.
С чистым кислородом. Потому что иначе человеку будет кислорода не хватать. А для дыхания ему надо расширять и сужать грудную клетку/диафрагму - т.е. менять внутренний объем скафандра. Расширить получится, сжать - нет, мускулов не хватит.
Облегающий костюм, создающий внешнее давление - он по факту позволяет не лопнуть в вакууме, но дышать - не позволяет. Получается что-то типа дайвинга без акваланга - можешь выжить в вакууме 2-3 минуты, пока кислород в крови не кончится.
Разве что включить в этот костюм "искусственное легкое" подключенное к кровеносной системе напрямую. А сами лёгкие чем-то заполнить - вероятно, жидкостью (потому что если будут постоянно сдуты и слипнуться - потом запустить их не получится).
Нет, есть ещё вариант: костюм делает постоянное искусственное дыхание (т.е. расслабляется и сжимается). Но человек так долго не выдержит.
---------------
То что имитация - это да, похоже штаны к ботинкам вообще никак не приделаны.
Для начала надо надрючить всех ваших разработчиков на то, чтобы ВСЁ ПО писалось исключительно в стиле "защитного программирования".
Вам нужен аналог assert(), не исключающийся из релизного продукта, и абсолютно во всех случаях, когда есть какое-то условие или возвращаемое значение - оно должно быть проверено или нормальным кодом проверки ошибки, или добавлением неисключаемого из кода assert(). Который должен фиксировать строку/функцию/условие/файл/версию файла.
Таким образом, ваше ПО никогда не должно распространять ошибку дальше.
Использование исключений из кода удалить полностью - точнее, оставить только в модульных тестах.
Ваша программа/модуль должна немедленно паниковать (с сохранением стека и дампа) как только обнаружена ошибка, для которой не предусмотрены штатные условия устранения/восстановления.
Да, и ещё: заставьте своих разработчиков использовать достаточно старый стандарт языка. Ещё лучше: ограничьте используемое множество языка.
Разработчиков, которые тащатся от новейших фич языка - выпихивайте туда, где от них будет минимум вреда - желательно к конкурентам.
В общем-то логично. Анонимности в сети и так нет, это иллюзия.
А так люди хотя бы будут это осознавать.
Скорее всего сойдут практически любые параметры. Начиная с определённого времени (гуглите LBA) диски перестали обращать внимание на параметры сектор/цилиндр/головка или что ещё там, и просто преобразовывало эти данные в линейный номер сектора.
Понятно, что IDE-конвертор CF-карт делает то же самое.
Т.е. достаточно подобрать такие параметры, чтобы размер диска был не больше размера карты.
Вообще-то есть такие компании. Делают ПО для прямого управления АЭС, железнодорожной автоматикой, авионикой, энергетикой, медицинским оборудованием. Но - ценник конский, работают медленно, свистелки и перделки не добавляют, к интернету подключать запрещают...
У них наверняка правильно, юридически корректно сформулированы условия лицензии на ПО. Полностью снимающее всю ответственность с фирмы-разработчика.
Вообще-то тот софт, который реально управляет системами, от которых зависит жизнь и здоровье людей - он как раз лицензированный, доказанный и чрезвычайно дорогой. И обновляется редко и с большим скрипом. А антивирус на такое в принципе не ставят - идиотов нет.
Всё, что упало сегодня - это сервисы, от которых ничего существенного не зависит.
Обратите внимание: обломались системы резервирования авиабилетов, но вот диспетчера связь с самолётами не потеряли, и самолёты экстренно не садились.
Нет такой страны, что не ведёт войну. Или ведёт, или является шестёркой того, кто воюет.
А если найдёшь такую - вот на неё и нападёт, например, США с гуманитарными бомбардировками. Или какой ИГИЛ подтащат, для удобства.
Для информации: в США собираются восстановить призыв, т.к. добровольцев чегой-то маловато.
Ага. Молодые и горячие студенты годик поработают, и убегут куда-нибудь. А 50-летний разработчик под Турбо паскаль будет работать в этой конторе ещё лет 20.
Это всё-таки промышленность, а не вебка - тут не переписывают ПО каждые полгода из-за того, что модной стала другая технология.
Единственный 100% надёжный вариант защиты данных - это текущий лог изменений (например, в SQL-базу) перенаправлять через односторонний интерфейс (диод данных) в хранилище, которое никаких других связей с любыми сетями не имеет.
Самое забавное: вот такой промпт - это ведь не чёткое программирование, что можно - и что нельзя. По определению, нейросетка всегда может наплевать/игнорировать вот так заложенные ограничения. Т.е всё это - благие пожелания.
Ну например, выложив в Perforce бинарный файл (который не получиться смержить) вы сможете поставить ему тип "binary+l". Так как Perforce - система централизованная, после этого данный файл сможет редактировать только один человек за один раз. Соответственно, необходимости "сливать" конкурентные изменения - не будет.
Разумеется, скорее всего для git можно сколхозить что-то подобное. Или использовать отдельную систему "управления документацией" - но это, как надеюсь вы понимаете, набор из резиновых костылей.
Ещё раз - в git можно сделать всё. Но предназначен git для специфической модели разработки и специфических целей - как только вы пытаетесь его приспособить за пределы его исходной концепции - получается хреново.
Кстати, с этой точки зрения точно то же самое и в Perforce. Разрабатывать классический опенсоурсный продукт в Perforce - с получением патчей от неопределённого круга лиц, с разработчиками работающими независимо и самостоятельно - ну, больше всего похоже на мазохизм.
Слышали и пробовали. Не работает в качестве системы управления конфигурацией.
Perforce, например. Разумеется, изменения в бинарных файлах произвольного типа просмотреть/объединить сама система не может (точнее, может для ограниченного количества форматов, в основном картинки) - но если есть внешние средства - можно использовать их.
При этом, например, хранение проектной документации в том же Word/Autocad/Visio - запросто. Одна возможность хранить историю изменений бинарных файлов (и сами файлы) - это уже очень много.
Концепция гит: куча ветвей, сделанная программистами неизвестного качества, которые интегрирует в мастер-ветвь гуру продукта. В принципе, неплохо ложиться на процесс разработки в компании, которые постоянно нанимают джунов, немного их эксплуатируют и заменяют на новых. Плохо ложиться на организацию, которая нанимает опытных программистов, в случае, когда над отдельным подпродуктом работает 1-2 программиста максимум.
Распределённая разработка в гит не имеет особого смысла для корпоративного применения (скорее, опасна и неудобна для корпораций), но очень востребована в опенсоурсе.
Концепция гит: один репозитарий - один продукт. Ветвление репозитария целиком. Отлично подходит для опенсоурсной разработки, но в корпоративной среде возникают проблемы с зависимостями: продукты не являются независимыми. Т.е. крупные организации очень редко разрабатывают самодостаточный продукт, использующий только "чужие" библиотеки. Обычно он состоит их кучи библиотек и кучи экзешников, каждый из которых - отдельные подпродукты с собственным циклом выпуска релизов. В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях.
Гит может работать с бинарными файлами. Но - всегда криво и с косяками, с дополнительными нашлёпками.
В общем и целом, гит отлично подходит для компаний, чьи разработки не требуют системы управления конфигурации (сonfiguration management).
Т.е. если версия вашего продукта "живёт" полгода, релизы выпускаются часто-часто, долгосрочной поддержки нет, цена ошибки низкая - гит для этого отлично подходит.
Отлично гит подходит для веб-разработки, когда конечный продукт вы же и поддерживаете (т.е. предоставляете доступ к своему хостингу, но не даёте клиенту автономный хостинг).
Если ваш цикл технической поддержки продукта - десятилетия, если продукты сложные и взаимно-зависимые, если вам в любой момент может понадобиться точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик, и вы не можете заставить заказчика обновиться на текущую версию продукта, потому что обновление стоит очень больших ресурсов, если вместе с продуктом вы разрабатываете документацию в разных форматах (бинарных форматах редакторов и CADов) - гит не для вас.
С моей точки зрения, идеальной системой управления версиями была бы централизованная система с кластером серверов, похожая на Perforce или SVN, но с возможностью выделять/маркировать отдельные папки/подпродукты/каталоги так, чтобы слияние изменений можно было выполнять только на папку целиком.
По крайней мере, я пойму, что операционная система проверяет/ремонтирует файловые системы. Что она не зависла наглухо, что прогресс идёт, и можно оценить, что это займет ещё час/день/неделю.
Пользователи (и я тоже) в таких ситуациях довольно часто просто не дожидаются завершения процесса - и, например, перезагружают машину питанием. Что, естественно, проблему усугубляет.
Фигня!
Американские астронавты уже были на Луне, и бегали, и прыгали - и никакие "роборуки" им были не нужны.
Более того, эти крутые парни даже не горбились под тяжестью системы жизнеобеспечения на спине, полностью игнорируя необходимость поддерживать проекцию центра тяжести внутри периметра ступней.
Так что бессмысленную задачу решает, не нужно этого на Луне.
Внутри такого скафандра всё равно давление минимум 1/3 земного.
С чистым кислородом. Потому что иначе человеку будет кислорода не хватать. А для дыхания ему надо расширять и сужать грудную клетку/диафрагму - т.е. менять внутренний объем скафандра. Расширить получится, сжать - нет, мускулов не хватит.
Облегающий костюм, создающий внешнее давление - он по факту позволяет не лопнуть в вакууме, но дышать - не позволяет. Получается что-то типа дайвинга без акваланга - можешь выжить в вакууме 2-3 минуты, пока кислород в крови не кончится.
Разве что включить в этот костюм "искусственное легкое" подключенное к кровеносной системе напрямую. А сами лёгкие чем-то заполнить - вероятно, жидкостью (потому что если будут постоянно сдуты и слипнуться - потом запустить их не получится).
Нет, есть ещё вариант: костюм делает постоянное искусственное дыхание (т.е. расслабляется и сжимается). Но человек так долго не выдержит.
---------------
То что имитация - это да, похоже штаны к ботинкам вообще никак не приделаны.
Хрень какая-то. В этих "скафандрах" не видно никаких механизмов компенсации давления.
У них что, люди внутри скафандра при марсианском давлении находятся?
А без этих средств - скафандр надуется как пузырь, и будешь в нём валяться на поверхности Марса.
Вообще-то исчезнет. И довольно скоро - заменой на китайский.
Как язык международного общения - будет терять популярность, так как современные автопереводчики более-менее решают вопросы бытового общения.
А для технического общения - китайцев просто существенно больше.
Ну да, ну да.
Пишите быстро, дёшево, и чтобы программа у клиента не падала ни в коем случае, зато глючила так, чтобы никто концов не нашёл.
Даже подскажу: обкручивайте всё try-catch, и игнорируйте все исключения. Продукт получится охренительный!
Для начала надо надрючить всех ваших разработчиков на то, чтобы ВСЁ ПО писалось исключительно в стиле "защитного программирования".
Вам нужен аналог assert(), не исключающийся из релизного продукта, и абсолютно во всех случаях, когда есть какое-то условие или возвращаемое значение - оно должно быть проверено или нормальным кодом проверки ошибки, или добавлением неисключаемого из кода assert(). Который должен фиксировать строку/функцию/условие/файл/версию файла.
Таким образом, ваше ПО никогда не должно распространять ошибку дальше.
Использование исключений из кода удалить полностью - точнее, оставить только в модульных тестах.
Ваша программа/модуль должна немедленно паниковать (с сохранением стека и дампа) как только обнаружена ошибка, для которой не предусмотрены штатные условия устранения/восстановления.
Да, и ещё: заставьте своих разработчиков использовать достаточно старый стандарт языка. Ещё лучше: ограничьте используемое множество языка.
Разработчиков, которые тащатся от новейших фич языка - выпихивайте туда, где от них будет минимум вреда - желательно к конкурентам.