Эта заметка – о бесполезных элементах в сложных системах.
Бесполезными я называю такие элементы системы, которые не выполняют и в будущем ни при каких условиях не будут выполнять совершенно никакой полезной работы. При этом следует отметить что бесполезные элементы могут быть как исправными, так и неисправными, могут не работать вообще или выполнять какие-то бессмысленные действия.
Бесполезные элементы могут входить в состав системы изначально, в результате ошибок, допущенных при проектировании, а также появиться позднее, в процессе саморазвития или модернизации системы. Кроме того, полезные элементы со временем могут становиться бесполезными (например, после очередной модернизации).
Вред от бесполезных элементов в большой и сложной системе бывает по началу неочевидным и малозаметным для пользователей. Проблема заключается в том, что бесполезные элементы со временем накапливаются, а сила мелочей – в их многочисленности.
Даже в том случае, если бесполезный элемент просто бездействует, он все равно занимает некоторый объем в пространстве и потребляет некоторое количество энергии. Когда хотя-бы десятая часть от всех элементов оказывается бесполезной, пользователи системы начинают обращать внимание на то, что происходит что-то неправильное.
Было бы неплохо оптимизировать систему, удалив из нее все ненужные элементы, вот только стоит ли овчинка выделки? Иногда бывает гораздо проще и дешевле создать новую систему, чем отчистить от мусора старую.
Можно ли для некоей конкретной системы придумать эффективную процедуру обнаружения бесполезных элементов? Удастся ли их безболезненно изъять?
Как отличить бесполезные элементы от полезных?
Что можно использовать в качестве критерия бесполезности?
Здесь следует отметить, бездействие само по себе надежным критерием служить не может. Предположим, что мы способны постоянно следить за работой всех элементов системы (это трудоемко и весьма затратно, но допустим, что такое возможно). Что произойдет, если после длительного наблюдения за работой системы удалить из нее все бездействующие элементы? Ответ: резервные и защитные устройства могут подолгу бездействовать, а после их изъятия при каком-нибудь изменении окружающей среды система будет внезапно разрушена.
Другой возможный вариант действий – попытаться проанализировать работу системы. Однако детальный анализ работы отдельных элементов может оказаться не просто трудоемким, а практически невыполнимым даже при использовании различных вспомогательных средств, позволяющих частично автоматизировать труд.
Возьмем в качестве наглядного примера персональные компьютеры (ПК). В современном ПК современные элементы могут соседствовать с элементами полувековой давности: самой по себе линейке компьютеров IBM PC уже более 40 лет, а в момент своего появления IBM PC должны были поддерживать созданное ранее периферийное оборудование.
Цитата из Википедии:
IBM PC — первый массовый персональный компьютер производства фирмы IBM, выпущенный в 1981 году.
В ПК бесполезные элементы могут присутствовать и в составе данных (как информационный мусор), и в составе программного обеспечения, и в составе аппаратуры, но в течение длительного периода времени технический прогресс маскировал их негативное влияние на работу пользователей, так как производительность и надежность компьютерного оборудования непрерывно росла.
Современный видеоконтроллер, например, поддерживает сотни стандартных видеорежимов, половина из которых устарела и уже лет тридцать не используется, но пользователям они особо не мешают, поэтому разработчики новых контроллеров эти режимы все еще сохраняют на всякий случай.
С другой стороны, мусор в файловой системе способен сильно раздражать владельца ПК, но при этом плохо поддаваться уборке. В частности, из-за мусора сильно увеличивается продолжительность проверки содержимого жесткого диска ПК на наличие вирусов.
На рисунке 1 показан в качестве примера результат сканирования системного раздела. Откуда в нем взялось более полумиллиона файлов?
Рисунок 1. Результат проверки на наличие вирусов системного раздела на электронном диске ПК
Для того чтобы понять проблемы, связанные с файловой системой MS Windows, необходимо совершить небольшой экскурс в историю ПК. Первоначально расширения имен файлов были короткими (не более трех символов) и стандартизированными. Стандартных расширений становилось со временем все больше, а когда их накопилось несколько тысяч, Билл Гейтс не выдержал давления со стороны многочисленных разработчиков программного обеспечения и разрешил использовать произвольные расширения файлов с произвольной длиной (как говорится, «Делайте, что хотите!»).
В результате подобного решения программы-чистильщики работают все менее эффективно, так как утрачивают способность по расширениям имен отличить полезные файлы от бесполезных.
Рассмотрим в качестве примера бесполезные файлы небольшого размера, которые можно назвать информационной пылью.
На то, что распределение по размерам файлов на дисках серверов соответствует логарифмическому нормальному (логнормальному) закону, специалисты заметили давно.
Ссылки:
A five-year study of file system metadata
Generating Realistic Impressions for File-System Benchmarking
Подобный вид распределения означает наличие большого количества мелких файлов. Для серверов это является естественным, но в последнее время пользователи ПК получили точно такие же проблемы, что и владельцы серверов.
Развлечение специально для программистов: вы можете написать небольшую программу для последовательного обхода дерева каталогов на своем компьютере, разделить файлы по размерам на несколько групп, подсчитать количество файлов в каждой группе и вывести табличку, по которой можно будет затем построить гистограмму. Результат одного из таких экспериментов показан на рисунке 2.
Рисунок 2. Результат эксперимента, проведенного на ПК с целью получения распределения файлов системного раздела диска по размерам
Информационная пыль по своим свойствам похожа на обычную пыль, попавшую в механизм: она составляет небольшую часть от общего объема, занимаемого на диске информационным мусором, но может создавать серьезные трудности в работе системы. Например, она существенно замедляет выполнение операций поиска файлов на диске и проверки системы на наличие компьютерных вирусов. Присутствие информационной пыли может также значительно увеличивать общую трудоемкость выполнения процедуры уборки мусора из системы.
Программы-чистильщики с пылью справляются плохо. Одной из проблем является появление на диске большого количества файлов с нестандартными расширениями: откуда чистильщик может знать, потребуется ли когда-нибудь зачем-нибудь такой файл? Выдавать пользователю по поводу каждого такого файла отдельный запрос на удаление также бесполезно: подобных файлов в системном разделе ПК могут быть тысячи, а зачем какой из них нужен – пользователь не знает.
Комментарии
Проблема есть, очень трудно решаемая. Вероятно, о ней нужно думать на этапе разработки концепции системы.
Интересно. В отвлечённый пример можно привести Чубайса. Вот действительно, а зачем он был нужен? Есть, конечно, версия, что это привнесённый вредоносный код, но достоверно подтвердить это пока не получается, поэтому придётся её пока отложить. Но вот как бесполезный элемент и мусор, не несущий полезной функции, занимающий место на накопителе данных, тратящий на себя электроэнергию на обслуживание и замедляющий эффективную работу системы и проверку её на ошибки - это идеальный пример.
Даже программы-чистильщики так и не справились с удалением этого элемента полностью, а смогли в рамках оптимизации лишь вывести его за рамки системы, частично ограничив доступ.
Упрощюнинг чреват ненадежингом.
никто не мешает юзеру взять и удалить все лишние файлы - пусть посидит 5 лет, поразбирается с каждым и удалит лишние
Очевидно, что большая часть новых файлов поступает в системный раздел из Интернет или создается операционной системой.
Сам пользователь столько файлов «наклепать» не может, даже если будет работать в режиме «отбойного молотка».
Поэтому способ «заставить пользователя разгребать мусор» практически не работает: человек вычищает мусор медленнее, чем компьютер его закачивает из сети Интернет.
Никто не мешает юзеру использовать линукс или написать свою ось без мусора
Не реклама.
Проблемы подобного рода фактически нет в современных Linux системах.
В них никто, конечно, не мешает получить права суперпользователя и начать резвиться точно так-же, как резвятся инсталляторы программ в винде. Но так поступать как бы не принято.
В них есть системный инсталлятор программ. Дистрибутив программы называется "пакет". Это один большой файл. В нём содержатся метаданные о том что это за пакет, что ему нужно для работы. Какие библиотеки потребны, как нужно изменить конфигурацию других пакетов/системы для его работы и как откатить всё назад если надо. И собственно файлы, относящиеся к программе.
И пакет накатывается и удаляется без каких либо проблем целиком и полностью. Ибо системный инсталлятор ведёт БД обо всех пакетах и их компонентах.
В любой момент времени можно узнать частью какого пакета является вот этот вот непонятный файл.
Если вы не работаете под суперпользователем, то у вас и запущенных вами программ просто нет прав для записи в основную файловую систему машины. Фактически, писАть можно только в два места по умолчанию: Это домашняя директория и временная директория. Все временные файлы, нужные для работы программы создаются во временной директории, которая потом чистится. В домашней будьте добры разбираться сами.
Возможно, что суперпользователь разрешит вам запись куда-то ещё. Но, это особый случай и для массовой обычной работы мы его не рассматриваем.
> Не реклама
Да, не реклама. Это камингаут.
> Проблемы подобного рода фактически нет в современных Linux системах
Ой, дура-а-ак... Как раз в говнолинухе эта проблема стоит более остро и хуже того, она неизлечима. Именно потому, что говнолинукс не система. Не система в широком смысле и даже не операционная система. Так, произвольно взятый набор стаффа. И в общем случае взятый далеко не только составителем дистрибутива.
> Но так поступать как бы не принято
Ты дурак. Принято и считается признаком крутости. Скачать тулзу с гитхаба - признак мастерства. Мейк, мейк инсталл, магия!
> В них есть системный инсталлятор программ.
Не один чаще всего (апт, апт-гет, аптитьюд, симантик, етц). Одного этого факта достаточно чтобы даже не заикаться о превосходстве.
> Дистрибутив программы называется "пакет".
А у пакета есть зависимости. А у линкусовых разработчиков самой распространённой болезнью является версиоз. Пакеты используют либы и прочие шаред ресурсы. Даже в одном дистрибутиве они могут быть разных версий. А пакеты регулярно обновляются. И тянут себе новые версии либов и прочего стаффа. А старые не всегда можно удалять. А даже если можно, не всегда удаляются. А все они лежат в одной помойке /usr/bin и /usr/lib. Там в итоге скапливается столько мусора, что виндузовые system и system32 выглядят в сравнении эрмитажем.
> Если вы не работаете под суперпользователем
Ага, ага. Весь современный говнолинукс как США на ЛГБТ-повесточку подсел на sudo. И покажи мне того, кто правит конфиг этого судо чтобы убрать дефолтный таймаут в течении которого повторный вызов судо не спрашивает пароль. Раз выполнил судо, в течении минуты (не помню точно, может две или пять, лень проверять) новое выполнение судо даст тебе права рута без малейшего конфирма. Делай что хочешь, гуляй, рванина по всей ФС. Б - безопасность. И вот так у вас всё, фапаете на линукс, но не знаете его, не понимаете его, не умеете с ним работать.
1. Любезнейший, я не пил с вами брудершафтов. Не думаю, что я достоин чести в общении с вами пользоваться местоимением "ты".
2. Ваше оценочное мнение без аргументации очень важно для меня. Продолжайте вести наблюдения и обязательно докладывайте.
Теломеры, вот? Они бесполезны?
А вот инфо пыль в случае поломки компа? Полезна или нет?
Система не работает в идеальных условиях. Хотя, сферический конь в вакууме...
Информационная пыль, подобно обычной пыли, может увеличить частоту возникновения неисправностей (сокращать срок работы ПК между ремонтами).
Является ли эта статья полезной?
Является, если хоть кого-нибудь заставит задуматься над проблемой!
Все проблемы из-за
бабвхода на комп под админкой.Вы в статье даёте практически философское определение бесполезности, а потом скатывается к обсуждению трудности удаления накапливаемого в компе инфомусора. Если смотреть за мусор, то это не баг, а фича, позволяющая жить куче около/софоовского люда, и никакой тут бесполезности с их точки зрения нет.
Одна из проблем заключается в том, чтобы наглядно продемонстрировать саму возможность существования большого количества бесполезных элементов в какой-либо технической системе: многие в такую возможность просто не верят.
За многих не скажу, но само понятие "бесполезность" относительно. Потому что кажется бесполезным вам, является иногда полезным другим.
А вот выявить то, что никому не полезно - тут надо создавать специальную комиссию на постоянной основе, с подкомитетами по бесполезностям в различных отраслях Н/х. И лучше на правительственном уровне!
В случае с информационным мусором пользователи ПК и смартфонов по одну сторону, а все остальные – по другую:
- изготовителям аппаратуры выгодно, чтобы запоминающие устройства быстрее забивались мусором и быстрее изнашивались из-за его наличия;
- хакерам и вирусописателям удобно прятать в мусоре вредоносное ПО;
- соответственно, выгоду от наличия мусора получают разработчики антивирусного ПО и программ-чистильщиков памяти;
- и так далее…
Воот. Теперь копаем далее. Чиста гипотетически. Создали софт без изъянов. Это в принципе решаемо. Что дальше делать программистам, создавшим эту программу? И куче народа, который кормился с выправления косяков программному и настройки мест пользователей?Теперь они становятся бесполезны?
Организационные системы обычно создаются для решения одной или нескольких ТИПОВЫХ задач.
В самом начале "бесполезных" элементов там нет и быть не может.
Как, например, в 20-е - 30-е годы в СССР.
Почему?
Потому, что топология таких систем - прямое отражение топологи взаимосвязей функционалов, необходимых для достижения иерархии целей.
То есть.
Сначала описываются цели. Вернее - иерархия целей/подцелей.
Потом находятся (или придумываются) функционалы, которые реализуют достижение этих целей.
Потом, если система создаётся заново, то, в зависимости от "объёма"/трудозатратности/ресурсозатратности оцениваемого функционала, для его выполнения или заново организуется исполнитель, или такой функционал нагружается на/"приписывается" уже имеющимся "типовому исполнительному элементу".
Поэтому, в заново спроектированной "организационной структуре", её топология (почти) эквивалентна топологиям целей и функционалов. Отличия могут быть тогда, когда исполняющие элементы могут совмещать "функциональные обязанности", "НЕ МЕШАЮЩИЕ" друг другу и их топологии - не изоморфны.
В процессе проектирования, в системе появляются ещё дополнительные элементы, НАПРЯМУЮ, КАК БЫ, НЕ СВЯЗАННЫЕ С ВЫПОЛНЕНИЕМ КОНКРЕТНЫХ ЗАДАЧ ПО ФУНКЦИОНАЛАМ - обычно это элементы, работающие на УПОРЯДОЧИВАНИЕ ОБМЕНА ИНФОРМАЦИОННЫХ/РЕСУРСНЫХ ПОТОКОВ, появляющихся в процессе работы "основных" функциональных элементов. Такой тип элементов присущ "более универсальным" системам, которые заточены на решение более широкого спектра, нагружаемых на систему, наборов задач. Эти элементы - наиболее рИсковая часть любой системы. Потому, что именно они "гасят расхождения" между топологиями систем целей и задач, И - топологиями исполнителей.
Теперь обратим внимание на то, что цели и задачи постоянно пересматриваются, с течением времени. МЕНЯЕТСЯ их смысл и - САМОЕ ГЛАВНОЕ - находятся новые наборы функционала для их достижения и выполнения. Сиречь - «модернизация».
Но!
"Организационная структура" (топология) системы исполнителей, чаще всего, остаётся неизменной.
Например, множество заводов и промобъединений, которые были построены и образованы в 20-30-х годах, дожили до перестройки и сохранились позже, ПРАКТИЧЕСКИ НЕ МЕНЯЯСЬ.
А - наборы задач и способы их решений - менялись, причём - порой достаточно радикально.
До определённого момента времени, у системы исполнителей остаётся "резерв" (чаще - производительности), чтобы работать в новых условиях и "по новым требованиям".
У советских предприятий и управленческих структур, построенных в 20-30-е годы, такой резерв был примерно - до середины-конца 60-х. Потом они стали "захлёбываться" по причине уже радикального расхождения "топологий" и "природы" задач с "топологиями" и "возможностями" исполнительных элементов. Значительный вклад в такое "захлёбывание" вносили те самые, выделенные и упомянутые "элементы за штатом" (помните?, это - которые обеспечивали "связность" системы по потокам информации и ресурсам)
На западе такие сложности и проблемы тоже возникали раньше и постоянно.
Сначала они пошли по "явному" пути. Под каждый вид и поколение продукции проектировались/строились/организовывались ОТДЕЛЬНЫЕ, НОВЫЕ производственные единицы и их конгломерации. С приходом новых техпроцессов, бывало, что даже не модернизировались старые, а — тупо «шли на слом и в утиль»!
Два примера.
Пока не было нормального освещения, после появления железо-бетонных конструкций и зданий, офисные здания в Нью-Йорке стали тянуться на максимальное расстояние вверх и имели ОГРОМНЫЕ окна - чтобы максимально растянуть по времени использование дневного солнечного света для работы клерков. Потом, с началом массового выпуска ламп дневного света офисные здания и их окна "измельчали" ("вернулись к разумной норме и размерам"). Кроме того, в "классических" нью-йоркских небоскрёбах располагалось ОГРОМНОЕ количество фирм и фирмочек. А, после внедрения ЛДС - фирмы уже могли строить небольшие офисные здания "под себя".
Второй пример - из танкостроения. Вначале, оптимальным было признано строительство отдельных заводов под ДАЖЕ определённую модификацию танка (а - не только под отдельную конструкцию). Последний такой пример - производство американцами абрамсов. В определённые моменты времени, одновременно работало два завода под производство разных модификаций этого танка, а один их них перестраивался практически полностью с принятием следующей модификации машины.
С появлением гибких, перенастраиваемых, производственных линий, надобность в строительстве новых и "модернизации" старых заводов отпала.
В обоих случаях, кстати заметьте, что большая часть "перенастройки" касалась.... именно тех, "внесистемных" элементов системы - которые обеспечивали связь между "штатными" исполняющими элементами системы. В случае офисных конгломераций это были системы доставки «канцтоваров» или папок/пакетов с документами специальными посыльными (или - пневмопочтой), а на заводах - экспериментированием со связями между складами и сборочными пунктами или конвейером.
Заметьте, что в компьютерах, в подавляющем большинстве случаев, вирусы организуют атаку именно на какой-либо из таких, "обеспечивающих связность системы", элемент (будь то электронное устройство или блок, или — программная часть).
"Атаки на офисы" (промышленный шпионаж) идут тоже по "связям".
Побеги из тюрем организуются, чаще всего, с использованием слабостей в защите "связующих" элементов.
Почему так?
Потому, что используется основное свойство "универсальных связующих элементов" - НЕЗНАНИЕ "СЕМАНТИЧЕСКОГО НАПОЛНЕНИЯ" ТОГО, ЧТО ОНИ "ПЕРЕДАЮТ" ПО "КАНАЛАМ". Именно это свойство, собственно, и обеспечивает универсальность их работы. Они не могут проверить то, что передают! Они - "НЕ знают смысла" передаваемого.
... в отличие от "штатных" исполнительных элементов.
(Кстати именно поэтому, логика УСПЕШНОГО и быстрого проведения СВО, «в классике», требовала вывода из строя таких «элементов связности» - авто- и железно- дорожной сети! Но, видимо, там работает «другая логика», обусловленная «другими целями» «исполняющих элементов системы»......... )
Дальше об "бесполезности" элементов...
В процессе "перенастройки" системы исполняющих элементов под новые задачи, может сложиться ситуация, когда система выйдет в полный "разбаланс" по расписаниям работы элементов, а связные элементы - либо "захлебнутся" в потоках, либо станут недозагруженными/незанятыми.
Помнится был какой-то советский фильм, там "осуждалась забюрократизированность" одной конторы, "распределяющей приказы, постановления и справки", где работала молодая девочка, приготавливающая чай для сотрудников. Там, за спиной героя Филиппова, висела "Схема распределения и доставки директив и приказов" - эдакий ацикличный однонаправленный граф с одним стартовым, двумя-тремя конечными и КУЧЕЙ промежуточных узлов, на которых документы копировались, архивировались, распределялись между "потомками" по связям в графе...
Скорее всего, мы имеем пример организации, когда промежуточные узлы не возникли "сами собой" или злому умыслу/хитрожопистости начальства этой конторы. Думается, что, в процессе реорганизации отрасли/объединения, внешние (относительно данной конторы) источники и потребители документов были упразднены/сокращены/перепрофилированы... А начальство просто преобразовало часть «освободившихся узлов» в "промежуточные" элементы "обработки информации".
Кстати, и на Западе, и в СССР, в 30-е-60-ые годы, была профессия "вычислитель-расчётчик". Вот тогда — да, целый штат расчётчиков с «железными феликсами» на столах, объединялись в "топологии", аналогичные структурам «расчётных нужд».
И - именно оттуда масса методов организаций вычислений, кстати, перекочевала в алгоритмы и программы для ЭВМ.
Такие "вычислительные группы и отделы" были не только у Королёва и Курчатова с Туполевым, но и - ранее, во время войны - например, у Жукова, Рокосовского и в ГенШтабе, для планирования операций.
Собственно, успешность и "незатратность"/оптимальность работы системы - прямая функция от "степени идентичности" её структуры структуре решаемой задачи.
В вычтехнике это можно обеспечить наиболее гибко, наглядно.
И именно поэтому, сегодняшнее направление "поиска самой лучшей УНИВЕРСАЛЬНОЙ архитектуры процессоров" - в корне ошибочно и тупиково. Нет, конечно же, гигагерцы конструкторы и дальше будут "отвоёвывать" на нанометрах техпроцессов производства. Но это быстродействие НИКОГДА не сравнится со строго специализированными решениями "под задачу". Отсюда - самый оптимальный вариант видится в создании перенастраиваемых архитектур ("ПЛИСоподобные"). В отличие от универсальных подходов, там производство вычислений и передача данных между "исполнителями" таких вычислений не будет иметь "лишних" промежуточных элементов (буферизация, переходы между внутренними шинами, преобразования между внутренним и внешним представлением данных и т.д.).
В области организационных систем народ - тоже ищет решения. Например создают вместо строго деревьев иерархий "матричные" или "сетевые" топологии, с "перестройкой топологии". Но, они подразумевают уход, в специализации "исполнительных" элементов, от строгого набора стандартных действий к постоянно изменяемому "функционалу", что большинству народа НЕ нравится, да и не имеет оно на то желания, способностей и талантов ("...к пуговицам - претензии есть? - нет! пришиты накрепко - не оторвёшь!").
Многие видели спасение в "компьютеризации управления", когда множество «рутинных операций» перекладывается на набор специализированного ПО, обеспечивающего перестройку и поддержку разных "виртуальных" топологий в процессе переключения между разными проектами и набором задач. Пока (даже после 70-ти лет развития ИТ в этом направлении), успехи - ОЧЕНЬ скромные. Опять же - по причине чисто "человеческого фактора".