Имея ZFS-mirror пользоваться костылями? Не вижу ни одной причины так делать. Снапшоты ничего не стоят, поэтому у меня, например, папка с документами снапшотится каждый час.
Для меня сигналом к отказу от Яндекс Диска стал перевод синхронизации файлов в десктопном клиенте в платную категорию. При этом я уже платил за Плюс и ещё 199 рублей в месяц за «мозги» Алисы, но для синхронизации требовалась отдельная подписка.
В итоге купил корпус для NAS и собрал домашний сервер: Intel Core i3-14100, 16 ГБ оперативной памяти и два диска по 4 ТБ в зеркале ZFS. Поставил Debian, для синхронизации файлов — Syncthing, для фотографий — Immich. Заодно настроил автоматические снимки ZFS, чтобы можно было восстановить случайно удалённые файлы или откатить неудачные изменения.
Жена говорила: «Паранойя». Теперь уже не кажется… Конечно, свой сервер тоже может сломаться, но хотя бы хранение данных и доступ к ним теперь под моим контролем.
А без понимания CSS, js и HTML, что, никак? Зачем тогда ИИ? Он же за меня думать должен, не? А если серьёзно, то пока что все без исключения ИИ дают нужный ответ только тому, кто сформулировал промт имея полное понимание вопроса. Такое полное, какого достаточно, чтобы не пользоваться ИИ вообще.
Интересное решение - использовать один raspberry pico как CPU, а другой, как GPU. Чаще встречал, да и сам так делаю, когда два ядра одного pico выполняют эти же функции. Но, допускаю, что проблема в малом объёме памяти, не позволяющей развернутся с той же двойной буферизацией.
Что за бредовый вопрос про биты? Какие именно считать: 0 или 1 или все? И да, сортировка или сдвиг тоже имеют свою стоимость, так что вряд ли получишь выигрыш от использования simd и прочих плюшек AMD64 архитектуры перед несортированным массивом.
Интересно, не знаю такого закона, погуглю. А что скажете в случае, когда потоки занимаются подготовкой своей доли массива данных, а главный поток, по мере готовности, окучивает их. И главному потоку нужно заблокировать лишь один рабочий тред, который закончил свою порцию подготовки, к остальным нужно продолжать расчёты? Весьма реальная ситуация.
Не буду строить из себя жертву, работник я такой себе: мыслю на ассемблере, и смотрю как бы "сквозь код", а потому часто имею своё мнение там, где надо было бы и приподзаткнуться:🤣 Поэтому, мой удел - фриланс, там особо не смотрят на реализацию, так как большинству нужна картинка.
Смотря как им пользоваться: я как-то завалил собес, используя мьютекс и condition_variable для каждого экземпляра потока, чтобы сделать блокировку двусторонней: любой из потоков может запретить главному пользоваться ФС, также главный поток может запретить начинать генерацию данных всем потокам до тех пор, пока текущие данные не будут сохранены. Но потенциального работодателя такой креатив не устроил. Судя по критике, ему нужно было именно бутылочное горлышко. А вопроса про смысл многопоточности, похоже, вообще не услышал. P.S. опережая вопрос про дедлок, он был исключён, так как wait с одной стороны физически не мог начаться во время wait с другой. Это было предусмотрено.
Забавно, что во всех примерах по многопоточности с помощью мьютексов и прочих condition variable, учат не распараллеливать задачи, а наоборот, приводить задачи из всех потоков в один. Что потом и делают ученики.
Как-то, года три назад, заморочился - sha256 на SIMD реализовал. Увы, распараллелить процесс в силу алгоритма невозможно, к тому же память и диск не дали алгоритму вволю развернуться. А раз так, то и к дальнейшему развитию интерес упал.
Аналогично! Стараюсь нейросети задавать вопросы по изучаемой теме, а не прошу думать за меня. На мой взгляд это самый выигрышный подход: и сам не деградируешь и нейросети не даёшь много косячить.
Нейросети хороши на короткой дистанции: придумать имена переменным эквивалентам БД (скармливаешь запрос) и сделать из них класс или структуру; реализовать алгоритм; привести пример использования незнакомого API и т.д. Всё что касается структуры проекта, пока что её лучше держать в голове. Посмотрим что будет дальше.
Ушёл от этих эффективных менеджеров в конце года. Как мой домен с 2000р стал стоить 9000р, а у шефа сопровождаемой мною организации и вовсе 27000р. - осталось загадкой. Но в итоге сам ушёл и организацию перевёл на другую площадку. Чтоб вы там подавились, уроды.
Имея ZFS-mirror пользоваться костылями? Не вижу ни одной причины так делать. Снапшоты ничего не стоят, поэтому у меня, например, папка с документами снапшотится каждый час.
Для меня сигналом к отказу от Яндекс Диска стал перевод синхронизации файлов в десктопном клиенте в платную категорию. При этом я уже платил за Плюс и ещё 199 рублей в месяц за «мозги» Алисы, но для синхронизации требовалась отдельная подписка.
В итоге купил корпус для NAS и собрал домашний сервер: Intel Core i3-14100, 16 ГБ оперативной памяти и два диска по 4 ТБ в зеркале ZFS. Поставил Debian, для синхронизации файлов — Syncthing, для фотографий — Immich. Заодно настроил автоматические снимки ZFS, чтобы можно было восстановить случайно удалённые файлы или откатить неудачные изменения.
Жена говорила: «Паранойя». Теперь уже не кажется… Конечно, свой сервер тоже может сломаться, но хотя бы хранение данных и доступ к ним теперь под моим контролем.
Вовремя предать — это не предать, а предвидеть)))
А без понимания CSS, js и HTML, что, никак? Зачем тогда ИИ? Он же за меня думать должен, не? А если серьёзно, то пока что все без исключения ИИ дают нужный ответ только тому, кто сформулировал промт имея полное понимание вопроса. Такое полное, какого достаточно, чтобы не пользоваться ИИ вообще.
Интересное решение - использовать один raspberry pico как CPU, а другой, как GPU. Чаще встречал, да и сам так делаю, когда два ядра одного pico выполняют эти же функции. Но, допускаю, что проблема в малом объёме памяти, не позволяющей развернутся с той же двойной буферизацией.
Вот-вот. Похоже и сам кандидат не очень смыслил.
Что за бредовый вопрос про биты? Какие именно считать: 0 или 1 или все? И да, сортировка или сдвиг тоже имеют свою стоимость, так что вряд ли получишь выигрыш от использования simd и прочих плюшек AMD64 архитектуры перед несортированным массивом.
Интересно, не знаю такого закона, погуглю. А что скажете в случае, когда потоки занимаются подготовкой своей доли массива данных, а главный поток, по мере готовности, окучивает их. И главному потоку нужно заблокировать лишь один рабочий тред, который закончил свою порцию подготовки, к остальным нужно продолжать расчёты? Весьма реальная ситуация.
А есть ли смысл распараллеливания в таких случаях?
Спасибо 🙂
Закончу текущую задумку и снова начну поиски. Надеюсь, именно такая контора мне и попадётся. Сложно работать в среде, где ты "инопланетянин" 👽))
Не буду строить из себя жертву, работник я такой себе: мыслю на ассемблере, и смотрю как бы "сквозь код", а потому часто имею своё мнение там, где надо было бы и приподзаткнуться:🤣 Поэтому, мой удел - фриланс, там особо не смотрят на реализацию, так как большинству нужна картинка.
Смотря как им пользоваться: я как-то завалил собес, используя мьютекс и condition_variable для каждого экземпляра потока, чтобы сделать блокировку двусторонней: любой из потоков может запретить главному пользоваться ФС, также главный поток может запретить начинать генерацию данных всем потокам до тех пор, пока текущие данные не будут сохранены. Но потенциального работодателя такой креатив не устроил. Судя по критике, ему нужно было именно бутылочное горлышко. А вопроса про смысл многопоточности, похоже, вообще не услышал.
P.S. опережая вопрос про дедлок, он был исключён, так как wait с одной стороны физически не мог начаться во время wait с другой. Это было предусмотрено.
Забавно, что во всех примерах по многопоточности с помощью мьютексов и прочих condition variable, учат не распараллеливать задачи, а наоборот, приводить задачи из всех потоков в один. Что потом и делают ученики.
О! Наконец-то полноценную двойную буферизацию для дисплея замутить можно!
Зачем? Страуструп уже сделал всё до вас, по максимуму использовав все слабые места процессора:-)
Как-то, года три назад, заморочился - sha256 на SIMD реализовал. Увы, распараллелить процесс в силу алгоритма невозможно, к тому же память и диск не дали алгоритму вволю развернуться. А раз так, то и к дальнейшему развитию интерес упал.
Аналогично! Стараюсь нейросети задавать вопросы по изучаемой теме, а не прошу думать за меня. На мой взгляд это самый выигрышный подход: и сам не деградируешь и нейросети не даёшь много косячить.
Нейросети хороши на короткой дистанции: придумать имена переменным эквивалентам БД (скармливаешь запрос) и сделать из них класс или структуру; реализовать алгоритм; привести пример использования незнакомого API и т.д. Всё что касается структуры проекта, пока что её лучше держать в голове. Посмотрим что будет дальше.
А я от них на рег. ру ушёл, думал, что это другая организация. Понял. В следующий год свалю и от них.
Ушёл от этих эффективных менеджеров в конце года. Как мой домен с 2000р стал стоить 9000р, а у шефа сопровождаемой мною организации и вовсе 27000р. - осталось загадкой. Но в итоге сам ушёл и организацию перевёл на другую площадку. Чтоб вы там подавились, уроды.