C Firefox 28 подключили новый, хромоподобный, интерфейс. Но нравится он не всем...
http://www.opennet.ru/opennews/art.shtml?num=38504
Вернуть интерфейс примерно к старому виду:
Classic Theme Restorer
Но вообще, клонировать хром это тупиковый путь, и хром выбирают совсем не за скругления табов... Мне, например,хром нравится нормальной работой с флэшем, тормоза флэша никак не мешают остальному браузеру, и подвисание части табов не мешает работе с активной парой табов. Причина -- в многопоточности и многопроцессности хрома. Можно даже снять спокойно наиболее прожорливый процесс, а когда содержимое связанных табов понадобится - просто обновить страницу.
А не нравятся оба прожорливостью памяти. Например, хром на 600 табах ест более 20Гб оперативки, ФФ 2.0 на 700 табах влезало в 2 гига. Правда, сейчас ФФ ест даже больше хрома и течёт памятью. Эта идиотская гонка версий тоже чего стоит. А вообще, будь моя воля, стояли бы у меня везде ФФ 3.5, как "последняя из могикан".
Ещё убрали диспетчер вкладок. Вообще. У того же хрома диспетчер есть и вполне рабочий, так что халтурно функционал копируют.
Показаны сообщения с ярлыком размышления. Показать все сообщения
Показаны сообщения с ярлыком размышления. Показать все сообщения
среда, 18 июня 2014 г.
воскресенье, 23 марта 2014 г.
Рассуждения о Software Defined Storage: что не так с IO?
http://habrahabr.ru/post/124755/
Первое прочтение: как он прав.
Второе: какой бред..
Третье: что-то разумное есть, но в целом идея не очень. Действительно, СХД может тоже выдать сбой, но это всегда требует переписывания софта, потому что только софт может знать, что и как обрабатывать. А дальнейшие размышления в комментах на тему вероятности правдивости -- реальный бред.
Первое прочтение: как он прав.
Второе: какой бред..
Третье: что-то разумное есть, но в целом идея не очень. Действительно, СХД может тоже выдать сбой, но это всегда требует переписывания софта, потому что только софт может знать, что и как обрабатывать. А дальнейшие размышления в комментах на тему вероятности правдивости -- реальный бред.
четверг, 9 января 2014 г.
немного о GPON
Навеяно Зачем МГТС двигает PON
Автор явно паникёр и не понимает многих вещей, но некоторые опасения действительно не пустые.
Да, сокращение размеров оборудования - это хорошо, и вместо 5 этажей на АТС достаточно 1 этажа, а то и пары комнат. Плюс ИБП достаточной мощности и ёмкости, плюс дизель (пара). Система пассивна, поэтому питание на промежуточных точках не нужно. А вот конечное оборудование - ONT (Optical Network Terminal) - представляет ряд проблем:
Автор явно паникёр и не понимает многих вещей, но некоторые опасения действительно не пустые.
Да, сокращение размеров оборудования - это хорошо, и вместо 5 этажей на АТС достаточно 1 этажа, а то и пары комнат. Плюс ИБП достаточной мощности и ёмкости, плюс дизель (пара). Система пассивна, поэтому питание на промежуточных точках не нужно. А вот конечное оборудование - ONT (Optical Network Terminal) - представляет ряд проблем:
- ему требуется питание, а также системы резервного питания (и менять батареи раз в 1-3 года)
- устройства не "тупые" телефоны, а по сути компьютеры, с уязвимостями, зависаниями и прочими проблемами
- зачастую открытый наружу административный интерфейс и пароль, легко подбираемый по некоторым шаблонам (см хабр)
- многим ставится оборудование с wifi, который конечному клиенту не нужен (всяким бабушкам), а эфир забивает + ещё уязвимость, причём весьма серьёзная: см хабр про вшитые пароли, не подлежащие отключению + слабые пароли...
- если вместо ONT поставить (не)обычный медиаконвертер, худо станет всей ветке
- внутри GPON телефония бегает по обычному SIP -- ещё слой отказа. Да и протокол не лучший, тот же IAX поинтереснее будет
- входящий канал идёт всем, поэтому возможно сниффать чужой траф. Привет, хабы. *
* Прямой поток на уровне оптических сигналов является широковещательным. Каждый абонентский узел ONT, читая адресные поля, выделяет из этого общего потока предназначенную только ему часть информации. Фактически, мы имеем дело с распределённым демультиплексором. (1)
Ну и некоторая сложность диагностики пон-линий, простой рефлектометр из-за делителей тут уже плохо подходит. И отлов сбойного/"левого" конвертера может стать той ещё сказкой.
Линки
пятница, 29 марта 2013 г.
perl+cpan
Если есть возможность, всегда надо ставить штатной системой пакетов. Но иногда всё-таки нужно ставить из цпана, делается это так
perl -MCPAN -e 'install DBD::mysql'
Могут быть ошибки разного рода, например
dbdimp.c:3215 error: 'imp_sth_t' has no member named 'warning_count'
В данном случае видно, что это ошибка сборки dbdimp.c, то есть проблема зависимостей библиотек. В линуксе обычно требуется сначала поставить mysql-devel + mysqlclient. В общем, тут нет автоматического решения зависимостей, и это ещё один минус такой ручной установки. Ну и сложнее потом сопровождать такую систему, поэтому если нужен 1-2 модуля, можно их просто скачать прямо в проект, доставив зависимости через систему.
Линки
http://twiki.org/cgi-bin/view/TWiki/HowToInstallCpanModules
http://www.dark.ca/2010/04/08/cpan-rpms-in-rhel-centos/
http://stackoverflow.com/questions/1440320/installation-of-perl-packages-is-failing-on-centos-5-64-bit
perl -MCPAN -e 'install DBD::mysql'
Могут быть ошибки разного рода, например
dbdimp.c:3215 error: 'imp_sth_t' has no member named 'warning_count'
В данном случае видно, что это ошибка сборки dbdimp.c, то есть проблема зависимостей библиотек. В линуксе обычно требуется сначала поставить mysql-devel + mysqlclient. В общем, тут нет автоматического решения зависимостей, и это ещё один минус такой ручной установки. Ну и сложнее потом сопровождать такую систему, поэтому если нужен 1-2 модуля, можно их просто скачать прямо в проект, доставив зависимости через систему.
Линки
http://twiki.org/cgi-bin/view/TWiki/HowToInstallCpanModules
http://www.dark.ca/2010/04/08/cpan-rpms-in-rhel-centos/
http://stackoverflow.com/questions/1440320/installation-of-perl-packages-is-failing-on-centos-5-64-bit
суббота, 5 января 2013 г.
OpenFlow на хабре
Программно-конфигурируемые сети — как это работает?
Сколько стоит SDN?
Программно определяемые сети (Software Defined Networks): настоящее и будущее
Как работать с Openflow контроллером NOX
[openflow]
Ну и вики
Совсем вкратце: это как SNMP, только глобальнее. И более стандартизовано, хотя на данный момент стандарт весьма убог, ибо молодой.
Можно сравнивать с VMware Distributed Switch (пока не углубляюсь)
Зато уже есть всякие Cisco One, полностью под эту систему.
Применимость пока непонятна, а особенно когда много мелких динамичных потоков. То, что раньше было внутри свичей, теперь сидит где-то снаружи.
Скорее всего применимо на стыке облаков и реального железа.
"Пока еще рано говорить о серьезных индустриальных решениях в области ПКС, самой разработке всего 5 лет. Можно сказать, что она только выходит из лабораторий, поэтому «белых пятен» много.Фактически ПКС в промышленных масштабах еще никто не пробовал.
Но то, что практически все крупных вендоры так или иначе начали делать оборудование и ПО под ПКС-сети (кроме Cisco свичи с поддержкой режима OpenFlow делает HP, Brocade, Juniper, Extreme Networks …, у Marvel, NEC и Pronto есть OpenFlow-only коммутаторы), плюс в эту тему влез еще и Google c Yahoo и ряд крупных провайдеров AT&T, NTT говорит о том, что индустрия на будущее считает ПКС очень перспективной и «денежной» технологий. Думаю, что в ближайшие 2-3 года все станет понятно "
Из комментов.
Сколько стоит SDN?
Программно определяемые сети (Software Defined Networks): настоящее и будущее
Как работать с Openflow контроллером NOX
[openflow]
Ну и вики
Совсем вкратце: это как SNMP, только глобальнее. И более стандартизовано, хотя на данный момент стандарт весьма убог, ибо молодой.
Можно сравнивать с VMware Distributed Switch (пока не углубляюсь)
Зато уже есть всякие Cisco One, полностью под эту систему.
Применимость пока непонятна, а особенно когда много мелких динамичных потоков. То, что раньше было внутри свичей, теперь сидит где-то снаружи.
Скорее всего применимо на стыке облаков и реального железа.
"Пока еще рано говорить о серьезных индустриальных решениях в области ПКС, самой разработке всего 5 лет. Можно сказать, что она только выходит из лабораторий, поэтому «белых пятен» много.Фактически ПКС в промышленных масштабах еще никто не пробовал.
Но то, что практически все крупных вендоры так или иначе начали делать оборудование и ПО под ПКС-сети (кроме Cisco свичи с поддержкой режима OpenFlow делает HP, Brocade, Juniper, Extreme Networks …, у Marvel, NEC и Pronto есть OpenFlow-only коммутаторы), плюс в эту тему влез еще и Google c Yahoo и ряд крупных провайдеров AT&T, NTT говорит о том, что индустрия на будущее считает ПКС очень перспективной и «денежной» технологий. Думаю, что в ближайшие 2-3 года все станет понятно "
Из комментов.
воскресенье, 23 декабря 2012 г.
Начало развала GNU?
Лидеры проектов GnuTLS, grep и sed выходят из движения GNU в знак несогласия с политикой Фонда СПО
"Никос Маврогианнопулос (Nikos Mavrogiannopoulos), создатель, ключевой разработчик и лидер проекта GnuTLS, объявил о выводе GnuTLS из-под контроля Фонда СПО и движения GNU. Разработка GnuTLS перемещена из инфраструктуры GNU, при передаче кода проекту больше не требуется подписание соглашения о передаче имущественных прав Фонду СПО.
В качестве причины называется несогласие с системой принятия решений и действиями Фонда СПО, притом, что Никос по-прежнему остаётся сторонником идей, продвигаемых Фондом СПО. Указывается на то, что в движении GNU отсутствует возможность влияния на принятие решений, все решения единолично исходят от Столлмана, а не принимаются в ходе дискуссий, учитывающих различные мнения. Поэтому Никос устал от того, что его участие в проекте ограничивается только написанием кода, без возможности выражения и обсуждения различных точек зрения."
И далее несколько неадекватная позиция Столлмана, который держится за власть зубами.
Истинные причины неизвестны. То ли проблемы с финансированием, то ли невозможность отдавать код под двойной лицензией и зарабатывать на закрытой версии, то ли неадекватность Столлмана... Сложно судить. Тем не менее, если это будет первым шагом и другие так же начнут выходить из проекта - Столлману не поздоровится.
Только имеет смысл сразу создать другой фонд, чтобы собирать этих уходящих на других условиях... И потом, "Если это плохо реализовано в Unix, не стесняйтесь заменить это на что-то совершенно иное и более совершенное"...
Хотя лишнее дробление чревато сказкой про журавля, рака и щуку.
"Никос Маврогианнопулос (Nikos Mavrogiannopoulos), создатель, ключевой разработчик и лидер проекта GnuTLS, объявил о выводе GnuTLS из-под контроля Фонда СПО и движения GNU. Разработка GnuTLS перемещена из инфраструктуры GNU, при передаче кода проекту больше не требуется подписание соглашения о передаче имущественных прав Фонду СПО.
В качестве причины называется несогласие с системой принятия решений и действиями Фонда СПО, притом, что Никос по-прежнему остаётся сторонником идей, продвигаемых Фондом СПО. Указывается на то, что в движении GNU отсутствует возможность влияния на принятие решений, все решения единолично исходят от Столлмана, а не принимаются в ходе дискуссий, учитывающих различные мнения. Поэтому Никос устал от того, что его участие в проекте ограничивается только написанием кода, без возможности выражения и обсуждения различных точек зрения."
И далее несколько неадекватная позиция Столлмана, который держится за власть зубами.
Истинные причины неизвестны. То ли проблемы с финансированием, то ли невозможность отдавать код под двойной лицензией и зарабатывать на закрытой версии, то ли неадекватность Столлмана... Сложно судить. Тем не менее, если это будет первым шагом и другие так же начнут выходить из проекта - Столлману не поздоровится.
Только имеет смысл сразу создать другой фонд, чтобы собирать этих уходящих на других условиях... И потом, "Если это плохо реализовано в Unix, не стесняйтесь заменить это на что-то совершенно иное и более совершенное"...
Хотя лишнее дробление чревато сказкой про журавля, рака и щуку.
MySQL Master-Master
Основная дока этой заметки:
Опыт эксплуатации MySQL Master-Master — как пережить аварию датацентра
Плюс о репликации у меня есть
http://dragonflybsd.blogspot.ru/search/label/mysql
Опыт эксплуатации MySQL Master-Master — как пережить аварию датацентра
Плюс о репликации у меня есть
http://dragonflybsd.blogspot.ru/search/label/mysql
суббота, 22 декабря 2012 г.
Облако от infobox
Вот и infobox включился в популярные нынче облака. Вот только их облако относительно честное типа селектела или это обычный VDS, который можно с натяжкой назвать облачным vds (но не честным облаком!)?
Сам сервис, на базе решения Parallels Automation for Cloud Infrastructure:
http://infobox.ru/cloud/servers/
Хотя судя по ценам, появляется надежда что это настоящее честное облако, где оплата именно по потреблению, а не за то, что выставляли предварительно.
Некоммерческое тестирование продлится до 1 февраля 2013 года.
Хотя надо относиться к услугам компании infobox с некоторой осторожностью: месяца 2 назад они полностью лежали по меньшей мере пол дня (мне помнится, что более суток), включая их днс, которые обязаны быть географически распределены. Так что мешает лечь их облаку при очередном DDoS?
Тем более у них НЕТ нормального дц, а тот что есть, тянет хорошо если на минимальный уровень. Дизеля нет, охлаждение уличным воздухом без фильтров, каналы довольно тощие, покупать честные МБиты канала довольно дорого, около 1.5к руб за 1мбит... Хотя есть надежда, что у них арендованы стойки в 2-3 нормальных современных ДЦ и весь траф не проходит через 1 место (вспоминаем селектел, когда московский ДЦ не был доступен из-за аварии в питере).
UP
http://twitpic.com/r5rpv
Сам сервис, на базе решения Parallels Automation for Cloud Infrastructure:
http://infobox.ru/cloud/servers/
Хотя судя по ценам, появляется надежда что это настоящее честное облако, где оплата именно по потреблению, а не за то, что выставляли предварительно.
Некоммерческое тестирование продлится до 1 февраля 2013 года.
Хотя надо относиться к услугам компании infobox с некоторой осторожностью: месяца 2 назад они полностью лежали по меньшей мере пол дня (мне помнится, что более суток), включая их днс, которые обязаны быть географически распределены. Так что мешает лечь их облаку при очередном DDoS?
Тем более у них НЕТ нормального дц, а тот что есть, тянет хорошо если на минимальный уровень. Дизеля нет, охлаждение уличным воздухом без фильтров, каналы довольно тощие, покупать честные МБиты канала довольно дорого, около 1.5к руб за 1мбит... Хотя есть надежда, что у них арендованы стойки в 2-3 нормальных современных ДЦ и весь траф не проходит через 1 место (вспоминаем селектел, когда московский ДЦ не был доступен из-за аварии в питере).
UP
http://twitpic.com/r5rpv
Amazon Glacier
Скинули недавно линк на новый сервис амазона Amazon Glacier. Это такое мегадешёвое хранилище для бэкапов со временем доступности данных оттуда порядка 4-5 часов
четверг, 20 декабря 2012 г.
бэкап mysql без простоев
Самый простой метод бэкапа - на рабочем сервере - часто вызывает простои, поскольку на время бэкапа БД вешает локи, и на больших таблицах это бывает очень заметно. Простой способ решить эту проблему - сделать на отдельном или даже том же сервере инстанс БД в режиме slave, только не забываем выставить уникальный server-id и прописать в конфиг слейву режим read-only. И теперь можно сделать очень интересную штуку: остановим слейв (достаточно только SQL thread) и можно дампить. Из плюсов - мы даже можем дампить разные базы и таблицы в разные файлы, сохранив при этом целостность репликации! То есть можно потом загрузить на новый сервер все эти файлы, и мы будем знать master_log_pos для этой схемы! Суть в том, что поскольку слейв остановлен, master_log_pos меняться не будет, поэтому достаточно сохранить пару log_pos и log_file и мы можем использовать этот комплект при разворачивании нового слейва или даже мастера. Главное, не забыть залить полную структуру :)
Есть вариант 2, поставив flush tables with read lock и сделав снапшот, но это хоть небольшой но простой и не очень хорошо автоматизируется: из самого mysql не сказать "сделать снапшот", и нельзя закрывать соединение с базой раньше времени, иначе лок снимется. Вдобавок, если была обработках больших объёмов, можно очень долго ждать пока лок встанет, что может сильно увеличить простой системы. И опять же для правильного бэкапа нужен отдельный инсанс базы, например innodb нельзя бэкапить просто запаковав его файлы.
Вариант 3 - используя mysqldumpslow, но ничего про него сказать не могу, у нас пока не применялось. И вопрос с сохранением master_log_pos, особенно применимо к записи по разным файлам.
Для MyISAM есть метод простого копирования файлов, сделать только сначала flush tables, и снова это не сохранит позицию.
Есть вариант 2, поставив flush tables with read lock и сделав снапшот, но это хоть небольшой но простой и не очень хорошо автоматизируется: из самого mysql не сказать "сделать снапшот", и нельзя закрывать соединение с базой раньше времени, иначе лок снимется. Вдобавок, если была обработках больших объёмов, можно очень долго ждать пока лок встанет, что может сильно увеличить простой системы. И опять же для правильного бэкапа нужен отдельный инсанс базы, например innodb нельзя бэкапить просто запаковав его файлы.
Вариант 3 - используя mysqldumpslow, но ничего про него сказать не могу, у нас пока не применялось. И вопрос с сохранением master_log_pos, особенно применимо к записи по разным файлам.
Для MyISAM есть метод простого копирования файлов, сделать только сначала flush tables, и снова это не сохранит позицию.
среда, 21 ноября 2012 г.
SSD серверного назначения
Обычно стоят сильно дороже бытового сегмента, но обладают бОльшей наработкой на отказ. Обычно на SLC, но сейчас появляется всё больше на eMLC.
Из наиболее известных - intel x25-e, на SLC, уже снятый с производства.
Известная серия FusionIO - ставится в pci-e, очень быстрые, но очень дорогие диски.
Первый взгляд на Fusion-IO ioDrive2 плюс комменты.
Про intel 710 уже было
http://habrahabr.ru/qa/24271/#answer_99211
Надежность — 520 интел.
Скорость — 4 вертекс.
Бюджетность — круциал.
На nix.ru есть тестирование:
http://www.nix.ru/hardware-review/ssd-benchmark-performance.html
...где практически на всех дисках в описании "Невозможно использование в серверах из-за недостаточного ресурса", что основано на технологии их чипов памяти. Хотя опять же, в роли кэша чтения жить они будут нормально.
У 520 интела (да и у многих других ссд) есть нюанс: чем больше объём, тем выше скорость (iops). Это связано с тем, что микросхемы памяти там ставятся параллельно, и внутри диска будет несколько одновременных каналов работы. И чем больше микросхем, тем больше каналов можно задействовать (до лимита чипа, обычно 10 каналов), поэтому отличия 60 и 180гб моделей по иопс примерно в 3 раза.. а вот дальше уже роста скорости почти нет.
(потом дополню еще моделями)
Из наиболее известных - intel x25-e, на SLC, уже снятый с производства.
Известная серия FusionIO - ставится в pci-e, очень быстрые, но очень дорогие диски.
Первый взгляд на Fusion-IO ioDrive2 плюс комменты.
Про intel 710 уже было
http://habrahabr.ru/qa/24271/#answer_99211
Надежность — 520 интел.
Скорость — 4 вертекс.
Бюджетность — круциал.
На nix.ru есть тестирование:
http://www.nix.ru/hardware-review/ssd-benchmark-performance.html
...где практически на всех дисках в описании "Невозможно использование в серверах из-за недостаточного ресурса", что основано на технологии их чипов памяти. Хотя опять же, в роли кэша чтения жить они будут нормально.
У 520 интела (да и у многих других ссд) есть нюанс: чем больше объём, тем выше скорость (iops). Это связано с тем, что микросхемы памяти там ставятся параллельно, и внутри диска будет несколько одновременных каналов работы. И чем больше микросхем, тем больше каналов можно задействовать (до лимита чипа, обычно 10 каналов), поэтому отличия 60 и 180гб моделей по иопс примерно в 3 раза.. а вот дальше уже роста скорости почти нет.
(потом дополню еще моделями)
вторник, 20 ноября 2012 г.
правда и заблуждения о долговечности SSD
Kingston HyperX 3K: правда и заблуждения о долговечности SSD
Складывается ощущение, что даже с 3к-ячейками эти диски долговечны... Тем не менее, многие дают на такие диски гарантию всего год, причём если у диска выработан полностью ресурс (!) -- это уже не гарантийный случай (!!). Ну и вспоминаем SLC с ресурсом в 100к записей на ячейку.
А сложно ли выработать этот ресурс? На самом деле - несложно. И даже если исключить серверную сферу, где такой диск можно "съесть" за месяц, банально windows 7 + мало памяти + swap на таком диске - работать будет неплохо.. но довольно недолго. Не месяц конечно, но год это будет уже очень хорошо.
Поэтому эти диски хороши там, где много чтения и мало записи - кэш чтения, система без свопа, фильмы, игрушки...
Складывается ощущение, что даже с 3к-ячейками эти диски долговечны... Тем не менее, многие дают на такие диски гарантию всего год, причём если у диска выработан полностью ресурс (!) -- это уже не гарантийный случай (!!). Ну и вспоминаем SLC с ресурсом в 100к записей на ячейку.
А сложно ли выработать этот ресурс? На самом деле - несложно. И даже если исключить серверную сферу, где такой диск можно "съесть" за месяц, банально windows 7 + мало памяти + swap на таком диске - работать будет неплохо.. но довольно недолго. Не месяц конечно, но год это будет уже очень хорошо.
Поэтому эти диски хороши там, где много чтения и мало записи - кэш чтения, система без свопа, фильмы, игрушки...
суббота, 10 ноября 2012 г.
Наценка за бренд
Хороший пример наценки за бренд, на примере СХД (где всё очень печально):
http://forum.ixbt.com/topic.cgi?id=66:2005-110#3996
V3700
200GB 2.5In SAS SSD USD 7,405.00
400GB 2.5In SAS SSD USD 16,110.00
V7000
200GB 2.5-inch SSD (E-MLC) USD 9,544.00
400GB 2.5-inch SSD (E-MLC) USD 18,352.00
Такие же диски-оригиналы (SAS) стоят порой в 10-20 раз дешевле. С SSD ещё веселее: помимо самих расходов на устройство + бренд + всякие проверки совместимости сюда еще похоже включают упущенную прибыль: такие же диски на примере intel 710 серии:
Intel 710 Series ( Lyndonville) 200GB 2.5" SATA II eMLC Enterprise Solid State Disk SSDSA2BZ200G301 - OEM
790 и 9550 долларов. Чуть меньше чем на порядок. А чтобы люди не ставили такие же диски но без фирменных шильдиков - используется вендор-лок, и работают только "Сертифицированные" дорогие диски.
http://forum.ixbt.com/topic.cgi?id=66:2005-110#3996
V3700
200GB 2.5In SAS SSD USD 7,405.00
400GB 2.5In SAS SSD USD 16,110.00
V7000
200GB 2.5-inch SSD (E-MLC) USD 9,544.00
400GB 2.5-inch SSD (E-MLC) USD 18,352.00
Такие же диски-оригиналы (SAS) стоят порой в 10-20 раз дешевле. С SSD ещё веселее: помимо самих расходов на устройство + бренд + всякие проверки совместимости сюда еще похоже включают упущенную прибыль: такие же диски на примере intel 710 серии:
Intel 710 Series ( Lyndonville) 200GB 2.5" SATA II eMLC Enterprise Solid State Disk SSDSA2BZ200G301 - OEM
790 и 9550 долларов. Чуть меньше чем на порядок. А чтобы люди не ставили такие же диски но без фирменных шильдиков - используется вендор-лок, и работают только "Сертифицированные" дорогие диски.
воскресенье, 7 октября 2012 г.
DaaS
Довольно интересный вариант
http://www.activecloud.ru/ru/services/daas/
DaaS (Desktop-as-a-Service) — комплексное решение по построению инфраструктуры виртуальных рабочих столов на базе облачной платформы ActiveCloud. Вы сможете быстро развернуть рабочие места сотрудников, а ваши коллеги получат рабочее окружение и набор всех необходимых приложений удаленно через сеть Интернет, что обеспечит надежность, мобильность и безопасность IT-инфраструктуры.
Правда, тут предполагается только windows. Было бы хорошо еще сделать решение на базе linux - это было бы дешевле, но без таких пакетов как ms office.
Бывают варианты "рабочий стол в браузере", но отлаженных вариантов мне пока не встречалось.
http://www.activecloud.ru/ru/services/daas/
DaaS (Desktop-as-a-Service) — комплексное решение по построению инфраструктуры виртуальных рабочих столов на базе облачной платформы ActiveCloud. Вы сможете быстро развернуть рабочие места сотрудников, а ваши коллеги получат рабочее окружение и набор всех необходимых приложений удаленно через сеть Интернет, что обеспечит надежность, мобильность и безопасность IT-инфраструктуры.
Правда, тут предполагается только windows. Было бы хорошо еще сделать решение на базе linux - это было бы дешевле, но без таких пакетов как ms office.
Бывают варианты "рабочий стол в браузере", но отлаженных вариантов мне пока не встречалось.
вторник, 17 июля 2012 г.
Облака, за и против (2)
Несколько разверну заметку (1)
Казалось бы, полное дублирование оборудования, дорогие СХД, дорогие и быстрые технологии... И при этом оплата только по потреблению. Казалось бы, рай. Про настоящие и "маркетинговые" облака напишу в другой раз.
С момента зарождения облаков прошло уже несколько лет, появились отзывы.. И стало понятно, что у облаков тоже есть проблемы, просто эти проблемы другие. Что может быть с реальным сервером? Пропало питание, сгорел процессор, пробило память, выгорел порт в свиче, посыпался жесткий диск... 90% проблем касаются чисто технической стороны, подлежат предсказанию и принятию мер заранее. А также требуют обслуживания именно как оборудование.
В облаках проблемы другие. В основном это проблемы с СХД, потери связности, а также очень много - "человеческий фактор". Хороший пример -- clodo (линки ниже).
Плюс у облаков есть ряд проблем, которые все любят "опровергать", и которые на практике только многократно подтверждаются. (та же безопасность и linode), и одна из реальных главных проблем честного облака - крайне сложно предсказать расходы. День ддоса - и весь бюджет на 3 месяца вперёд съеден.
По всем ссылкам также читать комменты.
Selectel
2 облачные системы, спб-1 и спб-2. В спб-1 периодически выпадала СХД, ввели СПб-2 со своими косяками и багами. Главное отличие спб-2 в том, что там уже не 1 СХД, а несколько.
Проблемы есть, но в виде резерва нас оно устраивает полностью + поддержка масштабирования памяти (увы, от мин до макс не более х8, например 256мб-1гб). Самым дорогим ресурсом для нас выходит всё-таки диск, и это единственное, что масштабируется напильником и остановкой сервера, и оплата за выделение места + потребление иопс. В остальном настоящее облако.
Зимой (2011-2012) была проблема с тем, что их облако просто исчерпало лимиты масштабируемости, поэтому создание машин было приостановлено, и потом запущена система спб-2.
Прощай, Selectel
в комментах
Опять авария в облаке Selectel… Доколе?
Clodo
Вроде мегасистема с хранилищем на infiniband, на практике весьма проблемный.
Есть несколько ДЦ, в том числе в оверсан-меркурий, который даёт своё облако Scalaxy
Приключения с Clodo: про земной и заоблачный подход к работе
Clodo.ru и очередное загадочное падение
CLODO — опять лежим или нужно предупреждать заранее
Scalaxy
Особо не изучали: по отзывам, не очень стабильны и весьма дорогие.
О проблемах:
Облако cannot be read
Amazon
"Эталон" облаков, хотя он менее облачный чем даже селектел и представляет из себя просто виртуальную машину (VDS) с автомиграцией на новую ноду в случае чего. Диски тоже, оплата не за реально занятое место (EBS которые), а за выделенное место. Плюс все операции платные, хоть и крайне дешёвые. Но даже в таком виде есть знатные падения.
Рассказ о том, как молния «убила» облако Amazon. По отзывам, простой "супер надёжной системы с 99.9999% (вроде)" надёжностью составил порядка 5 суток.
Есть проблемы и помельче.
"Прямо как я недавно свалил со Scalaxy. Как раз-таки на Selectel. Имхо, так вечно бегать можно. У моего друга подобная неприятность случалась на AWS. Подумать только, сам Amazon, с их то ценами… Амазон, конечно, сам выслал нотификацию о проблеме, и предлагал компенсацию — но потерянная машина была просто тестовой средой, представляющей из себя просто свежеустановленный Debian с FTP+Nginx."
http://habrahabr.ru/post/145647/
"как человек, который амазон пользовал, скажу — там далеко не радужно.
и если виртуалка падает — амазон предлагает запустить новую.
диски надо? используйте persistent. ах, вы не подключали его? извините.
ах подключали, и не доступно? поднимайте snapshot.
ах, вы его не делали? извините, сами дураки.
ах, они не доступны? извините, или подождите и может станет доступным, или сами дураки что снапшоты не лили в другую зону."
http://habrahabr.ru/post/145112/
Rackspace
Считается конкурентом амазону, тоже весьма дорогим. Ссылками возможно дополню позднее.
Jira
У нас не сильно известен, но тут за славный факап "We've completely lost all your data":
"Проблемы случаются не только в России, перевел среду разработки на облачный хостинг: Task Management, Issue Tracker, Subversion, Builds, Wiki. На прошлой неделе в четверг у них все свалилось, к выходным обещали починить. В понедельник прислали письмо: We've completely lost all your data. хостинг к слову в Англии Jira.com"
http://habrahabr.ru/post/143056/#comment_4793925
Итог
Облака могут быть хороши, особенно на старте. Но они же могут съесть все бюджеты при любой ошибке или ддосе. И если с реальной железкой можно защититься, задублировав почти всё, то с облаками надо тоже дублироваться, но уже в другое облако, в другую страну, и лучше вообще другой компании. А также всегда делать бэкапы. Облако - не панацея, и не спасёт от умышленного удаления данных с автоматическим дублированием этого по всем зеркалам.
"3) облачная виртуализация — всего-лишь способ добиться высокой плотности размещения виртуалок на физике. Удобно для хостера, но никак не панацея для клиента."
http://habrahabr.ru/post/120303/#comment_3943417
По мере изучения отзывов стали попадаться вещи вроде "лежим 10 часов... уже 18 часов.. Потеряны деньги и репутация!". А можно вспомнить сбои в любимом всеми амазоне, где были падения на 5 дней. И небольшой вопрос тем, кто потом плачется про огромные потери: А что сделали лично ВЫ, чтобы не допустить этих самых простоев? "Ну вот сейчас всё поднимется, мы заберём проект, бэкапы и уйдём к другим". И тут уместно вспомнить клиентов макхоста, которым отдавали их сайты по 3 месяца.. hosting.ua, у которого ряд серверов просто сгорел, с данными.. Особенно смешно смотрятся фразы "подорвана репутация одного проекта, которую не за какие деньги теперь не восстановить, я делал компенсации и бонусы сколько мог своим пользователям за каждое ваше падение. Что мне теперь делать не представляю.". Видимо, теперь человек представляет как минимум 1 необходимое действие: бэкапы. И минимум в 2 места, а лучше в 3-4. Предполагаю, что после этого такие люди всё-таки начнут делать бэкапы. А у нас уже несколько лет для таких критичных сайтов есть ещё полная копия в горячем резерве, с репликацией баз master-slave с быстрым переключением днс на новое место. А для минимизации расходов - первое место свои железки, а второе как раз облака. И когда в очередной раз облака отваливаются - ничего страшного, это только зеркало. Ну и бэкапы в несколько мест, включая амазон.
Казалось бы, полное дублирование оборудования, дорогие СХД, дорогие и быстрые технологии... И при этом оплата только по потреблению. Казалось бы, рай. Про настоящие и "маркетинговые" облака напишу в другой раз.
С момента зарождения облаков прошло уже несколько лет, появились отзывы.. И стало понятно, что у облаков тоже есть проблемы, просто эти проблемы другие. Что может быть с реальным сервером? Пропало питание, сгорел процессор, пробило память, выгорел порт в свиче, посыпался жесткий диск... 90% проблем касаются чисто технической стороны, подлежат предсказанию и принятию мер заранее. А также требуют обслуживания именно как оборудование.
В облаках проблемы другие. В основном это проблемы с СХД, потери связности, а также очень много - "человеческий фактор". Хороший пример -- clodo (линки ниже).
Плюс у облаков есть ряд проблем, которые все любят "опровергать", и которые на практике только многократно подтверждаются. (та же безопасность и linode), и одна из реальных главных проблем честного облака - крайне сложно предсказать расходы. День ддоса - и весь бюджет на 3 месяца вперёд съеден.
По всем ссылкам также читать комменты.
Selectel
2 облачные системы, спб-1 и спб-2. В спб-1 периодически выпадала СХД, ввели СПб-2 со своими косяками и багами. Главное отличие спб-2 в том, что там уже не 1 СХД, а несколько.
Проблемы есть, но в виде резерва нас оно устраивает полностью + поддержка масштабирования памяти (увы, от мин до макс не более х8, например 256мб-1гб). Самым дорогим ресурсом для нас выходит всё-таки диск, и это единственное, что масштабируется напильником и остановкой сервера, и оплата за выделение места + потребление иопс. В остальном настоящее облако.
Зимой (2011-2012) была проблема с тем, что их облако просто исчерпало лимиты масштабируемости, поэтому создание машин было приостановлено, и потом запущена система спб-2.
Прощай, Selectel
в комментах
Опять авария в облаке Selectel… Доколе?
Clodo
Вроде мегасистема с хранилищем на infiniband, на практике весьма проблемный.
Есть несколько ДЦ, в том числе в оверсан-меркурий, который даёт своё облако Scalaxy
Приключения с Clodo: про земной и заоблачный подход к работе
Clodo.ru и очередное загадочное падение
CLODO — опять лежим или нужно предупреждать заранее
Scalaxy
Особо не изучали: по отзывам, не очень стабильны и весьма дорогие.
О проблемах:
Облако cannot be read
Amazon
"Эталон" облаков, хотя он менее облачный чем даже селектел и представляет из себя просто виртуальную машину (VDS) с автомиграцией на новую ноду в случае чего. Диски тоже, оплата не за реально занятое место (EBS которые), а за выделенное место. Плюс все операции платные, хоть и крайне дешёвые. Но даже в таком виде есть знатные падения.
Рассказ о том, как молния «убила» облако Amazon. По отзывам, простой "супер надёжной системы с 99.9999% (вроде)" надёжностью составил порядка 5 суток.
Есть проблемы и помельче.
"Прямо как я недавно свалил со Scalaxy. Как раз-таки на Selectel. Имхо, так вечно бегать можно. У моего друга подобная неприятность случалась на AWS. Подумать только, сам Amazon, с их то ценами… Амазон, конечно, сам выслал нотификацию о проблеме, и предлагал компенсацию — но потерянная машина была просто тестовой средой, представляющей из себя просто свежеустановленный Debian с FTP+Nginx."
http://habrahabr.ru/post/145647/
"как человек, который амазон пользовал, скажу — там далеко не радужно.
и если виртуалка падает — амазон предлагает запустить новую.
диски надо? используйте persistent. ах, вы не подключали его? извините.
ах подключали, и не доступно? поднимайте snapshot.
ах, вы его не делали? извините, сами дураки.
ах, они не доступны? извините, или подождите и может станет доступным, или сами дураки что снапшоты не лили в другую зону."
http://habrahabr.ru/post/145112/
Rackspace
Считается конкурентом амазону, тоже весьма дорогим. Ссылками возможно дополню позднее.
Jira
У нас не сильно известен, но тут за славный факап "We've completely lost all your data":
"Проблемы случаются не только в России, перевел среду разработки на облачный хостинг: Task Management, Issue Tracker, Subversion, Builds, Wiki. На прошлой неделе в четверг у них все свалилось, к выходным обещали починить. В понедельник прислали письмо: We've completely lost all your data. хостинг к слову в Англии Jira.com"
http://habrahabr.ru/post/143056/#comment_4793925
Итог
Облака могут быть хороши, особенно на старте. Но они же могут съесть все бюджеты при любой ошибке или ддосе. И если с реальной железкой можно защититься, задублировав почти всё, то с облаками надо тоже дублироваться, но уже в другое облако, в другую страну, и лучше вообще другой компании. А также всегда делать бэкапы. Облако - не панацея, и не спасёт от умышленного удаления данных с автоматическим дублированием этого по всем зеркалам.
"3) облачная виртуализация — всего-лишь способ добиться высокой плотности размещения виртуалок на физике. Удобно для хостера, но никак не панацея для клиента."
http://habrahabr.ru/post/120303/#comment_3943417
По мере изучения отзывов стали попадаться вещи вроде "лежим 10 часов... уже 18 часов.. Потеряны деньги и репутация!". А можно вспомнить сбои в любимом всеми амазоне, где были падения на 5 дней. И небольшой вопрос тем, кто потом плачется про огромные потери: А что сделали лично ВЫ, чтобы не допустить этих самых простоев? "Ну вот сейчас всё поднимется, мы заберём проект, бэкапы и уйдём к другим". И тут уместно вспомнить клиентов макхоста, которым отдавали их сайты по 3 месяца.. hosting.ua, у которого ряд серверов просто сгорел, с данными.. Особенно смешно смотрятся фразы "подорвана репутация одного проекта, которую не за какие деньги теперь не восстановить, я делал компенсации и бонусы сколько мог своим пользователям за каждое ваше падение. Что мне теперь делать не представляю.". Видимо, теперь человек представляет как минимум 1 необходимое действие: бэкапы. И минимум в 2 места, а лучше в 3-4. Предполагаю, что после этого такие люди всё-таки начнут делать бэкапы. А у нас уже несколько лет для таких критичных сайтов есть ещё полная копия в горячем резерве, с репликацией баз master-slave с быстрым переключением днс на новое место. А для минимизации расходов - первое место свои железки, а второе как раз облака. И когда в очередной раз облака отваливаются - ничего страшного, это только зеркало. Ну и бэкапы в несколько мест, включая амазон.
пятница, 27 января 2012 г.
По железке под задачу или виртуализировать?
Периодически встаёт выбор: купить под каждую задачу по железке или виртуализироваться и собрать все задачи на меньшем количестве машин. Ведь, как это отмечается во многих брошюрах и статьях, среднестатистический сервер загружен лишь на 10%. Но там же обычно забывают сказать, что виртуализация по хорошему будет требовать хорошего железа, SAN, внешний SAS/FC, хотя иногда пойдёт и iSCSI. Плюс свичи несколько другой стоимости, особенно FC, плюс карты, оптика.. А также всё это будет тоже требовать обслуживания, и уровень знаний нужен более серьёзный, чем для пачки серверов всё-на-себе. И отказ инфраструктуры будет иметь более печальные последствия, поэтому нужно будет всё дублировать, это в лучшем случае стоимость х2, а зачастую и больше.
Поэтому для крупных компаний - да, железа будет меньше, его загруженность больше, админам работы станет чуть побольше в плане обслуживания софта - надо хост-системы обслуживать + виртуальных серверов обычно становится даже больше, поскольку создание новой виртуалки - процесс довольно простой, а выделение по машине под каждый сервис повышает надёжность и управляемость системы. Хотя если меньше железа - меньше нужно обслуживания аппаратной части, но уровень "дежурный инженер" обычно ниже и порой весьма дешевле комплекта профессионалов сеть-виртуализаторы-админы_виртуалок.
Для мелких компаний, у которых "сервера" это старые снятые с эксплуатации персоналки - абсолютно невыгодно, потому что надёжность старого железа, особенно уровня персоналок, очень низкая, а покупать новое железо выходит крайне дорого. Собирать же подобные системы из старья - никто никаких гарантий дать не может, железо будет не валидировано, нет SAS, ECC и прочих необходимых в контексте повышенной нагрузки возможностей. И если раньше отказ 1 железки грозил отказом 1 сервиса (телефонии например), то с виртуализацией, когда всё на 1 железке - ляжет ВСЁ. А если откажет физически - на восстановление может уйти и неделя, и хорошо если были бэкапы.
Ну и уровень админа должен быть более высоким, то есть приходящего админа скорее всего уже будет недостаточно, если простой должен быть менее суток.
Самая интересная категория тут - средние компании, у которых уже есть админы, есть много разнотипного железа, которое постоянно требует обслуживания, выходом их строя старого железа, которому уже по 10 лет и его авральной заменой, полный хаос в фирмах, софте, технологиях... Хотя парк железа скорее всего будет подлежать модернизации и приведению к неким стандартам, в частности вендорам: такие интересные вещи как live migration требуют не просто однотипного железа, а желательно полностью совпадающего: на разном железе может и получится смигрировать, но ВДРУГ всё может упасть из-за мелких нюансов. С большой вероятностью сеть потребует перевода на новые свичи, внедрение 10гбит итд.
Ну и надо учитывать, что "средняя IT-компания" это совсем не тоже самое, что какая-нибудь лесопилка, пусть и с парой сотен/тысяч рабочих. Также надо смотреть на длительность возможного простоя и завязанность техпроцессов на работу информационных систем.
Поэтому для крупных компаний - да, железа будет меньше, его загруженность больше, админам работы станет чуть побольше в плане обслуживания софта - надо хост-системы обслуживать + виртуальных серверов обычно становится даже больше, поскольку создание новой виртуалки - процесс довольно простой, а выделение по машине под каждый сервис повышает надёжность и управляемость системы. Хотя если меньше железа - меньше нужно обслуживания аппаратной части, но уровень "дежурный инженер" обычно ниже и порой весьма дешевле комплекта профессионалов сеть-виртуализаторы-админы_виртуалок.
Для мелких компаний, у которых "сервера" это старые снятые с эксплуатации персоналки - абсолютно невыгодно, потому что надёжность старого железа, особенно уровня персоналок, очень низкая, а покупать новое железо выходит крайне дорого. Собирать же подобные системы из старья - никто никаких гарантий дать не может, железо будет не валидировано, нет SAS, ECC и прочих необходимых в контексте повышенной нагрузки возможностей. И если раньше отказ 1 железки грозил отказом 1 сервиса (телефонии например), то с виртуализацией, когда всё на 1 железке - ляжет ВСЁ. А если откажет физически - на восстановление может уйти и неделя, и хорошо если были бэкапы.
Ну и уровень админа должен быть более высоким, то есть приходящего админа скорее всего уже будет недостаточно, если простой должен быть менее суток.
Самая интересная категория тут - средние компании, у которых уже есть админы, есть много разнотипного железа, которое постоянно требует обслуживания, выходом их строя старого железа, которому уже по 10 лет и его авральной заменой, полный хаос в фирмах, софте, технологиях... Хотя парк железа скорее всего будет подлежать модернизации и приведению к неким стандартам, в частности вендорам: такие интересные вещи как live migration требуют не просто однотипного железа, а желательно полностью совпадающего: на разном железе может и получится смигрировать, но ВДРУГ всё может упасть из-за мелких нюансов. С большой вероятностью сеть потребует перевода на новые свичи, внедрение 10гбит итд.
Ну и надо учитывать, что "средняя IT-компания" это совсем не тоже самое, что какая-нибудь лесопилка, пусть и с парой сотен/тысяч рабочих. Также надо смотреть на длительность возможного простоя и завязанность техпроцессов на работу информационных систем.
четверг, 29 декабря 2011 г.
12 заблуждений сетевого администратора
http://habrahabr.ru/blogs/sysadm/122145/
1. Комментировать изменения в конфигах — не нужно. На память вы не жалуетесь, amiright?
2. QoS — не нужен. Всегда проще купить канал, заведомо превышающий потребности компании.
3. Бессмысленно проверять возможность удаленного управления оборудованием перед отправкой в удаленный офис.
Вы — профессионал и не могли ошибиться в настройке такой элементарной функции.
4. Устная договоренность с сетевиками ISP является полноценной разновидностью SLA.
5. Сертификация — незначима. Экзамены всегда можно сдать с помощью дампов.
6. Прямой доступ через serial к оборудованию — анахронизм. IP-интерфейс — удобнее.
7. С системой мониторинга должен работать соответствующий отдел. Сотрудники там опытные, разберутся, что к чему.
8. Во внутренних маршрутах никогда не будет более 15 хопов.
9. Остановка работы компании из-за разрыва линка со стороны ISP — не ваша вина.
10. Одного гигабитного линка будет достаточно для всех.
11. Никто никогда не соединит 2 сетевые розетки патчкордом. Зачем это делать?
12. Какой смысл ставить 2 маршрутизатора в ядре, если загрузка одного менее 50%?
Со многим согласен, в частности "com-порт не нужен". Действительно, зачем нам ком-порт, если мы угробили например прошивку и нам нужно её восстановить, для чего надо попасть в pre-boot mode? Или просто убили конфиг и айпи нет ни на одном интерфейсе. (если кто не понял - я это считаю заблуждением).
Хотя похоже, скоро может стать стандартом usb, на том же huawei уже есть клиентский порт (miniusb). Пока никак не заявленный, но как сказали на их тренинге, что-то на тему перехода было. При этом не отменяя com. Хотя смысл непонятен:
1) для кома никаких драйверов не надо. Подключайтся любым терминалом, выставляй скорость порта и работай. Для усб - вышла винда 9, а эта железка больше не поддерживается. Всё, в пролёте. Плюс очень вероятная закрытость этих самых драйверов, что приведёт к сложности их отладки и на ранных версиях - возможны бсоды на виндовых управляющих машинах. Итд.
2) Насколько я знаю, макс длина для ком-хвоста 100м. Для усб - макс 5 без активных повторителей. А 20 повторителей работать не будут.
3) во многих чипах com аппаратный, что не грузит и без того обычно слабый проц плюс его можно включать в режиме отладки. Тогда как usb всегда программный.
Минус кома только 1 - низкая скорость. Обычно требуется 9600, и залить по нему прошивку пусть в 20мб - процесс, который может растянуться на часы. usb 2.0 - 30мб/с и упираемся только в скорость флэша.
По остальным вопросам это скорее просто "мало жизненного опыта". А кольца у меня были и в начале моей карьеры в сети на 20 машин. Не по моей вине конечно, кто-то убрал "лишний хвост", вроде уборщица. Но там начальство было очень жадным, а управляемые свичи очень дорогими.
1. Комментировать изменения в конфигах — не нужно. На память вы не жалуетесь, amiright?
2. QoS — не нужен. Всегда проще купить канал, заведомо превышающий потребности компании.
3. Бессмысленно проверять возможность удаленного управления оборудованием перед отправкой в удаленный офис.
Вы — профессионал и не могли ошибиться в настройке такой элементарной функции.
4. Устная договоренность с сетевиками ISP является полноценной разновидностью SLA.
5. Сертификация — незначима. Экзамены всегда можно сдать с помощью дампов.
6. Прямой доступ через serial к оборудованию — анахронизм. IP-интерфейс — удобнее.
7. С системой мониторинга должен работать соответствующий отдел. Сотрудники там опытные, разберутся, что к чему.
8. Во внутренних маршрутах никогда не будет более 15 хопов.
9. Остановка работы компании из-за разрыва линка со стороны ISP — не ваша вина.
10. Одного гигабитного линка будет достаточно для всех.
11. Никто никогда не соединит 2 сетевые розетки патчкордом. Зачем это делать?
12. Какой смысл ставить 2 маршрутизатора в ядре, если загрузка одного менее 50%?
Со многим согласен, в частности "com-порт не нужен". Действительно, зачем нам ком-порт, если мы угробили например прошивку и нам нужно её восстановить, для чего надо попасть в pre-boot mode? Или просто убили конфиг и айпи нет ни на одном интерфейсе. (если кто не понял - я это считаю заблуждением).
Хотя похоже, скоро может стать стандартом usb, на том же huawei уже есть клиентский порт (miniusb). Пока никак не заявленный, но как сказали на их тренинге, что-то на тему перехода было. При этом не отменяя com. Хотя смысл непонятен:
1) для кома никаких драйверов не надо. Подключайтся любым терминалом, выставляй скорость порта и работай. Для усб - вышла винда 9, а эта железка больше не поддерживается. Всё, в пролёте. Плюс очень вероятная закрытость этих самых драйверов, что приведёт к сложности их отладки и на ранных версиях - возможны бсоды на виндовых управляющих машинах. Итд.
2) Насколько я знаю, макс длина для ком-хвоста 100м. Для усб - макс 5 без активных повторителей. А 20 повторителей работать не будут.
3) во многих чипах com аппаратный, что не грузит и без того обычно слабый проц плюс его можно включать в режиме отладки. Тогда как usb всегда программный.
Минус кома только 1 - низкая скорость. Обычно требуется 9600, и залить по нему прошивку пусть в 20мб - процесс, который может растянуться на часы. usb 2.0 - 30мб/с и упираемся только в скорость флэша.
По остальным вопросам это скорее просто "мало жизненного опыта". А кольца у меня были и в начале моей карьеры в сети на 20 машин. Не по моей вине конечно, кто-то убрал "лишний хвост", вроде уборщица. Но там начальство было очень жадным, а управляемые свичи очень дорогими.
среда, 16 ноября 2011 г.
аутсорс
http://juick.com/101O101/753410
как способ работы с идиотами:
заключаем договор. отвозим к заказчику свой программно-аппаратный комплекс (линукс коробка с системой мониторинга и оповещения), настраиваем на площадке клиента интернет для этой железки. берем бабло ежемесячно. при этом в договоре указываем, что железку вскрывать нельзя, ничего с ней делать нельзя, жалазка эта наша, мы её не продаем.
у мало компетентного заказчика есть твердая увереность: все люди идиоты, просто самые хитрые из них берут много денег.
при виде нашей железки подсознательно формируется ощущение, что вот так выглядит будущее, что это инновация и панацея от его бед. разрывать договор страшно, потому что волшебную коробку заберут. :)
...
Любая компания, которая соприкосается с IT в России, пытается экономить на этом секторе, более того, зачастую не понимая, а зачем нужны все эти люди. Причём, палка о двух концов, первый конец — "почему всё постоянно ломается?!", второй конец — "а зачем вы все нужны, если всё работает?!". Баланса не бывает. По большому счёту, IT-инженер должен воплощать в себе волшебника, что постоянно шариком мечется между первым и вторым концом, почти падая со второго. Студенты-админы со временем вырастают в серьезных инженеров, поднимая глубоко запущенные проекты, и уходят, который год. Уже с медалями, в другие страны. А IT-бизнес Росии так до сих пор ничему и не может научиться. Ведь менеджерам со степенью MBA невдомёк, что надо беречь кадры, ибо завтра на их место придут те, которые сделают моментально первый конец палки на недели или даже месяцы.
(орфография сохранена)
как способ работы с идиотами:
заключаем договор. отвозим к заказчику свой программно-аппаратный комплекс (линукс коробка с системой мониторинга и оповещения), настраиваем на площадке клиента интернет для этой железки. берем бабло ежемесячно. при этом в договоре указываем, что железку вскрывать нельзя, ничего с ней делать нельзя, жалазка эта наша, мы её не продаем.
у мало компетентного заказчика есть твердая увереность: все люди идиоты, просто самые хитрые из них берут много денег.
при виде нашей железки подсознательно формируется ощущение, что вот так выглядит будущее, что это инновация и панацея от его бед. разрывать договор страшно, потому что волшебную коробку заберут. :)
...
Любая компания, которая соприкосается с IT в России, пытается экономить на этом секторе, более того, зачастую не понимая, а зачем нужны все эти люди. Причём, палка о двух концов, первый конец — "почему всё постоянно ломается?!", второй конец — "а зачем вы все нужны, если всё работает?!". Баланса не бывает. По большому счёту, IT-инженер должен воплощать в себе волшебника, что постоянно шариком мечется между первым и вторым концом, почти падая со второго. Студенты-админы со временем вырастают в серьезных инженеров, поднимая глубоко запущенные проекты, и уходят, который год. Уже с медалями, в другие страны. А IT-бизнес Росии так до сих пор ничему и не может научиться. Ведь менеджерам со степенью MBA невдомёк, что надо беречь кадры, ибо завтра на их место придут те, которые сделают моментально первый конец палки на недели или даже месяцы.
(орфография сохранена)
суббота, 5 ноября 2011 г.
Linux на десктопах
Использую линукс дома, были попытки использовать на работе...
Итог: до сих пор для массового пользователя непригодно. Для небольших компаний непригодно. Железо требуется мощнее, чем для винды, даже 7.
Итог: до сих пор для массового пользователя непригодно. Для небольших компаний непригодно. Железо требуется мощнее, чем для винды, даже 7.
четверг, 13 октября 2011 г.
Intel осваивает модель платежей donate (donat)?
Обнаружил на 3dnews статью Core i3-2332M: заплати и получи плюс 400 МГц и больше кеша. Но данная система довольно давно известна игрокам под названием "donate" - чтобы получить круче, плати. (суть: платишь баблос, всё больше и больше, получаешь всё меньше и меньше)
В идеале - интел станет раздавать процы с 1 ядром 1ГГц, 128к кэша, и можно ступенчато апать до топовых. Ну или продавать по себестоимости кристалла. Впрочем, это очень остро поставит вопрос о разлочке таких ядер программно или аппаратно, и может быть как очень прибыльным, так и весьма убыточным вариантом продаж.
В идеале - интел станет раздавать процы с 1 ядром 1ГГц, 128к кэша, и можно ступенчато апать до топовых. Ну или продавать по себестоимости кристалла. Впрочем, это очень остро поставит вопрос о разлочке таких ядер программно или аппаратно, и может быть как очень прибыльным, так и весьма убыточным вариантом продаж.
Подписаться на:
Сообщения (Atom)