Dayan Guhong считается одним из самых быстрых, при этом достаточно тихим (хотя всё равно гремит). Зато его разломать весьма тяжело при неаккуратном движении.
Могу ещё попробовать найти другой кубик, от первого попавшегося китайского производителя — он ещё тише и дешевле, но при быстрой сборки может весь разлететься по комнате.
И да, берите с цветными гранями, а не наклейками, на соревнования с такими не пустят, зато они гораздо дольше служат и веселее. :)
3. Исторически сложился log4net — особого смысла менять, пока не видим.
Пока, имхо, стоит ждать .NET Core 2.0, смотреть что у них получится, заодно фидбека и best practices накопится. С Mono, если удастся подобрать идентичное железо попробую натравить свою числодробилку, оптимизированную под .NET, на Mono и .NET Core, посмотрю на результаты. Если не забуду, отпишусь :)
С этим .NET Core иногда нужно столько переписывать, что пункт 3 из вашего списка не кажется таким уж проблемным. То, что я увидел в .NET Core:
1. Полностью переделана конфигурация. Т.е. сегодня модно в JSON, завтра в protobuf будет. Придётся переписывать весь конфиг для проектов.
2. Очень сильно перекочеврыжен рефлекшен. В большинстве случаев решается через GetTypeInfo (обезьянкой ходишь по коду и вставляешь эту строчку). Опять же, переписывать кучу всего.
3. Потеря кучи библиотек, или сидеть ждать, когда авторы переделают, или пытаться самостоятельно, если исходники есть. Банальный log4net не работает
4. Постоянная смена API. Например, Kestrel с каждой версией полностью меняет API. При этом «каждая» версия это (1.0.0-beta, 1.0.0-rc, 1.0.0). До кучи бардак в репозиториях — тот же кестрел лежит под тремя именами.
5. Периодически мелкое изменение API стандартных библиотек в самых неожиданных местах. Например у RSA нельзя получить XML с параметрами. Т.е. весь код надо обкладывать ифами и проводить тестирование
При этом по факту, под mono работает то, что и вроде бы и не должно работать, например HttpListener. Скорость — не ясно, но числодробилки на .NET реализовывать странно, а в бизнес.приложениях всё равно всё упирается в базу данных, или как у вас в SOAP, который архитектурно никогда быстрым не был.
Заменили батарейку на ту, которая не должна взрываться (они вроде писали, что проблема с анодом и катодом, из-за которого происходит КЗ со спец.эффектами). Для старых партий принудительно накатили обновление, которое ограничивает заряд 60%
Ну, вообще void — это тип. System.Void, и вы можете сделать typeof(void), больше, правда ничего не можете сделать с ним. Т.е. в кишках тип номинально уже есть. Какой-нить Invoke, имеющий возвращаемый тип object, на void возвращает null (с горя). Т.е. уже встроенная библиотека .NET борется с этим типом.
На мой взгляд, Func<void> всё-таки лучше чем грустный Action. Хотелось бы, чтобы его можно было использовать более гибко.
Ну вот мне, кажется, что гораздо хуже чем null, в дизайне C#, это void. Из-за этого сейчас активно дублируется всё API по работе с функциями (Action и Func, Task и Task<>). Вот это, раздражает гораздо больше.
Да, бюджетные Dedicated.
С i7 можно ещё сэкономить на материнке кроме самого процессора.
Серверная винда не такая уж и дорогая, и хостеры перекладывают её стоимость на клиента.
Хостеры иногда любят i5 и i7 использовать (да и я их люблю, если честно), ибо дешевле ксеонов. Если многопроцессорность в сервере не нужна, то это отличный выбор.
Какой-то бред, Microsoft до сих пор не может родить Windows Server 10 (ну или 2016), т.е. серверную версию 10-ой винды, а уже с умным видом говорит, что драйверов не будет. Их за такое корпоративщики распнут.
А если будут серверные драйвера, то тот же Windows Server 2008 R2 поддерживается до 2020-ого года, и имеет тоже ядро что и обычная семёрка, собственно значит и в семёрке фактически будут.
Могут запретить ставить сервер не на ксеоны (тут уже и хостеры с вилами и факелами подойдут), но задним числом всё равно не смогут ничего изменить. Так что, во что это выльется — вообще непонятно.
Да, а про глюки и прочее, имхо, обычные страшилки. Всё будет работать как раньше, обратную совместимость никто не отменял.
Может нотификации? Вроде в андроиде нет нормального разграничения прав, на получение смс, факт получения смс, отправку смс. Поэтому и хватают, что можно, ради мелкой фичи.
Хм… а почему сравнивали JPEG, а не какой-нить JPEG2000 или ещё что-нить из новенького? Тот же JPEG2000 даёт гораздо лучшее изображение, а артефакты гораздо приятнее для глаза.
Да. Есть доля шутки. Но просто имейте в виду, что сейчас много пользователей пользуются интернетом именно с телефона, и для них не проблема держать телефон вертикально, чтобы смотреть видео (а вот если ютуб не позволяет подобное — это ему минус).
Сам не люблю вертикальное видео, но иногда без него не обойтись, потому что человек существо вертикальное (обычно) и не любит сливаться с ландшафтом. А угол камеры телефона не позволяет снимать человека в полный рост в горизонтальном режиме.
и что насчет времени при компрессии high\ultra — может тоже проблема с базами больше 2гб?
Да с этим вроде нет проблем, это просто 7z такой медленный.
проводили ли тесты на промышленных масштабах 200-300-500Гб? но поскольку база в кластере и утилита может работать только с локальным сервером, увы не получится...(
Тут не должно быть никаких проблем, только долго (ну и обычный бекап долгий в данном случае). А с кластером — если на одном из узлов локально запустить?
Смотрите, тут дело в том, что вы можете получить 7z быстрее и проще чем стандартными средствами (и не тратить место на диске). А потом этот 7z восстановить не распаковывая. А т.к. 7z жмёт гораздо лучше чем zip и стандартные средства, для долговременного хранения лучше использовать его (если есть время). Ну или для быстрых бекапов уменьшить качество сжатия.
По цифрам.
Вариант раз на слабом сервере. Стандартные средства 74 секунды бекап + 391 секунда сжатия в 7z = 465. Тот же эффект через PackDb — 446 секунд.
Варинат два на мощном сервере (база другая). 192 + 399 = 591 против 413.
Размер базы для примера: без сжатия 8.3Gb, сжатие средствами SQL — 1.9Gb, сжатие в 7z — 0.46Gb. Т.е. выигрыш на 1.5Gb для одной базы.
По поводу проблем с зипом — обнаружили, виновные будут наказаны. Есть проблемы со сжатием в zip при размерах базы более 2Gb (у зипа постоянно с этим проблемы лезут).
Могу ещё попробовать найти другой кубик, от первого попавшегося китайского производителя — он ещё тише и дешевле, но при быстрой сборки может весь разлететься по комнате.
И да, берите с цветными гранями, а не наклейками, на соревнования с такими не пустят, зато они гораздо дольше служат и веселее. :)
Пока, имхо, стоит ждать .NET Core 2.0, смотреть что у них получится, заодно фидбека и best practices накопится. С Mono, если удастся подобрать идентичное железо попробую натравить свою числодробилку, оптимизированную под .NET, на Mono и .NET Core, посмотрю на результаты. Если не забуду, отпишусь :)
1. Полностью переделана конфигурация. Т.е. сегодня модно в JSON, завтра в protobuf будет. Придётся переписывать весь конфиг для проектов.
2. Очень сильно перекочеврыжен рефлекшен. В большинстве случаев решается через GetTypeInfo (обезьянкой ходишь по коду и вставляешь эту строчку). Опять же, переписывать кучу всего.
3. Потеря кучи библиотек, или сидеть ждать, когда авторы переделают, или пытаться самостоятельно, если исходники есть. Банальный log4net не работает
4. Постоянная смена API. Например, Kestrel с каждой версией полностью меняет API. При этом «каждая» версия это (1.0.0-beta, 1.0.0-rc, 1.0.0). До кучи бардак в репозиториях — тот же кестрел лежит под тремя именами.
5. Периодически мелкое изменение API стандартных библиотек в самых неожиданных местах. Например у RSA нельзя получить XML с параметрами. Т.е. весь код надо обкладывать ифами и проводить тестирование
При этом по факту, под mono работает то, что и вроде бы и не должно работать, например HttpListener. Скорость — не ясно, но числодробилки на .NET реализовывать странно, а в бизнес.приложениях всё равно всё упирается в базу данных, или как у вас в SOAP, который архитектурно никогда быстрым не был.
На мой взгляд, Func<void> всё-таки лучше чем грустный Action. Хотелось бы, чтобы его можно было использовать более гибко.
С i7 можно ещё сэкономить на материнке кроме самого процессора.
Серверная винда не такая уж и дорогая, и хостеры перекладывают её стоимость на клиента.
А если будут серверные драйвера, то тот же Windows Server 2008 R2 поддерживается до 2020-ого года, и имеет тоже ядро что и обычная семёрка, собственно значит и в семёрке фактически будут.
Могут запретить ставить сервер не на ксеоны (тут уже и хостеры с вилами и факелами подойдут), но задним числом всё равно не смогут ничего изменить. Так что, во что это выльется — вообще непонятно.
Да, а про глюки и прочее, имхо, обычные страшилки. Всё будет работать как раньше, обратную совместимость никто не отменял.
Сам не люблю вертикальное видео, но иногда без него не обойтись, потому что человек существо вертикальное (обычно) и не любит сливаться с ландшафтом. А угол камеры телефона не позволяет снимать человека в полный рост в горизонтальном режиме.
normal
Да с этим вроде нет проблем, это просто 7z такой медленный.
Тут не должно быть никаких проблем, только долго (ну и обычный бекап долгий в данном случае). А с кластером — если на одном из узлов локально запустить?
Пожелания записали, будут ресурсы — сделаем.
По цифрам.
Вариант раз на слабом сервере. Стандартные средства 74 секунды бекап + 391 секунда сжатия в 7z = 465. Тот же эффект через PackDb — 446 секунд.
Варинат два на мощном сервере (база другая). 192 + 399 = 591 против 413.
Размер базы для примера: без сжатия 8.3Gb, сжатие средствами SQL — 1.9Gb, сжатие в 7z — 0.46Gb. Т.е. выигрыш на 1.5Gb для одной базы.
По поводу проблем с зипом — обнаружили, виновные будут наказаны. Есть проблемы со сжатием в zip при размерах базы более 2Gb (у зипа постоянно с этим проблемы лезут).