Хром в сумме всегда мог сожрать больше 4 гигабайт оперативы — он не монолитен, плагины запускаются в отдельных процессах, каждый из которых может сожрать свои 4 гигабайта.
Проблема в том, что начиная с iOS 7.1, появилась фича iCloud Activation Lock. Теперь заблокированный через FMI телефон невозможно разблокировать без участия Apple или доступа к AppleID (если телефон не джейлбрейкнут).
Наличие бэкапа — прекрасно, но телефон останется кирпичом. Factory Reset эту блокировку НЕ снимает.
В 5s — 64Гб памяти. У вас правда есть 64Гб данных, которые нужны на телефоне, причем нужны непрерывно и в любой ситуации (т.е. дропбокс и прочие облачные хранилки не подойдут)?
Это под 100 часов музыки в ALAC или пяток HD-фильмов. Ну правда, куда?
Пока в общем-то не очень понятно, как она переживет наш климат. Мне кажется, что если Теслу оставить на пару дней в -30 на улице, то и батареям, и дисплеям в салоне может стать не очень хорошо. И даже совсем не хорошо.
Ну и на наших дорогах, особенно за городом, ее пневмоподвеска убивается кошмарно быстро.
Неверный принцип выбора технологий, совсем неверный.
Выбирать технологии под знания *всей* команды — это прямой путь к отставанию от прогресса. «Мы этого не знаем» — это вообще не аргумент. Аргумента может быть два:
— Нам эта технология подходит (и тогда мы ее изучаем и используем)
— Нам эта технология не подходит (и тогда мы ее в этом проекте не используем, даже если знаем)
Команда, которая будет пытаться иметь равные компетенции и избегать вещей, непонятных хоть кому-то из ее членов будет хранически на несколько лет отставать от актуальных технологий, т.к. пока нечто новое узнают и освоят (без пинков, как я понимаю) *все* — пройдет очень много времени.
Специалистов нужно слегка подталкивать к развитию своих знаний и навыков, даже если им этого не особо-то и хочется, но в проекте это нужно.
Вообще, довольно странное понимание у авторов ресурса понятия 'bug'. Вот это, например, совсем не bug — AXFR-ответ является частью стандарта DNS (RFC-1035) и такое поведение сервера — есть полное соответствие вышеназванному стандарту.
Закрытие AXFR в целях безопасности мера во-первых, довольно сомнительная (но это вопрос для дискуссии), а во-вторых — чисто опциональная и применяться может и должна только в случае, если во-первых, AXFR не используется и во-вторых, в DNS содержится некая приватная информация. Бага здесь нет. Уязвимости в чистом виде (т.е. при условии отсутствия уязвимостей в сервисах, работащих на этих именах) — тоже.
А что именно можно в ГУ делать через ЭЦП? Просто интересно. Вообще без физического присутствия решать вопросы, или по стандартной ГУшной схеме «подай в электронном виде, а потом принеси еще и в бумажном» (как на загранпаспорт, например)?
Эта уязвимость критична именно потому, что FF17 является ESR и поддерживается не смотря на то, что есть уже FF22.
Был бы он не ESR — уязвимости в прошлогодней версии никого бы и не волновали.
Во-первых, смартфон больше (занимает половину лобовика), тяжелее и быстрее садится (в режиме записи), чем любой регистратор.
Во-вторых, нормальный регистратор спроектирован с учетом вероятности ДТП и скорее всего его переживет, а смартфон умрет гарантированно.
В-третьих, в регистраторах, как правило, довольно специфичный алгоритм записи (кусочками с максимальным сдампливанием на флешку, т.к. регистратор в любой момент может умереть).
А цена и качество… не берите китай, что могу сказать. Камера BlackVue, например, даст фору камере iPhone 5, а в ночном режиме — вообще практически любого телефона. На нормальных КарКамах и ДОДах — тоже.
Во-первых, интернет и не надо. Сеть организации (и даже manage vlan), как правило, не настолько доверенная, чтобы давать root от СХД любому, кто способен открыть гугл и набрать «storevirtual hpsupport password».
Во-вторых, кейсы бывают разные. Я вполне могу придумать кейс, для реализации которого требовался бы доступ к СХД из не доверенной сети.
В-третьих, ж… или не ж.., а процентов 80 администраторов могут не задумываясь открыть себе удаленный доступ к СХД, чтобы в субботу в офис не ездить, если донастроить не успел. А потом забыть его закрыть.
Наличие бэкапа — прекрасно, но телефон останется кирпичом. Factory Reset эту блокировку НЕ снимает.
Это под 100 часов музыки в ALAC или пяток HD-фильмов. Ну правда, куда?
Ну и на наших дорогах, особенно за городом, ее пневмоподвеска убивается кошмарно быстро.
Выбирать технологии под знания *всей* команды — это прямой путь к отставанию от прогресса. «Мы этого не знаем» — это вообще не аргумент. Аргумента может быть два:
— Нам эта технология подходит (и тогда мы ее изучаем и используем)
— Нам эта технология не подходит (и тогда мы ее в этом проекте не используем, даже если знаем)
Команда, которая будет пытаться иметь равные компетенции и избегать вещей, непонятных хоть кому-то из ее членов будет хранически на несколько лет отставать от актуальных технологий, т.к. пока нечто новое узнают и освоят (без пинков, как я понимаю) *все* — пройдет очень много времени.
Специалистов нужно слегка подталкивать к развитию своих знаний и навыков, даже если им этого не особо-то и хочется, но в проекте это нужно.
Закрытие AXFR в целях безопасности мера во-первых, довольно сомнительная (но это вопрос для дискуссии), а во-вторых — чисто опциональная и применяться может и должна только в случае, если во-первых, AXFR не используется и во-вторых, в DNS содержится некая приватная информация. Бага здесь нет. Уязвимости в чистом виде (т.е. при условии отсутствия уязвимостей в сервисах, работащих на этих именах) — тоже.
Виджеты комментирования соцсетей, социальные закладки и т.д. — прекрасно может.
По факту же такой монитор если и купят, то директору, а дежурным инженерам поставят самые дешевые китайские мониторы.
Эта уязвимость критична именно потому, что FF17 является ESR и поддерживается не смотря на то, что есть уже FF22.
Был бы он не ESR — уязвимости в прошлогодней версии никого бы и не волновали.
Во-первых, смартфон больше (занимает половину лобовика), тяжелее и быстрее садится (в режиме записи), чем любой регистратор.
Во-вторых, нормальный регистратор спроектирован с учетом вероятности ДТП и скорее всего его переживет, а смартфон умрет гарантированно.
В-третьих, в регистраторах, как правило, довольно специфичный алгоритм записи (кусочками с максимальным сдампливанием на флешку, т.к. регистратор в любой момент может умереть).
А цена и качество… не берите китай, что могу сказать. Камера BlackVue, например, даст фору камере iPhone 5, а в ночном режиме — вообще практически любого телефона. На нормальных КарКамах и ДОДах — тоже.
Сначала программист ошибется в коде, потом администратор в настройке, потом аналитик просмотрит при аудите — «ой, нас взломали».
Нормальная система не должна давать выстрелить себе в ногу как минимум случайно.
Во-первых, интернет и не надо. Сеть организации (и даже manage vlan), как правило, не настолько доверенная, чтобы давать root от СХД любому, кто способен открыть гугл и набрать «storevirtual hpsupport password».
Во-вторых, кейсы бывают разные. Я вполне могу придумать кейс, для реализации которого требовался бы доступ к СХД из не доверенной сети.
В-третьих, ж… или не ж.., а процентов 80 администраторов могут не задумываясь открыть себе удаленный доступ к СХД, чтобы в субботу в офис не ездить, если донастроить не успел. А потом забыть его закрыть.