Успех мероприятия зависит от пропускной способности канала. Например если все 4 участника этой гонки - магнитные диски и включены в SATA3 порты - то копирование будет в первую очередь ограничиаться шлейфом SATA3 (до 6Gbit) и даже если 3 других в сумме дают более быстрый трафик то мы будем исходить их скорости самого медленного верблюда в караване.
Иногда помогает легкое поджатие информации. В BigData например используют кодеки snappy/LZ0.
Хотя я никогда не видел snappy реализованного в виде консольной утилиты.
Я-бы посмотрел на количество человек в команде разработки. И еще можно глянуть баг-трекер.
Если там дефекты висят по пол-года - то это тревожный сигнал о том что не стоит
с ним связываться. Ведь эти дефекты - будут у тебя.
Времена когда люди гонялись за операционками остались в 2000х. Особого смысла менять один
декстоп на другой нет. По возможностям они все примерно одинаковы. И если что и осталось выбирать
то это - надежность патчей и оперативность их выкатывания.
Недостатки Убунту описывал сам Столлман. По его мнению эта ОС слегка ... стучит на своих пользователей.
На современном языке - собирает телеметрию. В каком объеме собирает и как - никто не знает.
Никто такой вопрос кроме Столлмана видимо не поднимал. Но даже если так ... какие гарантии
что Минт не делает тоже самое?
Для современной разработки уже нет смысла держать две оси.
Если на Windows нужна bash-консоль и линукс окружение - то можно поставить WSL2.
Если нужны Linux-специфичные службы и приложения в сети - то их можно поднять через Docker.
Если тебе нужен хайлоад на локальной машине как мне - то просто сразу ставь себе Линукс как основную
ОС. Это радикально и решительно. К чему эта каша-размазня?
Фактически когда мы говорим Linux - мы подразумеваем не саму ОС а ядро. Ядро физически лежит в каталоге
/boot
и это единая точка в системе где можно говорить именно о весии ядра. На все остальное - версия ядра не распространяется. Версии утилит и пакетов и приложений - могут быть любые. И может быть миллионы
их сочетаний вместе с ядром. Это кстати иногда отвечает на вопрос почему у некоторых пользователей
баг воспроизводится а у некоторых - нет.
Сама формула расчета размера свопа была разная для разных объемов оперативки для разных линуксов. Кажется для памяти меньше чем 2Гб рекоммендовалось брать своп хотя-бы в 2 раза больше. Для иного варианта - брать хотя-бы не менее чем размер свопа.
Зависит от того какой диск у тебя будет загрузочным. Собственно ты можешь загружать обе операционки с первого диска но для каждой указывать монтирование только своих дисков и разделов. Это достаточно прикрывает тебя от кривых рук.
Но когда будешь изучать команды типа fdisk, parted, mkfs то лучше конечно ценную ОС отключить вообще.
Ну... в линуксе есть утилитка stat которая выдает аж 3 даты. Одна из них - то что тебе надо.
В линуксе есть итератор (find) который может обойти всю файловую систему и выдать все файлы.
Вот. Твоя дата подходит под шаблон "2022-0[345]". Можешь взять grep/gawk и выбрать все что подходит.
Получается pipeline. Find ищет. Stat трансформирует. Grep фильтрует.
Вот такой вот план. В традициях ФП. Пробуй. И не ищи однострочники. Хороший софт может быть написан в виде
bash скрипта например.
Нужно дейстовать как делают сисадмины. Собрать сначала все сведенья. Что за линукс? Минт - это просто маркетинговое название. Для фикса проблемы - ничего пока нет. Нужна модель-версия ядра с точностью до билдов (uname -a). Потом обновить всё. Вообще всё. (apt update && apt upgrade). Потом посмотреть версию модель принтера и версию дров принтера (lp, lpadmin, lpstat). Вот иди по ключевым словам в гугл и копай.
Во первых - никто не прекращает. Есть огромный сегмент микропроцессоров малого энергопотребления которые так и останутся 32х битными. Микроконтроллеры и прочее. И операционки и прошивки и код вообще для них как писался так и пишется. И я думаю что такой класс оборудования будет существовать всегда. Нет смысла его каким-то образом хоронить.
По поводу адресации 64х бит. Насколько я помню адресные линии современных процессоров материнских плат так и не достигли этого размера. Что такое вообще - полный объем памяти с 64х битами - это больше чем во всех датацентрах вместе взятых. Посчитайте сами. Простая арифметика. Каждый бит - удваивает количество железа на борту. Сколько щас Intel Core способен адресовать? Я не помню. Пускай знающие подскажут.
Тоесть когда мы говорим 64 бит - то надо уточнять какие на самом деле биты имееются в виду. Доступная память для процесса? Ну да. Может быть.
IBM в 20м веке выпускала железки с 128 битной адресацией но там смысл указателя был немного более сложный. Что-то вроде бесконечной виртуальной ленточной памяти.
А 64х разрядные регистры были еще у первых Pentium MMX в 90х. Но это не имело отношения к адресации памяти.
Я в таких случаях просто подмигиваю продавцу.... дескыть. Договоримся. И он позволяет поставить на ноут что угодно в магазине или в сервисном центре и мы далее вместе смотрим как Linux стартует. Расчитываемся и продавец на кармашек получает свои несколько долларов.
Давайте поговорим о шрифтах. В 2012 я перешел с windows7 на Linux. И первая проблема практической работы с десктопом заключалась в том что я начал менять шрифты. Вот не нравились мне не шрифты не алгоритмы их рендеринга. Надо отдать должное МС. Шрифты у них хорошие. Дизайнеры очень долго думали над ними. Вот. Когда вы заняты кросс-платформенным UI возникает проблема. - Где взять шрифты максимально похожие на оригинал. Высота. Кернинг. Все должно быть максимально похожим на оригинальный десктоп где идет разработка иначе дизайн разваливается. В годы развития Linux Suse я пытался устанавливать их десктопы и использовать. И самая большая визуальная проблема что я видел - это полный развал шрифтового оформления. Доходило до смешного. Я просто не мог прочитать кириллический месседж в окне. Текст - сползал куда-то за границу окна. Или текст успешно переносился а баттон сползал за границы окна. Вобщем проблем было масса. Я думаю что одна из главных проблем кросс-платформенного UI - это унификация шрифтов. И дело тут вовсе не в Qt или Gnome/Gtk или KDE. А дело в том что другая платформа понятия не имеет как должен выглядет текстовый месседж.
Я видел пакет iwatch. Кажется пытался где-то его применить. Он слушает слишком много событий. Там буквально каждый чих в файловую систему будь то просмотр директорий или атрибутов вызывает шквал событий и их надо грамотно буферизировать и фильтровать.
В идеале вы должны поставить свой ФТП-root под версионный контроль. Например под git. И делать чисто технический коммит на каждое событие изменения файла.
Проблема в том что в такой много-пользовательской среде как ФТП трудно выделить атомарную часть изменения чтобы обозвать ее коммитом. Если 2 пользователя одрновременно пишут в 2 файла в ФТП - это нормальное действие с точки зрения файлового сервака. И в этот момент трудно принять решение где-же собсно
был коммит. Мы полюбому будем фиксировать в коммитах недописанные тела файлов. Вот в чем проблемка.
И кому нужна такая бестолковая история изменений где файлы постоянно битые. Вобщем такие вот мысли.
Может я ошибаюсь.
Проверьте делает ли ФТП временное расширение для файла во время записи или обновления. Это важно.
В вопросе звучат два вопроса.
1) Нормально ли использовать primary partitions вместо extended. Ответ - да нормально.
2) Как под Windows прочитать этот раздел. Моё имхо - лучше этого не делать. Если вам
нужен какой-то обмен данными - то лучше отформатируйте под Fat32 например.
Или вообще откажитесь от использования Windows и пользуйтесь Linux-файловыми
системами без ограничений. В противном случае ситуация выглядит как некое необоснованное
"чудачество" автора.
Вобщем у меня подобная задача стояла пол-года назад. Для облачного диска. Но я ее порешал по другому.
Ftp не понадобился. Но если что- смотри утилиту lftp. И там в скриптах у нее есть команда mirror.
~$ lftp --help
Usage: lftp [OPTS] <site>
`lftp' is the first command executed by lftp after rc files
-f <file> execute commands from the file and exit
-c <cmd> execute the commands and exit
.....