А ведь всего лишь надо было поднять своё отказоустойчивое облако и постепенно перемещать узлы, на котором оно работает в него же. А когда последний узел переедет, железо можно будет выключить.
Многие из этих задач можно решить на уровне блочного устройства, практически без содействия драйвера файловой системы. Точно ли этот набор потребностей достаточен для переезда с ext4 на btrfs?
Если бы меня спросили, почему стоит использовать btrfs, я бы вспомнил про btrfs send.
Например для того, чтобы оттранслировать существующий C-проект, а потом, постепенно, переписывать его части, используя возможности Rust. Как режим BetterC в D.
Часто возникает соблазн внедрить свой код в чужой файл без какой бы то нибыло его модификации.
Самый простой способ: создать процесс с чужим кодом с помощью CreateProcess()с dwCreationFlags=CREATE_SUSPENDED, а затем выделить новую страницу памяти (VirtualAllocEx с hProcess и flAllocationType=MEM_COMMIT|MEM_RESERVE), потом WriteProcessMemory запишет в неё имя нашей DLL. И останется только запустить ещё один поток (CreateRemoteThread), который вызовет LoadLibrary. Сложности будут, если чужой код собран под 32-битную архитектуру, а внедряющая программа - под 64 бита, но это тоже решаемо. И в конце останется только разбудить чужой процесс (ResumeThread).
В Arch Linux основной пакетный менеджер, pacman, работает как раз с бинарными пакетами. Но обмениваться ими проблематично как раз из-за того, что это rolling release, и пакеты собираются под самые свежие версии зависимостей. Рецепты (их обычно берут из AUR) - это файлы PKGBUILD, из которых makepkg делает пакеты.
Чтобы обмен бинарными пакетами был возможен, все должны либо всегда обновляться на самые свежие версии всего, либо договориться сделать срез зеркала на какой-то момент времени (фактически "отвести релиз") и собирать всё остальное против зависимостей из этого среза.
В Debian и Slackware такой проблемы не будет из-за существования релизов, а в NixOS и Guix ещё и из-за возможности установить новую программу с новыми зависимостями, не обновляя их для старых программ - в последних можно жить как с релизами, так и без.
Пока писал этот комментарий, захотел посмотреть, как у Guix с разнообразием пакетов и частотой релизов, но обнаружил, что не могу из России подключиться к https://guix.gnu.org/
Arch Linux не выглядит хорошим вариантом. В нём rolling release, нет возможности установить предыдущую версию пакета с зеркала и одновременно с этим не поддерживаются частичные обновления. Попробуйте не обновлять систему полгода, а потом установить какую-нибудь программу из бинарного репозитория - скорее всего, она не запустится, так как не найдёт нужную версию какой-нибудь библиотеки (а раз частичные обновления не поддерживаются, то авторы пакета не будут утруждать себя указанием правильных версий зависимостей в метаданных).
Ubuntu или Debian выглядят в этом плане несколько лучше. Можно установить систему релизной версии (не unstable/sid), затем доставить что-нибудь новое из -updates или -backports, а если что-то пойдёт не так, то стандартными средствами откатиться на прежнюю версию пакета: apt install PKGNAME=1.0.24. Проблема только в инструментах, которые используются для поддержки репозиториев - самые популярные из них (в том числе и тот, что используют в самом проекте) не позволяют залить несколько версий одного пакета в один репозиторий - в этом случае "побеждает" максимальная версия. Но ни в apt, ни в форматах метаинформации такой проблемы нет - используя другие инструменты, можно создать репозиторий, где будет лежать, например, до пяти последних версий каждого пакета.
Gentoo - ещё лучше. В portage лежат только рецепты для сборки пакетов (ebuilds), а многие зеркала отдают дельты изменений и поддерживают rsync - значит получится, потратив мало трафика, иметь всегда актуальную версию portage. Старые версии пакетов оттуда удаляют не сразу, а сломанные маскируют вместо удаления, что даёт пользователю возможность откатиться (даже на заведомо уязвимую версию, если пользователь будет настаивать). Rolling release, но поддерживается частичное обновление (в рамках одной версии EAPI). Для сборки потребуются distfiles (исходники), и именно они займут больше всего места, но portage не навязывает какой-то определённый источник, а сами ebuild содержат ещё и ссылки на upstream, откуда можно скачать исходник. Для проверки целостности в portage лежат хэш-суммы всего, что требуется для сборки. Из недостатков - придётся компилировать исходники, но для крупных пакетов (libreoffice, firefox, chromium) есть готовые бинарные сборки. Если использовать в рамках организации, то можно держать свой binhost для того, чтобы избежать повторной сборки на всех узлах.
И стоит рассмотреть NixOS. Можно обмениваться кусками /nix/store, разработчики системы сильно продвинулись в достижении цели полной воспроизводимости сборки, окружения получаются гораздо более герметичными. Переход от input-addressable к content-addressable должен сократить ненужные скачивания при обновлении зависимостей. Число готовых пакетов сравнимо с Debian, более 80000. Из недостатков - очень отличается от привычных систем подходом к управлению пакетами, структурой директорий.
Утекать может и место на диске. Наверняка у вас где-нибудь в $HOME/.config/ и $HOME/.local/share/ есть целые директории, которые созданы программами, которые больше не установлены в системе. И ошибки тоже могут накапливаться (хотя и с меньшей вероятностью, так как кода, меняющего персистентное состояние меньше), если они являются частью персистентного состояния - чтобы бороться с этой проблемой, Firefox при восстановлении после сбоя каждый раз спрашивает, хочет ли пользователь восстановить ранее открытые вкладки.
Если у программы есть два места, в которых хранится состояние - персистентное (диск) и оперативное (регистры, память, состояние объектов ОС), то программисту каждой такой программы придётся заботится о явной синхронизации этих мест. Ошибки её реализации возникают настолько часто, что у спидраннеров есть даже специальный термин - save/load abuse.
Это ещё проще. Достаточно сделать язык, в котором нельзя сказать "я видел НЛО" или "я слышу барабашек", а лишь "я наблюдаю странное перемещение источника света своими глазами, и если работа моего организма не нарушена, то по моему скромному мнению это может быть свидетельством существования инопланетной цивилизации" и "я слышу звук, но не понимаю, что является его источником; учитывая тот факт, что я недостаточно скептически отношусь к написанному в книге «былички и рассказы о НЛО», приму за рабочую гипотезу, что его источником являются барабашки". То есть не давать возможности носителю языка обобщать явление без явного указания на субъективность такого суждения и/или источник информации. А выдавать свои наблюдения за общий консенсус можно вовсе запретить.
Даже если один индивид допустит ошибку из-за сбоя в работе организма, другой будет ретранслировать полученную от него информацию, как подлежащую сомнению - "мой друг вчера сказал мне, что по его мнению он видел НЛО" вместо "здесь видели НЛО вчера".
Достаточно помнить 10²=100. (x+1)²=x²+x+(x+1), значит 10²+11²+12²+13²+14² = 100+100+100+100+100+(10+11)+(10+11)+(10+11)+(10+11)+(11+12)+(11+12)+(11+12)+(12+13)+(12+13)+(13+14) = 500+21*4+23*3+25*2+27 = 527+84+69+50=577+84+69 = 576+84+70 = 646+84 = 650+80 = 730
А ведь всего лишь надо было поднять своё отказоустойчивое облако и постепенно перемещать узлы, на котором оно работает в него же. А когда последний узел переедет, железо можно будет выключить.
Если плата позволяет безопасно подключить клавиатуру "на горячую", то можно это сделать и нажать F1.
ПКЫ? Только совершенно не помню, откуда и почему я это знаю.
Интересно, что очень похожая программа компилируется без проблем:
А документ о правах на недвижимость приравнять к ROA, чтобы адреса могли получить и (суб)арендаторы, например, отдельных комнат?
Многие из этих задач можно решить на уровне блочного устройства, практически без содействия драйвера файловой системы. Точно ли этот набор потребностей достаточен для переезда с ext4 на btrfs?
Если бы меня спросили, почему стоит использовать btrfs, я бы вспомнил про btrfs send.
Например для того, чтобы оттранслировать существующий C-проект, а потом, постепенно, переписывать его части, используя возможности Rust. Как режим BetterC в D.
В Linux можно открыть на запись /dev/vcs и писать туда любые символы, включая управляющие - они не будут интерпретироваться драйвером терминала.
Самый простой способ: создать процесс с чужим кодом с помощью
CreateProcess()сdwCreationFlags=CREATE_SUSPENDED, а затем выделить новую страницу памяти (VirtualAllocExсhProcessиflAllocationType=MEM_COMMIT|MEM_RESERVE), потомWriteProcessMemoryзапишет в неё имя нашей DLL. И останется только запустить ещё один поток (CreateRemoteThread), который вызоветLoadLibrary. Сложности будут, если чужой код собран под 32-битную архитектуру, а внедряющая программа - под 64 бита, но это тоже решаемо. И в конце останется только разбудить чужой процесс (ResumeThread).Это char-rnn или BERT?
Windows 10 Mobile это не Windows Mobile, о чём упоминается в Википедии:
Так что в статье этот момент описан верно.
В Arch Linux основной пакетный менеджер, pacman, работает как раз с бинарными пакетами. Но обмениваться ими проблематично как раз из-за того, что это rolling release, и пакеты собираются под самые свежие версии зависимостей. Рецепты (их обычно берут из AUR) - это файлы PKGBUILD, из которых makepkg делает пакеты.
Чтобы обмен бинарными пакетами был возможен, все должны либо всегда обновляться на самые свежие версии всего, либо договориться сделать срез зеркала на какой-то момент времени (фактически "отвести релиз") и собирать всё остальное против зависимостей из этого среза.
В Debian и Slackware такой проблемы не будет из-за существования релизов, а в NixOS и Guix ещё и из-за возможности установить новую программу с новыми зависимостями, не обновляя их для старых программ - в последних можно жить как с релизами, так и без.
Пока писал этот комментарий, захотел посмотреть, как у Guix с разнообразием пакетов и частотой релизов, но обнаружил, что не могу из России подключиться к https://guix.gnu.org/
Нисколько, на него можно поставить chromium-bin.
Arch Linux не выглядит хорошим вариантом. В нём rolling release, нет возможности установить предыдущую версию пакета с зеркала и одновременно с этим не поддерживаются частичные обновления. Попробуйте не обновлять систему полгода, а потом установить какую-нибудь программу из бинарного репозитория - скорее всего, она не запустится, так как не найдёт нужную версию какой-нибудь библиотеки (а раз частичные обновления не поддерживаются, то авторы пакета не будут утруждать себя указанием правильных версий зависимостей в метаданных).
Ubuntu или Debian выглядят в этом плане несколько лучше. Можно установить систему релизной версии (не unstable/sid), затем доставить что-нибудь новое из -updates или -backports, а если что-то пойдёт не так, то стандартными средствами откатиться на прежнюю версию пакета:
apt install PKGNAME=1.0.24. Проблема только в инструментах, которые используются для поддержки репозиториев - самые популярные из них (в том числе и тот, что используют в самом проекте) не позволяют залить несколько версий одного пакета в один репозиторий - в этом случае "побеждает" максимальная версия. Но ни в apt, ни в форматах метаинформации такой проблемы нет - используя другие инструменты, можно создать репозиторий, где будет лежать, например, до пяти последних версий каждого пакета.Gentoo - ещё лучше. В portage лежат только рецепты для сборки пакетов (ebuilds), а многие зеркала отдают дельты изменений и поддерживают rsync - значит получится, потратив мало трафика, иметь всегда актуальную версию portage. Старые версии пакетов оттуда удаляют не сразу, а сломанные маскируют вместо удаления, что даёт пользователю возможность откатиться (даже на заведомо уязвимую версию, если пользователь будет настаивать). Rolling release, но поддерживается частичное обновление (в рамках одной версии EAPI). Для сборки потребуются distfiles (исходники), и именно они займут больше всего места, но portage не навязывает какой-то определённый источник, а сами ebuild содержат ещё и ссылки на upstream, откуда можно скачать исходник. Для проверки целостности в portage лежат хэш-суммы всего, что требуется для сборки. Из недостатков - придётся компилировать исходники, но для крупных пакетов (libreoffice, firefox, chromium) есть готовые бинарные сборки. Если использовать в рамках организации, то можно держать свой binhost для того, чтобы избежать повторной сборки на всех узлах.
И стоит рассмотреть NixOS. Можно обмениваться кусками /nix/store, разработчики системы сильно продвинулись в достижении цели полной воспроизводимости сборки, окружения получаются гораздо более герметичными. Переход от input-addressable к content-addressable должен сократить ненужные скачивания при обновлении зависимостей. Число готовых пакетов сравнимо с Debian, более 80000. Из недостатков - очень отличается от привычных систем подходом к управлению пакетами, структурой директорий.
Утекать может и место на диске. Наверняка у вас где-нибудь в $HOME/.config/ и $HOME/.local/share/ есть целые директории, которые созданы программами, которые больше не установлены в системе. И ошибки тоже могут накапливаться (хотя и с меньшей вероятностью, так как кода, меняющего персистентное состояние меньше), если они являются частью персистентного состояния - чтобы бороться с этой проблемой, Firefox при восстановлении после сбоя каждый раз спрашивает, хочет ли пользователь восстановить ранее открытые вкладки.
Если у программы есть два места, в которых хранится состояние - персистентное (диск) и оперативное (регистры, память, состояние объектов ОС), то программисту каждой такой программы придётся заботится о явной синхронизации этих мест. Ошибки её реализации возникают настолько часто, что у спидраннеров есть даже специальный термин - save/load abuse.
Так же, как персистентность файлов в привычных нам ОС сочетается с необходимостью в периодическом сбросе состояния системы путём её переустановки.
Теперь и до меня доехал мой анонимный Дед Мороз! Он поинтересовался моим поведением, и, удволетворшись ответом, подарил мне футболку и шоколадку.
Изображение
Ура!
Это ещё проще. Достаточно сделать язык, в котором нельзя сказать "я видел НЛО" или "я слышу барабашек", а лишь "я наблюдаю странное перемещение источника света своими глазами, и если работа моего организма не нарушена, то по моему скромному мнению это может быть свидетельством существования инопланетной цивилизации" и "я слышу звук, но не понимаю, что является его источником; учитывая тот факт, что я недостаточно скептически отношусь к написанному в книге «былички и рассказы о НЛО», приму за рабочую гипотезу, что его источником являются барабашки". То есть не давать возможности носителю языка обобщать явление без явного указания на субъективность такого суждения и/или источник информации. А выдавать свои наблюдения за общий консенсус можно вовсе запретить.
Даже если один индивид допустит ошибку из-за сбоя в работе организма, другой будет ретранслировать полученную от него информацию, как подлежащую сомнению - "мой друг вчера сказал мне, что по его мнению он видел НЛО" вместо "здесь видели НЛО вчера".