Версии PowerShell
PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.
На сегодняшний день существуют две версии PowerShell:
🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1
🔹 PowerShell Core – основан на .NET Core, является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell Core нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell Core 7.х разработчиками заявлена максимальная совместимость.
Windows PowerShell имеет следующие выпуски:
▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709
В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell Core.
PowerShell Core имеет следующие выпуски:
▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell
▫️ PowerShell Core 7.х на базе .NET Core 3.x, заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.
PowerShell Core можно получить с официальной страницы на Github, через WinGet или из магазина Windows.
Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.
Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell Core следует использовать Visual Studio Code.
PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.
На сегодняшний день существуют две версии PowerShell:
🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1
🔹 PowerShell Core – основан на .NET Core, является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell Core нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell Core 7.х разработчиками заявлена максимальная совместимость.
Windows PowerShell имеет следующие выпуски:
▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709
В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell Core.
PowerShell Core имеет следующие выпуски:
▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell
▫️ PowerShell Core 7.х на базе .NET Core 3.x, заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.
PowerShell Core можно получить с официальной страницы на Github, через WinGet или из магазина Windows.
Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.
Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell Core следует использовать Visual Studio Code.
SMART атрибуты NVMe дисков
Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.
Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)
🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:
▫️
▫️
▫️
▫️
▫️
🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.
🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться
🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.
🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.
🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.
🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.
🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.
🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером
🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.
🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя
🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения
🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания
🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA
🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера
🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры
🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры
🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.
🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.
Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.
Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)
🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:
▫️
0x01 – доступное свободное пространство упало ниже порогового значения▫️
0x02 – температура вышла за пороговые значения (как вверх, так и вниз)▫️
0x03 - надежность подсистемы NVM ухудшилась из-за значительных проблем, связанных со средой передачи данных, включая ошибки, снижающие надежность подсистемы NVM ▫️
0x04 – накопитель перешел в режим только чтения▫️
0x08 – устройство энергозависимой памяти (DRAM) вышло из строя 🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.
🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться
🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.
🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.
🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.
🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.
🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.
🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером
🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.
🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя
🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения
🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания
🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA
🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера
🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры
🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры
🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.
🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.
Что такое PowerShell и чем он отличается от своих аналогов
Практически после каждой нашей публикации PowerShell появлются негативные комментарии или вообще агрессивное отрицание данного продукта. Что довольно неожиданно, игнорировать столь мощный инструмент – идея далеко не самая лучшая.
Возможно, что не все до конца представляют, чем является из себе PowerShell и чем он отличается от своих аналогов.
Начнем с небольшого экскурса в историю. Для обеспечения интерфейса командной строки были придуманы командные интерпретаторы, которые представляли собой скриптовые языки с определенным набором возможностей.
Впервые они были заданы в стандарте POSIX (ISO/IEC 9945) (Том 3. Оболочка и утилиты) , который предписывал языкам оболочки иметь конструкции последовательного, условного и циклического исполнения команд, а также оператор присваивания.
К таким языкам до сих пор относятся bash и аналоги, а также CMD. Несмотря на различные возможности – это все типичные скриптовые языки оболочки. Со своими типичными возможностями и ограничениями.
Одной из характерных особенностей этих языков является текстовый интерфейс взаимодействия, что вынуждает при анализе и обработке результата прибегать к сериализации или парсингу.
Я думаю, что любой, кто писал сложные скрипты на том же bash с этим сталкивался. Поэтому при определенном уровне сложности многие начинают переходить на скриптовые языки общего назначения с объектной моделью, например, Python.
Основное отличие объекта от текста в том, что объект имеет свои свойства и методы, к которым мы можем обращаться без всякого парсинга просто зная их наименование. Например, чтобы посмотреть условный статус объекта нам достаточно прочитать свойство Объект.Статус.
Это весьма грубая и упрощенная модель, но достаточная для базового понимания сути.
Так вот, при разработке PowerShell было принято решение реализовать в нем объектную модель. Таким образом PowerShell, хоть и является языком оболочки, но по функциональным возможностям гораздо ближе к скриптовым языкам общего назначения, таким как Python.
Это же наложило отпечаток и на его синтаксис, он также сильно отличается от синтаксиса языков оболочек и гораздо ближе к обычным языкам программирования.
И этот момент вызывает у многих недоумение, так как PowerShell является одной из оболочек командной строки и языком этой оболочки. А отличительная особенность языков оболочек – это короткие команды, которые легко запомнить и быстро вводить.
Но у этой медали есть и обратная сторона. Скрипты на таких языках очень трудно читаются, особенно если вы не помните наизусть всех команд и их ключей. Очень часто код приходится читать буквально «со словарем».
В PowerShell решили подойти с другой стороны и его синтаксис позволяет читать скрипты буквально налету, понимая, что они делают без обращения к документации. При написании скриптов это также не вызывает сложности благодаря возможностям сред разработки.
При этом мы согласимся с тем, что для повседневного администрирования синтаксис PowerShell неудобен и многословен, однако он поддерживает алиасы, позволяющие работать в привычном коротком, но практически нечитабельном, синтаксисе.
Что касается порога входа в PowerShell, то он тоже гораздо выше, на уровне скриптовых языков, но его изучение того стоит, так как открывает гораздо более широкие возможности по взаимодействию с системой, особенно учитывая глубокую интеграцию в нее посредством .NET.
Практически после каждой нашей публикации PowerShell появлются негативные комментарии или вообще агрессивное отрицание данного продукта. Что довольно неожиданно, игнорировать столь мощный инструмент – идея далеко не самая лучшая.
Возможно, что не все до конца представляют, чем является из себе PowerShell и чем он отличается от своих аналогов.
Начнем с небольшого экскурса в историю. Для обеспечения интерфейса командной строки были придуманы командные интерпретаторы, которые представляли собой скриптовые языки с определенным набором возможностей.
Впервые они были заданы в стандарте POSIX (ISO/IEC 9945) (Том 3. Оболочка и утилиты) , который предписывал языкам оболочки иметь конструкции последовательного, условного и циклического исполнения команд, а также оператор присваивания.
К таким языкам до сих пор относятся bash и аналоги, а также CMD. Несмотря на различные возможности – это все типичные скриптовые языки оболочки. Со своими типичными возможностями и ограничениями.
Одной из характерных особенностей этих языков является текстовый интерфейс взаимодействия, что вынуждает при анализе и обработке результата прибегать к сериализации или парсингу.
Я думаю, что любой, кто писал сложные скрипты на том же bash с этим сталкивался. Поэтому при определенном уровне сложности многие начинают переходить на скриптовые языки общего назначения с объектной моделью, например, Python.
Основное отличие объекта от текста в том, что объект имеет свои свойства и методы, к которым мы можем обращаться без всякого парсинга просто зная их наименование. Например, чтобы посмотреть условный статус объекта нам достаточно прочитать свойство Объект.Статус.
Это весьма грубая и упрощенная модель, но достаточная для базового понимания сути.
Так вот, при разработке PowerShell было принято решение реализовать в нем объектную модель. Таким образом PowerShell, хоть и является языком оболочки, но по функциональным возможностям гораздо ближе к скриптовым языкам общего назначения, таким как Python.
Это же наложило отпечаток и на его синтаксис, он также сильно отличается от синтаксиса языков оболочек и гораздо ближе к обычным языкам программирования.
И этот момент вызывает у многих недоумение, так как PowerShell является одной из оболочек командной строки и языком этой оболочки. А отличительная особенность языков оболочек – это короткие команды, которые легко запомнить и быстро вводить.
Но у этой медали есть и обратная сторона. Скрипты на таких языках очень трудно читаются, особенно если вы не помните наизусть всех команд и их ключей. Очень часто код приходится читать буквально «со словарем».
В PowerShell решили подойти с другой стороны и его синтаксис позволяет читать скрипты буквально налету, понимая, что они делают без обращения к документации. При написании скриптов это также не вызывает сложности благодаря возможностям сред разработки.
При этом мы согласимся с тем, что для повседневного администрирования синтаксис PowerShell неудобен и многословен, однако он поддерживает алиасы, позволяющие работать в привычном коротком, но практически нечитабельном, синтаксисе.
Что касается порога входа в PowerShell, то он тоже гораздо выше, на уровне скриптовых языков, но его изучение того стоит, так как открывает гораздо более широкие возможности по взаимодействию с системой, особенно учитывая глубокую интеграцию в нее посредством .NET.
Как создать копию драйверов текущего ПК не прибегая к сторонним инструментам
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Кроме PowerShell вы также можете использовать DISM:
Или pnputil, что актуально для старых систем, начиная с Windows 7:
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Export-WindowsDriver —Online —Destination F:\Drivers
Кроме PowerShell вы также можете использовать DISM:
dism /online /export-driver /destination: F:\Drivers
Или pnputil, что актуально для старых систем, начиная с Windows 7:
pnputil.exe /export-driver * F:\Drivers
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
Используем ImDisk для эмуляции флешек и других типов накопителей
Современный мир все больше и больше переходит к использованию онлайн-хранилищ и привычные типы физических накопителей потихоньку становятся историей.
При этом необходимость их использования все еще остается, а некоторый специализированный софт может прямо требовать наличие физического накопителя. Но это не всегда возможно, например, в виртуальных средах или на удаленных системах. В этом случае нам на помощь придут эмуляторы.
В данной статье мы рассмотрим работу с ImDisk - простым и мощным решением для работы с виртуальными накопителями.
https://interface31.ru/tech_it/2024/05/ispol-zuem-imdisk-dlya-emulyacii-fleshek-i-drugih-tipov-nakopiteley.html
Современный мир все больше и больше переходит к использованию онлайн-хранилищ и привычные типы физических накопителей потихоньку становятся историей.
При этом необходимость их использования все еще остается, а некоторый специализированный софт может прямо требовать наличие физического накопителя. Но это не всегда возможно, например, в виртуальных средах или на удаленных системах. В этом случае нам на помощь придут эмуляторы.
В данной статье мы рассмотрим работу с ImDisk - простым и мощным решением для работы с виртуальными накопителями.
https://interface31.ru/tech_it/2024/05/ispol-zuem-imdisk-dlya-emulyacii-fleshek-i-drugih-tipov-nakopiteley.html
Немного о телеметрии
Есть темы, при обсуждении которых многие коллеги утрачивают остатки здравого смысла и начинают оперировать домыслами, один другого удивительнее.
Одной из таких тем является телеметрия. И больше всех здесь достается компании Microsoft, которую в чем только не обвиняют, вплоть до сбора скринштов рабочего стола.
При этом включить мозги и подумать, а зачем компании ваши скриншоты – это задача, явно выходящая за пределы пантеона мифов и легенд, к коим относится и телеметрия.
При этом как-то все забывают, что в кармане у каждого есть персональный сборщик телеметрии и не только: смартфон. И объемы собираемой им информации в разы превосходят то, что собирает Microsoft и Windows.
Загляните хотя бы в Цифровое благополучие от Google, оно прекрасно осведомлено о вашем режиме дня и отдыха, месте жительства, месте работы и т.д. и т.п.
Google вместе с Apple также прекрасно осведомлены о ваших передвижениях, способе передвижения, кулинарных, музыкальных и литературных предпочтениях и еще о многом, многом другом.
Также мы носим на руке умные часы или фитнесс-браслеты, которые имеют доступ к данным о состоянии здоровья и физической активности организма. Все это тоже передается на сервера (облачные функции) и как минимум анализируется на базовом уровне, чтобы выдать вам персональные рекомендации.
Кроме того, нашу активность отслеживают сайты, браузеры, мобильные приложения. Собирая данные о наших вкусах, предпочтениях и поведенческих факторах.
И я не скажу, что это плохо. Телеметрия это просто инструмент и использовать его можно по-разному. Например, я предпочитаю, чтобы рекламные сети показывали мне рекламу на основе моих запросов, а не случайно подобранную.
Тем более что таким образом я уже находил интересные предложения, которые вряд ли бы начал искать сам.
Также мне нравится, когда приложение для заказа продуктов предлагает мне что-то новое из тех категорий, которые я предпочитаю, а не непонятно что.
Но это взгляд с одной стороны, стороны потребителя. А теперь поменяем позиции на другую сторону баррикад.
Как владелец сайта я размещаю на нем счетчики, которые не только ведут подсчет посетителей, но и отслеживают их активность в весьма широком диапазоне. Самые известные – это счетчики от Google и Яндекса.
Благодаря их аналитике я могу не только посмотреть сколько страниц моего сайта было просмотрено, но и получить достаточно подробную информацию о посетителях, их устройствах, программному обеспечению, половзрастной структуре, личным предпочтениям и интересам.
Также я могу изучить поведенческие факторы для каждой статьи, например, сколько посетителей дочитало ее до конца.
Все это помогает делать материал на сайте полезнее и увеличивать удобство сайта для посетителей. Скажем, располагая данными об экранных разрешениях устройств можно выбрать оптимальные размеры изображения и макета сайта.
А зная поведенческие факторы более доступно доносить материал. Например, было выяснено, что есть некий предельный объем статьи, после которого количество дочитываний начинает падать. Исходя из этого мы стали делить материал на части меньшего объема.
Выигрывает ли от этого читатель? Конечно выигрывает. Например, я тоже не очень люблю длинные статьи, какие бы интересные они не были. Потому что их прочтение отнимает много времени и внимания.
Но и короткие, поверхностные статьи – это тоже не очень хорошо. Где же золотая середина? Ее как раз дает телеметрия.
Поэтому, повторюсь, телеметрия – это не хорошо и не плохо. Это неотъемлемая часть жизни, делающей ее немного лучше и удобнее в обмен на некоторые наши данные.
Плохо – это когда телеметрия начинает нарушать личные пределы и собирать чувствительную личную информацию и персональные данные. Это, конечно же, недопустимо и этому следует обязательно препятствовать.
Есть темы, при обсуждении которых многие коллеги утрачивают остатки здравого смысла и начинают оперировать домыслами, один другого удивительнее.
Одной из таких тем является телеметрия. И больше всех здесь достается компании Microsoft, которую в чем только не обвиняют, вплоть до сбора скринштов рабочего стола.
При этом включить мозги и подумать, а зачем компании ваши скриншоты – это задача, явно выходящая за пределы пантеона мифов и легенд, к коим относится и телеметрия.
При этом как-то все забывают, что в кармане у каждого есть персональный сборщик телеметрии и не только: смартфон. И объемы собираемой им информации в разы превосходят то, что собирает Microsoft и Windows.
Загляните хотя бы в Цифровое благополучие от Google, оно прекрасно осведомлено о вашем режиме дня и отдыха, месте жительства, месте работы и т.д. и т.п.
Google вместе с Apple также прекрасно осведомлены о ваших передвижениях, способе передвижения, кулинарных, музыкальных и литературных предпочтениях и еще о многом, многом другом.
Также мы носим на руке умные часы или фитнесс-браслеты, которые имеют доступ к данным о состоянии здоровья и физической активности организма. Все это тоже передается на сервера (облачные функции) и как минимум анализируется на базовом уровне, чтобы выдать вам персональные рекомендации.
Кроме того, нашу активность отслеживают сайты, браузеры, мобильные приложения. Собирая данные о наших вкусах, предпочтениях и поведенческих факторах.
И я не скажу, что это плохо. Телеметрия это просто инструмент и использовать его можно по-разному. Например, я предпочитаю, чтобы рекламные сети показывали мне рекламу на основе моих запросов, а не случайно подобранную.
Тем более что таким образом я уже находил интересные предложения, которые вряд ли бы начал искать сам.
Также мне нравится, когда приложение для заказа продуктов предлагает мне что-то новое из тех категорий, которые я предпочитаю, а не непонятно что.
Но это взгляд с одной стороны, стороны потребителя. А теперь поменяем позиции на другую сторону баррикад.
Как владелец сайта я размещаю на нем счетчики, которые не только ведут подсчет посетителей, но и отслеживают их активность в весьма широком диапазоне. Самые известные – это счетчики от Google и Яндекса.
Благодаря их аналитике я могу не только посмотреть сколько страниц моего сайта было просмотрено, но и получить достаточно подробную информацию о посетителях, их устройствах, программному обеспечению, половзрастной структуре, личным предпочтениям и интересам.
Также я могу изучить поведенческие факторы для каждой статьи, например, сколько посетителей дочитало ее до конца.
Все это помогает делать материал на сайте полезнее и увеличивать удобство сайта для посетителей. Скажем, располагая данными об экранных разрешениях устройств можно выбрать оптимальные размеры изображения и макета сайта.
А зная поведенческие факторы более доступно доносить материал. Например, было выяснено, что есть некий предельный объем статьи, после которого количество дочитываний начинает падать. Исходя из этого мы стали делить материал на части меньшего объема.
Выигрывает ли от этого читатель? Конечно выигрывает. Например, я тоже не очень люблю длинные статьи, какие бы интересные они не были. Потому что их прочтение отнимает много времени и внимания.
Но и короткие, поверхностные статьи – это тоже не очень хорошо. Где же золотая середина? Ее как раз дает телеметрия.
Поэтому, повторюсь, телеметрия – это не хорошо и не плохо. Это неотъемлемая часть жизни, делающей ее немного лучше и удобнее в обмен на некоторые наши данные.
Плохо – это когда телеметрия начинает нарушать личные пределы и собирать чувствительную личную информацию и персональные данные. Это, конечно же, недопустимо и этому следует обязательно препятствовать.
🔮 Приглашаем на вебинар по CVoS — узнайте, как зарезервировать облачные ресурсы Yandex Cloud с выгодой до 22%
10 июня в 11:00 по мск эксперты Yandex Cloud, FinOps-платформы «Клаудмастер» и Hilbert Team расскажут, как превратить резервирование ресурсов в надежный инструмент экономии без рисков.
Вы узнаете:
— CVoS: что это и с чем его едят
— Секреты CVoS: как резервирование ресурсов защитит от повышения тарифов и перерасхода бюджета
— Как FinOps-подход помогает оценить объем ресурсов, покрываемых CVoS, без рисков переплаты
— Пошаговый алгоритм подключения CVoS от «Клаудмастер» — начиная с анализа нагрузки и заканчивая оценкой потенциальной экономии
— CVoS в Yandex Cloud: выгодные условия подключения от провайдера
— Разбор полетов: кейсы компаний, которые подключили CVoS и сэкономили до 22% бюджета
Ждем техдиров, DevOps-инженеров, финансовых специалистов и всех, кому интересна тема оптимизации ИТ-инфраструктуры и управления облачными ресурсами.
👉 Регистрируйтесь на вебинар по ссылке
✉️ После мероприятия все участники получат видеозапись вебинара, презентацию экспертов и расширенный доступ к триальной версии FinOps-платформы «Клаудмастер» на 30 дней.
10 июня в 11:00 по мск эксперты Yandex Cloud, FinOps-платформы «Клаудмастер» и Hilbert Team расскажут, как превратить резервирование ресурсов в надежный инструмент экономии без рисков.
Вы узнаете:
— CVoS: что это и с чем его едят
— Секреты CVoS: как резервирование ресурсов защитит от повышения тарифов и перерасхода бюджета
— Как FinOps-подход помогает оценить объем ресурсов, покрываемых CVoS, без рисков переплаты
— Пошаговый алгоритм подключения CVoS от «Клаудмастер» — начиная с анализа нагрузки и заканчивая оценкой потенциальной экономии
— CVoS в Yandex Cloud: выгодные условия подключения от провайдера
— Разбор полетов: кейсы компаний, которые подключили CVoS и сэкономили до 22% бюджета
Ждем техдиров, DevOps-инженеров, финансовых специалистов и всех, кому интересна тема оптимизации ИТ-инфраструктуры и управления облачными ресурсами.
👉 Регистрируйтесь на вебинар по ссылке
✉️ После мероприятия все участники получат видеозапись вебинара, презентацию экспертов и расширенный доступ к триальной версии FinOps-платформы «Клаудмастер» на 30 дней.
Философия UNIX и современность
Про философию UNIX слышали многие, это некий неформальный свод правил, которым руководствовались первые разработчики UNIX.
Впоследствии данные правила стали использоваться как прямыми наследниками UNIX (Solaris, BSD), так и системами, сделанными по образу и подобию (Linux) и именно следование данной философии позволяет говорить о семействе UNIX-подобных операционных систем.
Для понимания причин возникновения данной философии следует окунуться в исторический контекст разработки UNIX.
Одной из главных задач разработчики видели переносимость, в те годы не существовало универсальной операционной системы, каждый производитель оборудования писал что-то свое, с другим оборудованием несовместимое.
Второй важный аспект – крайняя ограниченность ресурсов, Кен Томпсон изначально писал новую ОС для компьютера PDP-7 оперативная память которого составляла всего 4000 18-битных слов, что оправдывалось предельно низкой ценой данной модели – 72 000$ (711 000$ по нынешнему курсу).
Сегодня компьютеры уже совсем иные и многие вещи, которые волновали разработчиков UNIX уже неактуальны, но философия, заложенная ими в основу системы живет и иногда сбивает с толку современное поколение администраторов.
К написанию данной заметки нас сподвигло то, что уже не раз и не два читатели высказывали свое недоумение или непонимание работы различных Linux программ, которое вытекало как раз из непонимания философии UNIX.
Обычно это касается старых, классических программ и утилит, но также этой философии могут следовать и многие современные службы.
В основе философии UNIX лежит следующий постулат:
Разрабатывайте программы так, чтобы они выполняли только одну задачу, но делали это хорошо, и чтобы они хорошо работали вместе с другими программами.
В те времена это было как нельзя актуально, ограниченность ресурсов не позволяла писать сложные программы, но можно было вызвать последовательно несколько простых программ, которые вместе дали бы требуемый результат.
Но в этом кроется и более глубокий смысл: каждая программа должна делать что-то одно, но делать это хорошо. Простые программы легче поддерживать, в них меньше ошибок и они работают быстрее.
Но это и первая причина недоумения современных администраторов, когда они спрашивают, а умеет ли данная программа это и сильно удивляются, когда им говорят, что нет и нужно дополнительно использовать еще это, это и это.
С другой стороны подобная гибкость позволяет быстро и просто построить именно то, что требуется в данном случае, без оглядки на реализацию в той или иной программе. Когда система построена из простых кубиков гораздо проще заменить один кубик другим, чем сделать это в сложной системе.
Второй важный постулат – правило тишины. Программы по умолчанию не должны ничего говорить (т. е. не выдавать никаких результатов). Это тоже повергает в ступор многих, привыкших к современному информационному шуму и многословию.
Я ввел команду и ничего не произошло… Как так???
На самом деле команда выполнила свое действие, но если все прошло как надо, то зачем об этом говорить? Ведь это же очевидно. И этот принцип продолжает соблюдаться и во многих современных системах.
Например, перезапуск службы. Если все прошло нормально, то вы не получите никакого результата, но будете уведомлены в случае возникновения каких-либо ошибок.
Ну и третий принцип – это использование читаемого текста для обмена как с пользователем, так и между программами.
Данный принцип часто преподносился как недостаток, мол текст архаичен, неудобен и т.д. и т.п.
Но сегодня мы снова видим возврат к тексту, как средству обмена в информационных системах и, хотя вместо плоского текста чаще используются XML или JSON – это снова текст, который одинаково удобно читается как человеком, так и компьютером.
Поэтому говорить о том, что философия UNIX устарела преждевременно, она жива и оказывает сильное воздействие на современные Linux системы. А каждый администратор должен знать ее хотя вы в общих чертах.
Про философию UNIX слышали многие, это некий неформальный свод правил, которым руководствовались первые разработчики UNIX.
Впоследствии данные правила стали использоваться как прямыми наследниками UNIX (Solaris, BSD), так и системами, сделанными по образу и подобию (Linux) и именно следование данной философии позволяет говорить о семействе UNIX-подобных операционных систем.
Для понимания причин возникновения данной философии следует окунуться в исторический контекст разработки UNIX.
Одной из главных задач разработчики видели переносимость, в те годы не существовало универсальной операционной системы, каждый производитель оборудования писал что-то свое, с другим оборудованием несовместимое.
Второй важный аспект – крайняя ограниченность ресурсов, Кен Томпсон изначально писал новую ОС для компьютера PDP-7 оперативная память которого составляла всего 4000 18-битных слов, что оправдывалось предельно низкой ценой данной модели – 72 000$ (711 000$ по нынешнему курсу).
Сегодня компьютеры уже совсем иные и многие вещи, которые волновали разработчиков UNIX уже неактуальны, но философия, заложенная ими в основу системы живет и иногда сбивает с толку современное поколение администраторов.
К написанию данной заметки нас сподвигло то, что уже не раз и не два читатели высказывали свое недоумение или непонимание работы различных Linux программ, которое вытекало как раз из непонимания философии UNIX.
Обычно это касается старых, классических программ и утилит, но также этой философии могут следовать и многие современные службы.
В основе философии UNIX лежит следующий постулат:
Разрабатывайте программы так, чтобы они выполняли только одну задачу, но делали это хорошо, и чтобы они хорошо работали вместе с другими программами.
В те времена это было как нельзя актуально, ограниченность ресурсов не позволяла писать сложные программы, но можно было вызвать последовательно несколько простых программ, которые вместе дали бы требуемый результат.
Но в этом кроется и более глубокий смысл: каждая программа должна делать что-то одно, но делать это хорошо. Простые программы легче поддерживать, в них меньше ошибок и они работают быстрее.
Но это и первая причина недоумения современных администраторов, когда они спрашивают, а умеет ли данная программа это и сильно удивляются, когда им говорят, что нет и нужно дополнительно использовать еще это, это и это.
С другой стороны подобная гибкость позволяет быстро и просто построить именно то, что требуется в данном случае, без оглядки на реализацию в той или иной программе. Когда система построена из простых кубиков гораздо проще заменить один кубик другим, чем сделать это в сложной системе.
Второй важный постулат – правило тишины. Программы по умолчанию не должны ничего говорить (т. е. не выдавать никаких результатов). Это тоже повергает в ступор многих, привыкших к современному информационному шуму и многословию.
Я ввел команду и ничего не произошло… Как так???
На самом деле команда выполнила свое действие, но если все прошло как надо, то зачем об этом говорить? Ведь это же очевидно. И этот принцип продолжает соблюдаться и во многих современных системах.
Например, перезапуск службы. Если все прошло нормально, то вы не получите никакого результата, но будете уведомлены в случае возникновения каких-либо ошибок.
Ну и третий принцип – это использование читаемого текста для обмена как с пользователем, так и между программами.
Данный принцип часто преподносился как недостаток, мол текст архаичен, неудобен и т.д. и т.п.
Но сегодня мы снова видим возврат к тексту, как средству обмена в информационных системах и, хотя вместо плоского текста чаще используются XML или JSON – это снова текст, который одинаково удобно читается как человеком, так и компьютером.
Поэтому говорить о том, что философия UNIX устарела преждевременно, она жива и оказывает сильное воздействие на современные Linux системы. А каждый администратор должен знать ее хотя вы в общих чертах.
Как установить магазин и современные приложения в Windows 11 LTSC
Уж сколько раз твердили миру, что LTSC редакции Windows – это не для повседневной работы и даже не для корпоративного сектора, а для ряда систем (POS-системы, промышленное и медицинское оборудование и т.д. и т.п.), где на первый план выходит стабильность и неизменность кодовой базы, а не все остальное.
👉 Более подробно (пусть и про Windows 10), можно прочитать в нашей статье: Чем является и чем не является Windows 10 LTSB/LTSC
Но кто же читает большие и скучные статьи, особенно если в них написано совсем не то, что хочется прочитать. Так в очередной раз и случилось. Третьего дня один молодой коллега задал нам вопрос – а сталкивались ли мы с Windows 11 LTSC, потому что он поставил ее к себе на ноутбук и ему теперь кажется, что он скачал и поставил что-то не то.
Почему? Да потому что в системе не оказалось ни нового Блокнота, ни новых Ножниц с распознаванием текста, но это мелочи, в системе даже не оказалось нового терминала, к которому коллега привык и отказываться от которого упорно не желал.
Зачем при этом ставить LTSC-редакции оставим за кадром, так как это тема не рациональная, а из разряда религиозных предпочтений, которые, как известно, являются личным делом каждого.
Но с подобной проблемой могут столкнуться и вполне добросовестные пользователи данной системы, получившие ее с оборудованием.
К счастью, поправить эту проблему несложно, причем не прибегая к никаким нештатным методам, кодовая база у всех редакций Windows общая, разница только в доступных по умолчанию компонентах.
Здесь можно пойти двумя путями: сделать все самому руками или воспользоваться готовыми инструментами, которые сделают все тоже самое за нас.
Если вы решили идти по второму пути, то можно воспользоваться готовыми репозиториями на GitHub, например, этим: https://github.com/QuangVNMC/LTSC-Add-Microsoft-Store
Их содержимое практически одинаково – набор необходимых зависимостей и скрипт для их установки. Скрипт простой, читается быстро и просто. Это к тому, что чужие скрипты перед запуском надо все-таки просматривать.
После его запуска в системе появится поддержка магазина и современных приложений, после чего вы можете установить все, чего вам так не хватало хоть через магазин, хоть посредством WinGet или вообще скачав appx с того же Github.
Уж сколько раз твердили миру, что LTSC редакции Windows – это не для повседневной работы и даже не для корпоративного сектора, а для ряда систем (POS-системы, промышленное и медицинское оборудование и т.д. и т.п.), где на первый план выходит стабильность и неизменность кодовой базы, а не все остальное.
👉 Более подробно (пусть и про Windows 10), можно прочитать в нашей статье: Чем является и чем не является Windows 10 LTSB/LTSC
Но кто же читает большие и скучные статьи, особенно если в них написано совсем не то, что хочется прочитать. Так в очередной раз и случилось. Третьего дня один молодой коллега задал нам вопрос – а сталкивались ли мы с Windows 11 LTSC, потому что он поставил ее к себе на ноутбук и ему теперь кажется, что он скачал и поставил что-то не то.
Почему? Да потому что в системе не оказалось ни нового Блокнота, ни новых Ножниц с распознаванием текста, но это мелочи, в системе даже не оказалось нового терминала, к которому коллега привык и отказываться от которого упорно не желал.
Зачем при этом ставить LTSC-редакции оставим за кадром, так как это тема не рациональная, а из разряда религиозных предпочтений, которые, как известно, являются личным делом каждого.
Но с подобной проблемой могут столкнуться и вполне добросовестные пользователи данной системы, получившие ее с оборудованием.
К счастью, поправить эту проблему несложно, причем не прибегая к никаким нештатным методам, кодовая база у всех редакций Windows общая, разница только в доступных по умолчанию компонентах.
Здесь можно пойти двумя путями: сделать все самому руками или воспользоваться готовыми инструментами, которые сделают все тоже самое за нас.
Если вы решили идти по второму пути, то можно воспользоваться готовыми репозиториями на GitHub, например, этим: https://github.com/QuangVNMC/LTSC-Add-Microsoft-Store
Их содержимое практически одинаково – набор необходимых зависимостей и скрипт для их установки. Скрипт простой, читается быстро и просто. Это к тому, что чужие скрипты перед запуском надо все-таки просматривать.
После его запуска в системе появится поддержка магазина и современных приложений, после чего вы можете установить все, чего вам так не хватало хоть через магазин, хоть посредством WinGet или вообще скачав appx с того же Github.
🚀⭐️ Разберётесь, как работают стандартные потоки в Linux и научитесь управлять вводом, выводом и ошибками в терминале
👉 Приглашаем на вебинар: Управление потоками ввода и вывода в Linux
На вебинаре вы узнаете:
— Что такое стандартные потоки ввода, вывода и ошибок
— Как перенаправлять потоки с помощью >, >>, <, 2>, | и других операторов
— Как использовать пайпы (конвейеры) для обработки данных в командной строке
— Как комбинировать команды, управлять выводом и создавать эффективные цепочки
В результате вебинара вы:
— Научитесь различать и использовать stdin, stdout и stderr
— Сможете перенаправлять потоки и использовать их в сценариях автоматизации
— Попробуете строить пайплайны и обрабатывать данные без создания временных файлов
— Поймёте, как вывод ошибок и данных влияет на поведение скриптов и программ.
🎁 Урок пройдет в преддверие старта курса «Administrator Linux. Basic». Все участники вебинара получат скидку на обучение.
👉 Для участия зарегистрируйтесь: https://tglink.io/ba39def24be9?erid=2W5zFJWzFtc
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
👉 Приглашаем на вебинар: Управление потоками ввода и вывода в Linux
На вебинаре вы узнаете:
— Что такое стандартные потоки ввода, вывода и ошибок
— Как перенаправлять потоки с помощью >, >>, <, 2>, | и других операторов
— Как использовать пайпы (конвейеры) для обработки данных в командной строке
— Как комбинировать команды, управлять выводом и создавать эффективные цепочки
В результате вебинара вы:
— Научитесь различать и использовать stdin, stdout и stderr
— Сможете перенаправлять потоки и использовать их в сценариях автоматизации
— Попробуете строить пайплайны и обрабатывать данные без создания временных файлов
— Поймёте, как вывод ошибок и данных влияет на поведение скриптов и программ.
🎁 Урок пройдет в преддверие старта курса «Administrator Linux. Basic». Все участники вебинара получат скидку на обучение.
👉 Для участия зарегистрируйтесь: https://tglink.io/ba39def24be9?erid=2W5zFJWzFtc
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
Блокировка подключения USB-устройств в Linux
USB-устройства – это удобно, подключил и работай, но это серьезная брешь в безопасности. Поэтому многие администраторы задумываются над тем, как ограничить возможность использовать USB-устройства.
Самое простое решение, что называется «в лоб», заблокировать загрузку драйвера usb-storage, для этого выполните:
После чего потребуется перезагрузить устройство. Данный метод заменяет установку драйвера usb-storage командой
При этом кроме USB-накопителей у вас также перестанут работать и USB устройства ввода, такие как клавиатуры или мыши.
Данный способ вполне подойдет для серверов, чтобы уменьшить возможности «шаловливых рук» в случае непосредственного физического доступа к устройствам.
Альтернативой указанному выше способу можно использовать:
Список модулей приведен для систем Debian и Ubuntu, после чего также перезагрузите устройство.
Более гуманным будет запрет на автоматическое монтирование USB-накопителей, после чего это можно будет сделать только вручную и только с правами суперпользователя.
Создадим файл /etc/udev/rules.d/99-usb.rules и внесем в него строку:
Для применения без перезагрузки применяем:
Чтобы разрешить автоматическое монтирование выбранных устройств сначала нам потребуется узнать их серийный номер:
В нашем случае мы узнаем серийный номер устройства sdd, затем добавляем в /etc/udev/rules.d/99-usb.rules строку:
Где в кавычках указываем серийный номер нужного устройства. Таких строк можно добавить несколько.
Данные способы простые и в чем-то даже грубые, но они доступны на любой системе без установки стороннего ПО.
Если же требуется более гибкое управление USВ устройствами, то вам потребуется специализированный софт, например, USBGuard, но это уже тема отдельной заметки.
USB-устройства – это удобно, подключил и работай, но это серьезная брешь в безопасности. Поэтому многие администраторы задумываются над тем, как ограничить возможность использовать USB-устройства.
Самое простое решение, что называется «в лоб», заблокировать загрузку драйвера usb-storage, для этого выполните:
echo "install usb-storage /bin/true" > /etc/modprobe.d/usb-storage.conf
После чего потребуется перезагрузить устройство. Данный метод заменяет установку драйвера usb-storage командой
/bin/true, которая ничего не делает, а только возвращает код успешного завершения операции. При этом кроме USB-накопителей у вас также перестанут работать и USB устройства ввода, такие как клавиатуры или мыши.
Данный способ вполне подойдет для серверов, чтобы уменьшить возможности «шаловливых рук» в случае непосредственного физического доступа к устройствам.
Альтернативой указанному выше способу можно использовать:
echo "blacklist uas" > /etc/modprobe.d/blacklist.conf
echo "blacklist usb-storage" > /etc/modprobe.d/blacklist.conf
Список модулей приведен для систем Debian и Ubuntu, после чего также перезагрузите устройство.
Более гуманным будет запрет на автоматическое монтирование USB-накопителей, после чего это можно будет сделать только вручную и только с правами суперпользователя.
Создадим файл /etc/udev/rules.d/99-usb.rules и внесем в него строку:
ENV{ID_USB_DRIVER}=="usb-storage",ENV{UDISKS_IGNORE}="1"Для применения без перезагрузки применяем:
udevadm control --reload-rules
Чтобы разрешить автоматическое монтирование выбранных устройств сначала нам потребуется узнать их серийный номер:
udevadm info --query=env --name=/dev/sdd | grep ID_SERIAL
В нашем случае мы узнаем серийный номер устройства sdd, затем добавляем в /etc/udev/rules.d/99-usb.rules строку:
ATTRS{serial}=="4079621041319618643",ENV{UDISKS_IGNORE}="0"Где в кавычках указываем серийный номер нужного устройства. Таких строк можно добавить несколько.
Данные способы простые и в чем-то даже грубые, но они доступны на любой системе без установки стороннего ПО.
Если же требуется более гибкое управление USВ устройствами, то вам потребуется специализированный софт, например, USBGuard, но это уже тема отдельной заметки.
Кеширующий прокси или зеркало репозитория?
Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.
По мере роста количества машин под управлением Linux возникает проблема доступа к репозиториям. Например, при обновлении весь парк машин будет многократно выкачивать один и тот же объем трафика.
Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.
Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.
Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.
Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.
В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.
Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.
Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.
Как и любой прокси-сервер он становится посредником между системой и репозиторием и один раз скачав любой пакет помещает его в локальный кеш. При последующих запросах пакет будет уже отдаваться из кеша, без повторного скачивания.
Локальная структура также организуется по принципу репозиториев, с учетом версии системы, архитектуры, источника пакетов и т.д.
Поэтому один кеширующий прокси может без проблем обслуживать любое количество систем и их версий. Никаких настроек при этом делать не надо. Новая система первый раз скачает необходимые файлы из интернета, а остальные получат их уже из локального хранилища.
Потребовался новый пакет или обновление? Аналогично, один раз качаем, остальное получаем локально.
При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.
Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.
Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.
Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu
Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.
По мере роста количества машин под управлением Linux возникает проблема доступа к репозиториям. Например, при обновлении весь парк машин будет многократно выкачивать один и тот же объем трафика.
Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.
Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.
Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.
Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.
В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.
Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.
Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.
Как и любой прокси-сервер он становится посредником между системой и репозиторием и один раз скачав любой пакет помещает его в локальный кеш. При последующих запросах пакет будет уже отдаваться из кеша, без повторного скачивания.
Локальная структура также организуется по принципу репозиториев, с учетом версии системы, архитектуры, источника пакетов и т.д.
Поэтому один кеширующий прокси может без проблем обслуживать любое количество систем и их версий. Никаких настроек при этом делать не надо. Новая система первый раз скачает необходимые файлы из интернета, а остальные получат их уже из локального хранилища.
Потребовался новый пакет или обновление? Аналогично, один раз качаем, остальное получаем локально.
При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.
Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.
Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.
Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu
Как показала практика, не все знают, что такое пакетные менеджеры и с чем их едят. А также путают форматы пакетов, низкоуровневые инструменты по управлению ими и высокоуровневые менеджеры.
Если коротко, то на самом нижем уровне притаились низкоуровневые инструменты вроде
Выше уровнем стоят пакетные менеджеры, которые предоставляют пользователю удобный интерфейс для работы с низкоуровневыми инструментами и ряд дополнительных функций, основная из которых - это разрешение зависимостей, также их задача - это работа с репозиториями.
Пример таких менеджеров - APT, YUM/DNF, Zypper и т.д.
Они не умеют устанавливать и удалять пакеты, и по большому счету им вообще все равно с чем работать. Их задача - найти нужные пакеты, все зависимости к ним, скачать и передать это все на уровень ниже. Либо "доходчиво" пояснить низкоуровневому инструменту чего именно хочет пользователь, скажем удалить или переустановить пакет.
Таким образом у нас имеется два уровня абстракции: низкоуровневый инструмент, который непосредственно работает с пакетами и высокоуровневый менеджер, который предоставляет пользователю удобный инструмент для управления пакетами и ряд дополнительных сервисных функций.
Поэтому не следует удивляться таким проектам, как APT-RPM используемый в ALT Linux, который представляет собой пакетный менеджер APT наученный работать с низкоуровневым rpm, вместо dpkg.
Более подробно почитать на эту тему применительно к Debian/Ubuntu можно в нашей статье: https://interface31.ru/tech_it/2019/09/linux-nachinayushhim-chast-5-upravlenie-paketami.html
Если коротко, то на самом нижем уровне притаились низкоуровневые инструменты вроде
dpkg или rpm, которые умеют работать только с локальными пакетами и не умеют ничего кроме их установки и удаления. Разрешать зависимости тоже не их задача.Выше уровнем стоят пакетные менеджеры, которые предоставляют пользователю удобный интерфейс для работы с низкоуровневыми инструментами и ряд дополнительных функций, основная из которых - это разрешение зависимостей, также их задача - это работа с репозиториями.
Пример таких менеджеров - APT, YUM/DNF, Zypper и т.д.
Они не умеют устанавливать и удалять пакеты, и по большому счету им вообще все равно с чем работать. Их задача - найти нужные пакеты, все зависимости к ним, скачать и передать это все на уровень ниже. Либо "доходчиво" пояснить низкоуровневому инструменту чего именно хочет пользователь, скажем удалить или переустановить пакет.
Таким образом у нас имеется два уровня абстракции: низкоуровневый инструмент, который непосредственно работает с пакетами и высокоуровневый менеджер, который предоставляет пользователю удобный инструмент для управления пакетами и ряд дополнительных сервисных функций.
Поэтому не следует удивляться таким проектам, как APT-RPM используемый в ALT Linux, который представляет собой пакетный менеджер APT наученный работать с низкоуровневым rpm, вместо dpkg.
Более подробно почитать на эту тему применительно к Debian/Ubuntu можно в нашей статье: https://interface31.ru/tech_it/2019/09/linux-nachinayushhim-chast-5-upravlenie-paketami.html
Форматируем раздел как ReFS в Windows 10/11
Файловая система ReFS была представлена в 2012 году и имеет ряд существенных преимуществ над своей предшественницей – NTFS. Также она имеет ряд особенностей и ограничений.
Например, на ReFS не может быть расположен загрузочный том, поэтому установить систему на эту ФС не удастся.
Подробнее обо всем этом можно почитать в первоисточнике: https://learn.microsoft.com/ru-ru/windows-server/storage/refs/refs-overview
Первоначально ReFS была доступна без ограничений как в клиентских, так и серверных выпусках ОС Windows, но это продолжалось недолго.
Начиная с выпуска 1709 в Windows 10 убрали поддержку ReFS для всех редакций кроме Professional for Workstation и Enterprise.
Но убрали ее по-хитрому: просто отключили возможность форматировать разделы в ReFS, сама же поддержка этой файловой системы была сохранена в полноценном виде.
Это, кстати, вполне объяснимо: ломать совместимость для пользователей уже успевших отформатировать диски в ReFS никто не рискнул.
Да и толку от этой затеи немного, поддержка файловых систем реализована на уровне ядра и выпилить ее полностью – задача непростая. А все остальное достаточно легко обходится различными твиками.
В общем Microsoft поступили в своем репертуаре, сначала дали попробовать, потом спрятали.
Но они бы не были собой, если бы с последними обновлениями Windows 11 не случилось второго пришествия ReFS под видом «дисков для разработки», о чем мы писали в дневной заметке.
Однако, если вам нужна ReFS не следует бежать за Windows 11 и срочно обновлять ее. Можно поступить проще.
Энтузиастом создана утилита mkrefs, которая позволяет быстро и просто отформатировать любой том в ReFS в любых выпусках Windows 10 и 11.
Скачать ее можно с репозитория разработчика на Github: https://github.com/0xbadfca11/mkrefs
Чтобы использовать утилиту вам потребуется создать том и присвоить ему букву, можно без форматирования, либо переформатировать уже существующий.
Чтобы получить справку просто запустите утилиту без ключей. В самом простом виде, с параметрами по умолчанию, можем отформатировать том под ReFS так:
Ключ
Также доступны ключи:
▫️
▫️
▫️
Например:
После чего в вашей системе появится диск с файловой системой ReFS который вы сможете полноценно использовать.
Также существует альтернативный способ с правкой реестра, но мы не рекомендуем его использовать, так как после такой правки у некоторых пользователей наблюдались проблемы с пробросом
Файловая система ReFS была представлена в 2012 году и имеет ряд существенных преимуществ над своей предшественницей – NTFS. Также она имеет ряд особенностей и ограничений.
Например, на ReFS не может быть расположен загрузочный том, поэтому установить систему на эту ФС не удастся.
Подробнее обо всем этом можно почитать в первоисточнике: https://learn.microsoft.com/ru-ru/windows-server/storage/refs/refs-overview
Первоначально ReFS была доступна без ограничений как в клиентских, так и серверных выпусках ОС Windows, но это продолжалось недолго.
Начиная с выпуска 1709 в Windows 10 убрали поддержку ReFS для всех редакций кроме Professional for Workstation и Enterprise.
Но убрали ее по-хитрому: просто отключили возможность форматировать разделы в ReFS, сама же поддержка этой файловой системы была сохранена в полноценном виде.
Это, кстати, вполне объяснимо: ломать совместимость для пользователей уже успевших отформатировать диски в ReFS никто не рискнул.
Да и толку от этой затеи немного, поддержка файловых систем реализована на уровне ядра и выпилить ее полностью – задача непростая. А все остальное достаточно легко обходится различными твиками.
В общем Microsoft поступили в своем репертуаре, сначала дали попробовать, потом спрятали.
Но они бы не были собой, если бы с последними обновлениями Windows 11 не случилось второго пришествия ReFS под видом «дисков для разработки», о чем мы писали в дневной заметке.
Однако, если вам нужна ReFS не следует бежать за Windows 11 и срочно обновлять ее. Можно поступить проще.
Энтузиастом создана утилита mkrefs, которая позволяет быстро и просто отформатировать любой том в ReFS в любых выпусках Windows 10 и 11.
Скачать ее можно с репозитория разработчика на Github: https://github.com/0xbadfca11/mkrefs
Чтобы использовать утилиту вам потребуется создать том и присвоить ему букву, можно без форматирования, либо переформатировать уже существующий.
Чтобы получить справку просто запустите утилиту без ключей. В самом простом виде, с параметрами по умолчанию, можем отформатировать том под ReFS так:
mkrefs E: /X Ключ
/X используется для форсирования форматирования, полезно если вы переформатируете уже существующую файловую систему, на которой могут быть открытые файловые дескрипторы.Также доступны ключи:
▫️
/V:label – метка тома, задаем произвольно, при наличии пробелом заключаем в кавычки▫️
/A:{4096 | 64K} – размер блока файловой системы, по умолчанию 4К▫️
/I:{enable | disable} – включение проверки целостности файловой системы, по умолчанию выключеноНапример:
mkrefs E: /X /V:”My ReFS Vol” /A:64K /I:enabledПосле чего в вашей системе появится диск с файловой системой ReFS который вы сможете полноценно использовать.
Также существует альтернативный способ с правкой реестра, но мы не рекомендуем его использовать, так как после такой правки у некоторых пользователей наблюдались проблемы с пробросом
Потоки целостности ReFS – плюсы, минусы и подводные камни
Потоки целостности ReFS – это дополнительная функция файловой системы, которая позволяет осуществлять контроль целостности данных путем использования контрольных сумм. При этом ReFS всегда использует контрольные суммы для метаданных.
Потоки целостности можно включить для файла, директории или тома. По умолчанию они выключены. Потоки целостности наследуются от родительского каталога или корня тома, т.е. включив потоки целостности для каталога вы включите их для всех находящихся в нем файлов и папок.
Как работают потоки целостности? При создании или любом изменении файла для него вычисляется контрольная сумма и записывается в метаданные. При чтении вначале вычисляется контрольная сумма запрошенных данных, затем она сравнивается с сохраненной и, если они совпадают, содержимое отдается запросившему его процессу.
При повреждении данных возможны два варианта действия.
1️⃣ Если ReFS используется на одиночном томе или на Дисковых пространствах без отказоустойчивости, то поврежденный файл блокируется и приложению сообщается об ошибке чтения.
2️⃣ Если используется зеркало или пространства четкости, то ReFS попробует восстановить файл, при успехе приложению будет отдан восстановленный файл, при неудаче – сообщение об ошибке чтения.
Также ReFS имеет собственный скраббер, который позволяет регулярно проводить проверки целостности редко используемых данных.
Проверить состояние потоков целостности для файлов можно командой:
Для всех файлов в каталоге:
Включить потоки целостности можно для файла, каталога или тома:
Вроде бы пока все хорошо и интересно, но есть один неочевидный момент.
Если мы посмотрим в вывод команды
Ну с колонкой
Выше мы говорили, что в случае неудачного восстановления доступ к файлу будет заблокирован. Параметр
🆘 Применительно к ReFS блокировка означает фактическое удаление, так как нет никаких способов разблокировать такой файл.
Это может быть опасно, скажем из-за одной байтовой ошибки у вас может оказаться удален виртуальный диск на десятки и сотни гигабайт. Который можно было спокойно подключить и считать с него данные.
Такое поведение можно выключить, для этого используйте
Но помните, что по умолчанию оно включено для всех объектов тома.
Отключить потоки целостности тоже легко:
Данная технология относится к числу тех, которые не следует применять бездумно, так как это может быть чревато потерей данных.
С другой она же позволит обеспечить лучшую целостность при наличии отказоустойчивости, либо поможет проще справиться с повреждениями диска.
👆В общем – применяйте с умом.
Потоки целостности ReFS – это дополнительная функция файловой системы, которая позволяет осуществлять контроль целостности данных путем использования контрольных сумм. При этом ReFS всегда использует контрольные суммы для метаданных.
Потоки целостности можно включить для файла, директории или тома. По умолчанию они выключены. Потоки целостности наследуются от родительского каталога или корня тома, т.е. включив потоки целостности для каталога вы включите их для всех находящихся в нем файлов и папок.
Как работают потоки целостности? При создании или любом изменении файла для него вычисляется контрольная сумма и записывается в метаданные. При чтении вначале вычисляется контрольная сумма запрошенных данных, затем она сравнивается с сохраненной и, если они совпадают, содержимое отдается запросившему его процессу.
При повреждении данных возможны два варианта действия.
1️⃣ Если ReFS используется на одиночном томе или на Дисковых пространствах без отказоустойчивости, то поврежденный файл блокируется и приложению сообщается об ошибке чтения.
2️⃣ Если используется зеркало или пространства четкости, то ReFS попробует восстановить файл, при успехе приложению будет отдан восстановленный файл, при неудаче – сообщение об ошибке чтения.
Также ReFS имеет собственный скраббер, который позволяет регулярно проводить проверки целостности редко используемых данных.
Проверить состояние потоков целостности для файлов можно командой:
Get-FileIntegrity -FileName H:\Docs\TextDocument.txtДля всех файлов в каталоге:
Get-Item -Path 'C:\Docs\*' | Get-FileIntegrityВключить потоки целостности можно для файла, каталога или тома:
Set-FileIntegrity H:\Docs\TextDocument.txt -Enable $TrueSet-FileIntegrity H:\Docs -Enable $TrueSet-FileIntegrity H:\ -Enable $TrueВроде бы пока все хорошо и интересно, но есть один неочевидный момент.
Если мы посмотрим в вывод команды
Get-FileIntegrity то увидим:FileName Enabled Enforced-------- ------- --------
H:\Docs\TextDocument.txt False True
Ну с колонкой
Enabled – понятно, а вот что такое Enforced?Выше мы говорили, что в случае неудачного восстановления доступ к файлу будет заблокирован. Параметр
Enforced как раз отвечает за блокировку файла.🆘 Применительно к ReFS блокировка означает фактическое удаление, так как нет никаких способов разблокировать такой файл.
Это может быть опасно, скажем из-за одной байтовой ошибки у вас может оказаться удален виртуальный диск на десятки и сотни гигабайт. Который можно было спокойно подключить и считать с него данные.
Такое поведение можно выключить, для этого используйте
Set-FileIntegrity H:\Docs\TextDocument.txt -Enforce $FalseНо помните, что по умолчанию оно включено для всех объектов тома.
Отключить потоки целостности тоже легко:
Set-FileIntegrity H:\Docs\TextDocument.txt -Enable $FalseДанная технология относится к числу тех, которые не следует применять бездумно, так как это может быть чревато потерей данных.
С другой она же позволит обеспечить лучшую целостность при наличии отказоустойчивости, либо поможет проще справиться с повреждениями диска.
👆В общем – применяйте с умом.
Трансформация цифровых продуктов
На заре формирования рынка программного обеспечения приобретаемая вами программа рассматривалась как еще одна вещь, такая же как ботинки, штаны или бутылка пива.
Действительно, в ту пору передать экземпляр ПО можно было в основном только физическим способом, на некотором физическом носителе, после чего вы становились его владельцем и никакого простого способа лишить вас права владения им не было.
Но в отличие от штанов ПО, как и любой другой цифровой контент, обладало одной интересной особенностью – его можно скопировать.
Купив штаны, вы, конечно, можете одолжить их другу, но тогда у вас самих штанов уже не будет. Поэтому на вечеринку в модных штанах пойдет кто-то один, либо каждому придется раскошелиться на собственный экземпляр штанов.
Клонировать программу мы можем бесчисленное количество раз, причем без всякого ухудшения ее качества. Что и послужило причиной появления такого явления как компьютерное пиратство.
И не нужно лукавить, что несанкционированное копирование – это не тоже самое, что кража штанов из магазина. Ведь ни у продавца, ни у производителя ничего не убавилось…
На самом деле это не так, как производство штанов, так и производство программного обеспечения имеет расходы, как прямые, так и косвенные.
Покупая штаны, вы оплачиваете не только ткань, но и расходы на их производство (амортизация оборудования, зарплаты персонала и т.д. и т.п.) , однако благодаря объему эти затраты размазаны на всю партию тонким слоем и не обременительны для покупателя.
То же самое и с цифровыми продуктами, нельзя говорить, что цифровой экземпляр ничего не стоит, ну или имеет цену носителя, на который записан. Его разработка и поддержка стоит денег, а привлекательная цена основана на предположении что будет продан определенный тираж.
Каждая несанкционированная копия – это фактический убыток. Так как затраты вы уже понесли, а прибыли до сих пор не получили.
Но контролировать физические копии практически невозможно, особенно если владелец «честно» ею поделился, вместе с ключом для установки.
Поэтому, как только интернет перестал быть роскошью, а стал повседневной обыденностью производители ПО перешли к различным онлайн-способам проверки легальности владения экземпляром программы.
Первой ласточкой стал механизм активации, который предусматривал блокировку основных возможностей программы если она не прошла онлайн-проверку законности владения.
По мере развития сетевых возможностей и расширения каналов передачи данных появилась возможность онлайн-доставки контента, что позволило не передавать покупателю лицензии физический экземпляр программы, а устанавливать его онлайн.
Это уже сужало возможные злоупотребления, но все еще давало в руки пользователя автономную копию продукта, которую он, при желании и умении, мог перенести на другой ПК без приобретения нового экземпляра.
Следующий шаг – это подписная модель, когда ПО не продается, а сдается в аренду на основе небольших ежемесячных платежей.
Из плюсов – доступность, если раньше какой-то профессиональный пакет был вам просто финансово недоступен, то теперь вы можете использовать его всего лишь за небольшую месячную оплату.
Минусы также очевидны – вы не владеете даже локальной копией продукта и полностью завязаны на внешние сервисы. Со всеми вытекающими. Если производителю что-то не понравится, то он может просто отключить вас от своих серверов и вы останетесь у разбитого корыта.
Еще хуже, если там хранятся ваши данные, и локальная копия так же контролируется приложением.
Облака, не так давно это было модно. Вам не нужны собственные мощности, вам не нужны собственные сотрудники, просто оплати тариф…
Сегодня идет обратная волна, отказа от облаков в пользу self-hosted, но это не про деньги и затраты, а про право владения.
Производителей ПО можно понять, но сегодня ситуация сильно перекошена в их сторону, когда пользователь покупает некое эфемерное право и ничем не защищен.
Но потребитель голосует кошельком, поэтому поживем – увидим. Рынок – это всегда баланс и компромисс.
На заре формирования рынка программного обеспечения приобретаемая вами программа рассматривалась как еще одна вещь, такая же как ботинки, штаны или бутылка пива.
Действительно, в ту пору передать экземпляр ПО можно было в основном только физическим способом, на некотором физическом носителе, после чего вы становились его владельцем и никакого простого способа лишить вас права владения им не было.
Но в отличие от штанов ПО, как и любой другой цифровой контент, обладало одной интересной особенностью – его можно скопировать.
Купив штаны, вы, конечно, можете одолжить их другу, но тогда у вас самих штанов уже не будет. Поэтому на вечеринку в модных штанах пойдет кто-то один, либо каждому придется раскошелиться на собственный экземпляр штанов.
Клонировать программу мы можем бесчисленное количество раз, причем без всякого ухудшения ее качества. Что и послужило причиной появления такого явления как компьютерное пиратство.
И не нужно лукавить, что несанкционированное копирование – это не тоже самое, что кража штанов из магазина. Ведь ни у продавца, ни у производителя ничего не убавилось…
На самом деле это не так, как производство штанов, так и производство программного обеспечения имеет расходы, как прямые, так и косвенные.
Покупая штаны, вы оплачиваете не только ткань, но и расходы на их производство (амортизация оборудования, зарплаты персонала и т.д. и т.п.) , однако благодаря объему эти затраты размазаны на всю партию тонким слоем и не обременительны для покупателя.
То же самое и с цифровыми продуктами, нельзя говорить, что цифровой экземпляр ничего не стоит, ну или имеет цену носителя, на который записан. Его разработка и поддержка стоит денег, а привлекательная цена основана на предположении что будет продан определенный тираж.
Каждая несанкционированная копия – это фактический убыток. Так как затраты вы уже понесли, а прибыли до сих пор не получили.
Но контролировать физические копии практически невозможно, особенно если владелец «честно» ею поделился, вместе с ключом для установки.
Поэтому, как только интернет перестал быть роскошью, а стал повседневной обыденностью производители ПО перешли к различным онлайн-способам проверки легальности владения экземпляром программы.
Первой ласточкой стал механизм активации, который предусматривал блокировку основных возможностей программы если она не прошла онлайн-проверку законности владения.
По мере развития сетевых возможностей и расширения каналов передачи данных появилась возможность онлайн-доставки контента, что позволило не передавать покупателю лицензии физический экземпляр программы, а устанавливать его онлайн.
Это уже сужало возможные злоупотребления, но все еще давало в руки пользователя автономную копию продукта, которую он, при желании и умении, мог перенести на другой ПК без приобретения нового экземпляра.
Следующий шаг – это подписная модель, когда ПО не продается, а сдается в аренду на основе небольших ежемесячных платежей.
Из плюсов – доступность, если раньше какой-то профессиональный пакет был вам просто финансово недоступен, то теперь вы можете использовать его всего лишь за небольшую месячную оплату.
Минусы также очевидны – вы не владеете даже локальной копией продукта и полностью завязаны на внешние сервисы. Со всеми вытекающими. Если производителю что-то не понравится, то он может просто отключить вас от своих серверов и вы останетесь у разбитого корыта.
Еще хуже, если там хранятся ваши данные, и локальная копия так же контролируется приложением.
Облака, не так давно это было модно. Вам не нужны собственные мощности, вам не нужны собственные сотрудники, просто оплати тариф…
Сегодня идет обратная волна, отказа от облаков в пользу self-hosted, но это не про деньги и затраты, а про право владения.
Производителей ПО можно понять, но сегодня ситуация сильно перекошена в их сторону, когда пользователь покупает некое эфемерное право и ничем не защищен.
Но потребитель голосует кошельком, поэтому поживем – увидим. Рынок – это всегда баланс и компромисс.
Ценообразование на ПО и подписки
Постоянно, как только речь заходит о ценах на ПО, в комментариях появляются мнения, что экземпляр ПО ничего не стоит и его пиратство не может нанести разработчику материального ущерба.
На самом деле это не так, ПО как любой материальный предмет или нематериальная работа или услуга стоит денег. Как минимум тех, которые были потрачены на его разработку. И даже если разработчик занимается этим один, то ему все равно нужно питаться, одеваться, содержать семью, оплачивать счета.
И неважно чем он занимается, пишет ПО или печет пирожки. Все эти затраты так или иначе относятся на себестоимость, вне зависимости от материальности результата труда.
А дальше считаем. Допустим затраты на разработку составили 3 млн. руб., примерная аудитория оценивается нами как 1000 человек. Отсюда выводим себестоимость экземпляра программы в 3 000 руб., но мы же должны еще что-то заработать, а также поддерживать и развивать программу.
Оцениваем свою прибыль в 1 млн. руб. и затраты на дальнейшую поддержку и развитие как 2 млн. руб. Итого цена одной лицензии составит 6 000 руб. Продали больше – хорошо, а вот меньше – уже не очень. Потому что придется или затягивать пояс самим разработчикам, или экономить на поддержке и развитии.
Ну да ладно, будем считать, что план мы выполнили и будущее видится светлым и безоблачным. Но на самом деле проблемы только начинаются. Классический подход с оплатой за лицензию без дополнительных платежей сегодня не работает.
Почему? Давайте разбираться. Классическая бизнес-модель предусматривала продажу лицензий на некий продукт с достаточно коротким жизненным сроком. До 5 лет. И без какого-либо развития.
Вы оплачиваете лицензию и получаете некоторый законченный продукт, а также несколько пакетов исправлений к нему в течении жизненного цикла, причем такие пакеты могут выходить раз в полгода-год и это считалось нормальным.
Никакого развития и новых функций в продукте также не предусматривалось, так как все это предназначалось для новой версии продукта, которую надо приобретать заново, пусть и со скидкой для пользователей старой версии.
Такие новые релизы выходили раз в два-три года и ставили пользователя перед непростым выбором: нужны ли ему новые функции настолько, что нужно покупать новую версию или можно еще посидеть на старой.
Сегодня эта модель давно канула в лету, потому что исправления нужные еще вчера, а новые функции должны добавляться постоянно. И выход новой мажорной версии сегодня это чаще некоторое маркетинговое действие, нежели переход на что-то принципиально новое.
Бывает вообще очень тяжело понять, чем именно версия 2.0 отличается от 1.9, поэтому очень многие разработчики перешли на нумерацию по датам, скажем, 25.4 – релиз от апреля 25 года. Все просто и понятно. А также сразу видна актуальность ПО, потому что программу, последний релиз которой был в прошлом году многие будут рассматривать как устаревшую.
И вот тут появляется проблема – за чей счет весь этот банкет? В нашем примере разработчикам хватит средств только на первый год поддержки и сопровождения. А дальше что? Продавать новый мажорный релиз? А кто его купит? Особенно если отличий от текущего там кот наплакал?
Приберечь изменения для релиза? Так конкуренты обойдут, у которых все это уже будет. Как быть?
А выход тут только один – обеспечить постоянный приток денежных средств. Способ для этого есть только один – подписка. Берем ту же самую сумму и делим ее на регулярные платежи, 6000 руб. в год – это 500 руб./мес. Сумма крайне небольшая и необременительная.
При этом меняем бизнес-модель таким образом, чтобы на подписку были завязаны некоторые важные, но не основные функции, чтобы пользователь мог использовать ПО и без подписки. Чем сразу расширяем клиентскую базу и уменьшаем уровень пиратства, особенно если подписные функции завязать на онлайн.
В результате приходим к современной модели – базовые возможности бесплатно, обновления бесплатно, расширенные функции по подписке. И полный переход на нее – дело времени.
Постоянно, как только речь заходит о ценах на ПО, в комментариях появляются мнения, что экземпляр ПО ничего не стоит и его пиратство не может нанести разработчику материального ущерба.
На самом деле это не так, ПО как любой материальный предмет или нематериальная работа или услуга стоит денег. Как минимум тех, которые были потрачены на его разработку. И даже если разработчик занимается этим один, то ему все равно нужно питаться, одеваться, содержать семью, оплачивать счета.
И неважно чем он занимается, пишет ПО или печет пирожки. Все эти затраты так или иначе относятся на себестоимость, вне зависимости от материальности результата труда.
А дальше считаем. Допустим затраты на разработку составили 3 млн. руб., примерная аудитория оценивается нами как 1000 человек. Отсюда выводим себестоимость экземпляра программы в 3 000 руб., но мы же должны еще что-то заработать, а также поддерживать и развивать программу.
Оцениваем свою прибыль в 1 млн. руб. и затраты на дальнейшую поддержку и развитие как 2 млн. руб. Итого цена одной лицензии составит 6 000 руб. Продали больше – хорошо, а вот меньше – уже не очень. Потому что придется или затягивать пояс самим разработчикам, или экономить на поддержке и развитии.
Ну да ладно, будем считать, что план мы выполнили и будущее видится светлым и безоблачным. Но на самом деле проблемы только начинаются. Классический подход с оплатой за лицензию без дополнительных платежей сегодня не работает.
Почему? Давайте разбираться. Классическая бизнес-модель предусматривала продажу лицензий на некий продукт с достаточно коротким жизненным сроком. До 5 лет. И без какого-либо развития.
Вы оплачиваете лицензию и получаете некоторый законченный продукт, а также несколько пакетов исправлений к нему в течении жизненного цикла, причем такие пакеты могут выходить раз в полгода-год и это считалось нормальным.
Никакого развития и новых функций в продукте также не предусматривалось, так как все это предназначалось для новой версии продукта, которую надо приобретать заново, пусть и со скидкой для пользователей старой версии.
Такие новые релизы выходили раз в два-три года и ставили пользователя перед непростым выбором: нужны ли ему новые функции настолько, что нужно покупать новую версию или можно еще посидеть на старой.
Сегодня эта модель давно канула в лету, потому что исправления нужные еще вчера, а новые функции должны добавляться постоянно. И выход новой мажорной версии сегодня это чаще некоторое маркетинговое действие, нежели переход на что-то принципиально новое.
Бывает вообще очень тяжело понять, чем именно версия 2.0 отличается от 1.9, поэтому очень многие разработчики перешли на нумерацию по датам, скажем, 25.4 – релиз от апреля 25 года. Все просто и понятно. А также сразу видна актуальность ПО, потому что программу, последний релиз которой был в прошлом году многие будут рассматривать как устаревшую.
И вот тут появляется проблема – за чей счет весь этот банкет? В нашем примере разработчикам хватит средств только на первый год поддержки и сопровождения. А дальше что? Продавать новый мажорный релиз? А кто его купит? Особенно если отличий от текущего там кот наплакал?
Приберечь изменения для релиза? Так конкуренты обойдут, у которых все это уже будет. Как быть?
А выход тут только один – обеспечить постоянный приток денежных средств. Способ для этого есть только один – подписка. Берем ту же самую сумму и делим ее на регулярные платежи, 6000 руб. в год – это 500 руб./мес. Сумма крайне небольшая и необременительная.
При этом меняем бизнес-модель таким образом, чтобы на подписку были завязаны некоторые важные, но не основные функции, чтобы пользователь мог использовать ПО и без подписки. Чем сразу расширяем клиентскую базу и уменьшаем уровень пиратства, особенно если подписные функции завязать на онлайн.
В результате приходим к современной модели – базовые возможности бесплатно, обновления бесплатно, расширенные функции по подписке. И полный переход на нее – дело времени.
Нативная реклама, ожидания и реальность
Реклама бывает разная, но как бы к ней не относились – именно реклама является двигателем торговли. Сам не раз и не два находил в рекламе что-то интересное и покупал если не эту позицию, то что-то аналогичное.
Нативная реклама – отдельный вид рекламы, когда реклама выходит в качестве персонализированного отзыва или рекомендации от некого конкретного лица, пользующегося определенным доверием у аудитории.
Нативная реклама эффективна, но и недешева. Мы тоже иногда размещаем такую рекламу, но всегда сами перед этим тестируем рекламируемый продукт и пишем отзывы честно. Устраивает это не всех, плюс долго и дорого. Но по-другому тут быть и не может, так как на кону стоят не только деньги, но и репутация.
Последнее время все чаще стала попадаться реклама БАД MindBooster, звезд с неба не обещали, но делали упор на концентрацию, работоспособность, внимание и прочие плюшки для умственной деятельности в режиме хронических переработок, стресса и т.д. и т.п.
БАДы – штука такая, сложная, во многом индивидуальная, много и пустых обещаний, благо всегда можно сослаться на индивидуальные особенности и отсутствие прямых обещаний.
MindBooster – штука дорогая, мне упаковка на 40 капсул обошлась в 2 230 руб. или 112 руб. за один прием, так как глотать надо сразу по две капсулы. Упаковки хватает на три недели, я честно пропил две.
И? Эффекта ровно ноль, вообще никакого! Ни бодрости, ни концентрации, ни мотивации. Ничего из того, о чем распинались рекламирующие товарищи и что написано на упаковке.
Ну так это же БАДы, скажет кто-то, чего ты хотел. Ну чего-то хотел. Я давно покупаю другой БАД, который справа на рисунке. Который Женьшень-Таурин, 396 рублей за 60 капсул, или 7 рублей за прием.
Состав там прост и незамысловат, примерно тоже самое можно прочитать на банке энергетика. Эффект быстрый и аналогичный, но довольно мягкий, без скачков пульса и давления.
Хорошо бодрит с утра, примерно, как чашка кофе или банка энергетика. Эффект держится часа четыре. Что полностью соответствует ТТХ действующих веществ. Начинает клонить в сон после обеда – можно еще капсулу закинуть. В дороге тоже полезно, чтобы не спать за рулем.
В общем данный БАД работает и цену свою отбивает полностью.
А тут? Может пропил его мало, надо подольше? Но давайте почитаем состав. Кроме непонятных DMAE и Бакопа Монье все остальное вещества привычные и понятные, с коротким сроком действия.
Для большинства из них срок полувыведения – это часы, а полный вывод из организма – сутки или чуть больше. При этом ни одно их этих веществ не накапливается, а излишки выводятся с мочой. Т.е. никакого эффекта накопления тут нет и быть не может.
Ну так кому-то же помогает? Возможно. Во-первых, никто не отменял эффект плацебо, особенно после того, как вы заплатили более 2 тыс. руб. за баночку и полностью в ожидании чуда.
Во-вторых, вам действительно могло не хватать некоторых витаминов и тут вы просто «угадали» состав. Другое дело, что сделать это можно проще и дешевле. Достаточно купить мультивитаминный комплекс в ближайшей аптеке.
Но, опять-таки повторюсь, в некоторых сценариях, когда у человека есть явный недостаток витаминов или какие-то сопутствующие проблемы психосоматического характера, то пропить даже такой БАД будет полезно и будет определенный эффект.
Если же мы говорим о человеке, который сбалансированно питается и не испытывает психосоматических расстройств, то попытка как-то повысить производительность или обмануть природу в рамках соблюдения баланса труда и отдыха путем приема внутрь данного БАД (и не только данного) ожидаемого успеха не принесет.
Да и откуда ему тут взяться, это не психоактивное вещество, а безрецептурная добавка к пище. Просто травки и витаминки. В заведомо безопасных дозах.
Поэтому, как бы не хотелось, чудес не бывает. А хотите эффекта – берите БАДы попроще, с более понятным составом и понятным эффектом.
Как тот же Женьшень-Таурин, хотя и тут надо понимать, что это не про здоровый образ жизни, а про еще один пинок организму.
Реклама бывает разная, но как бы к ней не относились – именно реклама является двигателем торговли. Сам не раз и не два находил в рекламе что-то интересное и покупал если не эту позицию, то что-то аналогичное.
Нативная реклама – отдельный вид рекламы, когда реклама выходит в качестве персонализированного отзыва или рекомендации от некого конкретного лица, пользующегося определенным доверием у аудитории.
Нативная реклама эффективна, но и недешева. Мы тоже иногда размещаем такую рекламу, но всегда сами перед этим тестируем рекламируемый продукт и пишем отзывы честно. Устраивает это не всех, плюс долго и дорого. Но по-другому тут быть и не может, так как на кону стоят не только деньги, но и репутация.
Последнее время все чаще стала попадаться реклама БАД MindBooster, звезд с неба не обещали, но делали упор на концентрацию, работоспособность, внимание и прочие плюшки для умственной деятельности в режиме хронических переработок, стресса и т.д. и т.п.
БАДы – штука такая, сложная, во многом индивидуальная, много и пустых обещаний, благо всегда можно сослаться на индивидуальные особенности и отсутствие прямых обещаний.
MindBooster – штука дорогая, мне упаковка на 40 капсул обошлась в 2 230 руб. или 112 руб. за один прием, так как глотать надо сразу по две капсулы. Упаковки хватает на три недели, я честно пропил две.
И? Эффекта ровно ноль, вообще никакого! Ни бодрости, ни концентрации, ни мотивации. Ничего из того, о чем распинались рекламирующие товарищи и что написано на упаковке.
Ну так это же БАДы, скажет кто-то, чего ты хотел. Ну чего-то хотел. Я давно покупаю другой БАД, который справа на рисунке. Который Женьшень-Таурин, 396 рублей за 60 капсул, или 7 рублей за прием.
Состав там прост и незамысловат, примерно тоже самое можно прочитать на банке энергетика. Эффект быстрый и аналогичный, но довольно мягкий, без скачков пульса и давления.
Хорошо бодрит с утра, примерно, как чашка кофе или банка энергетика. Эффект держится часа четыре. Что полностью соответствует ТТХ действующих веществ. Начинает клонить в сон после обеда – можно еще капсулу закинуть. В дороге тоже полезно, чтобы не спать за рулем.
В общем данный БАД работает и цену свою отбивает полностью.
А тут? Может пропил его мало, надо подольше? Но давайте почитаем состав. Кроме непонятных DMAE и Бакопа Монье все остальное вещества привычные и понятные, с коротким сроком действия.
Для большинства из них срок полувыведения – это часы, а полный вывод из организма – сутки или чуть больше. При этом ни одно их этих веществ не накапливается, а излишки выводятся с мочой. Т.е. никакого эффекта накопления тут нет и быть не может.
Ну так кому-то же помогает? Возможно. Во-первых, никто не отменял эффект плацебо, особенно после того, как вы заплатили более 2 тыс. руб. за баночку и полностью в ожидании чуда.
Во-вторых, вам действительно могло не хватать некоторых витаминов и тут вы просто «угадали» состав. Другое дело, что сделать это можно проще и дешевле. Достаточно купить мультивитаминный комплекс в ближайшей аптеке.
Но, опять-таки повторюсь, в некоторых сценариях, когда у человека есть явный недостаток витаминов или какие-то сопутствующие проблемы психосоматического характера, то пропить даже такой БАД будет полезно и будет определенный эффект.
Если же мы говорим о человеке, который сбалансированно питается и не испытывает психосоматических расстройств, то попытка как-то повысить производительность или обмануть природу в рамках соблюдения баланса труда и отдыха путем приема внутрь данного БАД (и не только данного) ожидаемого успеха не принесет.
Да и откуда ему тут взяться, это не психоактивное вещество, а безрецептурная добавка к пище. Просто травки и витаминки. В заведомо безопасных дозах.
Поэтому, как бы не хотелось, чудес не бывает. А хотите эффекта – берите БАДы попроще, с более понятным составом и понятным эффектом.
Как тот же Женьшень-Таурин, хотя и тут надо понимать, что это не про здоровый образ жизни, а про еще один пинок организму.
