All streams
Search
Write a publication
Pull to refresh
7
0
Арсен Боровинский @borovinskiy

Предприниматель

Send message

Моя школа - это ФГИС (федеральная государственная информационная система). Сферум частью ФГИС Моя школа не является, так как Сферум принадлежит совместному ООО Ростелекома и ВК (Мейла). А независимый коммерческий сервис никак не может быть частью ФГИС.

Ну и рост есть. Думаю некоторые учителя, которые пользуются для коммуникацией ВК, таки мигрируют классы в Сферум.

А кто обязывал?
Пушкинская карта - она же по линии минкультуры, а не минпросвета и сложно приказывать не в рамках вертикали своего министерства.

А так про Пушкинскую карту есть гипотеза, что при помощи нее будут менять финансирование учреждений культуры. Там у них сейчас повальное очковтирательство по тому, сколько человек эти учреждение посещают. Если вход и обслуживание повсюду будут по Пушкинской карте, то все станет более-менее прозрачно.

Сливают школьников в ВК, чтоб был в ВК аккаунт. В этом смысл Сферума.

Лабораторные МЭШ сделаны не безопасно, ага.

Ну и там физиконовские на сервер Физикона обращаются типа с xAPI, но он видать не настроен.

В общем, там Содом и Гоморра в этой МЭШ -)

Просвещение - коммерческое издательство с оборотами (на память) 15 млрд.

Оно условно негосударственное - контрольный пакет в руках компаний, контролируемых государством.

Государство выгодно продало его лет 20 назад за 2 млрд., а недавно выгодно купило за условные 100 млрд. "на разницу и живут" успешные покупатели за 2.

У меня по виду точно такой же Lenovo thinkcenter 75Q или типа того с 8-ядерным Ryzen (у Lenovo много процессоров на одинаковом корпусе на выбор).

Похоже железо всем этим ASRock/Lenovo/Dell один производитель собирает.

Ну так вот, он не бесшумный. Радиатор там алюминиевый и шумит примерно как ноутбук (центробежный вентилятор). Причем в некоторых случаях давая нагрузку на одно ядро он начинал сильно разгоняться и подвывать, хотя это не характерное для ПК поведение.

Если отбросить фактор бесшумности, то да, довольно неплохой компактный ПК.

Ну только по стоимости с ним может еще mac mini конкурировать. Разница с маком в том, что мак компактнее, так как при схожих габаритах в него еще блок питания упихали и бесшумнее, но комплектация беднее.

У меня два одноплатника и тут соглашусь, что Celeron стоит лишь немногим больше, а по многим вопросам проблем имеет значительно меньше, как от выбора ОС, так и драйверов и аппаратного ускорения видео.

Мне для дома не нравятся полноценные сервера, которые шумят и жрут электричество как не в себя (мы электричество не считаем, так как в России оно дорогое, но это ведь тоже расходы).

Кроме того, современные процессоры имеют сильно большей IPC, а у ryzen7xxx базовая частота вообще 4.7 ГГц, в то время как у б/у серверов частота будет скорее всего 3ГГц при заметно меньшей IPC и базовая 2-2.5 ГГц. То есть работать на них все будет раза в 2 медленнее.

Если говорить про ECC, то матплаты часто неофициально ее поддерживают, в частности мой минипк на Ryzen Pro поддерживает, просто в России SODIMM ECC не нашел. А вот DDR5 ECC внутри памяти вовсе часть стандарта и вся DDR5 имеет ECC (но маркетинг не дал полноценный ECC при передаче, только в хранении).

Тут все верно, стоят они не дешево. Но я бы их относил к серверным материнским платам, поэтому стоимость соответствует позиционированию в рынок.

Я примерно считал, у меня получалось, что на таких комплектующих выгоднее собирать, чем привычный сервер. Но тут все от потребностей, конечно.

У asrock даже блейды есть с десктопными процессорами, если посмотреть, что они продают. В общем, надо с калькулятором считать как выгоднее.

Есть платы под десктопные процессоры с IPMI, но в России они не продаются. Пример: https://www.asrockrack.com/general/products.ru.asp#Server

Ага.

Вот 2 процессорный топовый в свое время Xeon 2690 на 8 ядрах: https://browser.geekbench.com/v5/cpu/18867065

А вот десктопный Ryzen 5750G (тоже 8 ядер) размером с мак мини и не слишком сильно шумящий: https://browser.geekbench.com/v5/cpu/17455785

