«Примитивное» это вы уже перегнули. Любое масштабное производство требует специалистов и технологий. Справедливости ради производство микропроцессоров не сильно технологичнее. Просто требует большей чистоты и других станков. Всё упирается в используемые технологии и количество переделов (участков). Да и ни кто тут не сравнивает одно с другим. Не все же должны делать интегральные микросхемы, кто-то должен и печатные платы производить.
Конечно нет. Если вы можете сделать один слой - уже производство! Но хорошо бы это делать рентабельно и массово. А самое главное с высокой степенью повторяемости. Вот в последнем мы не только в печатных платах, а почти во всех сегментах плаваем…
Сразу забегая вперёд - я не схемотехник, такие платы не проектировал. Моя область - монтаж. Так вот, платы с большими сложными BGA компонентами, которые по видимому имеют довольно сложный функционал, и одновременно изделие имеет ограничение по размеру - разводятся многослойными платами. Меньше 8 слоёв я встречал только на довольно простых изделиях. Как только появляются Xilinx, то 8 слоёв это норма. Как только появляется Intel - 16 это только начало.
Не стоит смешивать производства опытных партий и промышленные. Сделать 100 шт. двухслойных плат без контроля импеданса способны многие предприятия. А сделать 5000 шт. в месяц восьмислойных палат, с гальваническим покрытием ламелей... Ну даже в Китае не все.
Про "не мало" - мне кажется преувеличением. Я знаю 3 завода в России, которые способны делать сколько-нибудь значимые тиражи. Со сложными платами ни один из них не может помочь. Если вы знаете российский завод, который делает 16 слойные платы и более платы, то буду рад узнать о них.
Не могу с вами согласиться. Запросите у Резонита 16 слойную плату. Или нестандартный материал. Они покрывают только самые-самые популярные запросы. И тоже прибегают к помощи Китайских заводов.
Как они будут проверять самбу не знаю, немного не моя сфера. Но железки проверяют вплоть до завода изготовителя каждого компонента, там довольно сложная бальная система. И сборочный цех тоже смотрят, переписывают всё оборудования и проверяют достаточно ли его для производства. В случае если попадёшься на подлоге, это тюрьма. Не думаю что кто-то будет рисковать и ставить палёную винду (между прочим от 500 т.р. штраф), натягивать самбу и потом ещё это автоматом аккредитовать и продавать. Проще линукс, русский бренд и уже на него самбу, в общем как и описано в статье.
Возможно стоит конкретизировать. Буду рад, если подскажете более точный термин. Тут ведь с какой стороны посмотреть. Физически у вас есть возможность восстановить утраченные / повреждённые данные. И это в русскоязычном сегменте обычно зовётся "резервированием", с другой, конечно это не система хранения данных типа rsync, готового RAID и т.д.
По поводу «откроем и запишем», наверное было бы корректнее сказать «перепишем», но чтобы не отходить от темы опустил этот момент.
Практического применения код не имеет никакого) Глупо спорить, что уже имеющиеся решения, в том числе аппаратный RAID или mdamd покрывают весь спектр. Но иногда приходится решать узкие проблемы или разбираться в работе того или иного кода, и в этот момент просто полезно знать какой бывает инструментарий.
Согласен, всё описанное вами абсолютно верно. И отлично дополняет. Я решил, чтобы статья была лёгкой для чтения опустить подробности. Это как рассмотрение солнечной системы, если нарисовать все планеты и солнце в масштабе, но это будет не наглядно и начинать погружаться в астрономию с этого будет тяжело. Рассмотрение всех возможных эффективных способов сжатия мне кажется это вообще отдельная тема, в которой я точно не силён. В этом беда наглядных пособий, они не точны и приходится делать некоторые допущения.
HEX редактор напрямую никакого отношения не имеет. Но найти картинку способную точно передать идею я увы не смог. В добавок современные операционные системы хорошо скрывают реальные адреса, а DOS ради этого было ставить очень мутерно. Я использую эту картинку исключительно для визуализации отличия адреса от информации. Это не точное пособие, но в целом идею на нём показать можно.
Чем правильно редактировать например EmEditor или суровое консольное nano. Если хватит оперативной памяти, то оно должно открыть.
Это просто способ пощупать XOR. На этом можно построить защиту от повреждения, файлы будут друг друга контролировать. Но тогда хэш физического файла нужно сравнивать с хэшом XOR от двух других файлов, при не совпадении восстанавливать из XOR файла и даже можно будет определить конкретные битые места.
Мне кажется современное решение это NTFS. FAT32 не даст записать файл размером более 4 гб, и имеет ограничение на количество файлов в одном каталоге = 65534, на опыте я упирался в оба ограничения. У NTFS один файл может весить до 16ТБ и количество файлов в каталоге может быть более 4 млн. шт. Конечно какие-то экзотические устройства могут принимать только FAT32, но это скорее исключение. Ext (стандартный для Linux) я бы тоже не стал использовать, может потребоваться прочесть флешку на Windows.
Жалко вы не хотите писать полезные комментарии, видимо могли бы. Например предложить, как лучше и нагляднее донести эти простые темы? Или может имеете богатый опыт в развёртывании инфраструктуры, я бы почитал. Найти опечатки, это конечно мило, но может вы способны на что-то более продуктивное?
Это было в начале, откуда пошло рассуждение. Но если интересно, то вот так:
Когда файлы загружаются на сервер, то создаётся особая структура каталогов и файл именуется по шаблону. Таким образом в самом коде веб приложения сразу пишется паттерн, который указывает на на место в файловой системе. Для того чтобы приложению не нужно было администрировать файлы, то они при загрузке распределялись бы хардлинками по нужным каталогам.
Используя git вы сталкиваетесь именно в hard link и понимание этого есть основная цель.
XOR сам по себе не сильно интересен. Но при решении отдельных задач крайне спасает. Например, не помню где на просторах интернета встречал: СКУД много людей заходят, много выходят. Один не вышел, как найти? И одно из решений было пройти XOR-ом по всем записям. Не помню деталей, но и работало это только в случае, если не вышел 1 человек. Главное - это понимание механизма.
Очень аргументированное возмущение) А что так? Ни когда не приходилась восполнять пробелы в знаниях новых сотрудников, или есть предложение как сделать лучше? А нет, всё проще. Я почитал вашу историю комментариев и статей, вам просто нравятся дизлайки))
Вообще кода zfs получит распространение будет интересно) Тем не менее буквально в прошлом месяце я встречал флешку отформатированную в FAT32, и видел людей с дискетами 3,5 мб.
1. Windows использует hard liks. В основном для обратной совместимости. Если мне не сильно изменяет память то на обычный блокнот имеется 7 шт. hard link.
2. Windows не корректно считает размер файла по отношению к GUI пользователя, занятое место на диске отображается абсолютно корректно.
3. Уверен что программы, которые учитывают hard links по идентификаторам (inode, если бы мы говорили про UNIX) существуют, просто не являются дефолтными.
Подписываться на канал не буду, но в целом некоторые аргументы интересны. Не рассматривал это с такого ракурса.
«Примитивное» это вы уже перегнули. Любое масштабное производство требует специалистов и технологий. Справедливости ради производство микропроцессоров не сильно технологичнее. Просто требует большей чистоты и других станков. Всё упирается в используемые технологии и количество переделов (участков). Да и ни кто тут не сравнивает одно с другим. Не все же должны делать интегральные микросхемы, кто-то должен и печатные платы производить.
Конечно нет. Если вы можете сделать один слой - уже производство! Но хорошо бы это делать рентабельно и массово. А самое главное с высокой степенью повторяемости. Вот в последнем мы не только в печатных платах, а почти во всех сегментах плаваем…
Сразу забегая вперёд - я не схемотехник, такие платы не проектировал. Моя область - монтаж. Так вот, платы с большими сложными BGA компонентами, которые по видимому имеют довольно сложный функционал, и одновременно изделие имеет ограничение по размеру - разводятся многослойными платами. Меньше 8 слоёв я встречал только на довольно простых изделиях. Как только появляются Xilinx, то 8 слоёв это норма. Как только появляется Intel - 16 это только начало.
Не стоит смешивать производства опытных партий и промышленные. Сделать 100 шт. двухслойных плат без контроля импеданса способны многие предприятия. А сделать 5000 шт. в месяц восьмислойных палат, с гальваническим покрытием ламелей... Ну даже в Китае не все.
Про "не мало" - мне кажется преувеличением. Я знаю 3 завода в России, которые способны делать сколько-нибудь значимые тиражи. Со сложными платами ни один из них не может помочь. Если вы знаете российский завод, который делает 16 слойные платы и более платы, то буду рад узнать о них.
Не могу с вами согласиться. Запросите у Резонита 16 слойную плату. Или нестандартный материал. Они покрывают только самые-самые популярные запросы. И тоже прибегают к помощи Китайских заводов.
Как они будут проверять самбу не знаю, немного не моя сфера. Но железки проверяют вплоть до завода изготовителя каждого компонента, там довольно сложная бальная система. И сборочный цех тоже смотрят, переписывают всё оборудования и проверяют достаточно ли его для производства. В случае если попадёшься на подлоге, это тюрьма. Не думаю что кто-то будет рисковать и ставить палёную винду (между прочим от 500 т.р. штраф), натягивать самбу и потом ещё это автоматом аккредитовать и продавать. Проще линукс, русский бренд и уже на него самбу, в общем как и описано в статье.
Думаю нуль. Пройти аккредитацию минпромторга не так просто. Надо буквально наизнанку порой вывернуться.
Возможно стоит конкретизировать. Буду рад, если подскажете более точный термин. Тут ведь с какой стороны посмотреть. Физически у вас есть возможность восстановить утраченные / повреждённые данные. И это в русскоязычном сегменте обычно зовётся "резервированием", с другой, конечно это не система хранения данных типа rsync, готового RAID и т.д.
По поводу «откроем и запишем», наверное было бы корректнее сказать «перепишем», но чтобы не отходить от темы опустил этот момент.
Практического применения код не имеет никакого) Глупо спорить, что уже имеющиеся решения, в том числе аппаратный RAID или mdamd покрывают весь спектр. Но иногда приходится решать узкие проблемы или разбираться в работе того или иного кода, и в этот момент просто полезно знать какой бывает инструментарий.
macOS понимают NTFS, если мы говорим про чтение. Как писали выше exFAT тоже очень хороший вариант.
Согласен, всё описанное вами абсолютно верно. И отлично дополняет. Я решил, чтобы статья была лёгкой для чтения опустить подробности. Это как рассмотрение солнечной системы, если нарисовать все планеты и солнце в масштабе, но это будет не наглядно и начинать погружаться в астрономию с этого будет тяжело. Рассмотрение всех возможных эффективных способов сжатия мне кажется это вообще отдельная тема, в которой я точно не силён. В этом беда наглядных пособий, они не точны и приходится делать некоторые допущения.
HEX редактор напрямую никакого отношения не имеет. Но найти картинку способную точно передать идею я увы не смог. В добавок современные операционные системы хорошо скрывают реальные адреса, а DOS ради этого было ставить очень мутерно. Я использую эту картинку исключительно для визуализации отличия адреса от информации. Это не точное пособие, но в целом идею на нём показать можно.
Чем правильно редактировать например EmEditor или суровое консольное nano. Если хватит оперативной памяти, то оно должно открыть.
Это просто способ пощупать XOR. На этом можно построить защиту от повреждения, файлы будут друг друга контролировать. Но тогда хэш физического файла нужно сравнивать с хэшом XOR от двух других файлов, при не совпадении восстанавливать из XOR файла и даже можно будет определить конкретные битые места.
Мне кажется современное решение это NTFS. FAT32 не даст записать файл размером более 4 гб, и имеет ограничение на количество файлов в одном каталоге = 65534, на опыте я упирался в оба ограничения. У NTFS один файл может весить до 16ТБ и количество файлов в каталоге может быть более 4 млн. шт. Конечно какие-то экзотические устройства могут принимать только FAT32, но это скорее исключение. Ext (стандартный для Linux) я бы тоже не стал использовать, может потребоваться прочесть флешку на Windows.
Жалко вы не хотите писать полезные комментарии, видимо могли бы. Например предложить, как лучше и нагляднее донести эти простые темы? Или может имеете богатый опыт в развёртывании инфраструктуры, я бы почитал. Найти опечатки, это конечно мило, но может вы способны на что-то более продуктивное?
P.S. Да с RAID 1формулировка не точная, согласен.
Это было в начале, откуда пошло рассуждение. Но если интересно, то вот так:
Когда файлы загружаются на сервер, то создаётся особая структура каталогов и файл именуется по шаблону. Таким образом в самом коде веб приложения сразу пишется паттерн, который указывает на на место в файловой системе. Для того чтобы приложению не нужно было администрировать файлы, то они при загрузке распределялись бы хардлинками по нужным каталогам.
Используя git вы сталкиваетесь именно в hard link и понимание этого есть основная цель.
XOR сам по себе не сильно интересен. Но при решении отдельных задач крайне спасает. Например, не помню где на просторах интернета встречал: СКУД много людей заходят, много выходят. Один не вышел, как найти? И одно из решений было пройти XOR-ом по всем записям. Не помню деталей, но и работало это только в случае, если не вышел 1 человек. Главное - это понимание механизма.
Очень аргументированное возмущение) А что так? Ни когда не приходилась восполнять пробелы в знаниях новых сотрудников, или есть предложение как сделать лучше? А нет, всё проще. Я почитал вашу историю комментариев и статей, вам просто нравятся дизлайки))
Вообще кода zfs получит распространение будет интересно) Тем не менее буквально в прошлом месяце я встречал флешку отформатированную в FAT32, и видел людей с дискетами 3,5 мб.
Это три разных вопроса. По порядку.
1. Windows использует hard liks. В основном для обратной совместимости. Если мне не сильно изменяет память то на обычный блокнот имеется 7 шт. hard link.
2. Windows не корректно считает размер файла по отношению к GUI пользователя, занятое место на диске отображается абсолютно корректно.
3. Уверен что программы, которые учитывают hard links по идентификаторам (inode, если бы мы говорили про UNIX) существуют, просто не являются дефолтными.