В итоге Ryzen работает в одноядерной производительности в 2 раза быстрее (банально больше частота), а в многоядерной на уровне сервера с двумя топовыми 10 лет назад Xeon.

Ну и накой с этими серверами возиться?

Ну HDD тоже могут умирать, а в гелевых вряд ли так просто потом пластины на донора переставишь.

Тут вопрос в другом: нужно защититься от смерти диска? Используйте RAID, можно софтовый а-ля ZFS.

Хотите защититься от уничтожения данных (вирусы, случайное удаление или сбой при обновлении)? Используйте бэкапы.

А использовать HDD на воздухе - это такой себе способ сохранности данных.

Ну дело же не в PHP. Я проводил бенчи и в Symfony/PHP простейший hello world отрабатывает за 4 мс.

Дело в качестве кода. Seafile c самого начала писали с оглядкой на производительность (и в том числе используют тормозной python).

В NextCloud, похоже, производительности внимания не уделили.

Патентовать надо, да.
На счет патентов были же примеры с WebP/AVIF, когда набирается пул и разрешается свободно использовать без лицензионных отчислений. То есть это то, про что можно договориться и в Chrome будет только такие изображения, которые с точки зрения патентов бесплатны и имеют прогнозируемую политику по свободному использованию патентов.

Если ты собираешься взымать деньги за патенты, то все, рынка Chrome тебе не видать.

А как сравнивали?

Тут в чем проблема, как я вижу:
1) стандарты оооочень долго завоевывают браузеры. WebP завоевывал 10 лет и только сейчас его можно использовать без фалбаков с потерей отображения на старых iOS/macOS. За время завоевывания рынка появляются новые стандарты, которые еще на 25% лучше жмут.
2) лучше если будет аппаратное ускорение, чтобы можно было конвертить на лету и декодировать с минимальной нагрузкой CPU. У WebP до сих пор доступного аппаратного кодировщика нет. У JPEG есть, но через сколько лет?

Положим JPEG XL действительно лучше всего другого. Но к тому времени как он завоюет браузеры, он утратит актуальность, поэтому может ставку лучше сделать на то, что хуже, но по всей видимости больше готово к массовой замене JPEG/WebP?

Это я в контексте браузеров все, а не в контексте использования JPEG XL в фото, ОС и т.д.

NextCloud для другого кейса используют: делиться файлами как между несколькими своими устройствами, так и с коллегами для совместной работы.

Синхронизацией там пользуются когда не хотят через веб-интерфейс работать (или не хотят обучать тех, кто отказывается через веб-интерфейс работать, хочет "в папке с windows чтоб просто файл лежал").

Если бы можно быть уверенным, что твое приложение стартанет раньше всех других, кто может писать, то полный скан можно было бы сделать только при первом запуске и хранить все изменения в собственной базе с индексами и не делать полный скан при каждом запуске приложения.

Ага, ну и NextCloud сам по себе тормоз, видимо когда его писали не очень думали про скорость работы. SeaFile быстрее.

Впрочем SeaFile мало что умеет, NextCloud пофичастей, плагинов полно.

Я про это и написал (на самом деле вопрос был чтобы это показать), что с самого начала задача по удовлетворению хотелок @vikarti не решаема.

А можете объяснить, почему досинхрон будет быстрым? Ну положим на сервере можно знать какие файлы изменились, надо логировать запись в базу просто.

А вот как на десктопе синхронизатор узнает какие файлы когда изменились с последнего обновления, чтобы сэкономить и не делать полный рескан всего содержимого?

Это очевидный алгоритм, но он не быстрый, вот в чем дело -)

Начну с того, что рекурсивно спуститься в каталог и достать все 200 000 файлов с метаданными - не быстро. Просто напишите бенч и проверьте, почему не быстро. Если у пользователя HDD, желательно после сканирования папки делать таймаут, чтобы у людей другой IO на диск ходил, а не вставало все колом при запуске клиента.

Потом вам надо метаданные о 200 000 файлов отправить или с клиента на сервер или с сервера на клиент для сравнения различий, это десятки мегабайт данных перелить в сериализованном виде и распарсить там, где сличать будете, затем дать задание для тех, у кого отличия перечитать хеши и еще раз обменяться данными для сравнения.

Надеюсь я объяснил @vikarti про его ожидания "система, быстро синхронизующая жалкие 200 000 небольших файлов".

Information

Rating
Does not participate
Location
Пермь, Пермский край, Россия
Registered
Activity